Documentare i processi prima di automatizzarli: metodo in una pagina

Documentare un processo prima di automatizzarlo significa scrivere in modo esplicito chi fa cosa, in quale ordine, con quali informazioni e con quali eccezioni. Serve perché un'automazione costruita su un processo non definito fissa il disordine esistente e lo rende più veloce: il software esegue le regole che gli dai, comprese quelle sbagliate.

Nella pratica succede quasi sempre così: un'azienda chiede di automatizzare un'attività, e alla prima domanda su come funziona oggi emergono tre versioni diverse da tre persone diverse. Non è un difetto dell'azienda, è la condizione normale di qualunque organizzazione che non ha mai scritto i propri processi. Ma è una condizione incompatibile con l'automazione.

La buona notizia è che documentare non richiede metodologie complicate né mesi di lavoro. Per un processo operativo bastano una pagina, un'ora di conversazione con chi lo esegue e la disciplina di non scrivere come vorremmo che funzionasse, ma come funziona davvero.

Questa guida chiude il percorso generale sull'automazione dei processi ed è quella che consigliamo di leggere per prima, anche se logicamente arriva per ultima.

Una descrizione utile all'automazione ha sette elementi. Se ne manca uno, il progetto si fermerà proprio lì.

L'innesco: che cosa fa partire il processo. Una telefonata, un modulo compilato, una data che arriva, la conclusione di un altro processo. Va scritto con precisione, perché è il punto in cui l'automazione si aggancia.

Gli attori: chi interviene, con nome del ruolo e non della persona. Se un passaggio è legato a una persona specifica, è un rischio da segnalare.

I passaggi, in ordine, con un verbo per ciascuno. Se un passaggio richiede più di una riga per essere descritto, quasi sempre sono due passaggi.

Le informazioni: quali dati servono a ogni passaggio e da dove arrivano. È l'elemento che determina se e come sarà possibile integrare i sistemi.

Le decisioni: i punti in cui il percorso si biforca, con il criterio esplicito della scelta. "Dipende" non è un criterio: va trasformato in una regola o dichiarato come punto che resta umano.

L'esito: come si capisce che il processo è finito bene. Un processo senza esito definito non può essere misurato e quindi non può essere migliorato.

I tempi: quanto dura ciascun passaggio e quanto è accettabile che duri. È la base per capire dove conviene intervenire.

Il metodo più efficace è anche il più semplice: osservare e chiedere a chi esegue, non a chi coordina. La descrizione che dà un titolare è la versione ideale del processo; la descrizione di chi sta alla reception è quella reale, e l'automazione deve partire dalla seconda.

Un'ora di conversazione per processo è di solito sufficiente, se si seguono le domande giuste: cosa fai quando arriva, dove guardi, cosa scrivi e dove, a chi passi la pratica, cosa succede se manca un'informazione, quali sono i casi che ti fanno perdere più tempo.

L'ultima domanda è la più preziosa. I casi che generano frustrazione sono quasi sempre gli stessi che generano errori e che rallentano il processo: sono i primi candidati all'automazione.

Conviene poi verificare la descrizione su casi reali. Si prendono cinque pratiche recenti e si controlla se sono passate davvero per i passaggi descritti. Quasi sempre due su cinque hanno seguito un percorso diverso: quelle due sono le eccezioni che il progetto deve considerare.

Va evitato il questionario. Le schede compilate in autonomia producono descrizioni generiche, perché chi le compila tende a scrivere la procedura ufficiale e non quella applicata.

Il percorso principale di un processo è quasi sempre semplice e occupa poche righe. Quello che fa naufragare i progetti sono le eccezioni, e vanno trattate esplicitamente fin dall'inizio.

Prima regola: le eccezioni vanno elencate e quantificate. Non basta sapere che esistono, serve sapere quanto sono frequenti. Un caso che capita due volte l'anno non merita di essere automatizzato; un caso che capita due volte a settimana è parte del processo, non un'eccezione.

Seconda regola: per ogni eccezione si decide una delle tre strade. Viene inclusa nel flusso automatico, perché frequente e regolare. Viene gestita a mano con un percorso previsto, quindi il flusso deve saperla riconoscere e passarla a una persona. Oppure viene eliminata, cambiando una regola a monte: succede più spesso di quanto si pensi che un'eccezione esista solo per un'abitudine che nessuno ha più motivo di mantenere.

Terza regola: quello che non è stato previsto deve fermarsi in modo visibile, non passare inosservato. Un flusso che, davanti a un caso ignoto, procede comunque con un valore predefinito genera errori che si scoprono mesi dopo.

