Richiesta vs ordine di lavoro: differenza e flusso corretto

Perché confondere richiesta e ordine di lavoro costa alla manutenzione

In molti stabilimenti italiani «apri un ordine» e «segnala un guasto» sono la stessa cosa: chiunque può creare un ordine di lavoro (ODL), il planner rincorre priorità decise da altri, i KPI diventano ingestibili. Distinguere richiesta di intervento e ordine di lavoro non è formalismo: è la base per far funzionare il CMMS e per rendere leggibili MTTR, MTBF, aderenza ai piani e carico squadre.

Questo articolo chiarisce chi crea cosa, come funziona il triage, quando una richiesta diventa un ODL, gli anti-pattern più diffusi (WhatsApp, Excel, mail al capoturno) e propone un flusso corretto immediatamente utilizzabile.

Cos'è una richiesta di intervento

La richiesta di intervento (in inglese service request, SR) è la segnalazione di un problema, un'anomalia, un bisogno di manutenzione. È un input da valutare, non un impegno di lavoro. Può arrivare da:

• operatore di linea che vede un'anomalia sulla macchina;
• produzione o capoturno che segnala un fermo o un degrado;
• utente di un ufficio o addetto retail per HVAC, illuminazione, edificio;
• portale esterno o totem con codice asset;
• allarme automatico da PLC, SCADA o sensore IoT.

Caratteristica chiave: la richiesta è aperta ma non ancora valutata. Non ha priorità operativa definitiva, non ha squadra assegnata, non è ancora un impegno di manutenzione.

Cos'è un ordine di lavoro (ODL)

L'ordine di lavoro (ODL, work order) è l'unità elementare di attività di manutenzione tracciata nel CMMS: nasce dopo il triage di una richiesta o direttamente da un piano di preventiva o da un ordine a condizione da sensore. Ha asset, tipo, priorità, squadra, tempo stimato, ricambi previsti.

Per una definizione completa dei campi e degli stati vedi cos'è un ordine di lavoro (ODL) e come strutturarlo.

Differenza a colpo d'occhio

Chi crea cosa

Un errore diffuso è lasciare che chiunque apra ODL. Il risultato: ordini duplicati, priorità gonfiate, planner che perde tempo a chiudere «per cancellazione» ordini che non dovevano esistere.

Regola pratica:

• Chiunque autorizzato può creare una richiesta: operatore, capoturno, ufficio, portale esterno, sensore.
• Solo il planner o il responsabile crea un ODL — o approva la trasformazione di una richiesta in ODL.
• Il sistema può creare un ODL automatico solo da piani di preventiva registrati e da soglie sensore configurate con regole approvate.

Su portali richieste esterni (per HVAC in retail, uffici, magazzini) l'utente vede solo il modulo di richiesta, mai la coda ODL. Riceve però lo stato della sua segnalazione: aperta, presa in carico, risolta.

Il triage: da richiesta a ODL

Il triage è il momento in cui il planner (o il responsabile) trasforma la richiesta in decisione. Idealmente dura pochi minuti per ogni richiesta.

Passi standard:

1. Leggere la descrizione e chiedere chiarimenti al richiedente se serve (chat interna, non WhatsApp personale).
2. Verificare l'asset: la richiesta è agganciata correttamente? Se no, correggere prima di procedere.
3. Verificare duplicati: esiste già un ODL aperto sullo stesso asset per lo stesso problema? Se sì, chiudere come duplicato.
4. Assegnare priorità reale (P1, P2, P3) applicando regole scritte, non la sensibilità del richiedente.
5. Decidere l'esito:
   • Diventa ODL con squadra e tempo stimato.
   • Rientra in un piano preventivo già schedulato (non serve un ODL straordinario).
   • Viene respinta con motivazione (falso allarme, richiesta fuori perimetro, competenza altro reparto).
6. Notificare il richiedente dello stato in automatico.

Un triage strutturato produce un KPI utile: tempo medio di triage (dalla richiesta alla decisione). Se supera stabilmente 8 ore, il flusso è rotto — o mancano regole, o manca capacità sul planner.

Regole di priorità P1/P2/P3

Le regole di priorità devono essere scritte e visibili al richiedente in fase di apertura della richiesta:

• P1 — Urgente: fermo produzione in corso, rischio sicurezza persone, rischio ambientale, degrado con impatto imminente.
• P2 — Pianificabile: anomalia senza fermo, degrado prestazionale, richiesta con impatto entro turno.
• P3 — Differibile: manutenzione migliorativa, comfort, richiesta di ottimizzazione senza impatto operativo.

Se manca la regola scritta, ogni richiesta arriva come P1 «perché urgente» e la coda urgenze diventa impossibile da gestire.

