Alla fine di settembre, la comunità del process management si ritrova a Stoccarda per All about Process Management. Due giorni di keynote, masterclass e tavole rotonde e, a giudicare dal programma, un tema attraverserà la maggior parte di essi: gli agenti IA e cosa serve per lasciarli agire all'interno di un processo aziendale. Saremo presenti come espositori, e questa è la tesi che intendiamo sostenere.
Tutto comincia con qualcosa che non ha nulla a che fare con il software. Nella maggior parte delle aziende, scoprire cosa sta davvero andando storto in un processo richiede che qualcuno lo sospetti per primo.
Pensiamo a come emergono di solito queste cose. Un fornitore si lamenta per un pagamento in ritardo. Un manager nota che le approvazioni sembrano richiedere più tempo del solito. Un team ha la sensazione di fare due volte lo stesso lavoro. Qualcuno pone la domanda, e solo allora inizia il vero lavoro: estrarre i dati, costruire l'analisi, presentare i risultati, concordare una misura. Settimane dopo arriva una risposta, di solito buona.
Ma notate cosa doveva succedere prima di tutto questo. Qualcuno doveva avere un sospetto. E un sospetto si forma solo dove qualcuno è abbastanza vicino al lavoro da percepire che qualcosa non va. Tutto ciò che per caso nessuno percepisce resta invisibile: il reparto che non si lamenta mai, il passaggio di processo di cui nessuno è responsabile, l'eccezione che silenziosamente è diventata la norma. Non perché mancano i dati, ma perché a nessuno è venuto in mente di chiedere.
La risposta standard è un dashboard. Mettere i numeri su uno schermo, aggiornarli regolarmente e lasciare che le persone li guardino.
Aiuta, ma non risolve il problema di fondo. Un dashboard aspetta comunque di essere interrogato. Premia chi già sa quale grafico aprire, quale filtro impostare e quale numero è insolito per quel periodo dell'anno. Offre un modo per verificare più in fretta un sospetto, ma non fornisce il sospetto stesso. Così gli stessi punti ciechi sopravvivono, solo dietro un'interfaccia più gradevole.
Lo si vede da come i dashboard vengono davvero usati. Una manciata di specialisti li consulta costantemente. Quasi tutti gli altri li aprono solo quando gli viene chiesto, danno un'occhiata alla riga in alto e li richiudono. Non per disinteresse, ma perché scandagliare una vista di processo alla ricerca di anomalie è un lavoro davvero impegnativo, e la maggior parte delle persone ha già un altro lavoro da fare.
C'è un passaggio che quasi tutti saltano, perché sembra amministrativo più che intelligente. Se si vuole che un sistema segnali quando qualcosa è andato storto, bisogna prima dirgli come appare ciò che è corretto.
La maggior parte delle organizzazioni possiede questa conoscenza, ma vive nei posti sbagliati: in un manuale qualità che nessuno legge, in un documento di policy, nella testa della persona che fa questo lavoro da undici anni. Esiste come intenzione. Non esiste in una forma che si possa verificare.
Messa per iscritto correttamente, si rivela sorprendentemente semplice e sorprendentemente concreta. Una fattura non dovrebbe essere pagata prima di essere stata approvata. Un ordine non dovrebbe essere modificato tre volte dopo essere stato confermato. Chi richiede qualcosa non dovrebbe essere la stessa persona che lo autorizza. Una richiesta di un cliente non dovrebbe restare inevasa per più di cinque giorni. Niente di tutto questo è sofisticato. È ciò che le persone nel processo già credono, semplicemente reso esplicito.
In Process.Science Intelligence, è esattamente questo che sono i Process Norms: le proprie aspettative su un processo, scritte come regole e poi confrontate con ciò che è realmente accaduto nei propri sistemi, in ogni singolo caso e non su un campione. Dove i dati non permettono un verdetto chiaro, questo viene dichiarato apertamente, invece di essere silenziosamente conteggiato come a posto.
Questa è l'intera precondizione. Una volta stabilita, la direzione del lavoro può essere invertita.
Il percorso convenzionale va dal dashboard all'insight. Una persona apre una vista, cerca qualcosa che sembra sbagliato, formula un'ipotesi, filtra, approfondisce e alla fine arriva a una causa radice. Questo percorso dipende interamente dal fatto che qualcuno decida di guardare, sappia dove guardare e lo faccia abbastanza spesso. Scala con il numero di specialisti disponibili, il che significa che in pratica non scala.
Process.Science Intelligence ha una funzione chiamata Alerts che percorre la strada nella direzione opposta. Invece di aspettare di essere interrogato, il sistema confronta il processo con le proprie norme e indica esattamente i punti in cui la realtà si è discostata: qui, in questa parte del business, contro questa regola, così tante volte, così spesso di recente. Da quell'alert si passa direttamente all'analisi rilevante, e da lì alla causa radice: quali casi sono coinvolti, cosa hanno in comune, quanto tempo costa. Non c'è più bisogno di ricostruire il percorso, perché è già tracciato.
Non dal dashboard all'insight, ma dall'insight direttamente al punto giusto del dashboard, con la causa radice già in vista. E dove l'analisi mostra che le deviazioni si concentrano attorno a un fornitore, una sede o un tipo di documento, è esattamente questo che viene indicato. Una forte indicazione su dove guardare dopo vale moltissimo, e non è la stessa cosa di una prova, per questo non la presentiamo come tale.
La conseguenza è un cambiamento nel destinatario del lavoro sui processi. Il vecchio percorso serviva specialisti che conoscevano lo strumento, i dati e il processo abbastanza bene da muoversi tra tutti e tre contemporaneamente. Il nuovo serve le persone che possiedono il processo: team leader, controller, responsabili di reparto e manager dei servizi condivisi. Non devono sapere come costruire un'analisi. Devono sapere dove guardare, e poi essere in grado di seguire la pista da soli.
Per anni è stata una questione di efficienza. Meno punti ciechi, risposte più rapide, minore dipendenza da pochi analisti sovraccarichi. Utile da fare, ma non urgente.
L'automazione cambia le cose. Un software che approva, ordina, registra e risponde da solo non ha sospetti. Non nota che un fornitore è insolito, che una catena di approvazione è stata aggirata o che un passaggio è stato saltato perché qualcuno era in ferie. Le persone assorbono questo tipo di ambiguità costantemente e silenziosamente. Una macchina non ne assorbe nulla. Quindi, nel momento in cui si lascia che un software agisca all'interno di un processo, le regole non scritte devono diventare regole scritte, non per il bene dell'analisi, ma per definire il confine: dove può decidere la macchina, e dove deve restituire il controllo? Un'organizzazione che non ha mai stabilito come appare ciò che è corretto non ha modo di rispondere a questa domanda, né di sapere se la sua risposta reggerà ancora tra sei mesi.
Il valore si manifesta in tre punti. I problemi vengono trovati mentre sono ancora economici, perché una deviazione diventa visibile nella settimana in cui accade, non nel trimestre in cui qualcuno finalmente se lo chiede. Le persone che possiedono il processo possono agire da sole, il che significa che il miglioramento smette di aspettare in coda la disponibilità di un analista e inizia ad accadere dove si svolge il lavoro. E l'organizzazione finisce per avere qualcosa che prima non aveva: uno standard scritto e testato su come i propri processi dovrebbero funzionare. È questo standard a rendere difendibile il passo successivo, che si tratti di un accordo sugli obiettivi, di un audit o dell'affidamento di parte del processo a una macchina.
Niente di tutto questo dipende da un grande programma. Dipende dalla volontà di mettere per iscritto ciò che già si crede sul proprio processo, e poi lasciare che i dati diano ragione o torto.
Preferiamo discuterne piuttosto che affermarlo, perché la parte interessante è sempre il processo specifico: quali regole un'azienda ha la sicurezza di mettere per iscritto, e quali si rivelano più negoziabili di quanto chiunque si aspettasse.
Saremo presenti a All about Process Management il 30 settembre e il 1° ottobre 2026 presso l'ICS di Stoccarda, e mostreremo volentieri Alerts dal vivo, partendo da una singola deviazione fino ad arrivare alla causa radice. Passate al nostro stand per parlarne.
Preferite parlarne prima? Usate Parla con un esperto per organizzare una demo, che faremo su un vostro processo. Non vediamo l'ora di discuterne.