Nella pratica, la conversazione sulle eccezioni è quella che restituisce più valore all'azienda anche a prescindere dall'automazione, perché costringe a decidere cose che erano state rimandate per anni.

Il formato migliore è quello che le persone rileggeranno davvero. Un documento di trenta pagine con notazione formale è tecnicamente ineccepibile e praticamente inutile in un'azienda di dieci persone.

Consigliamo una pagina per processo, con i sette elementi elencati sopra, scritta in linguaggio corrente. Uno schema visivo aiuta quando ci sono più biforcazioni, ma non sostituisce il testo: i criteri delle decisioni in uno schema non ci stanno.

Le notazioni standard hanno senso quando il processo attraversa più reparti o quando l'azienda ha già una cultura di gestione dei processi. Per uno studio o una piccola struttura, la pagina in linguaggio corrente vince quasi sempre.

Sullo strumento: qualunque posto in cui il documento sia trovabile da tutti, modificabile e con una storia delle versioni. Un archivio condiviso ordinato vale più di una piattaforma sofisticata che nessuno apre.

Un accorgimento che fa la differenza: ogni documento riporta chi lo mantiene e la data dell'ultima revisione. Una documentazione senza responsabile smette di essere aggiornata dopo pochi mesi e diventa peggio di niente, perché descrive un processo che non esiste più.

Una volta che il processo è descritto, il passaggio all'automazione diventa un lavoro tecnico con confini chiari. Ecco come si legge la descrizione in chiave progettuale.

L'innesco diventa il punto di attivazione del flusso: un modulo, un messaggio in arrivo, un orario, un cambiamento di stato in un sistema.

Le informazioni indicano quali integrazioni servono. Se un dato arriva da un sistema che non espone alcun accesso, quello è il vincolo tecnico principale del progetto e va affrontato subito, non a costruzione avviata.

Le decisioni si dividono in due gruppi: quelle con criterio esplicito, che il flusso può eseguire, e quelle che richiedono giudizio, che diventano punti di passaggio a una persona. La qualità di questa separazione determina quanto il risultato sarà accettato da chi lavora.

L'esito diventa la misura: è il dato che permette di dire se il flusso funziona. Va registrato dal primo giorno.

I tempi diventano soglie di allarme: se un passaggio supera la durata accettabile, qualcuno deve essere avvisato. È la funzione che, più di ogni altra, evita che le pratiche restino ferme.

Una documentazione scritta una volta e mai più toccata perde valore rapidamente. Bastano però poche regole per mantenerla utile senza che diventi un lavoro a sé.

Ogni modifica al flusso automatico comporta l'aggiornamento della pagina che lo descrive. Se la modifica la fa un fornitore, l'aggiornamento è parte del lavoro, non un extra.

Una revisione periodica, anche solo due volte l'anno, in cui si rileggono i processi chiave e si verifica che corrispondano alla realtà. Trenta minuti per processo bastano.

L'inserimento di una nuova persona è il miglior momento di verifica: se riesce a lavorare seguendo il documento, il documento è buono. Se deve chiedere a un collega, manca qualcosa.

Infine, la documentazione ha un valore che va oltre l'automazione: riduce la dipendenza dell'azienda da singole persone, rende possibili le assenze senza blocchi e trasforma il passaggio di consegne da evento traumatico a operazione ordinaria. Per molte realtà che seguiamo è questo, più del risparmio di tempo, il beneficio che si nota per primo.

Prima di passare alla costruzione del flusso conviene rileggere il documento cercando tre segnali. Se compaiono, il lavoro di analisi non è finito e procedere significa accumulare modifiche costose più avanti.

Il primo segnale è la parola "normalmente". Se un passaggio è descritto come "normalmente si fa così", significa che esiste un caso diverso che nessuno ha ancora esplicitato. Va cercato e scritto.

Il secondo è l'assenza di numeri. Un processo descritto senza frequenze e senza durate non permette di decidere cosa conviene automatizzare: senza volumi, ogni passaggio sembra ugualmente importante.

Il terzo è la presenza di nomi di persona al posto dei ruoli. Quando la descrizione dice "lo fa Marta" invece di "lo fa la segreteria", il processo dipende da una persona e il documento sta fotografando un rischio organizzativo, non una procedura.

Correggere questi tre punti richiede in genere una seconda conversazione di mezz'ora. È il mezz'ora meglio investito dell'intero progetto, perché evita che le stesse ambiguità riemergano durante la realizzazione, quando ogni modifica costa molto di più.