Cos'è un ordine di lavoro (ODL) e come strutturarlo nel CMMS

A chi serve questa guida

Se in reparto convivono richieste su WhatsApp, fogli firma su carta e mail al capoturno, l'ordine di lavoro (ODL) è la struttura minima per portare la manutenzione dentro un CMMS e produrre dati coerenti per MTTR, MTBF, aderenza ai piani e costi per asset. Questa guida glossario è pensata per responsabili di manutenzione, planner e direttori tecnici di stabilimenti italiani che stanno definendo — o rivedendo — la struttura degli ODL.

L'obiettivo è pratico: capire cos'è un ordine di lavoro, quali campi obbligatori non possono mancare, come impostare stati, collegamenti ad asset, ricambi, tempi e cause, e come standardizzare modelli per famiglia in modo che la chiusura dell'ODL alimenti KPI utili senza raddoppiare il lavoro dei tecnici.

Cos'è un ordine di lavoro (ODL)

L'ordine di lavoro — in inglese work order, spesso sigla ODL o WO — è l'unità elementare di lavoro nel CMMS: descrive un'attività di manutenzione da eseguire su un asset, con un obiettivo, una priorità, tempi previsti, materiali attesi e un responsabile.

Nasce da tre origini tipiche:

• una richiesta di intervento valutata dal planner o dal responsabile (guasto segnalato, anomalia, malfunzionamento);
• un piano di manutenzione preventiva che genera in automatico l'ODL alla data o al contatore previsto;
• una soglia o allarme da sensore, PLC o SCADA che innesca un ordine a condizione.

Un ODL non è un semplice promemoria: è un contenitore di dati che, se compilato correttamente in apertura e — soprattutto — in chiusura, permette di ricostruire cosa è successo, quanto è costato, perché è successo e come evitare che si ripeta.

ODL vs richiesta vs task

Molte confusioni operative nascono dalla sovrapposizione di tre concetti:

• Richiesta di intervento: segnalazione da produzione, operatore, portale o mail. Non è un impegno di lavoro, è un input da valutare.
• Ordine di lavoro (ODL): attività approvata, con asset, priorità, squadra e tempi. Genera costi e KPI.
• Task: singola operazione dentro un ODL (checklist), utile su interventi lunghi o complessi con più step.

Trattare tutte le richieste come ODL gonfia i numeri e sporca i KPI; trattare ogni ODL come un semplice promemoria svuota i report di significato.

Perché serve una struttura ODL condivisa

Senza uno standard di ordine di lavoro, il reparto lavora ma non produce dati confrontabili. Ogni tecnico chiude a modo suo, ogni sito usa causali diverse, ogni report richiede lavoro manuale del planner.

Uno standard ODL condiviso porta tre vantaggi immediati:

1. KPI leggibili in direzione: MTTR, MTBF e aderenza ai piani si calcolano senza reinterpretazioni.
2. Consuntivi corretti: ore e ricambi imputati all'asset giusto rendono affidabili le decisioni riparare o sostituire.
3. Storico utilizzabile: al terzo guasto simile sulla stessa macchina, si vede un pattern e si può intervenire con manutenzione preventiva o predittiva.

Campi obbligatori di un ordine di lavoro

Un ODL utile ha un nucleo di campi obbligatori in apertura e un nucleo diverso in chiusura. Distinguere le due fasi evita di bloccare il tecnico a fine turno con dati che nessuno rileggerà.

Campi in apertura

Campi in chiusura

Stati di un ordine di lavoro

Gli stati governano il ciclo di vita dell'ODL. Un CMMS solido non ha 15 stati diversi: ne bastano da 5 a 7, con transizioni chiare.

Sequenza tipica per uno stabilimento italiano:

1. Bozza — ODL in preparazione dal planner, non ancora rilasciato.
2. Aperto / da assegnare — pronto per il planner ma senza squadra.
3. Assegnato — squadra o tecnico responsabile definito, in coda operativa.
4. In corso — presa in carico sul campo (timbro di inizio lavori).
5. In attesa — sospeso per ricambi mancanti, permessi di lavoro, autorizzazione produzione.
6. Chiuso — completato, con tutti i campi di chiusura compilati.
7. Annullato — chiuso senza esecuzione, con motivazione.

