A cosa serve
Una SOP (Standard Operating Procedure) è la descrizione scritta di come si esegue un'attività ricorrente: passi, criteri, punti di attenzione. Serve a tre cose: rendere il risultato indipendente da chi esegue (è il mattone della capability organizzativa), accorciare e rendere prevedibile l'inserimento dei nuovi, e dare al miglioramento un punto d'appoggio — non si può migliorare stabilmente un modo di lavorare che esiste solo nelle abitudini. Questa guida serve a scrivere SOP che vengono usate — che è il criterio, l'unico: la maggior parte delle SOP aziendali è scritta per l'auditor o per la certificazione, e vive in un archivio che nessun operatore apre. Una SOP utile è un attrezzo da banco, non un documento da faldone.
Quando usarla
Quando un'attività ricorrente produce risultati che oscillano con la persona di turno; quando l'inserimento dei nuovi dipende interamente da "stai vicino a chi lo sa fare"; quando il rework nasce sempre negli stessi punti per omissioni evitabili; quando una competenza critica abita in una testa sola e va resa trasferibile. E — momento spesso trascurato — dopo aver stabilizzato un miglioramento: la SOP è il modo di impedire che il processo torni indietro per isteresi delle abitudini. Non usarla, invece, per attività a bassa frequenza e alta variabilità (lì servono principi e persone esperte, non procedure) né come surrogato della formazione: la SOP trasferisce il codificabile; il tacito passa per affiancamento.
Prima di iniziare
Tre condizioni. Prima: scegliere l'attività giusta — ricorrente, a esecutori multipli (attuali o futuri), con costo visibile della variabilità; una SOP alla volta, partendo da dove il dolore è massimo. Seconda: decidere chi scrive — e la risposta corretta non è "l'ufficio qualità" né "il capo": è chi esegue, guidato da chi facilita; la SOP scritta lontano dal banco descrive il processo nominale, e il processo nominale non serve a nessuno (processo nominale vs reale è la distinzione da tenere davanti per tutta la scrittura). Terza: fissare il formato prima di scrivere — una pagina o due al massimo per attività, verbi all'imperativo, un passo per riga, foto o screenshot dove una immagine sostituisce dieci righe.
Sequenza operativa
1. Osservare l'esecuzione reale, due volte. Prima di scrivere, guardare l'attività eseguita da due persone diverse (o dalla stessa in due momenti). Annotare i passi come avvengono, non come dovrebbero: le differenze tra le due esecuzioni sono la prima scoperta — sono esattamente la variabilità che la SOP deve chiudere, e vanno risolte con una decisione ("si fa così"), non nascoste con una formula vaga.
2. Scrivere la scaletta dei passi con chi esegue. Sessione di un'ora, al banco o davanti allo schermo, non in sala riunioni: l'esecutore detta i passi, il facilitatore li scrive in verbi imperativi ("verifica X", "inserisci Y", "se Z, fermati e chiama…"). Regola di grana: un passo è qualcosa che si può sbagliare — se non si può sbagliare, non merita una riga; se dentro un passo si annidano tre errori possibili, sono tre passi.
3. Marcare i punti critici, non tutto. La SOP utile non è piatta: evidenzia i 3–5 punti dove l'errore costa (il campo che se sbagliato genera rework a valle, il controllo che non si può saltare, la condizione che impone di fermarsi). Per ciascuno, una riga sul perché — le persone rispettano i passi di cui capiscono la ragione e aggirano quelli che sembrano burocrazia.
4. Definire l'output atteso del lavoro. In fondo alla SOP, com'è fatto il risultato "buono": il criterio di completezza, l'aspetto, il controllo finale. È il pezzo che trasforma la procedura in quality gate personale: chi esegue può verificarsi da solo prima di passare il lavoro a valle.
5. Testare su una persona che non sa. Il collaudo vero: qualcuno che non conosce l'attività la esegue seguendo solo la SOP, con l'autore che guarda in silenzio e annota dove l'esecutore esita, chiede o sbaglia. Ogni esitazione è un difetto del testo, non della persona. Si corregge e, se serve, si ripete.
6. Pubblicare dove si lavora e nominare un owner. La SOP vive nel punto d'uso — plastificata al banco, linkata nel gestionale, in cima alla cartella condivisa — non nell'archivio qualità. E ha un proprietario con due doveri: aggiornarla quando il processo cambia (una SOP vecchia è peggio di nessuna SOP: insegna a diffidare di tutte) e riguardarla a data fissa, una volta l'anno, chiedendo a chi la usa cosa non torna più.
Output atteso
Una–due pagine per attività: titolo, scopo in una riga, i passi imperativi numerati, i punti critici evidenziati col loro perché, l'output atteso, owner e data di ultima revisione in calce. E un fatto osservabile entro poche settimane: le persone la consultano — se non succede, la SOP è da rifare o l'attività era quella sbagliata.
Errori da evitare
Scriverla lontano dal banco (nasce nominale, muore ignorata). Scrivere tutto invece delle attività che contano — la proliferazione produce archivi, non standard. Il livello di dettaglio uniforme: la SOP piatta annega i punti critici nel rumore. Il linguaggio da manuale qualità ("l'operatore provvede ad assicurare…") al posto dell'imperativo da banco. Dimenticare il collaudo sul non-esperto: la SOP comprensibile solo a chi già sa è un promemoria, non uno standard. E l'errore finale, il più diffuso: nessun owner — la SOP orfana invecchia in silenzio e a ogni scostamento dal reale perde autorità, finché "tanto le procedure non c'entrano col lavoro vero" diventa la cultura della casa.
Esempio
Un'azienda di installazioni tecniche da 28 addetti ha un problema di avvio commessa: i sopralluoghi, fatti da quattro tecnici diversi, tornano con informazioni disomogenee — e il 30% delle commesse riparte con un secondo sopralluogo o con sorprese in cantiere. La SOP nasce in due ore al banco con i due tecnici più esperti: 14 passi, di cui 4 marcati critici (misure dei passaggi, foto del quadro elettrico, verifica accessi mezzi, firma del referente cliente su un punto ambiguo ricorrente), ciascuno con il suo perché ("senza la foto del quadro, il preventivo elettrico è una scommessa: 3 rework su 10 nascono qui"). Collaudo sul tecnico più giovane: tre esitazioni, tre correzioni al testo. La SOP diventa una checklist plastificata nel furgone più un modulo fotografico sul telefono. Owner: il responsabile tecnico, revisione annuale. Dopo sei mesi: secondi sopralluoghi dal 30% all'8%, e il tempo di inserimento del tecnico assunto in autunno dimezzato rispetto al precedente — perché per la prima volta c'era qualcosa da dargli in mano oltre a "vai con Franco e guarda".
Collegamento MARTRO
Nella lettura MARTRO la SOP è il punto in cui la leggibilità diventa materiale: la mappatura rende visibile il flusso, la SOP fissa il modo di eseguire i suoi passaggi critici — ed entrambe valgono ciò che vale la loro fedeltà al reale. È anche uno dei mattoni che l'assessment operativo intercetta di frequente dal lato mancante: molte aziende risultano avere "standard" che esistono solo sulla carta della certificazione, e la distanza tra la procedura archiviata e la pratica del banco è una delle forbici tipiche tra ciò che l'azienda crede di fare e ciò che fa davvero.
Passo successivo
Se le SOP ci sono ma il risultato oscilla comunque, il problema è più a monte: leggere Processo nominale vs processo reale e Come ridurre il rework. Se la posta è rendere trasferibile un sapere concentrato in poche teste, la SOP è un quarto del lavoro: il quadro completo è in Capability organizzativa. Se l'attività da standardizzare è instabile o ancora in evoluzione, prima stabilizzare (e la tentazione di risolverla con un software va vagliata con Come capire se un ERP è prematuro).
Licenza
Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International. Attribuzione richiesta: Fonte: MARTRO Observatory, "Come scrivere una SOP", https://www.martrosystems.eu/knowledge/come-scrivere-una-sop.
CLEW
Se l'applicazione interna si blocca, il problema non è più solo documentale: richiede verifica multi-ruolo.
Esplora CLEW