Questa guida fa parte della serie "Come mappare un processo aziendale prima di automatizzarlo". Se non hai ancora letto la prima parte e la seconda parte ti consigliamo di iniziare da lì.

Come individuare colli di bottiglia e attività senza valore

Una volta raccolti tempi, volumi, errori ed eccezioni, la mappa può essere utilizzata per individuare i punti nei quali il processo rallenta, si interrompe o richiede più lavoro del necessario.

Un collo di bottiglia è un passaggio che limita la capacità complessiva del processo. Può dipendere da una persona, da un sistema, da una regola organizzativa o da un’attesa non gestita.

Nel processo di approvazione delle fatture, alcuni esempi potrebbero essere:

• tutte le richieste devono essere approvate dalla stessa persona;

• le fatture vengono controllate soltanto in determinati giorni;

• l’amministrazione deve cercare manualmente l’ordine corrispondente;

• le richieste di chiarimento vengono inviate tramite email senza uno stato tracciato;

• l’approvatore non riceve promemoria;

• le fatture con dati mancanti rimangono sospese senza un responsabile;

• lo stesso dato viene inserito in più applicazioni.

Per identificare i colli di bottiglia non basta chiedere quale attività richieda più tempo. Occorre osservare anche dove le pratiche si accumulano.

Un’attività può durare pochi minuti, ma diventare critica se tutte le richieste devono passare attraverso un’unica persona. Al contrario, un’attività più lunga può non rappresentare un problema se viene eseguita regolarmente e senza creare arretrati.

Domande utili per l’analisi

Per ogni passaggio è opportuno chiedere:

• Quante pratiche arrivano in una settimana o in un mese?

• Quante possono essere gestite nello stesso periodo?

• Quanto tempo rimangono in attesa?

• Chi può eseguire l’attività?

• Che cosa accade quando quella persona è assente?

• Quante richieste devono essere rilavorate?

• Quali errori si ripetono più spesso?

• Esistono passaggi che non producono un risultato utile?

• Il controllo viene ripetuto da più persone?

• Lo stesso dato viene richiesto o inserito più volte?

Queste domande aiutano a distinguere quattro situazioni:

1. attività necessarie e ben organizzate;

2. attività necessarie ma inefficienti;

3. attività che potrebbero essere automatizzate;

4. attività che potrebbero essere eliminate.

Automatizzare un’attività inutile non migliora il processo. La rende soltanto più veloce.

Attività che contribuiscono al risultato, attività necessarie e attività eliminabili

Durante l’analisi è utile classificare ogni passaggio in base alla sua funzione.

Attività che contribuiscono direttamente al risultato

Sono le attività che producono o modificano il risultato atteso dal cliente interno o esterno.

Nel processo delle fatture, ad esempio, l’esito finale consiste nel rendere il documento correttamente verificato, approvato, registrato e disponibile per le fasi successive.

Attività necessarie di controllo e supporto

Non producono direttamente il risultato, ma sono necessarie per ragioni amministrative, contabili, normative, organizzative o di controllo.

Nel processo delle fatture possono rientrare in questa categoria:

• verificare la corrispondenza con l’ordine;

• controllare la presenza dei dati obbligatori;

• ottenere l’approvazione prevista;

• registrare correttamente il documento;

• conservare le informazioni necessarie alla tracciabilità.

Queste attività non devono essere eliminate indiscriminatamente. Possono però essere semplificate, standardizzate o automatizzate quando si basano su regole chiare.

Attività senza valore eliminabili

Sono passaggi che non migliorano il risultato e non rispondono a una necessità concreta.

Esempi:

• ricopiare un dato già disponibile;

• inviare manualmente un aggiornamento che potrebbe essere generato dal sistema;

• effettuare due controlli identici;

• archiviare lo stesso documento in più cartelle senza una necessità reale;

• chiedere ogni volta informazioni che potrebbero essere rese obbligatorie all’origine;

• aggiornare fogli di calcolo paralleli che non rappresentano una fonte ufficiale.

L’obiettivo non deve essere automatizzare tutte le attività, ma progettare un processo futuro più semplice.

