Prima di automatizzare un processo, conviene ridisegnarlo
Automatizzare un processo sbagliato significa solo sbagliare più in fretta.
È l’errore più comune nei progetti di automazione: si prende il flusso di lavoro così com’è — con i passaggi accumulati negli anni, le approvazioni doppie, i fogli Excel di appoggio — e lo si trasferisce a un software. Il risultato è un processo inefficiente che ora costa anche una licenza.
Noi partiamo da un passo prima. Guardiamo come il lavoro scorre davvero oggi, misuriamo dove si ferma e quanto costa fermarsi, e ridisegniamo il flusso prima di automatizzarlo. Spesso emerge che metà dei passaggi esiste solo perché “si è sempre fatto così”, e che il guadagno maggiore non viene dalla tecnologia ma dalla semplificazione.
Cosa ottieni concretamente
- Una fotografia oggettiva di come funziona il processo oggi, ricavata dai dati dei tuoi sistemi e non dalle opinioni.
- L’indicazione di quali attività conviene automatizzare, quali eliminare e quali lasciare alle persone.
- Tempi e costi del processo prima e dopo, con la stessa unità di misura, così la decisione di investire si prende su numeri e non su impressioni.
Come lavoriamo: dai dati, non dalle interviste
Il metodo è quello classico as-is → to-be, ma alimentato dai dati anziché dalle sole interviste. Raccogliamo i log applicativi dei sistemi coinvolti — gestionale, CRM, ticketing, posta — e da lì ricostruiamo il percorso reale delle pratiche: quante volte un caso torna indietro, dove si accumulano le code, quali varianti del processo esistono davvero rispetto a quella descritta nelle procedure.
Gli indicatori che misuriamo
- Lead time: il tempo totale dall’ingresso alla chiusura del caso.
- Touch time: il tempo di lavoro effettivo delle persone sul caso.
- Tasso di rilavorazione: la percentuale di casi che tornano indietro almeno una volta.
- Tasso di straight through processing: la percentuale di casi che si chiudono senza alcun intervento manuale.
- Costo per transazione: il costo pieno di una singola esecuzione del processo.
Il divario tra lead time e touch time è quasi sempre la sorpresa più utile: mostra quanto il processo passa in attesa anziché in lavorazione.
Il ridisegno: una specifica, non una presentazione
Il processo to-be viene modellato in BPMN 2.0, una notazione standard leggibile sia da chi conosce il business sia da chi svilupperà. Serve anche come specifica di progetto: quello che viene approvato è quello che viene implementato, senza reinterpretazioni.
Per ogni attività definiamo il regime di esecuzione — autonoma, assistita o con validazione umana — così che i confini dell’automazione siano una decisione esplicita e non un effetto collaterale dello sviluppo.
Cosa non tocchiamo
I tuoi sistemi restano dove sono e continuano a essere i sistemi di riferimento del dato. Il ridisegno riguarda il flusso di lavoro, non l’infrastruttura. Nessuna migrazione, nessun cambio di gestionale, nessun fermo operativo.