Premesse
La riduzione dei tempi di presa in carico non si ottiene “motivando le persone” o aggiungendo un canale di segnalazione in più: si ottiene togliendo ogni ambiguità. In un CMMS, l’ambiguità principale è sempre la stessa: chi deve prendere quel ticket, adesso, su quel sito, per quel tipo di problema, con quel livello di priorità, dentro quel perimetro contrattuale? Se la risposta richiede una telefonata o un “giro mail”, hai già perso minuti preziosi, e stai già costruendo un rischio per i tuoi SLA.
L’assegnazione automatica funziona quando è governata da regole semplici ma complete, collegate a dati affidabili: skill, turni/reperibilità, priorità/criticità, perimetro (canone/extra-canone), e relazioni corrette tra servizi, siti e fornitori. Si ottiene facilmente tramite modellazione dei dati e di workflow. E sì: è esattamente il tipo di problema che si risolve bene con un motore a regole.
Quali prerequisiti dati devo avere nel CMMS prima di automatizzare?
Servono pochi dati, ma devono essere affidabili e obbligatori nei casi giusti: servizio richiesto (categoria contrattuale), sito/edificio/zona (almeno a livello che distingue i fornitori), asset o location (uno dei due, ma non vuoto), priorità/criticità con regole coerenti, e canale di ingresso (help desk, sensore, presidio, utente).
Poi possono entrare in gioco, anche in un secondo tempo, la matrice skill (chi può fare cosa) e la matrice copertura (chi è disponibile quando). Se queste sono incomplete l’automazione o non assegna, o assegna male, o crea eccezioni continue che diventano manualità.
Che cosa significa davvero “skill” in ottica assegnazione?
Nel mondo FM, la skill è un attributo contrattuale e operativo di ciascun tecnico: abilitazioni, competenze per disciplina (elettrico, HVAC, edile, speciali), e se previsto anche l’ambito di servizio (manutenzione correttiva, verifiche periodiche, pronto intervento, impianti speciali, ecc.). In assegnazione automatica la skill deve essere un insieme di tag controllati, non una descrizione.
Il punto pratico è: la skill va modellata a monte per servizio e poi mappata su gruppi/operatori/fornitori. Se definisci la skill “per persona” senza una tassonomia di servizi, ogni change contrattuale o cambio fornitore rompe le regole.
Come imposto le regole su turni, reperibilità e copertura senza trasformarle in un calendario ingestibile?
Devi separare “orari” da “ruoli”. In genere basta modellare: orario di presidio (fasce), reperibilità (finestre + escalation), e copertura per sito o cluster di siti. Poi associ queste coperture a gruppi (team) e solo alla fine agli operatori nominativi, se ha senso farlo.
Un errore tipico è voler assegnare sempre a una persona specifica; spesso è più robusto assegnare a un “gruppo operativo” e poi far scattare una sotto-assegnazione nominativa solo quando c’è presa in carico, oppure quando il gruppo ha un dispatcher. Nel tuo caso d’uso (preassegnazione a specifici operatori) funziona bene quando il perimetro è stabile e la reperibilità è formalizzata: altrimenti va previsto un fallback automatico, non una gestione manuale.
Qual è la relazione dati più importante da modellare?
La relazione più importante è: per questo servizio, in questo sito (o zona), chi è il fornitore responsabile e qual è il gruppo/operatore di riferimento? Se questa relazione è esplicita e governata, l’assegnazione diventa deterministica. Se non lo è, l’assegnazione diventa “indovina chi”.
Qui il riferimento alla tua esperienza è centrale: il motore che hai prodotto per quel cliente basato su relazioni automatiche tra servizi, siti e fornitori è esattamente l’approccio corretto, perché sposta la complessità dalla testa delle persone a una matrice di responsabilità. È anche l’unico modo per reggere cambi fornitore e perimetri multi-sito senza riscrivere ogni volta il workflow.
Devo assegnare al fornitore o all’operatore? E quando ha senso la “preassegnazione” nominativa?
Assegnare al fornitore (o al gruppo) è più robusto quando hai turni variabili, rotazioni, o più sedi con coperture elastiche. Assegnare a un operatore specifico è molto efficace quando hai un presidio stabile e vuoi ridurre al minimo il tempo perso su “chi lo prende”.
La preassegnazione nominativa ha senso se: i turni sono affidabili e aggiornati, la reperibilità è codificata, e hai una regola automatica di riassegnazione se l’operatore non prende in carico entro una soglia. Senza quella soglia e senza escalation automatica, la preassegnazione può paradossalmente rallentare: il ticket “appartiene” a qualcuno che magari oggi non c’è.
Quali sono le regole minime che consiglio per tagliare davvero i tempi?
In pratica bastano poche regole in cascata, purché siano complete e abbiano fallback: prima si determina il servizio, poi la copertura per sito/zona, poi il fornitore responsabile, poi il gruppo/skill, poi il turno (presidio o reperibile), poi l’operatore (se applicabile). Se manca un dato, la regola non deve “fallire in silenzio”: deve deviare su un gruppo di triage (help desk tecnico) con un motivo tracciato.
La cosa che fa la differenza è imporre una regola di “fallback”: se il ticket non viene preso in carico entro X minuti (diversi per priorità), scatta riassegnazione/escalation automatica e notifica. Senza questa, stai automatizzando l’invio, non la presa in carico.
Come gestisco le eccezioni reali (siti senza copertura, servizi ambigui, asset non censiti) senza tornare al manuale?
Le eccezioni vanno progettate come casi normali. Devi avere: un percorso di triage, una lista di “servizi non classificati” che non possono andare direttamente a un fornitore, e una regola per “asset/location mancanti” che obbliga a completamento dati (o almeno a scelta guidata) prima di procedere.
L’altra eccezione tipica è il perimetro contrattuale: se un servizio o un asset è fuori perimetro, l’assegnazione deve comunque andare a qualcuno, ma con stato e regole diverse (es. “in attesa approvazione”, o “richiesta offerta”). Se non distingui questi casi, i fornitori rifiutano, il ticket rimbalza, e tu perdi tempo e governance.
Come evito che l’automazione generi scaricabarile?
Devi rendere il rifiuto un’azione “costosa” in termini di dati: rifiuto solo con causale codificata, e solo verso destinazioni ammesse. E devi tracciare chi rifiuta e quante volte. Se un fornitore rifiuta sempre la stessa categoria, non è un problema operativo: è un problema di perimetro, anagrafica o contratto.
Inoltre devi separare chiaramente “rifiuto” da “richiesta chiarimenti”. Il rifiuto sposta responsabilità; la richiesta chiarimenti deve restare in mano all’assegnatario con una domanda puntuale e un tempo massimo. Se mescoli i due, crei rimbalzi infiniti mascherati.
Come misuro se l’assegnazione automatica sta funzionando davvero ?
Misura tre cose insieme: tempo di presa in carico (per priorità e per sito), percentuale di ticket presi in carico entro soglia, e tasso di riassegnazione/rifiuto. Aggiungi una metrica di qualità: percentuale di ticket chiusi con asset/location/causale valorizzati, perché se l’automazione spinge a chiudere male, stai solo spostando il problema.
Poi fai analisi per “regola”: quali regole assegnano correttamente e quali generano eccezioni. Un motore a regole maturo non è quello che “assegna sempre”, ma quello che rende visibile dove i dati o il contratto non sono allineati.
Come implemento tutto questo nel CMMS ?
Se il software di CMMS è adeguatamente configurabile questo motore lo imposti con uno strumento di workflow o tramite regole nel DB tra le tabelle dei servizi, delle ditte, dei presidi e del personale: matrice servizi–siti–fornitori con un primo set di regole di assegnazione e un fallback di triage. Solo dopo si rifiniscono skill e turni.
Il punto è iterare nel tempo: man mano che ti si presentano riduci le eccezioni (servizi ambigui, siti senza copertura, rifiuti non motivati) e consolidi i dati. È esattamente il tipo di lavoro incrementale che porta risultati in poche settimane, non in mesi.
Conclusioni
L’assegnazione automatica dei ticket nel CMMS riduce davvero i tempi di presa in carico quando è basata su relazioni dati solide (servizi–siti–fornitori), su regole di skill e copertura realistiche, e su una disciplina di workflow che include ack, escalation e gestione delle eccezioni. Se ti limiti a “smistare automaticamente”, ottieni rimbalzi; se modelli responsabilità e fallback, ottieni continuità operativa e KPI difendibili.
Se vuoi approfondire le tue esigenze di ottimizzazione di questi servizi puoi contattarmi qui