Prima di definire il workflow TO-BE, conviene quindi applicare questa sequenza:

Eliminare → semplificare → standardizzare → automatizzare

L’automazione dovrebbe arrivare soltanto dopo aver ridotto la complessità non necessaria.

Progettare il processo TO-BE

La mappa AS-IS descrive il funzionamento attuale. Il processo TO-BE rappresenta invece il modo in cui il lavoro dovrebbe essere svolto dopo l’intervento di miglioramento.

Non si tratta semplicemente di aggiungere un software al diagramma esistente.

Il processo futuro deve essere progettato partendo dal risultato che l’azienda vuole ottenere.

Nel caso delle fatture, gli obiettivi potrebbero essere:

• ridurre i tempi di approvazione;

• evitare richieste dimenticate;

• diminuire gli inserimenti manuali;

• migliorare la tracciabilità;

• separare i casi ordinari dalle eccezioni;

• applicare in modo uniforme le regole di approvazione;

• rendere sempre visibile lo stato della fattura.

A partire da questi obiettivi, il processo TO-BE potrebbe prevedere:

1. acquisizione automatica dei dati della fattura;

2. controllo della presenza delle informazioni necessarie;

3. ricerca dell’ordine o del contratto collegato;

4. confronto automatico tra importi e riferimenti;

5. instradamento verso l’approvatore corretto;

6. promemoria automatici;

7. escalation in caso di mancata risposta;

8. gestione separata delle anomalie;

9. registrazione dell’esito;

10. aggiornamento automatico del gestionale;

11. conservazione del log delle operazioni.

Il processo futuro dovrebbe essere rappresentato in una mappa distinta rispetto a quello attuale.

Sovrapporre AS-IS e TO-BE nello stesso diagramma può generare confusione. È preferibile utilizzare due versioni chiaramente identificate e indicare la data di aggiornamento.

Non automatizzare tutto

Un buon processo TO-BE non elimina necessariamente l’intervento umano.

L’automazione può occuparsi delle attività ripetitive e basate su regole, mentre le persone mantengono il controllo sulle decisioni che richiedono valutazione, responsabilità o conoscenza del contesto.

Nel processo delle fatture, il sistema potrebbe:

• acquisire i dati;

• controllare i campi obbligatori;

• verificare i duplicati;

• individuare l’approvatore;

• inviare la richiesta;

• registrare la risposta;

• sollecitare i ritardi;

• aggiornare lo stato.

Una persona potrebbe invece dover intervenire quando:

• l’importo non corrisponde all’ordine;

• la fattura riguarda più centri di costo;

• manca un contratto;

• esiste una contestazione;

• è richiesta un’autorizzazione economica;

• il sistema non riesce a interpretare correttamente i dati.

L’obiettivo non è sostituire indiscriminatamente le persone, ma assegnare al sistema le attività più standardizzabili e agli operatori quelle che richiedono giudizio.

Dalla mappa ai requisiti dell’automazione

Completare il diagramma non significa aver completato il progetto.

La mappa descrive il processo. I requisiti devono invece spiegare come dovrà comportarsi l’automazione.

Questa distinzione è fondamentale.

Un diagramma può indicare:

Verificare la fattura.

Per configurare un sistema, però, occorre specificare:

• quali dati devono essere verificati;

• da quale fonte devono essere acquisiti;

• quali condizioni devono essere rispettate;

• quale esito deve essere prodotto;

• che cosa deve accadere in caso di errore;

• chi deve essere avvisato;

• quali operazioni devono essere registrate.

Ogni attività candidata all’automazione deve quindi essere trasformata in una scheda di requisito.

Gli elementi da definire per ogni attività

1. Trigger

Il trigger è l’evento che avvia il workflow o una sua fase.

Esempi:

• ricezione di una nuova fattura;

• compilazione di un modulo;

• arrivo di un’email;

• creazione di un record nel gestionale;

• raggiungimento di una scadenza;

• modifica dello stato di una pratica.

Il trigger deve essere descritto in modo preciso.

“Quando arriva una fattura” potrebbe non essere sufficiente. Bisogna specificare dove viene resa disponibile, in quale formato e come il sistema deve riconoscerla.

