Quando il muro è quello sbagliato: come si documenta davvero un processo

di Stefania Cordiani | 10 giugno 2026

C'è una scena, nel film I soliti ignoti di Monicelli, che dovrebbe essere proiettata all'inizio dei corsi su come si documentano i processi.

La banda (Gassman, Mastroianni, un giovanissimo Salvatori, Totò nei panni del vecchio scassinatore che fa da consulente) prepara il colpo della vita con una cura incredibile, rubando persino una cinepresa per filmare la cassaforte del Monte di Pietà. Mandano Gassman a sedurre la cameriera dell'appartamento confinante, per ricostruire la piantina dei locali, si fanno insegnare il mestiere passo per passo e studiano, pianificano, documentano, a modo loro, ogni fase dell'operazione. Tutto sembra perfetto.

La notte del colpo scavano come talpe, sudano, sfondano il muro e quando, finalmente, passano dall'altra parte si ritrovano non davanti alla cassaforte ma nella cucina di una vecchietta, con una pentola sul fornello. Avevano bucato la parete sbagliata perché, tra il sopralluogo e l'esecuzione, qualcuno aveva spostato i mobili e la mappa che si erano costruiti con tanta fatica non corrispondeva più alla realtà.

Allo stesso modo, un processo documentato non è un processo descritto perché è un processo descritto come qualcuno ha creduto che fosse in un dato momento.

Questo articolo prova a rispondere alle domande che bisognerebbe porsi quando bisogna ricostruire un processo che esiste da anni ma che nessuno ha mai messo nero su bianco in modo decente.

Da dove si parte: l'output non mente

La tentazione, quando ci assegnano la ricostruzione di un processo, è aprire un software di diagrammi e cominciare a disegnare rettangoli ma il diagramma è un punto di arrivo, non di partenza. Se cominci da lì, finisci per disegnare il processo che ti aspetti, non quello che esiste davvero. Il punto da cui conviene partire è esattamente l'opposto: l'output. Cosa deve consegnare questo processo, a chi e con quali caratteristiche perché chi lo riceve sia soddisfatto? L'output è l'unica cosa che non mente, perché è verificabile: un lotto è conforme o non è conforme.

Una volta fissato l'output, si ricostruisce il processo a ritroso. Cosa serve per produrlo? Quali input, da chi, in quale stato? Quali attività trasformano gli input in quell'output? È il ragionamento che la ISO 9001 formalizza al punto 4.4 con l'approccio per processi, e che strumenti come il SIPOC traducono in pratica partendo proprio dai confini: chi fornisce cosa, chi riceve cosa. Su QualitiAmo ne abbiamo parlato a fondo nell'articolo dedicato a input e output dei processi qualità e il principio è semplice: prima si definiscono i confini, poi si entra nel merito.

C'è un passaggio che la maggior parte dei professionisti salta per fretta o per timore di disturbare chi sta lavorando: andare a guardare il lavoro mentre viene fatto, nelgemba. Prima di intervistare chiunque, prima di disegnare qualsiasi cosa, vale la pena passare mezza giornata accanto a chi quel processo lo esegue ogni giorno, a osservare quello che viene fatto (non quello che viene detto).

La trappola del responsabile unico

Chi dovrebbe partecipare alla documentazione di un processo? La risposta più comoda, affidarla al responsabile del processo, è anche la più sbagliata perché il responsabile descrive il processo da una posizione precisa ma quella posizione ha un punto cieco enorme perché conosce il processo come dovrebbe funzionare ma conosce molto meno il processo come funziona quando, ad esempio, manca un componente, o il gestionale è lento e l'operatore prende la scorciatoia che conoscono tutti gli operativi.

Erik Hollnagel, uno dei padri dell'ingegneria della resilienza, ha dato un nome a questo scarto che ormai è entrato nel vocabolario di chi studia la sicurezza e l'affidabilità.: lo chiama distanza tra work-as-imagined e work-as-done, il lavoro come viene immaginato da chi lo pianifica e da chi scrive le procedure, e il lavoro come viene effettivamente svolto da chi lo esegue.

Hollnagel sostiene che questi due piani non coincidono mai del tutto: il lavoro immaginato è una versione idealizzata che ignora come la prestazione debba continuamente adattarsi a condizioni che cambiano. Chi documenta intervistando solo chi sta in alto raccoglie il work-as-imagined e lo archivia credendo sia il work-as-done.

Da qui una regola operativa: triangolare. Servono almeno tre punti di vista.

