Sara lavora sulla stessa procedura da sei settimane. L’ha riscritta tre volte. Ha aggiunto una sezione sulle eccezioni, poi l’ha tolta, poi l’ha rimessa. Ha chiesto a due persone del team di leggerla. Ha aperto un documento nuovo per confrontare le versioni.
Nel frattempo, il processo che quella procedura dovrebbe regolare continua a essere gestito a voce, caso per caso, con lei nel mezzo di ogni decisione.
Sara non ha un problema di metodo. Ha un problema di soglia: non sa quando fermarsi.
È un blocco più comune di quanto sembri, e colpisce in modo particolare chi ha un approccio metodico al lavoro — esattamente il tipo di persona che decide di costruire un sistema operativo per la propria azienda. La stessa cura che rende le procedure solide diventa il freno che impedisce di usarle.
Una procedura perfetta che vive ancora in bozza non aiuta nessuno. Una procedura abbastanza buona che il team usa da domani mattina risolve già metà del problema.
Il paradosso del processo perfetto
C’è una logica distorta che si innesca quando si lavora sulle procedure: più conosci il processo, più vedi i casi che la procedura non copre. Più vedi i casi scoperti, più senti il bisogno di aggiungere. Più aggiungi, più il documento diventa lungo. Più è lungo, meno viene letto.
Il risultato finale è spesso una procedura esaustiva, accurata, e completamente inutilizzabile nella pratica quotidiana.
Il punto che viene perso di vista è questo: una procedura non deve coprire tutti i casi possibili. Deve coprire l’80% dei casi che si verificano davvero — quelli normali, ripetitivi, prevedibili. I casi edge esistono, ma gestirli dentro la procedura la rende più complessa senza renderla più utile.
| La regola dell’80% Se una procedura copre correttamente i casi che si verificano nella maggior parte delle situazioni, è pronta per essere usata. I casi eccezionali si gestiscono con una nota a margine — o con il buon senso di chi esegue. Una procedura che richiede ancora la tua supervisione per i casi normali non è abbastanza buona. Una che funziona da sola per i casi normali — sì. |
I tre segnali che una procedura è pronta
Non esiste un criterio oggettivo universale — ma esistono segnali pratici che indicano che una procedura ha raggiunto il livello giusto per essere resa operativa.
| Segnale | Cosa significa | Cosa fare |
| Le domande su quel processo sono sparite | Chi lo esegue sa cosa fare senza chiedere | Passa al processo successivo |
| Gli errori si sono ridotti, non azzerati | Il processo copre i casi normali — i casi edge sono ancora gestiti a mano | Aggiungi una sezione eccezioni, non riscrivere tutto |
| Funziona anche quando non ci sei tu | L’autonomia operativa è reale, non dipende dalla tua supervisione | Documenta il prossimo collo di bottiglia |
Nessuno di questi segnali richiede che la procedura sia completa in ogni dettaglio. Richiedono che funzioni per chi la usa, nel contesto in cui viene usata.
Le tre forme del blocco da perfezionismo — e come uscirne
1. Aggiungere invece di testare
Il segnale più frequente: ogni volta che la procedura sembra quasi pronta, si aggiunge un’altra sezione. Un’altra eccezione. Un altro caso.
L’antidoto è smettere di scrivere e iniziare a testare. Mandare la procedura a una persona del team con una sola istruzione: seguila senza che io ti spieghi nulla. Quello che non capisce non è un motivo per aggiungere — è un motivo per riscrivere quello che c’è già in modo più chiaro.
2. Aspettare il momento giusto per pubblicare
“La pubblico appena finisco questa parte.” “Aspetto di rivedere la sezione sulle eccezioni.” “Voglio prima fare una call con il team.”
Il momento giusto per pubblicare una procedura è quando supera il test: qualcuno riesce a seguirla senza farti domande. Non dopo. Non quando si sente più pronta — quando funziona nella pratica.
3. Riscrivere invece di aggiornare
Quando una procedura già in uso produce errori o domande, la risposta istintiva è spesso riscriverla da capo. È quasi sempre la risposta sbagliata.
Gli errori e le domande indicano punti specifici che non funzionano — uno o due passaggi, non l’intera struttura. Riscrivere tutto significa perdere quello che già funziona e ricominciare il ciclo di perfezionamento.
La regola pratica: identifica il passaggio esatto che ha generato l’errore o la domanda, riscrivilo, ritesta solo quello. Il resto della procedura non si tocca.
Quanto dura una procedura prima di dover essere aggiornata
Una delle preoccupazioni che alimenta il perfezionismo è questa: “Se la pubblico adesso e poi cambia qualcosa, devo riscriverla.”
È vero — ma è un argomento a favore della pubblicazione, non contro. Una procedura in uso genera feedback reali. Una procedura in bozza genera solo supposizioni su cosa potrebbe non funzionare.
Le procedure operative standard non sono documenti statici. Hanno un responsabile, una data di revisione, e un meccanismo per raccogliere segnali di obsolescenza — un passaggio che non funziona più, uno strumento cambiato, un ruolo ridefinito.
Quello che rende una procedura duratura non è la completezza iniziale. È la presenza di qualcuno che la mantiene aggiornata nel tempo.
| Se stai ancora costruendo la struttura delle tue prime procedure, l’articolo su come scrivere una SOP che il team segue e quello sul modello SOP sono i punti di partenza pratici prima di affrontare il tema della pubblicazione. |
L’azione da fare adesso
Prendi la procedura che stai ancora rifinendo — quella che è “quasi pronta” da più di due settimane.
Mandala oggi a una persona del team. Non spiegarle nulla. Chiedi solo: riesci a seguirla senza domande?
Se la risposta è sì: è pronta. Pubblicala.
Se la risposta è no: chiedi dove si è bloccata. Riscrivi solo quel passaggio. Ritesta.
Il ciclo di perfezionamento finisce quando qualcuno riesce a usarla — non quando tu smetti di trovare cose da migliorare. Quel momento non arriva mai da solo.
Hai le procedure — ma non sai da quale collo di bottiglia partire?
La mappa delle decisioni è un quiz gratuito di autodiagnosi in 10 domande. Identifica dove la tua azienda perde più controllo e quale area strutturare per prima — processi, decisioni, autonomia del team.
La mappa delle decisioni — quiz gratuito di autodiagnosi in 10 domande.
Ti restituisce uno dei tre profili più comuni negli imprenditori in questa fase, con indicazioni su dove intervenire per primo.
