Come mappare i rischi operativi per prepararsi all’imprevisto

Nel Facility Management l’imprevisto non è un’eccezione: è parte del lavoro. La differenza tra un’organizzazione che regge e una che va in crisi non è “se” capita qualcosa, ma quanto sei preparato a gestirlo senza perdere controllo su sicurezza, continuità del servizio e responsabilità contrattuali.

Mappare i rischi operativi non significa fare un documento da audit che nessuno usa. Significa costruire una mappa pratica: cosa può andare storto, che impatto reale ha (persone, impianti, servizio, penali), quanto velocemente devi reagire, e quali contromisure minime devono essere pronte prima. Il focus qui è operativo, coerente con i post precedenti: pianificazione realistica, capacità finita, logistica sul campo, informatica utile, e tracciabilità nel CMMS.

Qual è la differenza tra rischio operativo e “problema tecnico”?

Un problema tecnico è un guasto o un’anomalia. Un rischio operativo è la combinazione tra evento e incapacità di gestirlo bene: mancanza di accesso, mancanza di ricambi, mancanza di strumenti, assenza del tecnico giusto, catena fornitori non governata, sistemi informativi non disponibili, o perimetro contrattuale ambiguo.

Molti guasti si risolvono anche con procedure non perfette. Ma quando un guasto incontra un collo di bottiglia organizzativo, allora diventa evento critico: tempi lunghi, escalation, contenziosi, e spesso impatti su sicurezza.

Da dove parto per mappare rischi senza farmi travolgere dalla complessità?

Parti dai servizi e dagli impianti che, se degradano, generano conseguenze immediate: safety (antincendio, evacuazione, accessi), continuità (energia, UPS/GE, centrali frigo/caldaie), processi core (aree critiche di ospedali/fabbriche), e vincoli legali/normativi (verifiche periodiche, conformità impianti).

Poi parti dalla realtà dei tuoi incidenti: storico guasti, near-miss, richieste urgenti ricorrenti, interventi ripetuti, e cause tipiche di ritardo (accesso, ricambi, attrezzature, fornitori). Il rischio operativo più importante è quasi sempre un rischio già visto, solo non formalizzato.

Qual è la domanda corretta per ogni rischio: “cosa succede” o “cosa si ferma”?

La domanda utile è “cosa si ferma davvero e in quanto tempo”. Non basta dire “si guasta il componente X”: devi capire cosa smetti di garantire (comfort, processo, conservazione farmaci, continuità produzione), in quali aree, e con quale tempo di tolleranza prima che diventi incidente o penale.

Questa logica ti obbliga a ragionare per conseguenze e tempi di reazione, non per componenti. È l’unico modo per costruire priorità operative che reggano sotto stress.

Come classifico i rischi in modo pragmatico senza inventare matrici infinite?

Usa tre dimensioni, poche e chiare: impatto, urgenza e governabilità. L’impatto riguarda persone/servizio/costi/contratto. L’urgenza è il tempo massimo entro cui devi attivare una risposta (minuti, ore, giorni). La governabilità è quanto dipendi da fattori esterni (fornitori, accessi, ricambi, sistemi informativi).

Questa terza dimensione è spesso ignorata, ma nel FM è decisiva: due guasti tecnicamente simili possono avere rischi opposti se uno lo governi internamente e l’altro dipende da vendor che entra solo da remoto o con tempi lunghi.

Quali categorie di rischio operativo devo includere per non dimenticare i colli di bottiglia “non tecnici”?

Devi includere rischi di processo, non solo rischi impiantistici. Per esempio: indisponibilità del CMMS o dei canali di segnalazione, indisponibilità del controllo accessi o delle chiavi, indisponibilità di attrezzature critiche e strumenti calibrati, mancanza ricambi e tempi supply chain, assenza di personale o coperture turni, e rischi legati a fornitori (subappalti, accesso remoto, reperibilità).

Queste categorie sono quelle che trasformano un guasto gestibile in un evento critico. Se non le mappi, ti illudi che basti “avere impianti ridondanti”, ma poi ti fermi perché manca una chiave o una termocamera.

