Cosa devo tracciare sempre nel CAFM/CMMS per evitare discussioni e scaricabarile?

Premesse

Cosa succede quando si smette di andare d’amore e d’accordo con i propri fornitori? Entrare in contestazioni è sempre una fase stressante per tutti e può sfociare in cause e grandi problemi economici. Se vuoi evitare discussioni infinite, contestazioni sugli SLA e lo scaricabarile tra committente, FM, manutentori specialisti e subappaltatori, devi accettare una regola semplice: nel CAFM/CMMS non “si lavora”, nel CAFM/CMMS si prova che si è lavorato, con dati che devono essere incontestabili. Il sistema non serve a raccontare una storia: serve a ricostruire i fatti, in modo ripetibile, auditabile e contrattualmente difendibile.

Il trucco non è tracciare “tutto”, ma tracciare sempre le stesse cose, con definizioni univoche, campi obbligatori sensati e workflow che impediscono di chiudere attività senza evidenze. Questo post è operativo: cosa rendere non negoziabile nel tracciamento, e cosa invece è opzionale o può stare fuori.

Qual è l’errore che genera più contenziosi: dati “narrativi” e campi lasciati liberi?

Il contenzioso nasce quando il sistema contiene testo libero al posto di dati strutturati: “intervento eseguito”, “tutto ok”, “impianto non accessibile”. Frasi così non dimostrano niente, perché non definiscono quando, da chi, con che esito misurabile, con quali vincoli e con quali evidenze.

Devi quindi progettare il CAFM/CMMS come una macchina che produce record verificabili: timestamp, responsabilità, stati, codici causa, esiti standard, allegati obbligatori quando serve, e soprattutto regole che distinguono indisponibilità del sito, indisponibilità dell’asset, e indisponibilità del fornitore. Se non separi questi casi, ogni guasto diventa un ping-pong.

Che cosa devo rendere “a prova di audit” in qualunque ticket o ordine di lavoro?

Ogni ticket/WO deve consentire a un terzo (non coinvolto) di ricostruire l’evento senza telefonate. Per riuscirci servono sempre: identificazione univoca, localizzazione non ambigua, orari chiave, attori coinvolti, classificazione del problema e un esito verificabile.

Se una di queste parti manca, la discussione è inevitabile: perché non sai se l’intervento era nel perimetro, se era in SLA, se l’accesso era possibile, se la diagnosi era corretta, se l’asset era quello giusto, e se la chiusura è “risolto” o “ripristinato provvisoriamente”.

Quali identificativi non devono mai mancare (e come evitare codici che cambiano)?

Devi avere sempre un ID univoco del record (ticket/WO) e un ID univoco dell’asset o della location servita. L’errore tipico è usare descrizioni (“Pompa antincendio piano -1”) o codici non governati (“AHU-01” che poi diventa “UTA-1” in un’altra base dati). Queste cose esplodono appena cambi fornitore o riorganizzi siti.

La regola operativa è: l’asset ID deve essere stabile, gestito da un master (EAM/CAFM) e non dipendere da come lo chiama il tecnico. Nel CMMS puoi mostrare anche un “alias” leggibile, ma nei log devi avere sempre la chiave stabile. Stessa cosa per location: struttura gerarchica codificata (sito–edificio–piano–zona–locale/area) e non solo testo libero.

Quali timestamp devo tracciare sempre per rendere gli SLA non discutibili?

La maggior parte delle discussioni SLA nasce da un solo fatto: non è chiaro quando parte il tempo e quando si ferma. Quindi devi tracciare sempre, con timestamp automatici e non editabili dove possibile: creazione segnalazione, presa in carico, arrivo on-site (o inizio diagnosi remota se contrattualmente ammessa), inizio lavorazione, ripristino del servizio, chiusura amministrativa, e eventuale riapertura.

In parallelo devi tracciare gli “stop the clock” con causali codificate: attesa accesso, attesa ricambi, attesa approvazione, indisponibilità impianto per vincoli di sicurezza o produzione. Se non hai queste sospensioni tracciate, l’SLA diventa una discussione di opinioni, non di fatti.