2. Input

Gli input sono i dati e i documenti necessari per eseguire l’attività.

Nel caso della fattura potrebbero includere:

• file XML;

• copia PDF;

• partita IVA del fornitore;

• numero e data della fattura;

• importo;

• numero dell’ordine;

• centro di costo;

• scadenza;

• anagrafica del fornitore;

• contratto collegato.

Per ogni input è opportuno indicare:

• provenienza;

• formato;

• obbligatorietà;

• livello di affidabilità;

• eventuale necessità di validazione.

3. Output

L’output è il risultato prodotto.

Può trattarsi di:

• stato aggiornato;

• richiesta di approvazione;

• record creato;

• documento archiviato;

• notifica inviata;

• segnalazione di errore;

• dato trasferito a un altro sistema.

Ogni attività dovrebbe avere un output verificabile.

4. Regole di controllo

Le regole stabiliscono che cosa il sistema deve verificare.

Esempi:

• il numero della fattura non deve essere già presente;

• la partita IVA deve corrispondere a un fornitore attivo;

• l’importo deve essere numerico e maggiore di zero;

• il numero dell’ordine deve esistere;

• il totale della fattura non deve superare l’importo residuo dell’ordine;

• il centro di costo deve essere valido.

Le regole devono essere espresse in modo chiaro e, quando possibile, misurabile.

5. Regole decisionali

Le regole decisionali stabiliscono quale percorso deve seguire il processo.

Per esempio:

• importo entro una determinata soglia: approvazione del responsabile di reparto;

• importo superiore alla prima soglia: ulteriore controllo amministrativo;

• importo superiore alla soglia definita per la direzione: seconda approvazione;

• ordine mancante: assegnazione all’amministrazione;

• possibile duplicato: sospensione temporanea e verifica manuale.

Le soglie devono essere documentate e approvate dall’azienda.

6. Responsabilità e autorizzazioni

Per ogni fase occorre chiarire:

• chi può visualizzare i dati;

• chi può modificare le informazioni;

• chi può approvare;

• chi può respingere;

• chi può riaprire una pratica;

• chi può modificare le regole del workflow.

Le autorizzazioni non dovrebbero essere lasciate implicite.

7. Notifiche

È necessario definire:

• destinatario;

• evento che genera la notifica;

• canale utilizzato;

• contenuto minimo;

• eventuale collegamento alla pratica;

• frequenza;

• condizioni per evitare notifiche duplicate.

Una notifica utile deve permettere al destinatario di capire subito che cosa è richiesto.

8. Tempi-obiettivo e SLA

Per ogni fase è opportuno definire un tempo-obiettivo.

Quando tale tempo è formalizzato in un accordo di servizio, interno o esterno, può essere indicato come SLA, acronimo di Service Level Agreement.

Esempi:

• presa in carico entro quattro ore;

• approvazione entro due giorni lavorativi;

• gestione dell’anomalia entro tre giorni;

• aggiornamento del gestionale entro la fine della giornata.

È utile distinguere:

• il tempo atteso per completare l’attività;

• il tempo massimo prima di un promemoria;

• il limite oltre il quale deve essere attivata un’escalation.

9. Promemoria ed escalation

Il workflow deve stabilire che cosa accade quando una persona non interviene entro il tempo previsto.

Esempio:

• primo promemoria dopo 24 ore;

• secondo promemoria dopo 48 ore;

• escalation al responsabile superiore dopo 72 ore;

• segnalazione all’amministrazione dopo cinque giorni.

Senza escalation, un processo automatizzato può continuare a dipendere da solleciti manuali.

10. Eccezioni

Per ciascuna anomalia già individuata nella mappa occorre definire:

• modalità di rilevamento;

• stato assegnato;

• responsabile;

• azione richiesta;

• tempo di gestione;

• modalità di rientro nel flusso ordinario.

Le diverse eccezioni non devono essere riunite in un unico percorso generico.

Un duplicato sospetto, un ordine mancante e una contestazione commerciale richiedono azioni differenti.

11. Log e tracciabilità

Il sistema dovrebbe registrare almeno:

