Esempi di procedure operative standard: 3 casi pratici
Scopra tre esempi di procedure operative standard, con fasi, sistemi ed eccezioni. Approfondisca gli elementi essenziali di una procedura e come mantenerla aggiornata.
Un esempio di procedura operativa standard è davvero utile quando descrive le fasi concrete, i sistemi utilizzati e le eccezioni, anziché limitarsi a un elenco di titoli. Di seguito trova tre esempi dettagliati, la struttura di una procedura facile da mantenere aggiornata, indicazioni per documentare il lavoro là dove si svolge e un metodo pratico per verificare che la procedura rispecchi ancora la realtà.
Che cos’è una procedura operativa standard?
Una SOP descrive come si svolge un’attività ricorrente: chi se ne occupa, in quale ordine, con quale sistema e cosa fare quando il percorso abituale non è applicabile. Offre al team un riferimento condiviso per svolgere il lavoro e formare le nuove persone, ma la sua qualità dipende dall’ultima verifica effettuata confrontandola con il lavoro reale.
Qual è la differenza tra una SOP, una policy, un’istruzione operativa e una mappa di processo?
Questi documenti hanno scopi diversi:
- Una policy indica le decisioni prese dall’organizzazione. Per esempio: “Tutte le fatture superiori a 10.000 richiedono una doppia approvazione.”
- Un’istruzione operativa spiega come svolgere una fase specifica, per esempio quale schermata, campo o pulsante usare. La SOP indica cosa succede dopo; l’istruzione operativa spiega come eseguire quella fase.
- Una mappa di processo mostra come il lavoro si svolge tra ruoli e sistemi. Una SOP descrive nel dettaglio una singola attività. Consulti la nostra guida alla mappatura dei processi.
Scriva la SOP pensando alla persona che svolge il lavoro, includendo le decisioni da prendere e le eccezioni da gestire.
Tre esempi di procedure operative standard
Ogni esempio presenta una tabella con le fasi, il ruolo, il sistema, il risultato atteso e il percorso da seguire in caso di eccezione. Questi dettagli rendono la procedura più facile da seguire e da confrontare con il lavoro registrato nei sistemi.
Esempio 1: gestione delle eccezioni nelle fatture dei servizi condivisi
La procedura si avvia quando una fattura non supera il controllo di corrispondenza a tre vie. La colonna delle eccezioni indica cosa fare quando una fase non procede come previsto.
| Fase | Chi | Sistema | Risultato | Se qualcosa va storto |
|---|---|---|---|---|
| 1 | Addetto alla contabilità fornitori | ERP | Caso di eccezione creato con il codice del motivo | Se manca il codice del motivo, inoltrare il caso al responsabile del team contabilità fornitori prima di avviare le verifiche |
| 2 | Addetto alla contabilità fornitori | ERP, portale fornitori | Differenza individuata: prezzo, quantità o consegna | Se la differenza di prezzo rientra nella tolleranza del 2%, registrare la fattura e annotare la variazione |
| 3 | Responsabile acquisti | ERP | Conferma della ricezione della merce secondo l’ordine | Se il responsabile acquisti non è disponibile per 2 giorni, inoltrare il caso al responsabile di categoria |
| 4 | Addetto alla contabilità fornitori | ERP | Nota di credito richiesta o fattura approvata per il pagamento | Se il fornitore contesta la nota di credito, passare alla procedura per la gestione delle contestazioni e non lasciare il caso aperto |
| 5 | Responsabile del team contabilità fornitori | ERP | Caso chiuso con il motivo registrato | Se lo stesso codice del motivo ricorre per tre mesi consecutivi, aprire una richiesta di modifica del processo |
L’ultima riga consente al team di segnalare un problema ricorrente e richiederne la revisione, senza dare per scontato che tutte le eccezioni richiedano la stessa soluzione.
Esempio 2: ricezione e stoccaggio della merce
| Fase | Chi | Sistema | Risultato | Se qualcosa va storto |
|---|---|---|---|---|
| 1 | Addetto alla ricezione merci | WMS | Consegna verificata rispetto all’ASN | Se manca l’ASN, registrare manualmente la ricezione e segnalare il fornitore |
| 2 | Addetto alla ricezione merci | WMS | Quantità e danni registrati | Se si rilevano danni, scattare una foto, mettere il pallet in quarantena e avvisare l’ufficio acquisti |
| 3 | Addetto al controllo qualità | QMS | Decisione sul rilascio del lotto | Se il lotto è in attesa, la merce resta in quarantena: non avviare lo stoccaggio |
| 4 | Addetto al magazzino | WMS | Merce stoccata nella posizione suggerita | Se la posizione è bloccata, usare il contenitore di riserva e registrare la modifica |
| 5 | Addetto al magazzino | WMS | Scorte disponibili per il prelievo | Se la ricezione viene registrata dopo l’orario limite, verificare se occorre ripianificare gli ordini aperti |
Esempio 3: classificazione iniziale degli incidenti nel Service Desk IT
| Fase | Chi | Sistema | Risultato | Se qualcosa va storto |
|---|---|---|---|---|
| 1 | Agente del Service Desk | ITSM | Incidente registrato con servizio, impatto e urgenza | Se non è possibile contattare l’utente, registrare l’incidente per suo conto e indicare la fonte |
| 2 | Agente del Service Desk | ITSM, CMDB | Priorità definita in base alla matrice di impatto e urgenza | Se il gruppo di risoluzione contesta la priorità, rivolgersi al responsabile del servizio senza modificarla senza comunicarlo |
| 3 | Gruppo di risoluzione | ITSM | Diagnosi e tentativo di risoluzione entro i tempi previsti dallo SLA | Se la soluzione richiede una modifica, collegare il record della modifica e lasciare aperto l’incidente |
| 4 | Agente del Service Desk | ITSM | Conferma dell’utente e chiusura | Se l’utente non conferma entro 3 giorni, chiudere l’incidente indicando il motivo |
Che cosa deve includere una SOP?
Usi questa struttura come punto di partenza per la prossima procedura operativa standard:
- Scopo e ambito: Indichi cosa copre la procedura e cosa esclude. Definire con chiarezza i confini aiuta a mantenere ogni SOP incentrata su una sola attività.
- Evento di avvio: Indichi l’evento che avvia la procedura, così chi la consulta può capire quando applicarla.
- Ruoli: Indichi le responsabilità per ruolo, non per singola persona. Le persone cambiano, i ruoli sono più stabili.
- Fasi numerate e sistemi: Descriva ogni fase, chi la svolge e quale sistema utilizza.
- Percorso per le eccezioni: Spieghi cosa fare quando il percorso abituale non è applicabile. Includa le deviazioni più comuni, non solo il caso ideale.
- Controlli ed evidenze: Indichi cosa registrare, dove farlo e per quanto tempo conservare i dati.
- Responsabile e cronologia delle revisioni: Indichi la persona responsabile e registri la data e la natura di ogni modifica.
- Condizioni di revisione: Specifichi quali eventi dovrebbero avviare una revisione, per esempio una modifica ai sistemi, alle norme o al team, oppure una variazione misurata delle prestazioni.
La cronologia delle revisioni indica cosa è cambiato e quando. Le condizioni di revisione offrono un motivo per aggiornare la procedura prima che diventi obsoleta.
Come verificare se una SOP è pronta per essere utilizzata?
Prima di pubblicare o rivedere una procedura, si chieda:
- L’ambito specifica cosa non è incluso nella SOP?
- L’evento di avvio è indicato chiaramente all’inizio?
- Ogni fase specifica un ruolo, un sistema e il risultato atteso?
- Le fasi svolte in un’applicazione mostrano la schermata che la persona vedrà?
- La procedura spiega cosa fare quando il percorso abituale non è applicabile?
- Sono indicati il responsabile e la cronologia delle revisioni?
- Un evento specifico avvia la revisione?
- È possibile confrontare la procedura con i dati degli eventi e ha verificato le eventuali differenze con il responsabile del processo?
Se non sa rispondere all’ultima domanda, inizi individuando i sistemi che registrano il lavoro. Potrà così verificare se la procedura rappresenta ancora ciò che accade nella pratica e trasformare la gestione delle SOP in un ciclo di revisione, anziché in una semplice attività di archiviazione.
Come gestire le SOP
Creare una SOP è solo metà del lavoro. Gestire un programma di SOP è più impegnativo: bisogna stabilire dove conservare le procedure, quale versione è aggiornata e chi deve rivederle. Che utilizzi un software dedicato alla gestione delle procedure operative standard o una cartella di documenti, una copia per ogni team finirà per diventare obsoleta. ProcessMind conserva la procedura insieme al processo che descrive, così la governance resta associata al testo:
- Aggiunga la procedura all’attività che descrive. Ogni processo ha un albero della documentazione composto da sezioni, configurate una sola volta a livello di ambiente. Ogni procedura parte così dalle stesse sezioni dedicate a descrizione, ambito, ruoli, obiettivi e governance. Aggiunga sezioni personalizzate in base alle esigenze dell’organizzazione e conservi l’istruzione operativa accanto alla fase pertinente, anziché in una cartella che qualcuno deve cercare.
- Riveda la procedura insieme al resto del processo. Un processo può passare dagli stati Bozza, In revisione, Approvato, Pubblicato, Ritirato e Archiviato. I revisori trovano le attività da seguire con il filtro Richiede la mia revisione; inoltre, un’approvazione può creare una versione pubblicata nello stesso passaggio, evitando che un documento venga approvato in un punto e modificato in un altro.
- Aggiunga commenti nel punto in cui si svolge il lavoro. Con Aggiungi commento sulla fase si avvia una discussione relativa all’attività. Le domande su un campo, un controllo o un’eccezione restano così accanto all’istruzione, anziché perdersi nella posta in arrivo.
- Conservi le versioni. La Cronologia delle versioni registra cosa è cambiato, quando e a opera di chi; la pubblicazione determina quale versione viene mostrata a chi consulta la documentazione.
- Riprenda i ruoli dal modello. La matrice RACI nel documento viene compilata con i ruoli assegnati alle attività del modello, così le responsabilità indicate nel testo corrispondono a quelle riportate nel diagramma.
- Acquisisca le schermate nei punti in cui il lavoro si svolge sullo schermo. Acquisisca una schermata o registri lo schermo direttamente in ProcessMind, ritagli l’immagine per mostrare solo i controlli pertinenti, oscuri in modo permanente i dati personali nell’immagine salvata e aggiunga istruzioni in Markdown. L’editor può anche individuare i campi che potrebbero contenere dati sensibili; i riquadri restano modificabili, così può correggerli prima di salvare. L’acquisizione viene salvata come artefatto allegato all’attività.
- Esporti la documentazione per chi ha bisogno di un file. Word per i cicli di revisione e i sistemi di qualità, Markdown per il controllo delle versioni, PDF e stampa per la distribuzione e l’archiviazione. Le impostazioni di esportazione consentono di decidere se includere anche gli elementi del modello ancora privi di documentazione, i diagrammi di processo e la matrice RACI per ogni attività. Elencare gli elementi non documentati è spesso il modo più rapido per individuare le lacune nella procedura.
Il documento è solo una parte del lavoro. L’altra è la verifica, che deve avvenire nello stesso punto: confronti le fasi documentate con le attività registrate nei sistemi, quindi decida se occorre modificare la formazione, il documento o il processo. Ogni modifica approvata viene riportata nella documentazione con il proprio stato di versione.
È opportuno chiarire due limiti. ProcessMind organizza la documentazione e fornisce elementi utili per la revisione, ma non certifica la conformità e non sostituisce né l’approvazione richiesta dal sistema di gestione della qualità né la libreria di policy mantenuta dal team legale. Gli strumenti di acquisizione dello schermo esterni a questo flusso di lavoro, come Scribe, registrano altrettanto bene il modo in cui una persona svolge un’attività; per poche procedure gestite da un solo team può bastare anche una wiki. Né una wiki né un archivio di documenti separato, però, possono indicare se la procedura corrisponde ancora al lavoro.
Perché le procedure scritte non rispecchiano più il lavoro svolto?
Le procedure diventano obsolete perché il lavoro cambia dopo essere stato documentato. Non è necessariamente un problema di scrittura: è il segno che il processo si è evoluto.
La procedura si basa sulla memoria. Un workshop raccoglie il modo in cui le persone interpretano il processo, che può riflettere come era stato progettato anziché come viene svolto. Le eccezioni passano facilmente inosservate, anche se possono rappresentare una parte considerevole del lavoro.
I team trovano soluzioni alternative. Qualcuno individua un modo più rapido per gestire un caso frequente e lo condivide con i colleghi. Se aggiornare la procedura operativa standard richiede più impegno che ricorrere alla soluzione alternativa, il documento rischia di restare indietro.
I sistemi cambiano. Un campo viene rinominato, un controllo diventa automatico o cambia una soglia di approvazione. La procedura può continuare a descrivere la configurazione precedente.
È difficile accorgersi del cambiamento. Un documento scritto non indica quando il lavoro ha iniziato a svolgersi in modo diverso. Senza dati sul processo, potrebbe essere necessario chiedere alle persone di ricostruire quanto è accaduto.
Come mantenere aggiornata una procedura
Un documento archiviato in una cartella non può farlo da solo. Mantenere la procedura viva può: resta collegata al processo e all’attività che descrive, così ogni modifica a un passaggio e alla relativa documentazione viene sottoposta a revisione insieme, dai ruoli già indicati nel modello. La versione pubblicata è l’unica fonte attendibile consultata dal team nel Process Portal e ogni esportazione deriva da quel documento, non da una copia modificata localmente.
Sono due gli elementi che permettono di verificarne la coerenza. Il controllo di conformità misura la differenza tra il processo documentato e le attività registrate dai sistemi, rendendo gli scostamenti visibili e verificabili. La governance dei processi chiarisce chi è responsabile di questa verifica, mentre la governance e la pubblicazione sono gli ambiti in cui si gestiscono la revisione e le versioni.
Una procedura scritta diventa obsoleta solo dopo che il lavoro è già cambiato, e a quel punto nessuno sa dire quando è successo. Per accorgersene per tempo, l’unico modo che ho trovato è mantenere la procedura collegata al processo e all’attività che descrive. Occorre leggere insieme il documento e i dati: altrimenti, uno dei due sarà sempre non aggiornato.
Come si scrive una procedura operativa standard a partire dai dati degli eventi?
I dati degli eventi mostrano i passaggi svolti nei sistemi che già registrano il lavoro, come un ERP, un ITSM o un WMS. Li utilizzi insieme alle conoscenze sul processo per redigere e rivedere una procedura. È uno degli obiettivi del Process Mining:
-
Caricare l’Event Log
Individui nei sistemi che registrano il processo l’ID del caso, l’attività e la marca temporale; utilizzi un’unica definizione di caso e un solo intervallo di tempo, così i dati restano confrontabili. -
Collegarlo al processo documentato
Affianchi la sequenza registrata ai passaggi della procedura. Alcuni passaggi documentati si presentano in ogni caso, altri raramente e altri ancora mai. Ognuna di queste situazioni merita un approfondimento. -
Analizzare le variazioni
Misuri la frequenza dei diversi percorsi, i punti in cui il lavoro resta in attesa e i passaggi ripetuti. Una variazione nei dati è uno spunto per indagare, non la prova che il lavoro sia svolto in modo errato. -
Aggiungere alla procedura le variazioni rilevanti
Trasformi le variazioni ricorrenti in righe dedicate alle eccezioni, indicando un ruolo, un sistema e il risultato atteso, come nei tre esempi precedenti; chieda poi a chi svolge il lavoro di confermare ciò che i dati non possono mostrare.
I dati di processo consentono di verificare una procedura, ma non spiegano ogni decisione né stabiliscono come dovrebbe essere svolto il processo. Verifichi i risultati con le persone che svolgono e gestiscono il lavoro e, già che ci è, indichi un responsabile e una condizione che attivi la revisione: una procedura senza un responsabile è destinata a diventare obsoleta.
Where to Go From Here
You have a procedure and a way to check it. Compare the documented steps with the activity your systems already record, and use the differences to decide what to review with your process team.
