Come mappare un processo aziendale prima di automatizzarlo: dal diagramma all'analisi operativa

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

Nella prima parte di questa guida abbiamo visto perché la mappatura del processo rappresenta il punto di partenza di qualsiasi progetto di automazione aziendale.

Prima di scegliere uno strumento, collegare applicazioni o configurare un workflow, è necessario comprendere come il lavoro viene svolto realmente: quali attività vengono eseguite, da chi, con quali dati, attraverso quali sistemi e con quali eccezioni.

Abbiamo inoltre distinto:

• il processo AS-IS, cioè il modo in cui il processo funziona oggi;

• il processo TO-BE, cioè il modello operativo futuro;

• il processo dalla procedura, dal workflow e dall’istruzione operativa.

Questa analisi iniziale permette di evitare uno degli errori più comuni: automatizzare un processo poco chiaro, inefficiente o basato su regole che nessuno ha mai formalizzato.

La ricostruzione del processo, però, non si conclude con un elenco di attività.

Per trasformare l’analisi in un progetto concreto occorre:

1. rappresentare il processo in modo visivo;

2. evidenziare ruoli, sistemi, dati, tempi ed eccezioni;

3. individuare i colli di bottiglia;

4. progettare il processo futuro;

5. tradurre la mappa in requisiti utilizzabili per configurare l’automazione.

In questa seconda parte vedremo quindi come passare dal diagramma del processo alla definizione di un workflow automatizzato.

Come esempio utilizzeremo il processo di verifica e approvazione delle fatture dei fornitori, ma lo stesso metodo può essere applicato anche a richieste ricevute via email, gestione degli ordini, onboarding dei clienti, approvazione delle spese, raccolta dei documenti e numerosi altri processi aziendali.

Come rappresentare graficamente un processo aziendale

Dopo aver raccolto le informazioni e ricostruito il processo reale, è necessario trasformare quanto emerso in una rappresentazione visiva.

Un diagramma permette di osservare il processo nel suo insieme e di cogliere collegamenti che, durante il lavoro quotidiano, possono risultare poco evidenti.

Una buona rappresentazione grafica aiuta a individuare:

• attività duplicate;

• controlli ripetuti;

• passaggi manuali tra applicazioni diverse;

• approvazioni informali;

• attese tra un reparto e l’altro;

• attività prive di un responsabile chiaro;

• eccezioni gestite tramite email, telefonate o messaggi;

• dati copiati più volte;

• punti nei quali il processo si interrompe o rallenta.

Il diagramma non deve essere considerato soltanto un documento illustrativo. Deve diventare uno strumento di analisi e progettazione.

Per essere utile, deve mostrare non solo la sequenza delle attività, ma anche:

• chi svolge ogni passaggio;

• quale evento avvia il processo;

• quali dati entrano nel flusso;

• quali decisioni modificano il percorso;

• quali sistemi sono coinvolti;

• quali risultati vengono prodotti;

• come vengono gestiti errori ed eccezioni;

• quando il processo può considerarsi concluso.

Il livello di dettaglio deve essere sufficiente per comprendere il funzionamento del processo, ma non così elevato da rendere la mappa difficile da leggere.

Una mappa troppo sintetica non offre informazioni utili. Una mappa eccessivamente dettagliata rischia invece di trasformarsi in un manuale operativo.

Definire l’inizio e la fine del processo

Prima di inserire tutte le attività nel diagramma, è necessario stabilire con precisione il perimetro del processo.

In particolare, occorre identificare:

• l’evento iniziale;

• gli input;

• il risultato finale;

• la condizione di chiusura;

• l’eventuale processo successivo.

Nel caso della gestione delle fatture, l’evento iniziale potrebbe essere:

La fattura viene resa disponibile all’azienda attraverso il sistema utilizzato per la fatturazione elettronica.

Il risultato finale potrebbe essere:

La fattura è stata verificata, approvata, registrata nel gestionale e resa disponibile per il successivo pagamento.

Questa distinzione è importante perché evita di includere nello stesso diagramma attività appartenenti a processi differenti.

Ad esempio, il pagamento della fattura potrebbe rientrare nel processo amministrativo analizzato oppure appartenere a un processo di tesoreria separato.

La decisione dipende dal perimetro scelto dall’azienda.

Definire correttamente questi elementi impedisce alla mappa di estendersi senza controllo e rende più chiaro ciò che dovrà essere automatizzato.

Il diagramma di flusso

Il diagramma di flusso, o flowchart, è uno degli strumenti più semplici per rappresentare un processo.

Utilizza forme e frecce per mostrare:

• l’inizio e la fine;

• le attività;