Come collego i rischi ai dati e ai workflow del CMMS per renderli gestibili e non teorici?

Ogni rischio significativo deve tradursi in almeno una regola o un attributo nel sistema: criticità dell’asset o del servizio, procedure di escalation, check-list di evidenze, causali di sospensione SLA, e percorsi di autorizzazione (extra-canone, permessi, accessi). Se il rischio resta “in un file”, non cambia il comportamento operativo.

Questo si collega ai post su routing e dispacciamento: un rischio ad alta urgenza deve attivare preassegnazione corretta e notifica immediata con escalation. Un rischio ad alta dipendenza (es. ricambi) deve avere workflow che traccia attese e follow-up, altrimenti diventa backlog invisibile.

Come tratto il tema “capacità finita” dentro la mappa rischi?

La capacità finita è un rischio in sé: se pianifichi saturando i tecnici, qualunque imprevisto diventa crisi. Quindi nella mappa devi includere rischi legati al carico: picchi di MP ingestibili, sovrapposizioni su siti vincolati, e dipendenza da poche persone chiave.

Operativamente, il controllo è quello discusso nel post sul Gantt: revisione regolare del calendario prima di generare ordini MP e livellamento tramite spostamento date. Questa non è solo “buona pianificazione”: è una misura di riduzione rischio.

Come mappo i rischi legati alla logistica sul campo ?

Qui devi essere concreto: quali aree generano più tempo perso? quali siti sono lontani o difficili da accedere? quali strumenti critici sono condivisi? quali veicoli mancano o sono male distribuiti? Sono rischi operativi perché allungano i tempi di risposta e aumentano probabilità di sforare SLA.

Le contromisure minime sono quelle che abbiamo già trattato: pacchetti per zona, componenti virtuali, gestione pool attrezzature con assegnazioni e calibrazione, e gestione flotte con pianificazione per cluster. Se non le colleghi al rischio, restano “ottimizzazioni”; se le colleghi, diventano controlli.

Come gestisco i rischi legati ai fornitori ?

Devi mappare dove dipendi dai fornitori per competenze, accesso remoto, ricambi proprietari e configurazioni. Poi devi trasformare questa dipendenza in regole contrattuali e operative: reperibilità, canali di attivazione, tempi di intervento, logging accessi (dove applicabile), e procedure in caso di indisponibilità.

Un rischio tipico è il “single vendor bottleneck”: un impianto critico gestito da un solo soggetto. Se quel fornitore non risponde, tu sei fermo. La mappa rischi deve rendere visibili queste dipendenze e imporre almeno un piano di emergenza.

Come verifico che la mappa rischi sia vera, cioè che funzioni quando serve?

Con prove semplici e mirate, non con esercizi teatrali. Fai tentativi su scenari reali: guasto impianto critico in orario notturno, area non accessibile, ricambio mancante, CMMS non disponibile, fornitore non raggiungibile. Per ogni scenario verifica tre cose: chi decide, chi interviene, e quali informazioni servono.

Poi fai un check fisico: accesso ai locali tecnici, disponibilità strumenti, presenza schemi essenziali, e procedure di emergenza realistiche. La resilienza si verifica nei locali tecnici e nei telefoni che squillano, non nei PDF.

Come mantengo aggiornata la mappa rischi senza farla diventare burocrazia?

Deve aggiornarsi attraverso l’operatività: ogni incidente serio, ogni near-miss, ogni ritardo con causa ricorrente deve generare una revisione. Non serve farlo ogni settimana, ma serve una cadenza regolare (trimestrale o semestrale) e un owner chiaro.

E soprattutto: ogni aggiornamento deve produrre una modifica concreta, anche piccola, nel sistema o nel processo. Se aggiorni la mappa ma non cambi nulla, stai solo scrivendo.

Conclusioni

Mappare i rischi operativi significa prepararsi all’imprevisto con strumenti pratici: capire cosa si ferma e in quanto tempo, identificare colli di bottiglia non tecnici (accessi, ricambi, strumenti, fornitori, sistemi informativi), e trasformare le contromisure in regole e workflow nel CMMS. Senza questa traduzione, la mappa resta teoria.