Il problema, detto con precisione

Il problema non è «automatizzare il processo». Il processo standard, di solito, funziona già: è stato disegnato, è ripetitivo, le persone lo eseguono senza pensarci.

Il problema è che le eccezioni consumano il tempo di chi dovrebbe occuparsi d'altro. Il dieci per cento anomalo assorbe l'ottanta per cento dell'attenzione di un responsabile, e lo fa nel modo peggiore: a spizzichi, in mezzo ad altro, senza che nessuno lo veda come lavoro.

  • L'anomalia si nota tardi, quando correggerla costa molto più che accorgersene.
  • La ricostruzione precede la decisione: prima di decidere qualcosa bisogna passare venti minuti a capire cos'è successo, su tre sistemi diversi.
  • Le eccezioni non lasciano traccia, quindi non si impara: la stessa anomalia si ripresenta e ricomincia lo stesso lavoro.

Tre punti d'innesto, non uno

La domanda utile non è «possiamo usare un agente». È: in quale punto del processo, e con quanta autonomia. I punti sono tre, e hanno profili di rischio molto diversi.

SOGLIA DI CONTROLLO 1 · RILEVARE accorgersi che c'è un'anomalia rischio basso 2 · PREPARARE ricostruire il quadro e proporre opzioni rischio medio 3 · ESEGUIRE agire sui sistemi, avviare, comunicare rischio alto DOVE COMINCIARE Quasi tutto il valore sta nei primi due, e quasi tutto il rischio nel terzo. Chi comincia dal terzo di solito torna indietro; chi comincia dal primo di solito arriva al secondo.

Rilevare e preparare non cambiano nulla nel mondo: producono informazione per una persona che poi decide. Eseguire cambia lo stato di un sistema, e da lì in avanti valgono le regole di qualunque automazione — con l'aggravante che il criterio di attivazione non è una regola scritta da qualcuno, ma il giudizio di un modello.

I quattro modi in cui sbaglia

1 · VEDE UN'ECCEZIONE CHE NON C'È Genera lavoro invece di toglierlo. Se capita spesso, le persone smettono di guardare le segnalazioni. Ed è finita. 2 · NON VEDE QUELLA CHE C'ERA Nessuno se ne accorge, perché l'assenza di una segnalazione non è un evento. È l'errore che non si misura da solo. 3 · GIUSTO, MA NEL MOMENTO SBAGLIATO Agisce prima che un'altra cosa sia successa. Le dipendenze fra passi sono ovvie per chi lavora, non per il sistema. 4 · LO FA DUE VOLTE Riprova dopo un errore di rete e invia due solleciti, apre due ticket, manda due comunicazioni. Banale, e frequentissimo.

Il secondo e il quarto sono quelli che si trascurano in fase di progetto e si scoprono in produzione. Il secondo perché non produce nessun segnale: un'anomalia non rilevata è indistinguibile dall'assenza di anomalie, e l'unico modo di misurarla è confrontare periodicamente con un controllo umano su un campione.

Il quarto perché è un problema di ingegneria vecchio quanto i sistemi distribuiti e non c'entra nulla con l'AI: un'azione va progettata in modo che eseguirla due volte produca lo stesso risultato di eseguirla una volta. Se questo non è vero, prima o poi succede.

Come si progetta

  • Il mandato, scritto. Quali azioni può compiere, su quali sistemi, entro quali limiti quantitativi, in quali orari. Un mandato che si può leggere in dieci righe è un mandato governabile; se non si riesce a scriverlo, il problema non è ancora chiaro.
  • La reversibilità prima di tutto. Si automatizza per primo ciò che si può annullare: preparare una bozza, aprire un'attività, proporre una classificazione. Per ultimo, o mai, ciò che esce verso un cliente o modifica un dato contabile.
  • La soglia. Sopra quale valore, quale rilevanza o quale grado di incertezza decide una persona. E soprattutto: la soglia deve dipendere anche dalla confidenza del sistema, non solo dall'importo. Un sistema incerto su un caso piccolo va fermato quanto uno certo su un caso grande.
  • La tracciabilità. Ogni azione lascia chi l'ha decisa, quando, su quale base e con quali dati. Serve a ricostruire un incidente, ma prima ancora serve a poter dire di sì a chi chiede conto — ed è la condizione che rende il resto accettabile in un'organizzazione.
  • L'escalation. Che cosa succede quando il sistema non sa. La risposta giusta non è «prova comunque»: è fermarsi e passare la mano, con il contesto già preparato per chi riceve.
  • L'interruttore. Come si spegne, chi può spegnerlo senza chiedere permesso, e che cosa succede al lavoro in corso. Va provato prima di andare in produzione, non durante il primo problema.

Come si collauda

Un'automazione non si collauda a campione sui casi che funzionano: si collauda in ombra. Il sistema gira accanto al processo reale per alcune settimane proponendo le azioni senza eseguirle, e si confronta ogni proposta con ciò che la persona ha effettivamente deciso.

QUATTRO SETTIMANE IN OMBRA, PRIMA DI ESEGUIRE QUALSIASI COSA PROPONE E LA PERSONA AVREBBE FATTO LO STESSO È la misura che tutti guardano, ed è la meno interessante delle tre. PROPONE E NON ANDAVA FATTO Il costo qui non è l'azione: è la fiducia. Poche di queste e nessuno guarda più. NON PROPONE NULLA E ANDAVA FATTO Va cercata apposta: non produce nessun segnale e non si scopre da sola.

Il collaudo in ombra ha un secondo effetto, spesso più prezioso del primo: costringe a scrivere che cosa la persona ha deciso e perché. In molte organizzazioni quell'informazione non è mai esistita, e averla vale indipendentemente da come finisce il progetto.

Quando non conviene

  • Quando il processo non è stabile. Se cambia ogni due mesi, si automatizza il disordine e lo si rende più difficile da vedere.
  • Quando il processo non è misurato. Senza una misura di partenza non si potrà dimostrare che è migliorato, e il progetto verrà giudicato sulle impressioni.
  • Quando l'azione è irreversibile e verso l'esterno. Comunicazioni al cliente, movimenti contabili, atti con effetti. Lì il livello giusto è preparare, non eseguire — e resta giusto anche quando la tecnologia migliora.
  • Quando il volume non ripaga il governo. Un'automazione va mantenuta, monitorata e collaudata di nuovo a ogni cambiamento. Sotto una certa frequenza costa più di quanto risparmia.