• le decisioni;

• i documenti o i dati utilizzati;

• i percorsi alternativi.

Per una prima mappatura non è necessario utilizzare numerosi simboli.

Nel caso delle fatture, il percorso principale potrebbe essere rappresentato in questo modo:

Ricezione della fattura → verifica dei dati → confronto con ordine o contratto → richiesta di approvazione → approvazione del responsabile → registrazione nel gestionale → chiusura

Il diagramma deve però includere anche i percorsi alternativi.

Se durante il controllo emerge un’incongruenza, il flusso potrebbe diventare:

Incongruenza rilevata → richiesta di chiarimento → correzione o nota di credito → nuova verifica

Mostrare soltanto il percorso ideale non è sufficiente.

Un’automazione progettata esclusivamente sul cosiddetto happy path, cioè sulla sequenza priva di problemi, rischia di bloccarsi non appena si presenta una situazione diversa da quella prevista.

Come descrivere correttamente le attività

Ogni attività inserita nel diagramma dovrebbe essere formulata in modo chiaro e operativo.

La struttura più efficace è:

Verbo d’azione + oggetto

Esempi corretti:

• verificare i dati della fattura;

• confrontare la fattura con l’ordine;

• richiedere l’approvazione;

• registrare l’esito;

• inviare un promemoria;

• archiviare il documento.

Espressioni come “gestione fattura”, “controllo amministrativo” o “lavorazione richiesta” sono troppo generiche.

Non permettono di capire che cosa viene svolto, quale informazione viene utilizzata e quale risultato viene prodotto.

Ogni riquadro dovrebbe inoltre contenere una sola attività principale.

Una formulazione come:

Controllare la fattura, confrontarla con l’ordine, chiedere l’approvazione e registrarla nel gestionale.

contiene in realtà quattro passaggi distinti:

1. verificare i dati della fattura;

2. confrontare la fattura con l’ordine;

3. richiedere l’approvazione;

4. registrare l’esito nel gestionale.

Separare le attività è fondamentale perché, nella fase successiva, ogni passaggio dovrà essere analizzato singolarmente.

Per ciascuna attività sarà infatti necessario stabilire:

• se può essere automatizzata;

• se richiede una decisione umana;

• quali dati utilizza;

• quale sistema deve eseguirla;

• quale risultato deve produrre;

• quali eccezioni possono verificarsi.

Il diagramma a corsie

Quando un processo coinvolge più persone, reparti o sistemi, il diagramma di flusso tradizionale può non essere sufficiente.

In questi casi è utile utilizzare un diagramma a corsie, spesso chiamato swimlane.

Ogni corsia rappresenta un soggetto coinvolto nel processo, ad esempio:

• amministrazione;

• responsabile di reparto;

• direzione;

• fornitore;

• sistema gestionale;

• piattaforma di approvazione.

Le attività vengono inserite nella corsia del soggetto che le esegue.

In questo modo diventa immediatamente visibile:

• chi svolge ogni passaggio;

• chi prende una decisione;

• chi riceve una richiesta;

• quali attività vengono eseguite da un sistema;

• dove avvengono trasferimenti di responsabilità;

• in quali punti il processo può rimanere in attesa.

Esempio semplificato

La tabella non sostituisce il diagramma, ma aiuta a prepararlo e a verificare che ogni attività abbia un responsabile identificabile.

Perché i passaggi tra corsie sono spesso critici

Molti problemi non si trovano all’interno di una singola attività, ma nei passaggi tra persone, reparti o applicazioni.

Ogni trasferimento può introdurre:

• tempi di attesa;

• perdita di informazioni;

• duplicazione dei dati;

• errori di interpretazione;

• assenza di tracciabilità;

• richieste inviate alla persona sbagliata;

• difficoltà nel conoscere lo stato della pratica.

Nel processo delle fatture, ad esempio, l’amministrazione potrebbe inviare la richiesta di approvazione tramite email.

Il responsabile potrebbe rispondere verbalmente o con un messaggio, mentre l’esito viene annotato successivamente in un foglio di calcolo.

Il problema non è soltanto l’utilizzo dell’email.

Il vero problema è l’assenza di un flusso unico nel quale siano collegati:

• la richiesta;

• il documento;

• il responsabile;

• la decisione;

• la data;

• la motivazione;

• lo stato aggiornato.

Le frecce che attraversano più corsie meritano quindi particolare attenzione.

Spesso rappresentano i punti nei quali l’automazione può produrre il beneficio maggiore attraverso:

• assegnazioni automatiche;

• notifiche;

• approvazioni digitali;

• promemoria;

• aggiornamenti di stato;