Come devo tracciare responsabilità e passaggi di mano senza creare buchi?

Ogni passaggio di stato deve avere un responsabile assegnato e un motivo. I buchi nascono quando un ticket “rimbalza” tra gruppi senza log, o quando si usa lo stato “in lavorazione” per tutto, per settimane.

Serve un set minimo di stati coerenti e pochi, ma con semantica contrattuale chiara: aperto, assegnato, in diagnosi, in esecuzione, in attesa (con causale), ripristinato, chiuso, annullato (con motivazione). E ogni cambio stato deve registrare chi l’ha fatto e quando. Se il fornitore non vuole “essere misurato”, proverà a tenere tutto in stati ambigui: il sistema deve impedirlo.

Quali campi di classificazione devo imporre per evitare “non è competenza mia”?

Per evitare lo scaricabarile devi codificare: tipo richiesta (guasto, richiesta utente, ispezione, migliorativa, verifica periodica), disciplina (elettrico, meccanico, edile, speciali), categoria servizio (coerente col capitolato), criticità/priorità (non solo “alta”), e soprattutto “causa radice” o almeno “causa primaria” a chiusura.

La causa non deve essere un romanzo: deve essere un elenco controllato, tarato sul tuo parco impianti e sui contratti. Per esempio, distinguere chiaramente guasto reale, falso allarme, uso improprio, mancanza alimentazione, componente usurato, setpoint/parametro errato, sensore guasto, problema di rete/supervisione. Senza questi codici, ogni guasto diventa responsabilità di qualcun altro “a sensazione”.

Quali evidenze devo pretendere sempre (e quando foto e misure diventano obbligatorie)?

Le evidenze non servono per “controllare il manutentore”: servono per chiudere dispute. Devono essere proporzionate. Non ha senso chiedere 10 foto per cambiare una lampada, ma ha senso renderle obbligatorie su asset critici, su ripristini provvisori, su attività a rischio contestazione, e su interventi che impattano sicurezza o compliance.

Operativamente, imposta regole del tipo: su guasti critici e su ripristini temporanei serve almeno una foto prima/dopo o screenshot (se attività digitale), un valore misurato quando applicabile (pressione, temperatura, assorbimento, differenziale filtri, ecc.), e l’indicazione esplicita del “test di funzionamento” eseguito. Se non esiste un test dichiarato, la chiusura “risolto” è solo una parola.

Come devo tracciare accesso al sito e permessi per evitare che diventi la scusa universale?

“Non accessibile” è la scusa più abusata. Devi quindi tracciare accesso come evento: richiesta accesso, autorizzazione, finestra temporale, nominativi, e soprattutto esito (accesso effettuato sì/no) con motivo codificato se no. Se l’accesso dipende dal committente (es. aree sterili, produzione, laboratori), questo va tracciato come sospensione SLA con prova.

In siti complessi (ospedali, fabbriche) serve anche tracciare vincoli di sicurezza: permessi di lavoro, lockout/tagout, lavori in quota, ambienti confinati. Non devi mettere tutto nel CMMS come documento completo, ma devi almeno registrare l’ID del permesso e la sua validità, altrimenti in caso di incidente o contestazione sei scoperto.

Come devo tracciare ricambi, materiali e “attese” senza gonfiare il sistema?

Non devi trasformare il CMMS in un ERP, ma devi tracciare ciò che impatta tempi, costi e responsabilità. Quindi: quando un ricambio è richiesto, quando è ordinato, quando arriva, quando è installato, e se è coperto da garanzia. Se non tracci l’attesa ricambi con timestamp, il fornitore dirà “non dipendeva da noi” e tu non avrai dati per verificare.

Un accorgimento pratico è limitare i ricambi tracciati “a riga” agli asset critici e alle categorie ad alta incidenza. Per il resto puoi lavorare per kit o consuntivi aggregati, ma devi mantenere almeno la causale “attesa ricambi” e l’identificativo dell’ordine o DDT dove si può.