Regole di igiene sugli stati:

• La transizione In corso → Chiuso deve richiedere causa, tempo effettivo e ricambi. Nessun skip.
• La transizione Aperto → Chiuso è vietata (nessun ODL «chiuso mai lavorato»).
• In attesa ha sempre un motivo strutturato (ricambio X, autorizzazione Y): serve per il backlog e per capire dove si perde tempo.
• Annullato richiede motivo: doppione, richiesta rifiutata, asset dismesso.

Collegamenti obbligatori: asset, ricambi, tempi, cause

Un ODL isolato vale poco. Il valore è nei collegamenti che alimenta.

Collegamento all'asset

Ogni ODL deve puntare a un asset registrato nell'anagrafica, con gerarchia almeno a tre livelli: sito → linea (o area) → macchina (o componente). Su asset critici, aggiungere il livello componente (motore, riduttore, quadro) permette di ricostruire lo storico guasti per parte.

Errore frequente: ODL agganciati alla linea invece che alla macchina («Linea 3 — sostituzione cuscinetto»). Rende impossibile calcolare MTBF per singolo asset e distorce le decisioni di sostituzione.

Collegamento ai ricambi

I ricambi previsti in apertura verificano la disponibilità a magazzino; i ricambi effettivamente usati in chiusura generano il movimento e imputano il costo. Su asset critici, mantenere una distinta ricambi collegata all'asset evita al tecnico di cercare il codice ogni volta.

Vedi magazzino ricambi multi-sito per la gestione delle ubicazioni.

Collegamento ai tempi

Tre tempi tenuti separati:

• Tempo stimato (in apertura, dal planner): base per capacità del turno e per confronto stimato/effettivo.
• Tempo effettivo (in chiusura, dal tecnico): mano d'opera consuntivata sull'asset.
• Tempo di fermo asset (dove pertinente): dall'evento guasto al ripristino produzione, per calcolare MTTR reale e costo del fermo.

Confondere tempo effettivo (2 ore di intervento) con tempo di fermo (8 ore di macchina ferma per attesa ricambio) è l'errore più comune nel calcolo del MTTR.

Collegamento alle cause

Le cause guasto vanno gestite come tassonomia chiusa, non testo libero. Consigliato: massimo 30 codici, raggruppati per famiglia (meccanica, elettrica, elettronica, operatore, esterno). Ogni causa dovrebbe rispondere a perché è successo, non cosa è stato fatto.

Con causali coerenti, il modulo statistiche mostra Pareto guasti per asset, per famiglia, per turno.

Modelli ODL per famiglia asset

I modelli (o template) accelerano l'apertura degli ODL ricorrenti e riducono errori di compilazione. Ogni modello contiene: descrizione tipo, checklist, tempo stimato, ricambi previsti, cause probabili, allegati (schemi, procedure).

Famiglie tipiche in uno stabilimento industriale italiano:

• Compressori aria: sostituzione filtro, controllo perdite, cambio olio, verifica pressostati.
• Presse idrauliche: controllo pressioni, tenute cilindri, sostituzione flessibili.
• Impianti HVAC: pulizia filtri, controllo carica gas, taratura sonde, sanificazione batterie.
• Nastri trasportatori: allineamento, tensionamento, sostituzione rulli, controllo motoriduttori.
• Quadri elettrici: termografia, serraggio, verifica differenziali, pulizia.
• Serbatoi e linee fluidi: prove di tenuta, verifica valvole, campionamento.

Regola: un modello per intervento ricorrente, non un modello per asset. Su 300 asset e 30 tipi di intervento, servono ~30 modelli, non 300.

I modelli si legano ai piani di preventiva (ricorrenza calendario o contatore) e agli ordini straordinari come base di compilazione veloce.

Qualità dei dati di chiusura per MTTR e MTBF