Quando questi tre racconti combaciano, hai un processo semplice. Quando divergono (e divergono quasi sempre) biosgna mettersi a caccia delle informazioni utili per capire meglio la realtà.

Far parlare il lavoro invisibile

Veniamo alla domanda più difficile: quali domande si fanno alle persone operative per far emergere le attività invisibili, le scorciatoie, le eccezioni, i passaggi che tutti danno per scontati?

La prima cosa da capire è che la domanda diretta non funziona: se chiedi a un operatore "come fai X?", ti risponderà con la versione ufficiale, quella che ha imparato al corso che è quella che pensa tu voglia sentire perché tendiamo a descrivere le nostre azioni nei termini astratti e ordinati con cui le abbiamo apprese, non nei termini disordinati con cui le eseguiamo.

Lo dimostrò in modo memorabile un antropologo americano, Julian Orr, in una delle ricerche più istruttive che siano mai state fatte sul lavoro reale. Orr, che prima di diventare ricercatore aveva fatto il tecnico nell'esercito, passò anni a seguire sul campo i tecnici riparatori di fotocopiatrici. Ne uscì un libro, Talking About Machines (1996), che fece scuola perché la scoperta era spiazzante: il manuale ufficiale di riparazione, quello che l'azienda forniva, spesso non funzionava. Le procedure prescritte o non risolvevano il guasto, oppure riguardavano problemi così banali che nessun tecnico esperto aveva bisogno di leggerle.

Dove stava, allora, il sapere che faceva funzionare il lavoro? Nelle storie che i tecnici si scambiavano durante la pausa pranzo: le war stories, i racconti di quel guasto assurdo, di quella macchina che faceva quel rumore, di come ci si era arrivati a capire. La diagnosi, scoprì Orr, era un processo narrativo: si costruiva una storia coerente del guasto e quel sapere circolava oralmente, da persona a persona, completamente invisibile all'organizzazione che pure ci campava sopra.

Il modo in cui le persone lavorano davvero differisce in modo fondamentale dal modo in cui le organizzazioni descrivono quel lavoro nei manuali, nei programmi di formazione, negli organigrammi e nei mansionari. Eppure le organizzazioni continuano a fidarsi di questi ultimi. — John Seely Brown e Paul Duguid, Organizational Learning and Communities-of-Practice, 1991

Brown e Duguid teorizzarono il caso distinguendo tra pratica canonica, quella dei manuali, degli organigrammi, dei mansionari, e pratica non canonica, quella reale. Il loro punto è lo stesso di Hollnagel da un'altra angolazione: il modo in cui le persone lavorano davvero differisce in modo profondo dal modo in cui le organizzazioni descrivono quel lavoro, eppure le organizzazioni continuano cocciutamente a fidarsi delle descrizioni. È il rischio che corre chi tiene la conoscenza dentro la testa di poche persone senza trasferirla, un tema che abbiamo toccato parlando del paragrafo 7.1 della norma e della conoscenza organizzativa.

Allora come si stana il sommerso? Con domande indirette, che aggirano la versione ufficiale invece di chiederla.

C'è anche un perché dietro le scorciatoie, e conviene conoscerlo per non demonizzarle. Hollnagel lo ha chiamato principio ETTO, Efficiency-Thoroughness Trade-Off: davanti alla pressione, le persone barattano sistematicamente accuratezza per efficienza. Quando documenti un processo e scopri una scorciatoia, la domanda giusta non è "perché violano la procedura?", ma "cosa rende la procedura impraticabile al punto da costringerli a inventarsi un'alternativa?".

Il giusto grado di dettaglio

Quanto dettaglio serve? Da un lato c'è il documento troppo generico, quello che sembra una procedura ma non dice nulla che chi non conosce già il processo possa usare. Dall'altro c'è il documento iper-minuzioso, quaranta pagine che descrivono ogni clic del mouse, talmente esaustivo da risultare illeggibile, e quindi anch'esso inutile, perché nessuno lo aprirà mai.

Il criterio che uso per documentare è quello che chiamo "dei due lettori". Una buona documentazione di processo deve funzionare per due persone molto diverse: per il nuovo assunto che la apre per orientarsi e capire cosa fare e che ha bisogno di conoscere il flusso, la sequenza, le responsabilità e per l'esperto, che la apre (raramente) per allinearsi su un'eccezione o un caso limite che non gli capita spesso (alui non serve che gli si spieghi come si accende il computer, gli serve sapere cosa fare quando il caso non rientra nello standard). Se il documento serve solo al primo, l'esperto lo ignorerà; se serve solo al secondo, il nuovo assunto ci si perderà. La norma stessa, quando parla di informazioni documentate, non chiede di documentare tutto: chiede di mantenerle "nella misura necessaria". Quel "necessario" è il punto e va calibrato processo per processo.