Che cosa devo tracciare per distinguere “ripristinato” da “risolto” e non farmi fregare sulle chiusure?

Molti sistemi permettono di chiudere appena “torna a funzionare”. Ma contrattualmente e tecnicamente ripristino e risoluzione non sono la stessa cosa. Devi quindi avere due concetti separati: ripristino servizio (temporaneo o definitivo) e chiusura tecnica (causa rimossa, test eseguito, rischio residuo nullo o accettato).

La regola operativa è: se il ripristino è provvisorio, il ticket non deve chiudersi “risolto” ma deve generare automaticamente un follow-up (WO) con scadenza e priorità. Se non lo fai, accumuli debito tecnico nascosto e quando ricapita il guasto diventa “recidiva” e scatta la guerra su chi doveva risolverlo davvero.

Come devo tracciare le approvazioni economiche (extra-canone, varianti, urgenze) per non finire in discussioni infinite?

Ogni extra-canone o attività fuori perimetro deve avere: motivo, stima costi, autorizzante, timestamp autorizzazione, e riferimento al punto contrattuale o alla categoria “fuori canone”. Se l’autorizzazione avviene fuori sistema (telefonata, email), devi imporre almeno la registrazione a posteriori con allegato o riferimento, altrimenti paghi senza prova e apri contenziosi.

Il punto chiave è impedire l’esecuzione “a consuntivo libero” senza un evento di autorizzazione tracciato, salvo urgenze definite (HSE, continuità, fermo produzione). Anche nelle urgenze devi avere la regola: esegui subito, ma entro X ore devi inserire giustificazione e approvazione ex post, altrimenti l’ordine resta amministrativamente sospeso.

Quali dati devo tracciare per gestire fornitori e subappalti senza perdere il controllo?

Devi tracciare sempre chi esegue (azienda e tecnico), con quale qualifica dove serve, e con quale perimetro (fornitore principale vs subappaltatore). Devi tracciare anche la catena di assegnazione: se il principale riassegna al sub, il committente deve vedere l’evento e non scoprirlo a posteriori.

Inoltre, per i fornitori specialisti con accesso remoto o su sistemi proprietari, devi tracciare sessioni di intervento (almeno come evento: data/ora, motivo, esito) e allegare report tecnici quando contrattualmente previsto. Non per paranoia: perché quando qualcosa va storto, il “non siamo stati noi” è la prima risposta.

Come imposto campi obbligatori e controlli senza far odiare il CMMS agli operativi?

Se rendi obbligatori 30 campi, gli operativi iniziano a inventare dati pur di chiudere. Quindi devi essere chirurgico: pochi campi obbligatori, ma quelli che chiudono le scappatoie. Poi devi differenziare per tipologia: guasto critico richiede evidenze e test, richiesta semplice no.

La tecnica che funziona è: obbligatorietà condizionale (se stato = “ripristinato” allora serve test; se causale = “attesa accesso” allora serve richiesta accesso e contatto; se extra-canone = sì allora serve autorizzazione). Così il sistema resta veloce nei casi semplici e diventa rigoroso quando serve davvero.

Conclusioni

Per evitare discussioni e scaricabarile, assicurati che nel CAFM/CMMS siano tracciate sempre identità (ticket e asset), ubicazione univoca, timeline completa, responsabilità e stati con semantica chiara, causali codificate, sospensioni SLA tracciate, evidenze proporzionate e separazione netta tra ripristino e risoluzione. Devi inoltre tracciare accessi/permessi, ricambi e approvazioni economiche quando impattano tempi e perimetro contrattuale.

Se imposti questi elementi come non negoziabili, il sistema smette di essere “un gestionale” e diventa quello che ti serve davvero in un mercato pieno di tecnologia e pochi fatti: un registro oggettivo che protegge il servizio, i soldi e le responsabilità.

Se vuoi affrontare seriamente questo tema evitando i rischi sopra descritti puoi contattarmi qui.