• registrazione delle decisioni;

• trasferimento automatico di dati;

• escalation in caso di ritardo.

Quando utilizzare BPMN

Per processi semplici, un flowchart o un diagramma a corsie è normalmente sufficiente.

Quando il processo presenta numerose decisioni, eventi, percorsi paralleli, scadenze, interazioni tra sistemi o eccezioni, può essere utile utilizzare la notazione BPMN, acronimo di Business Process Model and Notation.

BPMN è una notazione standardizzata utilizzata per rappresentare i processi aziendali.

Permette di descrivere con maggiore precisione:

• eventi iniziali e finali;

• attività manuali e automatiche;

• decisioni;

• percorsi paralleli;

• scambi di messaggi;

• attese;

• scadenze;

• errori;

• eccezioni;

• sottoprocessi.

Il principale vantaggio di BPMN è la standardizzazione.

Chi conosce la notazione può interpretare il diagramma senza dover concordare ogni volta il significato dei simboli.

Per una PMI, tuttavia, non è necessario utilizzare immediatamente tutti gli elementi disponibili.

Una mappa troppo tecnica può risultare difficile da comprendere per le persone che devono validarla.

BPMN è particolarmente utile quando:

• il processo coinvolge più sistemi;

• esistono numerose regole decisionali;

• devono essere gestite scadenze o timeout;

• sono presenti attività parallele;

• il progetto sarà affidato a un fornitore esterno;

• la mappa dovrà essere utilizzata come specifica per lo sviluppo;

• il processo è critico e richiede una documentazione strutturata.

Flowchart, swimlane o BPMN: quale scegliere?

La scelta dipende dalla complessità del processo e dall’utilizzo della mappa.

Per molte PMI, il diagramma a corsie rappresenta il miglior punto di partenza.

È più informativo di un semplice flowchart, ma rimane comprensibile anche a chi non conosce una notazione tecnica.

BPMN può essere introdotto in una fase successiva, soprattutto se il processo dovrà essere trasformato in una specifica tecnica per consulenti, sviluppatori o fornitori di piattaforme di automazione.

Il diagramma deve mostrare anche i sistemi

Un errore frequente consiste nel rappresentare soltanto le attività svolte dalle persone.

Un processo aziendale comprende quasi sempre anche:

• software gestionali;

• fogli di calcolo;

• caselle email;

• moduli online;

• archivi documentali;

• piattaforme cloud;

• sistemi di fatturazione;

• strumenti di comunicazione;

• applicazioni verticali.

Questi elementi devono comparire nella mappa.

Per ogni attività è utile specificare:

• quale sistema viene utilizzato;

• quali dati vengono consultati;

• quali informazioni vengono inserite;

• quali documenti vengono prodotti;

• se i dati vengono trasferiti verso un’altra applicazione;

• se il trasferimento è manuale o automatico.

Nel processo delle fatture potrebbero essere coinvolti:

• il sistema di fatturazione elettronica;

• la casella email;

• il gestionale contabile;

• il software per gli ordini;

• un foglio di calcolo;

• l’archivio documentale;

• la piattaforma di approvazione.

La presenza di più strumenti non rappresenta necessariamente un problema.

Diventa però un elemento critico quando gli stessi dati vengono copiati manualmente da un’applicazione all’altra.

Questi passaggi possono generare:

• errori di digitazione;

• informazioni non aggiornate;

• duplicazioni;

• difficoltà di riconciliazione;

• assenza di una fonte unica;

• tempi di lavorazione più lunghi.

La mappa deve quindi evidenziare ogni trasferimento manuale.

Sono spesso proprio questi passaggi a offrire le migliori opportunità di automazione.

Rappresentare le decisioni in modo verificabile

Ogni decisione inserita nel diagramma dovrebbe corrispondere a una domanda chiara.

Esempi:

• La fattura contiene tutti i dati necessari?

• L’importo corrisponde all’ordine?

• Il fornitore è presente nell’anagrafica?

• La spesa rientra nel budget autorizzato?

• È richiesta una seconda approvazione?

• La scadenza è inferiore a sette giorni?

Domande generiche come “La fattura va bene?” non sono sufficienti per progettare un’automazione.

Per ogni decisione occorre definire:

• quali dati vengono controllati;

• quale regola viene applicata;

• chi prende la decisione;

• quali sono gli esiti possibili;

• quale percorso segue ciascun esito;

• che cosa accade quando i dati non sono disponibili.

Una persona può decidere utilizzando esperienza, contesto e conoscenze implicite.

Un sistema automatico, invece, ha bisogno di regole formalizzate.