• data e ora;

• operazione eseguita;

• utente o sistema responsabile;

• stato precedente;

• nuovo stato;

• decisione;

• motivazione;

• eventuale errore;

• notifica inviata.

La tracciabilità è essenziale per ricostruire il processo e verificare che le regole siano state applicate correttamente.

12. KPI

I KPI permettono di misurare se il nuovo processo produce il risultato atteso.

Possibili indicatori:

• tempo medio di completamento;

• tempo medio di approvazione;

• numero di pratiche in attesa;

• percentuale di fatture gestite senza intervento manuale;

• numero di anomalie;

• percentuale di rilavorazioni;

• richieste oltre il tempo-obiettivo;

• errori di registrazione;

• tempo risparmiato.

I KPI devono essere definiti prima dell’avvio dell’automazione, in modo da poter confrontare la situazione precedente con quella successiva.

Scheda sintetica dei requisiti

Una scheda per ogni attività potrebbe avere questa struttura:

Questa documentazione crea un collegamento concreto tra la mappa del processo e la configurazione tecnica.

Esempio completo: automazione del processo di gestione delle fatture

Consideriamo una PMI che gestisce ogni settimana decine di fatture dei fornitori.

Situazione AS-IS

Il processo attuale funziona in questo modo:

1. la fattura viene resa disponibile all’azienda;

2. l’amministrazione scarica il documento;

3. verifica manualmente i dati;

4. cerca l’ordine o il contratto;

5. controlla l’importo;

6. individua il responsabile;

7. invia un’email con la richiesta di approvazione;

8. attende la risposta;

9. invia eventuali solleciti;

10. registra l’esito in un foglio di calcolo;

11. inserisce i dati nel gestionale;

12. archivia il documento.

Le principali criticità sono:

• ricerca manuale dei documenti;

• richieste inviate a persone differenti senza una regola uniforme;

• risposte non sempre tracciate;

• promemoria manuali;

• dati duplicati;

• difficoltà nel conoscere lo stato;

• pratiche bloccate durante le assenze.

Processo TO-BE

Il processo futuro potrebbe essere progettato così:

1. il sistema rileva una nuova fattura;

2. acquisisce i dati disponibili;

3. verifica i campi obbligatori;

4. controlla l’eventuale duplicato;

5. ricerca l’ordine collegato;

6. confronta fornitore, importo e riferimenti;

7. assegna la fattura all’approvatore corretto;

8. invia una richiesta con collegamento alla pratica;

9. registra approvazione, rifiuto o richiesta di chiarimento;

10. invia promemoria ed escalation;

11. aggiorna il gestionale;

12. archivia documento, esito e log;

13. aggiorna gli indicatori del processo.

Le pratiche che non superano i controlli automatici vengono assegnate all’amministrazione con uno stato specifico.

Requisiti del workflow

Trigger

Disponibilità di una nuova fattura nel sistema sorgente.

Input

• file XML;

• eventuale PDF;

• anagrafica del fornitore;

• numero della fattura;

• data;

• importo;

• numero dell’ordine;

• centro di costo;

• scadenza.

Controlli automatici

• presenza dei campi obbligatori;

• verifica del duplicato;

• corrispondenza del fornitore;

• validità dell’ordine;

• coerenza dell’importo;

• presenza del centro di costo;

• individuazione dell’approvatore.

Regole decisionali

Le soglie seguenti hanno esclusivamente funzione esemplificativa. Ogni impresa deve definirle in base alla propria struttura organizzativa, alle deleghe autorizzative e alle procedure interne.

Nel nostro esempio ipotetico:

• importo fino a 1.000 euro: approvazione del responsabile di reparto;

• importo tra 1.001 e 5.000 euro: responsabile di reparto e amministrazione;

• importo superiore a 5.000 euro: approvazione della direzione;

• ordine mancante: assegnazione all’amministrazione;

• importo non coerente: pratica in anomalia;

• possibile duplicato: blocco temporaneo e verifica manuale.

Notifiche

La richiesta di approvazione dovrebbe includere:

• fornitore;

• numero della fattura;

• importo;

• scadenza;

