Automatizzare un processo aziendale: cosa chiarire prima di sviluppare

A cura della Redazione DACSO · Revisione editoriale e tecnica del team DACSO

Un processo lento non è automaticamente un buon candidato per l’automazione. Se regole, dati ed eccezioni non sono chiari, il software eseguirà più velocemente anche le ambiguità. Prima di sviluppare conviene capire quale decisione può prendere il sistema, quale deve restare a una persona e come verificare il risultato.

Partire da un caso reale, non dalla parola “automazione”

“Vogliamo automatizzare i preventivi” descrive un obiettivo troppo ampio. È più utile seguire una pratica concreta: arriva una richiesta, qualcuno raccoglie i dati mancanti, sceglie un listino, applica eventuali condizioni, genera il documento e lo invia. Per ciascun passaggio si annotano ingresso, responsabile, regola e risultato.

Questa ricostruzione fa emergere il vero collo di bottiglia. Potrebbe non essere la creazione del PDF, ma il tempo impiegato per ottenere informazioni complete oppure il controllo manuale di condizioni che cambiano da cliente a cliente. Automatizzare soltanto l’ultimo passaggio renderebbe più elegante il processo senza ridurne davvero l’attesa.

Una regola deve poter essere spiegata senza “di solito”

Il software lavora bene con condizioni verificabili: se il cliente appartiene a una certa categoria, applica quel listino; se manca un dato obbligatorio, ferma la pratica; se l’importo supera una soglia, richiedi un’approvazione. Le frasi come “valutiamo caso per caso” indicano invece una decisione che va scomposta oppure lasciata a una persona.

Non tutte le eccezioni devono entrare nella prima versione. Conviene misurarle: quante pratiche seguono il percorso normale e quante richiedono interventi particolari? Se il percorso standard copre la maggioranza dei casi, si può automatizzare quello e predisporre una coda chiara per il resto. Tentare di codificare subito ogni variante aumenta tempi, costi e possibilità di errore.

I dati mancanti non si risolvono con un’integrazione

Un’automazione dipende dalla qualità delle informazioni che riceve. Nomi scritti in modi diversi, codici non aggiornati, campi liberi e duplicati obbligano il sistema a indovinare. Prima di collegare CRM, gestionale, posta e contabilità bisogna stabilire quale applicazione è responsabile di ciascun dato e chi può correggerlo.

Il passaggio più delicato spesso è l’identificazione: il “cliente Rossi” presente in due sistemi è la stessa anagrafica? L’ordine citato in un’email corrisponde a quale commessa? Senza identificatori affidabili l’integrazione può produrre associazioni plausibili ma sbagliate, difficili da individuare dopo l’esecuzione.

Ogni esecuzione deve essere ripetibile senza creare danni

Timeout e interruzioni sono normali. Se il sistema invia una fattura ma non riceve la conferma, potrebbe tentare di nuovo. L’automazione deve quindi riconoscere un’operazione già completata ed evitare duplicati. In termini tecnici si parla di idempotenza; nella pratica significa poter riprovare senza emettere due documenti, scalare due volte una quantità o inviare tre email uguali.

Serve anche uno stato comprensibile: in attesa, in elaborazione, completato, bloccato. Un messaggio generico come “errore” non basta. Chi gestisce il processo deve sapere quale passaggio è riuscito, quale dato manca e da dove ripartire dopo la correzione.

Controlli umani nei punti in cui cambia il rischio

Automatizzare non significa togliere ogni verifica. Un’approvazione è utile quando l’operazione è difficile da annullare, comporta un impegno economico, comunica verso l’esterno o utilizza dati sensibili. Il controllo va collocato prima dell’azione rilevante, mostrando alla persona le informazioni necessarie per decidere.

Al contrario, chiedere conferma per ogni passaggio ricrea manualmente il processo precedente. Il sistema può eseguire da solo attività reversibili e ben definite, registrando ciò che ha fatto. La persona interviene sulle eccezioni e sulle decisioni con conseguenze reali.

Il registro operativo è parte del prodotto

Quando una procedura era manuale, spesso bastava chiedere a chi l’aveva eseguita. Con l’automazione servono tracce: quando è partita, quali dati ha usato, quale regola ha applicato, quali sistemi ha contattato e come è terminata. Il registro non dovrebbe contenere password o informazioni superflue, ma deve permettere di ricostruire un evento.

Anche permessi e responsabilità vanno definiti. Chi può avviare il flusso? Chi modifica le regole? Chi vede gli errori? Se tutti possono cambiare tutto, una procedura affidabile diventa fragile appena cresce il numero di utenti.

Misurare prima e dopo con pochi numeri utili

Il beneficio non coincide con il numero di clic eliminati. Prima dello sviluppo conviene rilevare tempo medio di lavorazione, tempo trascorso in attesa, percentuale di pratiche incomplete, correzioni e interventi manuali. Dopo il rilascio si confrontano gli stessi valori.

Un’automazione può ridurre il lavoro operativo ma aumentare le eccezioni; oppure può non accelerare molto il singolo caso, ma evitare errori costosi. Il risultato va letto rispetto all’obiettivo iniziale, non soltanto alla velocità del software.

Una prima versione utile ha confini espliciti

Per partire si può scegliere un solo evento di ingresso, un percorso standard e un risultato verificabile. Per esempio: importare gli ordini approvati, controllare i dati obbligatori, creare la commessa e segnalare quelli incompleti. In questa fase è preferibile lasciare fuori casi rari e integrazioni non documentate.

Dopo alcune settimane di utilizzo, il registro mostra dove il flusso si ferma e quali eccezioni si ripetono. A quel punto l’estensione nasce da evidenze operative. È un modo più prudente di investire rispetto a un progetto che prova a prevedere ogni situazione prima di essere usato.

Le domande da risolvere prima del preventivo

• Quale evento avvia il processo e quale risultato indica che è concluso?
• Quali regole sono oggettive e quali richiedono giudizio?
• Da dove arrivano i dati e quale sistema ne è responsabile?
• Quali eccezioni devono essere gestite subito?
• Quali azioni richiedono approvazione e quali sono reversibili?
• Come si evita di ripetere due volte la stessa operazione?
• Chi riceve un errore e quali informazioni servono per risolverlo?
• Con quali misure confronteremo il prima e il dopo?

Se queste risposte sono disponibili, si può stimare una soluzione con maggiore precisione. Se non lo sono, la prima attività utile è una breve analisi del processo: costa meno che trasformare in codice una procedura ancora incerta.