Quando un processo disordinato viene automatizzato, la confusione non scompare; cambia solo la portata e la velocità. Un criterio ambiguo applicato da una persona produce decisioni incoerenti che prima o poi qualcuno noterà; lo stesso criterio ambiguo applicato da un sistema produce migliaia di decisioni sistematicamente errate prima che qualcuno se ne accorga.
È proprio questo cambiamento di scala che rende l'automazione di un processo inefficiente peggiore rispetto al lasciarlo com'era, e non semplicemente invariato.
L'errore cessa di essere rilevabile per contrasto. In un processo manuale, la variabilità interpersonale funge da sistema di allarme: quando qualcuno risolve un caso in modo diverso, la differenza viene discussa e l'approccio viene corretto. L'automazione elimina questa variabilità e, con essa, il segnale di allarme.
La correzione cessa di essere puntuale. Scoprire un errore tre settimane dopo non significa risolvere un caso; significa rivedere e rifare tutto ciò che è stato elaborato durante quelle tre settimane. Il costo per correggere l'errore aumenta linearmente con il tempo di rilevamento.
Le eccezioni si stanno moltiplicando anziché diminuire. Un processo mal definito genera casi che non si adattano. Anche quando automatizzato, questi casi continuano ad arrivare e ora richiedono una gestione manuale al di fuori del flusso di lavoro, il che spesso si traduce in un carico di lavoro maggiore rispetto a prima.
La responsabilità si fa sfumata. Quando un caso viene gestito in modo errato, la risposta diventa "è colpa del sistema". E questa non è una risposta utile né per un cliente né per un revisore dei conti, come è emerso chiaramente nel caso del chatbot di Air Canada, risolto nel 2024: l'azienda è responsabile di ciò che fa il suo software.
Momento | Ciò che si osserva | Cosa sta succedendo davvero? |
|---|---|---|
Settimane 1-2 | Tutto funziona, c'è entusiasmo | I casi semplici vengono elaborati |
Settimane 3-6 | Appaiono casi "rari"« | Emergono eccezioni non previste |
Mesi 2-4 | Il lavoro manuale parallelo è in crescita | Il processo si è biforcato |
Mesi 4-6 | È stato rilevato un errore sistematico | È necessario rivedere i dati storici. |
La sequenza è talmente ripetitiva da fungere da strumento diagnostico. Se un progetto di automazione procede bene per le prime settimane e poi, nel secondo mese, inizia a generare lavoro parallelo, il problema non è l'implementazione: è che il processo non è stato definito al momento dell'automazione.
Esiste un controllo preliminare che richiede un pomeriggio e previene la maggior parte di questi casi: Fornisci lo stesso insieme di venti casi reali a tre persone diverse del team e confronta le loro decisioni..
Se tutti e tre i criteri concordano su diciotto o più, il processo è sufficientemente definito da poter essere automatizzato. Se concordano su dodici, non esiste un processo: ci sono tre criteri che coesistono e l'automazione significa sceglierne uno dei tre senza comunicarlo a nessuno.
Questo esercizio possiede anche un pregio politico: trasforma una discussione astratta sulla maturità dei processi in un fatto inconfutabile.
Scoprire che un processo non è pronto non significa dover rimandare tutto di sei mesi. Esistono tre interventi che producono risultati rapidi:
Definire i criteri nei casi frequenti. Non tutte: la sezione 80% del volume si concentra solitamente su quattro o cinque situazioni. Mettere per iscritto i criteri per queste cinque situazioni risolve la maggior parte delle ambiguità durante una sessione di lavoro.
Automatizzate solo la fase di preparazione. Raccogli le informazioni, confrontale e presentale in modo che una persona possa prendere una decisione. Questo permette di ottenere un notevole risparmio ed evita la diffusione di informazioni errate.
Strumentazione prima dell'automazione. La misurazione del processo manuale nell'arco di alcune settimane fornisce un valore di riferimento e rivela la variabilità effettiva, che è esattamente l'informazione mancante necessaria per prendere una decisione.
Tutte e tre sono compatibili per andare avanti. Nessuna di esse richiede un progetto di riprogettazione completo prima di apportare qualsiasi modifica.
È importante quantificare l'inversione di tendenza, perché è proprio questa la voce che trasforma un progetto redditizio in uno disastroso.
Se un sistema elabora duecento casi al giorno e dopo sei settimane viene rilevato un errore sistematico, ci sono circa seimila casi da esaminare. Anche se solo il caso 10% è interessato, si tratta comunque di seicento casi da correggere, oltre alla relativa comunicazione con il cliente, alle rettifiche contabili e all'impatto sulla reputazione.
Quel calcolo non compare quasi mai nel business case, ed è per questo che il tempo di guasto dovrebbe essere una metrica del comitato, come abbiamo sostenuto in L'automazione senza osservabilità è irresponsabile
Prima di automatizzare qualsiasi processo, c'è una domanda che guida la decisione: Se questo sistema è sistematicamente errato, quando lo scopriremmo e quanto costerebbe porvi rimedio?
Se la risposta è "in poche ore e con un clic", il rischio di automatizzare un processo imperfetto è accettabile e vale la pena procedere. Se invece la risposta è "in settimane e dovremmo analizzare i dati storici", il processo deve essere definito prima di poter essere automatizzato.
Non è una questione di prudenza. È una questione di aritmetica.
Il problema cambia scala: un criterio ambiguo applicato da una persona produce decisioni incoerenti che qualcuno alla fine nota, mentre applicato da un sistema produce migliaia di decisioni sistematicamente errate prima che qualcuno se ne accorga.
La variabilità individuale funge da sistema di allarme: quando qualcuno risolve un caso in modo diverso, la differenza viene discussa e l'approccio viene corretto. L'automazione elimina questa variabilità e con essa il segnale che ha permesso di individuare il problema.
Il processo consiste nel sottoporre lo stesso insieme di venti casi reali a tre membri del team e confrontare le loro decisioni. Se concordano su diciotto o più casi, il processo è definito; se concordano su dodici casi, coesistono diversi criteri e l'automazione implica la scelta di uno di essi senza una decisione esplicita.
Tre elementi compatibili con il progresso: definire i criteri per i quattro o cinque casi che concentrano il volume 80%, automatizzare solo la preparazione delle informazioni lasciando la decisione a una persona e implementare il processo manuale per alcune settimane per ottenere la base di riferimento.
Il problema si aggrava con il tempo di rilevamento. Un sistema che elabora duecento casi al giorno, con un guasto rilevato dopo sei settimane, implica la revisione di circa seimila casi; anche se solo il codice 10% è interessato, si tratta di seicento correzioni, con la relativa comunicazione al cliente e la conseguente rettifica contabile.
Se il sistema commette errori sistematici, quando verrebbero rilevati e quanto costerebbe correggerli? Se la risposta è entro poche ore e con un solo clic, il rischio è accettabile; se invece occorrono settimane e occorre analizzare i dati storici, il processo deve essere definito prima di poter essere automatizzato.
Il tuo processo è pronto per essere automatizzato? Prima di scrivere una sola riga di codice, testiamo il sistema con casi reali e vi indichiamo quale parte deve essere automatizzata e quale deve essere definita per prima. Parliamone →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