Flusso corretto: dalla segnalazione alla chiusura

Un flusso standard, applicabile a stabilimento, retail multi-sito e facility multi-edificio, si articola in sei passaggi:

Ogni passaggio genera un timestamp: il CMMS calcola tempo di triage (1→2), tempo di attesa in coda (3→4), tempo di intervento (4→6), tempo di fermo asset (evento reale → passo 6, se pertinente).

Anti-pattern: cosa succede se saltate il flusso

I quattro anti-pattern più diffusi in reparto:

1. Segnalazioni su WhatsApp personale

Il capoturno riceve foto e messaggi dal suo cellulare. Nulla è tracciato: non c'è storico, non c'è KPI, non c'è escalation se il capoturno è in ferie. Al primo audit o al primo cambio di persona il reparto ha zero memoria.

Alternativa: portale richieste web, app mobile con account nominale, o al limite chat aziendale con integrazione al CMMS.

2. Excel condiviso come coda urgenze

Un file urgenze_2026.xlsx in cartella di rete. Ognuno scrive quello che vuole, il file si corrompe, i filtri saltano. Priorità e stato dipendono da chi apre il file per ultimo.

Alternativa: modulo richieste nel CMMS con priorità strutturate e stati automatici.

3. Ogni segnalazione è un ODL

Nel tentativo di essere «tracciati», tutti aprono ODL. Il planner ne chiude 40 al giorno come duplicati o rifiutati. I numeri di produttività squadra diventano fittizi (ODL «chiusi» che non erano lavoro).

Alternativa: livello richiesta separato, triage rapido, ODL solo dopo approvazione.

4. ODL «di regolarizzazione» a fine settimana

Il venerdì il tecnico apre 15 ODL retroattivi «per mettere in ordine la settimana». Cause generiche, tempi stimati, MTTR distrutto. Il KPI di aderenza sembra buono, la realtà no.

Alternativa: apertura ODL prima o durante il lavoro, mobile in tasca, presa in carico con un tap.

Flusso richiesta → ODL: mappatura ruoli e strumenti

Escalation e SLA sulle richieste

Il flusso richiesta → ODL richiede regole di escalation per non lasciare richieste «orfane»:

• Richiesta P1 non presa in triage entro 15 minuti → notifica al responsabile.
• Richiesta P2 non presa in triage entro 4 ore → notifica al planner di turno.
• Richiesta aperta da più di 48 ore in stato «da valutare» → alert al responsabile.
• ODL P1 non preso in carico entro 30 minuti dall'assegnazione → notifica automatica.

Le regole di escalation sono la differenza tra un CMMS che funziona e un CMMS che rimane un archivio.

Metriche del flusso richiesta → ODL

Oltre a MTTR e MTBF (calcolati sull'ODL), monitorate almeno tre KPI del flusso richieste:

• Tempo medio di triage (richiesta → decisione).
• Tasso di trasformazione (percentuale richieste che diventano ODL). Un tasso troppo basso segnala regole di priorità confuse o richieste inutili; un tasso troppo alto segnala assenza di triage reale.
• Backlog richieste in stato «da valutare» oltre le 24 ore.

Su portali retail o facility, aggiungere:

• Tempo di risposta al richiedente (segnalazione → prima notifica ufficiale).
• Numero di segnalazioni per sito o edificio (per pesare capacità squadre e contract con fornitori esterni).

Come Maintain360 gestisce il flusso

Su Maintain360 il flusso richiesta → ODL è nativo e configurabile:

• Portale richieste per operatori, uffici, punti vendita e tenant, con QR asset e codici brevi.
• Coda triage dedicata al planner, con regole di priorità configurabili e vista per sito.
• Trasformazione richiesta → ODL in un click, con modello per famiglia asset e ricambi previsti già proposti.
• Escalation automatiche su P1, timeout triage e ODL non presi in carico.
• Notifiche al richiedente su stato richiesta e chiusura ODL, con testo configurabile per contesto (produzione, retail, tenant).

Vedi anche gestione richieste e manutenzione straordinaria, pianificazione manutenzione e — per ambienti multi-sito — carico di lavoro senza Excel.

In sintesi

Distinguere richiesta e ordine di lavoro non è burocrazia: è la struttura minima per far funzionare il CMMS in reparto e produrre KPI attendibili. Chi confonde i due livelli si ritrova con priorità gonfiate, backlog ingestibili e report che nessuno crede. Un flusso a sei passi, regole di priorità scritte, triage strutturato e mobile per il tecnico bastano per ripartire — anche in stabilimenti che oggi lavorano su WhatsApp ed Excel.