Quando una decisione non può essere trasformata in una regola chiara, il workflow deve prevedere il trasferimento del caso a una persona.

Distinguere controllo, decisione e approvazione

Nel linguaggio aziendale, controllo, decisione e approvazione vengono spesso utilizzati come sinonimi.

In un progetto di automazione devono invece essere distinti.

Controllo

Il controllo verifica la presenza o la correttezza di un’informazione.

Esempio:

Verificare che il numero dell’ordine sia presente.

Decisione

La decisione determina il percorso successivo.

Esempio:

Se l’importo supera 5.000 euro, inviare la richiesta alla direzione.

Approvazione

L’approvazione esprime un’autorizzazione da parte di un soggetto responsabile.

Esempio:

Il responsabile autorizza la registrazione della fattura.

Questa distinzione aiuta a stabilire quali attività possano essere automatizzate.

Un controllo basato su dati strutturati può spesso essere eseguito automaticamente.

Una decisione può essere automatizzata quando la regola è chiara.

Un’approvazione con effetti economici, organizzativi o autorizzativi può invece richiedere l’intervento di una persona abilitata.

La mappa deve includere le eccezioni

Il percorso principale descrive ciò che accade quando tutte le condizioni previste sono rispettate.

Nella pratica, però, una parte significativa del lavoro viene assorbita dalle eccezioni.

Nel processo delle fatture possono verificarsi situazioni come:

• numero d’ordine mancante;

• importo diverso da quello concordato;

• fornitore non presente nell’anagrafica;

• documento duplicato;

• approvatore assente;

• centro di costo non indicato;

• contratto scaduto;

• fattura riferita a più reparti;

• contestazione già aperta;

• necessità di una nota di credito.

Se il diagramma non rappresenta questi casi, l’automazione funzionerà soltanto in condizioni ideali.

Per ogni eccezione occorre chiarire:

1. come viene riconosciuta;

2. chi deve gestirla;

3. quali informazioni sono necessarie;

4. entro quanto tempo deve essere risolta;

5. come il processo rientra nel flusso ordinario;

6. che cosa accade se rimane aperta.

Non tutte le eccezioni devono essere automatizzate.

In molti casi è più efficace automatizzare:

• il rilevamento;

• l’assegnazione;

• la notifica;

• il monitoraggio;

• l’escalation.

La valutazione finale può invece rimanere affidata a una persona.

Verificare la qualità del diagramma

Una volta completata la prima versione, il diagramma deve essere validato.

È utile rileggerlo ponendo alcune domande:

• Ogni attività ha un responsabile?

• Tutte le decisioni hanno almeno due esiti?

• Le frecce conducono sempre a un passaggio successivo?

• Sono visibili i sistemi utilizzati?

• Sono rappresentate le principali eccezioni?

• È chiaro quando il processo inizia e termina?

• Esistono attività duplicate?

• Sono presenti passaggi che nessuno riconosce come propri?

• Il flusso rappresenta il lavoro reale o soltanto la procedura formale?

• Una persona esterna al processo riuscirebbe a comprenderlo?

La verifica dovrebbe coinvolgere:

• chi esegue quotidianamente le attività;

• il responsabile del processo;

• i responsabili dei sistemi coinvolti;

• eventuali figure amministrative, legali o di sicurezza.

Se le persone coinvolte non riconoscono il proprio lavoro nel diagramma, la mappa deve essere corretta.

Il valore del documento non dipende dalla perfezione grafica, ma dalla fedeltà con cui rappresenta il processo reale.

Dal diagramma all’analisi operativa

Il diagramma consente di comprendere la struttura del processo, ma non mostra ancora quanto tempo richiedano le attività, dove si concentrino le attese e quali eccezioni generino più rilavorazioni.

La fase successiva consiste quindi nell’arricchire la mappa con informazioni operative.

Per ogni passaggio dovranno essere analizzati:

• tempo effettivo di lavorazione;

• tempo trascorso in attesa;

• frequenza;

• volume delle pratiche;

• percentuale di errore;

• numero di rilavorazioni;

• dipendenze da persone o sistemi;

• eccezioni più frequenti;

• conseguenze di un ritardo.

È importante distinguere il tempo di lavorazione dal tempo complessivo di attraversamento.

Una verifica può richiedere cinque minuti di lavoro effettivo, ma rimanere in attesa per due giorni prima di essere eseguita.

In questo caso il problema principale non è la durata dell’attività, ma l’attesa tra un passaggio e l’altro.

Nella sezione successiva vedremo come utilizzare questi dati per individuare colli di bottiglia, attività senza valore e priorità di intervento, fino a trasformare la mappa in requisiti concreti per l’automazione.