• ordine collegato;

• eventuali anomalie;

• pulsanti o collegamenti per approvare, respingere o richiedere chiarimenti.

Promemoria

Nel nostro esempio ipotetico:

• primo promemoria dopo 24 ore;

• secondo promemoria dopo 48 ore;

• escalation dopo 72 ore.

Anche questi intervalli devono essere adattati alle esigenze operative dell’azienda.

Eccezioni

Possibili stati:

• dati mancanti;

• ordine non trovato;

• importo non coerente;

• fornitore non riconosciuto;

• duplicato sospetto;

• approvatore non disponibile;

• richiesta di chiarimento;

• fattura respinta.

Ogni stato deve avere un responsabile e un’azione successiva.

Log

Il sistema deve registrare:

• ricezione della fattura;

• controlli effettuati;

• anomalie rilevate;

• assegnazione;

• notifiche;

• promemoria;

• decisione;

• motivazione;

• registrazione finale;

• eventuali errori tecnici.

KPI

L’azienda potrebbe monitorare:

• tempo medio dalla ricezione alla registrazione;

• tempo medio di approvazione;

• percentuale di fatture approvate entro il tempo previsto;

• percentuale gestita senza rilavorazione;

• numero di eccezioni per tipologia;

• pratiche ferme oltre il tempo-obiettivo;

• tempo amministrativo risparmiato.

Il requisito deve descrivere il comportamento, non lo strumento

È preferibile evitare requisiti formulati soltanto in questo modo:

Creare un’automazione con Make.

oppure:

Usare Power Automate per approvare le fatture.

Queste frasi indicano una tecnologia, ma non descrivono il funzionamento richiesto.

Un requisito corretto dovrebbe spiegare:

Quando viene acquisita una nuova fattura, il sistema deve verificare la presenza dell’ordine, controllare l’eventuale duplicato, individuare l’approvatore in base al centro di costo e all’importo e inviare la richiesta entro quindici minuti.

Solo dopo aver definito il comportamento richiesto si potrà valutare, a titolo esemplificativo, se realizzarlo con:

• strumenti di automazione come Make, Zapier o Microsoft Power Automate;

• funzionalità già presenti nel gestionale;

• una piattaforma BPM;

• una soluzione personalizzata.

La scelta tecnologica deve seguire i requisiti, non sostituirli.

Privacy, sicurezza, accessi e tracciabilità

Ogni progetto di automazione deve considerare i dati trattati e i soggetti che possono accedervi.

La mappatura non sostituisce le valutazioni privacy, contrattuali o di sicurezza eventualmente necessarie. Serve però a rendere visibili i flussi di dati e a individuare i punti che richiedono un approfondimento specialistico.

La mappa dovrebbe indicare:

• quali dati personali vengono utilizzati;

• dove sono conservati;

• attraverso quali applicazioni transitano;

• chi può visualizzarli;

• chi può modificarli;

• per quanto tempo vengono mantenuti;

• quali fornitori esterni sono coinvolti.

Non tutti i processi presentano lo stesso livello di rischio.

Un workflow che trasferisce soltanto dati tecnici non è equivalente a un processo che tratta informazioni su dipendenti, clienti, pagamenti o situazioni finanziarie.

Prima di collegare più applicazioni è opportuno verificare:

• ruoli e responsabilità;

• autorizzazioni;

• credenziali utilizzate dalle integrazioni;

• registrazione degli accessi;

• protezione dei dati durante il trasferimento;

• conservazione;

• gestione degli errori;

• possibilità di revocare gli accessi;

• eventuali trasferimenti verso fornitori esterni.

Un’automazione non dovrebbe utilizzare account personali o credenziali condivise quando sono disponibili identità di servizio, ruoli specifici o autorizzazioni più controllabili.

È inoltre consigliabile applicare il principio del minimo privilegio: ogni persona e ogni integrazione dovrebbero poter accedere soltanto alle informazioni necessarie.

Come validare la mappa e i requisiti

Prima di configurare il workflow, la documentazione deve essere verificata con le persone coinvolte.

La validazione non dovrebbe limitarsi a una conferma generica.