Qui si innesta la scelta tra rappresentazione visiva e procedura narrativa: un diagramma di flusso è perfetto quando il processo è sequenziale e a basso tasso di decisione perché mostra il "cosa" e il "in che ordine" meglio di qualsiasi testo. Ma il diagramma ha un limite strutturale: mostra il cosa ma non sa dire il perché. Quando un passaggio esiste per una ragione non ovvia (un controllo che sembra ridondante ma che previene un errore costato caro anni fa) il diagramma da solo non basta perché bisogna spiegare.

Gli elementi irrinunciabili (e i due che tutti dimenticano)

Cosa non dovrebbe mai mancare nella documentazione di un processo? La lista classica la conosciamo tutti: obiettivo, input, output, responsabilità, rischi, indicatori, interazioni, evidenze, strumenti. Lo strumento che li raccoglie tutti su una pagina sola è il turtle diagram, il diagramma a tartaruga.

Quando il processo non è una linea retta

E i processi che di lineare non hanno niente? Quelli pieni di varianti, eccezioni, biforcazioni, attività che dipendono dal caso specifico? Qui il diagramma di flusso unico mostra tutti i suoi limiti: se provi a infilarci ogni variante, ottieni un groviglio illeggibile; se le ometti, non documenti la realtà.

La strada che funziona è smettere di inseguire la sequenza unica e cambiare logica. Una prima mossa è separare i piani: si documenta in modo pulito il percorso principale, e a parte si documenta la gestione delle eccezioni, con le sue regole e i suoi criteri di decisione. Tenerli insieme li rende illeggibili entrambi; separarli li rende usabili tutti e due.

Ma c'è un caso ancora più estremo, ed è quello dei processi ad alta intensità di conoscenza, dove la variabilità non è un'eccezione ma la regola. Il lavoro di un pronto soccorso non si documenta come una catena di montaggio e il tentativo di farlo produce solo carta che non serve a nulla. Per questi processi conviene rinunciare alla pretesa di descrivere le sequenze e documentare invece i principi guida, i vincoli da rispettare, gli obiettivi da raggiungere e i criteri con cui decidere, lasciando alla competenza delle persone il "come", perché quel "come" cambia ogni volta.

L'intelligenza artificiale per documentare i processi

Veniamo a una domanda che oggi nessuno può più evitare: che ruolo ha l'AI nella documentazione dei processi?

Comincio dalle cose in cui è davvero utile, perché sono parecchie e concrete. L'AI è un'ottima alleata per trascrivere e ordinare le interviste agli operativi, trasformando ore di registrazione in un testo navigabile. È brava a produrre una prima bozza strutturale a partire da appunti grezzi, dandoti uno scheletro da correggere invece della pagina bianca. È preziosa anche per mantenere la coerenza terminologica lungo decine di documenti, segnalando dove lo stesso concetto è chiamato in tre modi diversi e sa individuare incoerenze logiche tra documenti che un occhio umano, stanco, si lascia sfuggire.

Poi c'è il lato problematico: i modelli linguistici sono stati addestrati su una quantità enorme di processi standard, purchase-to-pay, order-to-cash, gestione dei reclami. Hanno imparato come "di solito" vanno le cose. Quando gli dai da modellare un processo che devia dallo standard (perché la tua azienda fa una cosa in modo anomalo per ottime ragioni) il modello tende a "correggere" silenziosamente la tua anomalia verso lo schema che si aspetta e a produrre un diagramma coerente e plausibile ma sbagliato (o, meglio, fedele a ciò che il modello sa, infedele a ciò che tu gli hai detto). Questo, ovviamente, non avviene quando si impara a dargli gli input giusti e lo si addestra ma, se sei alle prime armi, ti consiglio di prestare grande attenzione.

Per questo l'AI è uno strumento eccellente sulla forma e infido sulla sostanza e va usata esattamente così: per accelerare la stesura di ciò che un essere umano ha già verificato sul campo, mai per generare la verità di un processo che nessuno è andato a guardare.

Quando un documento è sbagliato anche se sembra giusto

Quali sono i segnali che un processo è stato documentato male, anche se il documento appare formalmente impeccabile? Ne ho raccolti alcuni negli anni, e funzionano come una mia personalissima checklist.