Process intelligence · 5 min di lettura

Il ritardo invisibile: come accorgersene prima del cliente

28 ottobre 2026

Pratiche che si fermano in silenzio, approvazioni dimenticate, scadenze scoperte tardi. Il problema non è il ritardo in sé, ma il fatto che nessuno lo veda mentre è ancora recuperabile.

Il problema è non vedere il ritardo

Una pratica ferma da tre giorni in una fase non fa rumore. Non genera errori, non blocca uno schermo, non compare in un report finché qualcuno non chiede dove sia finita. Di solito a chiederlo è il cliente.

In una PMI, dove le persone ricoprono più ruoli e i passaggi si appoggiano a email e promemoria personali, il ritardo si presenta in tre forme ricorrenti: la pratica che si ferma in silenzio, l'approvazione dimenticata, la scadenza scoperta quando è già passata. Il ritardo in sé spesso ha una spiegazione ragionevole. Quello che pesa è che nessuno l'abbia visto quando c'era ancora margine per intervenire.

Questo articolo riguarda la sorveglianza dei tempi e delle responsabilità: come rendere visibile ciò che è fermo e stabilire a chi tocca muoverlo. Segue il principio con cui lavoriamo in FlowSharp: prima misura, poi automatizza.

Cosa dice la ricerca Bain sulle decisioni, e cosa non dice

Bain & Company ha studiato la «decision effectiveness» su un campione di quasi 800 aziende, poi ripresa nel libro «Decide & Deliver» di Michael Mankins e Paul Rogers. Secondo Bain, esiste una correlazione del 95% tra le aziende che eccellono nel prendere ed eseguire le decisioni chiave e quelle con risultati finanziari di fascia alta, misurati in crescita dei ricavi, ritorno sul capitale e rendimento per gli azionisti. Qualità e rapidità sono due delle dimensioni misurate.

I limiti vanno detti con chiarezza. Le risposte sono autovalutazioni dei dirigenti, e Bain stessa riconosce il possibile effetto alone: chi ottiene buoni risultati può tendere a giudicare buone anche le proprie decisioni. Inoltre si tratta di una correlazione, che non prova che decisioni migliori causino risultati migliori.

La usiamo quindi come un indizio, non come una promessa: suggerisce che la rapidità e l'esecuzione delle decisioni contano. Una pratica ferma è spesso una decisione non presa o non eseguita: approvare, instradare, rispondere. La cifra descrive il problema. Non dimostra che un software lo risolva, e nemmeno che FlowSharp lo faccia.

Tre punti ciechi: automazione, attese umane, scadenze

Il primo è l'automazione che si ferma. In una fase automatica o AI una pratica può restare ferma, per esempio perché nessuna regola corrisponde e manca un ramo predefinito, oppure perché l'esecuzione AI è fallita. In FlowSharp compare un avviso persistente «Automazione ferma», uno per pratica e fase, che gli Admin ricevono secondo la policy di notifica del flusso. Esiste anche un controllo a monte: un processo non si pubblica se una fase automatica non ha una via certa di avanzamento, cioè una regola predefinita, un timeout con destinazione o un'escalation SLA.

Il secondo è il lavoro umano in attesa. Qui la policy di notifica prevede step temporali con email, webhook o evento, digest per destinatario e fasce orarie, così i solleciti non diventano rumore. La presa in carico avviene con un clic esplicito su un link monouso con scadenza: «ho visto la richiesta» diventa un fatto registrato, non un'impressione. Gli Admin vedono i tempi di presa in carico e di risoluzione.

Il terzo è la scadenza scoperta tardi. Con il timeout di fase, una pratica può avanzare in automatico verso una destinazione quando il termine scade, e lo storico lo etichetta «Timeout» o «SLA». La durata può usare variabili, per esempio una durata SLA condivisa tra più flussi. Per le pratiche create da un assistente esterno su un flusso con conferma di avvio, la scadenza è configurabile, con promemoria e rifiuto automatico oppure un avviso di scaduta.

Leggere i tempi: dall'indicatore alla singola pratica

Per vedere il quadro d'insieme, la sezione Analisi mostra gli indicatori «SLA warning attivi» ed «Escalation SLA attive», il Lead Time medio, i punti in cui le pratiche restano ferme e le fasi che richiedono più tempo. Sono i numeri da guardare prima di decidere dove intervenire.

Le fasi sature sono un segnale complementare. Con il limite WIP si vedono le pratiche ammesse, quelle in coda e la percentuale di saturazione: una coda che cresce è un ritardo in formazione, visibile prima che diventi una scadenza mancata.

Dall'aggregato si scende al singolo caso con i filtri della lista Pratiche: scadute, deviate, in coda WIP, con automazione ferma. È una lista di lavoro per chi coordina, non un archivio: permette di aprire la mattina e sapere quali pratiche meritano una telefonata prima che la faccia il cliente.

Da dove cominciare: misurare, poi assegnare, poi automatizzare

Un ordine pratico, coerente con «prima misura, poi automatizza». Primo: scegliere un flusso in cui il cliente ha già dovuto chiedere a che punto fosse la sua pratica. Secondo: guardare il Lead Time medio e le fasi in cui le pratiche restano ferme, senza ancora cambiare nulla.

Terzo: per ogni fase critica scrivere tre cose, cioè chi è responsabile, entro quanto tempo deve muoversi e che cosa succede alla scadenza. Solo a quel punto ha senso configurare timeout, escalation e notifiche, perché ciascuna di queste regole presuppone una risposta già data a quelle tre domande.

Non c'è garanzia che i ritardi spariscano. Il risultato realistico è un altro: spostare il momento della scoperta dal cliente al team, quando c'è ancora tempo per decidere. È una modesta ambizione, e proprio per questo verificabile sui propri dati.