È preferibile esaminare uno o più casi reali e seguire il percorso completo.

Chi dovrebbe partecipare

A seconda del processo:

• chi esegue le attività;

• il process owner;

• i responsabili dei reparti;

• l’amministrazione;

• i responsabili dei sistemi;

• le eventuali figure privacy o sicurezza;

• il consulente o il fornitore tecnico.

Che cosa verificare

• Il flusso rappresenta davvero il lavoro?

• Le responsabilità sono corrette?

• Le soglie decisionali sono approvate?

• Le eccezioni principali sono presenti?

• Gli input sono disponibili e affidabili?

• I sistemi possono scambiarsi i dati necessari?

• Le autorizzazioni sono coerenti?

• I tempi-obiettivo sono realistici?

• I KPI possono essere misurati?

• Il processo può proseguire in caso di errore tecnico?

La validazione dovrebbe produrre una versione approvata della mappa e dei requisiti.

Testare prima di estendere

Prima di applicare l’automazione a tutto il processo, è prudente realizzare un test controllato.

Il progetto pilota potrebbe riguardare:

• un solo reparto;

• una sola categoria di fatture;

• un gruppo limitato di fornitori;

• importi inferiori a una determinata soglia;

• un numero ridotto di utenti.

Durante il test è utile verificare:

• correttezza delle assegnazioni;

• qualità dei dati;

• tempi di elaborazione;

• efficacia delle notifiche;

• gestione delle eccezioni;

• comprensibilità per gli utenti;

• precisione dei log;

• comportamento in caso di errore.

L’automazione dovrebbe essere estesa soltanto dopo aver corretto le criticità emerse.

Errori da evitare

Automatizzare il processo AS-IS senza modificarlo

Riprodurre fedelmente un processo inefficiente significa trasferire nel software gli stessi problemi.

Prima di automatizzare occorre eliminare duplicazioni, passaggi inutili e regole poco chiare.

Progettare soltanto il percorso ideale

Le eccezioni devono essere considerate fin dall’inizio.

Un workflow che non sa gestire dati mancanti, ritardi o anomalie richiederà continui interventi manuali.

Utilizzare regole implicite

Frasi come “approva chi se ne occupa” o “controllare se è corretto” non sono requisiti utilizzabili.

Ruoli e criteri devono essere formalizzati.

Affidarsi esclusivamente allo strumento

La scelta della piattaforma non sostituisce l’analisi.

Anche il software più avanzato non può compensare un processo non definito.

Eliminare il controllo umano dove serve

Le attività ripetitive possono essere automatizzate, ma decisioni economiche, casi anomali e valutazioni contestuali possono richiedere l’intervento di una persona.

Non prevedere il caso di errore

Bisogna stabilire che cosa accade quando:

• un sistema non risponde;

• un dato non è disponibile;

• un’integrazione fallisce;

• una notifica non viene inviata;

• un utente non interviene;

• una pratica rimane bloccata.

Non definire un responsabile del processo

Il workflow deve avere un process owner che controlli risultati, modifiche e criticità.

Non misurare la situazione iniziale

Senza dati AS-IS non è possibile valutare con precisione il miglioramento prodotto.

Non aggiornare la documentazione

La mappa e i requisiti devono essere modificati quando cambiano ruoli, sistemi, soglie o procedure.

Checklist finale prima di automatizzare

Prima di avviare il progetto, verifica che:

Perimetro

☐ L’inizio del processo è definito.

☐ La condizione di chiusura è chiara.

☐ Gli input e gli output sono identificati.

☐ Il processo successivo è noto.

Attività e responsabilità

☐ Ogni attività ha un responsabile.

☐ Ogni approvazione ha un soggetto autorizzato.

☐ Le attività manuali e automatiche sono distinte.

☐ Sono previste sostituzioni in caso di assenza.

Dati e sistemi

☐ Le fonti dei dati sono identificate.

☐ I campi obbligatori sono definiti.

☐ I sistemi coinvolti sono elencati.

☐ I trasferimenti manuali sono evidenziati.

☐ La fonte principale di ogni informazione è chiara.

Regole