I KPI di manutenzione sono buoni solo quanto i dati di chiusura che li alimentano. Un CMMS con centinaia di ODL chiusi senza causa produce report inutili.

MTTR: cosa lo distorce

Il Mean Time To Repair misura il tempo medio di ripristino. Dati di chiusura che lo distorcono:

• ODL aperti a distanza di giorni dall'evento reale (MTTR gonfiato).
• Chiusura in blocco a fine mese (MTTR livellato, non reale).
• Nessuna distinzione tra tempo di intervento e tempo di fermo asset.
• Straordinari classificati come preventivi per «abbellire» i numeri.

MTBF: cosa lo distorce

Il Mean Time Between Failures misura la distanza media tra guasti sull'asset. Dati che lo distorcono:

• Guasti multipli chiusi in un unico ODL cumulativo.
• ODL agganciati a linea e non a macchina.
• Causali generiche («guasto generico») che non permettono di separare guasti reali da falsi allarmi.
• Asset senza codifica gerarchica coerente tra siti.

Vedi KPI manutenzione: MTBF, MTTR, backlog e costi per la definizione operativa dei KPI e degli errori più comuni.

Priorità e SLA: come si legano all'ODL

La priorità dell'ODL determina in gran parte SLA e assegnazione. Tre livelli sono sufficienti nella maggior parte degli stabilimenti:

• P1 — Urgente: fermo produzione o rischio sicurezza. Presa in carico entro 15–60 minuti, intervento immediato.
• P2 — Pianificabile: anomalia senza fermo o degrado prestazionale. Presa in carico entro turno, intervento entro 24–72 ore.
• P3 — Differibile: manutenzione migliorativa o richiesta non critica. Pianificazione in settimana o mese.

Attribuire priorità richiede regole scritte: non può dipendere dal richiedente. Un buon CMMS mostra la priorità in evidenza sul mobile del tecnico e attiva escalation automatica se l'ODL P1 non viene preso in carico entro il tempo previsto.

Errori frequenti nella gestione ODL

• Testo libero al posto di campi strutturati: descrizioni ricche ma nessun dato analizzabile.
• Chiusura con «guasto generico»: causale abbastanza generica da non servire a nessuno.
• ODL retroattivi «di regolarizzazione»: aperti e chiusi lo stesso giorno per riempire i buchi. Distruggono i KPI.
• Un solo tecnico che chiude per tutta la squadra: perdita del dato «chi ha fatto cosa».
• Modelli mai aggiornati: cause obsolete, ricambi non più a codice, tempi non realistici.
• Nessuna revisione mensile della tassonomia cause: dopo un anno le causali non riflettono la realtà del parco macchine.

Percorso consigliato in 4 settimane

Se partite da Excel o da un CMMS legacy, un percorso praticabile:

• Settimana 1: definire tipi ODL, stati, priorità, tassonomia cause (max 30 codici).
• Settimana 2: creare 5–8 modelli per le famiglie asset più critiche; caricare distinte ricambi.
• Settimana 3: formazione planner e tecnici su mobile; pilota su un reparto per 5 giorni.
• Settimana 4: verifica data quality, aggiustamenti su modelli e tassonomia, estensione a tutto il sito.

Vedi anche il piano operativo 30 giorni per implementare il CMMS per un percorso di adozione completo.

Cosa deve dare il CMMS

Un CMMS adeguato alla gestione ODL industriale offre almeno:

• Anagrafica asset con gerarchia siti → linee → macchine → componenti.
• Modelli ODL riutilizzabili per famiglia intervento.
• Mobile per tecnici con checklist, allegati, firma o QR asset.
• Stati e transizioni configurabili con campi obbligatori differenziati per stato.
• Report standard su MTTR, MTBF, aderenza piani, backlog e cause.
• Integrazione sensori per ordini a condizione (temperatura, vibrazione, ore lavorate).

Su Maintain360 la struttura ODL è supportata dai moduli manutenzione straordinaria, manutenzione preventiva, pianificazione, gestione asset e statistiche e report, con app mobile dedicata ai tecnici in reparto.