☐ Le regole decisionali sono formalizzate.

☐ Le soglie sono approvate.

☐ Ogni decisione ha esiti definiti.

☐ Le regole non dipendono da espressioni ambigue.

Eccezioni

☐ Le anomalie principali sono documentate.

☐ Ogni eccezione ha un responsabile.

☐ Sono definiti tempi e modalità di gestione.

☐ È previsto il rientro nel flusso ordinario.

Tempi e notifiche

☐ I tempi-obiettivo sono realistici.

☐ Gli eventuali SLA sono formalizzati.

☐ I promemoria sono definiti.

☐ Le escalation sono previste.

☐ Le notifiche hanno destinatari e contenuti chiari.

Sicurezza e tracciabilità

☐ Gli accessi sono coerenti con i ruoli.

☐ Le integrazioni utilizzano autorizzazioni controllate.

☐ Le operazioni rilevanti vengono registrate.

☐ I dati personali e riservati sono stati identificati.

Misurazione

☐ Sono disponibili dati sulla situazione iniziale.

☐ I KPI sono definiti.

☐ È stato stabilito chi li controllerà.

☐ È prevista una revisione dopo l’avvio.

Domande frequenti

Serve utilizzare BPMN per automatizzare un processo?

Non sempre. Per processi semplici può essere sufficiente un diagramma di flusso o a corsie. BPMN diventa utile quando sono presenti numerosi ruoli, sistemi, eventi, scadenze e percorsi alternativi.

Quanto deve essere dettagliata la mappa?

Deve permettere di comprendere attività, responsabilità, dati, sistemi, decisioni ed eccezioni. Non è necessario descrivere ogni clic, a meno che il dettaglio non serva alla configurazione o alle istruzioni operative.

È possibile automatizzare un processo non standardizzato?

Tecnicamente può essere possibile, ma il risultato sarà fragile. Prima è preferibile ridurre le varianti, chiarire le regole e separare i casi ordinari dalle eccezioni.

Tutte le decisioni possono essere automatizzate?

No. Le decisioni basate su regole stabili possono spesso essere automatizzate. Quelle che richiedono interpretazione, valutazione economica, responsabilità o conoscenza del contesto dovrebbero prevedere un intervento umano.

Qual è il miglior processo da scegliere per iniziare?

Un processo frequente, ripetitivo, basato su regole chiare, con dati disponibili e un volume sufficiente per produrre un beneficio misurabile. È preferibile evitare come primo progetto un processo critico, altamente variabile o ricco di eccezioni non documentate.

La mappa deve essere aggiornata dopo l’automazione?

Sì. Il processo TO-BE deve diventare la nuova versione di riferimento e deve essere aggiornato quando cambiano ruoli, sistemi, soglie, integrazioni o modalità operative.

Conclusioni

Mappare un processo prima di automatizzarlo non significa soltanto disegnare una sequenza di rettangoli e frecce.

Significa rendere visibile il modo in cui l’azienda lavora, distinguere le attività necessarie da quelle eliminabili, identificare responsabilità, dati, decisioni, sistemi ed eccezioni.

La mappa AS-IS permette di comprendere la situazione attuale. Il processo TO-BE definisce invece il modello futuro. I requisiti traducono quel modello in istruzioni concrete per il sistema che dovrà eseguirlo.

Il passaggio corretto è quindi:

Processo esistente → analisi → semplificazione → processo futuro → requisiti → scelta dello strumento → test → misurazione.

Seguire questa sequenza riduce il rischio di costruire automazioni fragili, difficili da mantenere o incapaci di gestire i casi reali.

Le due parti di questa guida compongono un unico metodo: la prima aiuta a ricostruire il processo reale; la seconda mostra come rappresentarlo, migliorarlo e tradurlo in requisiti utilizzabili per l’automazione.

Per una PMI, la qualità dell’automazione dipende meno dalla complessità della tecnologia e più dalla chiarezza con cui il processo è stato compreso e progettato.

Un diagramma accurato, requisiti verificabili e un controllo umano ben posizionato rappresentano la base per ottenere un workflow più rapido, tracciabile e sostenibile nel tempo.