Mappatura dei processi: cosa serve dello standard

01Perché mappare prima: Hammer, 1990

La frase che regge questo articolo ha trentasei anni. Michael Hammer la scrisse sul numero di luglio-agosto 1990 della Harvard Business Review, in un pezzo intitolato Reengineering Work: Don't Automate, Obliterate: i pesanti investimenti in tecnologia dell'informazione hanno dato risultati deludenti, e in gran parte perché le aziende usano la tecnologia per meccanizzare i vecchi modi di fare le cose, lasciando intatti i processi esistenti e usando i computer solo per accelerarli.

Hammer chiude il ragionamento con un'immagine che è rimasta: è ora di smettere di asfaltare i sentieri delle vacche. Un sentiero tracciato dal passaggio degli animali resta storto anche quando ci si mette sopra il bitume, e la macchina ci passa più in fretta facendo la stessa curva inutile.

Non possiamo ottenere salti di prestazione tagliando il grasso o automatizzando i processi esistenti.

Michael Hammer, Harvard Business Review, luglio-agosto 1990

Il caso che Hammer porta è la contabilità fornitori di Ford. All'inizio degli anni Ottanta il reparto contava più di 500 persone nel solo Nord America, e la direzione pensava di scendere del 20% razionalizzando i processi e installando nuovi sistemi informatici, cioè arrivando a 400 persone. Poi Ford guardò Mazda: là lo stesso reparto era di 5 persone. Anche corretto per la differenza di dimensione, il reparto di Ford risultò cinque volte più grande di quanto avrebbe dovuto essere.

La riprogettazione cambiò la regola implicita, che nessuno aveva mai scritto da nessuna parte: da «paghiamo quando riceviamo la fattura» a «paghiamo quando riceviamo la merce». Prima il reparto doveva far combaciare 14 dati fra ordine, documento di ricevimento e fattura; dopo ne bastano 3, codice articolo, unità di misura e codice fornitore, e ai fornitori Ford chiese di non mandare più la fattura. Il risultato fu una riduzione di organico del 75%, contro il 20% che avrebbe dato il programma convenzionale.

Quel 75% arriva da una mappa. Il gruppo di Ford prima ricostruì chi mandava cosa a chi, e solo guardando quel disegno si vide che il tempo se ne andava sulle discordanze fra tre documenti che esistevano perché esisteva la regola vecchia. Automatizzare la ricerca delle discordanze avrebbe dato il 20%.

02BPMN, e il sottoinsieme che lo standard stesso prevede

La notazione per disegnare un processo si chiama BPMN, Business Process Model and Notation, ed è mantenuta dall'Object Management Group. La versione in vigore è la 2.0.2, documento OMG formal/2013-12-09, datata dicembre 2013, e conta 532 pagine (specifica ufficiale). La stessa notazione è stata recepita come norma internazionale: ISO/IEC 19510:2013, pubblicata nel 2013 e adottata dal BSI il 31 luglio dello stesso anno.

Cinquecentotrentadue pagine non si insegnano a un ufficio acquisti, e lo standard lo sa. Il capitolo 2 della specifica definisce tre sottoclassi di conformità sotto la conformità piena alla modellazione di processi: Descriptive, Analytic e Common Executable. Della prima la specifica scrive che riguarda gli elementi visibili usati nella modellazione ad alto livello, e che dovrebbe risultare comoda agli analisti abituati agli strumenti di diagrammi di flusso. La seconda contiene la prima più circa metà dei costrutti della classe piena.

La tabella 2.1 della specifica elenca gli elementi della sottoclasse Descriptive: sono 24 righe, e una di queste, documentation, non è nemmeno un elemento visibile. Dentro ci stanno pool e corsie, il flusso di sequenza e il flusso di messaggio, i gateway esclusivo e parallelo, i task, i sottoprocessi, l'oggetto dati, l'annotazione testuale, gli eventi di inizio e fine con le varianti a messaggio, a tempo e di terminazione.

Quindi lavorare con pochi simboli è una scelta prevista dal documento che definisce la notazione. I quattro che bastano a mappare un ordine cliente, un ciclo di approvvigionamento o la gestione di un reclamo stanno tutti dentro la tabella 2.1, e una mappa fatta con quelli resta leggibile da chiunque conosca lo standard.

Evento, il cerchio

Segna qualcosa che accade. Cerchio sottile per l'inizio, cerchio spesso per la fine; ogni processo ne ha almeno uno per parte. Nella tabella 2.1 compaiono startEvent ed endEvent nelle varianti semplice, a messaggio, a tempo e di terminazione.

Attività, il rettangolo

Un'azione svolta da una persona o da un sistema, scritta con un verbo all'infinito: verificare la disponibilità a magazzino, emettere la fattura. Nella tabella 2.1 sono task, userTask e serviceTask, e i sottoprocessi aperti o chiusi.

Gateway, il rombo

Il punto in cui il flusso si biforca, con una domanda a risposte mutuamente esclusive: il materiale è disponibile, sì o no. La sottoclasse Descriptive ne ammette due, exclusiveGateway e parallelGateway; l'inclusivo e quello basato su eventi entrano nella sottoclasse Analytic.

Corsia, la swimlane

Chi è responsabile di cosa. Il diagramma si divide in corsie orizzontali, una per attore: commerciale, magazzino, amministrazione. Nella specifica sono participant, cioè il pool, e laneSet.

03L'As-Is: fotografare il processo che gira

La mappa As-Is è il processo come funziona oggi. Hammer descrive lo scarto fra il processo formale e quello reale con una frase secca: la vecchia regola di Ford, «paghiamo quando riceviamo la fattura», nessuno l'aveva mai formulata né messa per iscritto, eppure determinava come era organizzato tutto il reparto. Le regole che governano un processo stanno quasi sempre fuori dalle procedure.

Per farla uscire servono tre tecniche insieme, perché ognuna prende quello che le altre perdono.

1. Intervista a chi esegue: la persona descrive passo per passo da chi riceve, cosa fa, a chi consegna, con quali strumenti e dove si blocca. Le interviste ai soli responsabili restituiscono il processo come dovrebbe essere.
2. Osservazione diretta: si sta accanto mentre il lavoro accade, annotando tempi, interruzioni e i passaggi che nessuno cita perché li dà per scontati.
3. Analisi dei documenti: moduli, email, fogli di calcolo, ticket. Il caso Ford si regge su un conteggio di documenti, tre, e di campi da far combaciare, quattordici: quei numeri escono dalla carta prima che dalle interviste.

Poi si disegna, e si valida con le stesse persone intervistate. La domanda da fare è se il diagramma descrive quello che fanno ogni giorno, e le correzioni che arrivano a quel punto sono la parte utile del lavoro.

Il perimetro conta quanto il metodo. Hammer scrive che riprogettare la sola contabilità fornitori di Ford era inutile: il perimetro giusto era il processo di acquisizione della merce, che comprendeva anche acquisti e ricevimento. Una mappa che si ferma al confine di un reparto nasconde proprio i passaggi di mano, che sono dove il tempo si perde.

04I colli di bottiglia: 22 giorni, 17 minuti

Il numero più utile di tutto l'articolo di Hammer è una parentesi. Descrivendo il processo di Mutual Benefit Life, la diciottesima compagnia vita degli Stati Uniti, Hammer riporta la stima di un altro assicuratore: una pratica passava 22 giorni dentro al processo e veniva lavorata per 17 minuti.

Diciassette minuti su ventidue giorni fanno lo 0,05% del tempo di attraversamento. Tutto il resto è attesa fra un passaggio e l'altro. Un intervento che rende più veloce la lavorazione agisce su quei diciassette minuti; un intervento sui passaggi di mano agisce sui ventidue giorni.

Il processo di Mutual Benefit Life aveva numeri coerenti con quella stima: fino a 30 passaggi distinti, 5 reparti e 19 persone; nel migliore dei casi una pratica si chiudeva in 24 ore, ma i tempi tipici andavano da 5 a 25 giorni, e la maggior parte del tempo se ne andava nel passare le informazioni da un reparto al successivo. Dopo la riprogettazione, con una figura sola responsabile della pratica dall'inizio alla fine, il tempo minimo scese a 4 ore e quello tipico a 2-5 giorni, con 100 posizioni di filiale eliminate e più del doppio del volume gestito.

Accanto a ogni criticità va scritta una stima: quanti minuti, quanti errori, quante pratiche al mese. Anche approssimativa serve a ordinare le priorità, e il confronto fra 22 giorni e 17 minuti mostra quanto le due grandezze possano divergere.

05Il To-Be: eliminare, semplificare, automatizzare

Il To-Be è il processo come dovrà funzionare. L'ordine delle tre mosse viene dal caso Ford, dove l'ultima è arrivata davvero per ultima.

1. Eliminare: togliere quello che esiste per una regola che non vale più. Ford ha eliminato la fattura in ingresso, che era un documento intero, insieme alla regola non scritta che lo giustificava.
2. Semplificare: ridurre quello che resta. I campi da far combaciare sono passati da 14 a 3, e il confronto fra tre documenti è diventato un confronto fra due.
3. Automatizzare: solo alla fine. Nel nuovo processo di Ford l'incrocio dei tre campi lo fa il computer e il sistema prepara l'assegno, ma su un processo che nel frattempo era diventato un altro.

Questa è la stessa distinzione che Divide et Delega chiede di fare su ogni pezzo di lavoro: prima si spezza il processo, poi si decide pezzo per pezzo se è calcolo o giudizio, e alla macchina va il calcolo, con un cancello davanti. Il giro pratico, con il conto del tempo e il codice, sta in Gen AI per l'automazione dei processi.

È ora di smettere di asfaltare i sentieri delle vacche. Invece di incastrare processi superati dentro al silicio e al software, dovremmo cancellarli e ricominciare. (Hammer, 1990)

Nel disegnare il To-Be conta chi c'è nella stanza. Il nuovo processo di Mutual Benefit Life ha funzionato perché ha spostato la responsabilità su una figura sola, il case manager, che lavora senza passaggi di consegna e chiama un sottoscrittore anziano o un medico solo come consulenti. Quel disegno lo si fa con chi conosce le eccezioni.

Servono poi i numeri con cui si misura il prima e il dopo. Il caso Ford ne ha tre: teste nel reparto, documenti da confrontare, campi da far combaciare. Sono tutti conteggi che esistono già nella mappa As-Is, e questo li rende disponibili prima di spendere.

06Strumenti, e il formato che li tiene insieme

Per le prime sessioni carta e pennarelli reggono, perché mettono d'accordo le persone davanti allo stesso foglio. La versione digitale serve dopo, e serve per una ragione precisa: la specifica BPMN 2.0.2 definisce anche un formato di scambio, con uno schema XML pubblicato dall'OMG (BPMN20.xsd e i file CMOF associati). Una mappa salvata in quel formato si apre in un altro programma.

Questo è il criterio con cui scegliere uno strumento, e riduce l'elenco a una domanda: esporta BPMN 2.0 conforme allo schema, sì o no. Le lavagne collaborative online disegnano le forme ma spesso salvano solo il disegno; i modellatori dedicati salvano il modello. La differenza si vede il giorno in cui la mappa deve passare a chi implementa, oppure il giorno in cui si cambia fornitore.

Le convenzioni valgono più dello strumento. Un archivio unico delle mappe, un responsabile per ciascun processo, un codice e una data su ogni versione, per esempio PRO-COM-001 Gestione ordine cliente, rev. 2026-03. Una mappa non aggiornata descrive un processo che non esiste più, e chi la legge prende decisioni su quello.

07Gli errori che si ripetono, e il dato italiano

Il primo errore è mappare il processo ideale. La difesa è quella di Ford: cercare la regola non scritta. La domanda che la fa uscire è perché un passaggio esiste, ripetuta finché la risposta smette di essere «si è sempre fatto così». Hammer le affianca una seconda domanda da rifare a ogni passo: che cosa succederebbe se quel passaggio non ci fosse.

Il secondo errore è il dettaglio. Una mappa che vuole contenere ogni eccezione diventa illeggibile, e la sottoclasse Descriptive di BPMN esiste per questo: 24 elementi dentro a una specifica di 532 pagine sono una scelta di livello, fatta dallo stesso ente che ha scritto tutto il resto.

Il terzo è il perimetro corto. Riprogettare un reparto solo, scrive Hammer a proposito della contabilità fornitori di Ford, era futile: i passaggi di mano che costano stanno per definizione fra due reparti, quindi fuori dal perimetro di ciascuno.

Restano due errori di gestione: nessun responsabile della mappa e del suo aggiornamento, e nessuna domanda a cui la mappatura debba rispondere. Una mappa senza domanda produce un documento che nessuno riapre.

Quanti processi digitali ci sono davvero

Sul punto di partenza delle imprese italiane il dato lo pubblica l'Istat il 15 dicembre 2025. Un sistema gestionale ERP ce l'ha l'85,9% delle grandi imprese e il 48,8% delle piccole e medie; un CRM il 56,5% contro il 21,1%. Fa attività di analisi dei dati il 42,7% delle imprese con almeno dieci addetti, contro il 26,6% del 2023 (Istat, Imprese e ICT 2025).

Nella stessa rilevazione, fra le imprese che hanno valutato l'intelligenza artificiale e poi hanno rinunciato, il 45,2% indica come ostacolo la scarsa qualità o la mancanza dei dati, davanti al costo, che sta ultimo al 43,0%. Al primo posto ci sono le competenze, al 58,6%, seguite dalla normativa poco chiara al 47,3%. La qualità dei dati è un esito del processo che li produce: dove lo stesso dato si inserisce a mano in due sistemi, come nel Ford di prima della riprogettazione, i due valori divergono e il problema si presenta a valle come problema di dati.

08Le fonti primarie

I quattro documenti su cui si regge questo articolo, tutti consultabili per intero.

• Hammer 1990: Reengineering Work: Don't Automate, Obliterate, Harvard Business Review, luglio-agosto 1990, ristampa 90406. Da lì vengono i casi Ford e Mutual Benefit Life e i numeri citati qui (hbr.org).
• BPMN 2.0.2: specifica OMG formal/2013-12-09, dicembre 2013, 532 pagine. Il capitolo 2 contiene le sottoclassi di conformità e la tabella 2.1 con gli elementi della Descriptive (omg.org).
• ISO/IEC 19510:2013: Information technology, Object Management Group Business Process Model and Notation, la versione della stessa notazione come norma internazionale.
• Istat, Imprese e ICT anno 2025: comunicato del 15 dicembre 2025, con i dati su ERP, CRM, analisi dei dati e ostacoli all'adozione dell'AI (istat.it).

Sul passaggio dalla mappa all'automazione, il metodo che uso in azienda è descritto in Divide et Delega, e il corso gratuito che lo applica processo per processo è Gen AI per l'automazione dei processi.

09Glossario

I termini usati qui, con il riferimento alla specifica dove esiste.

• BPMN: Business Process Model and Notation, notazione dell'Object Management Group per i diagrammi di processo. Versione in vigore 2.0.2, dicembre 2013, recepita come ISO/IEC 19510:2013.
• Sottoclasse di conformità: insieme ridotto di elementi che uno strumento o una mappa possono usare restando conformi. BPMN 2.0.2 ne definisce tre: Descriptive, Analytic e Common Executable.
• As-Is: il processo come viene eseguito oggi, workaround compresi. La regola di Ford «paghiamo quando riceviamo la fattura» era parte dell'As-Is senza essere scritta da nessuna parte.
• To-Be: il processo come dovrà funzionare dopo l'intervento, nell'ordine eliminare, semplificare, automatizzare.
• Swimlane: corsia del diagramma che indica chi è responsabile di un'attività. Nella specifica sono participant per il pool e laneSet per le corsie interne.
• Gateway: rombo che biforca il flusso. La sottoclasse Descriptive ammette l'esclusivo e il parallelo; l'inclusivo e quello basato su eventi entrano nella Analytic.
• Tempo di attraversamento: il tempo che una pratica passa dentro al processo, attese comprese. Nella stima riportata da Hammer erano 22 giorni contro 17 minuti di lavorazione.
• Passaggio di mano: il momento in cui una pratica cambia responsabile. In Mutual Benefit Life erano fino a 30 su 5 reparti, ed è lì che stava la maggior parte del tempo.
• Process owner: la persona responsabile di un processo dall'inizio alla fine, mappa compresa. Il case manager di Mutual Benefit Life è la versione operativa della stessa idea.
• Process mining: ricostruzione delle mappe dai log dei sistemi informativi invece che dalle interviste. Richiede che il processo passi già da un sistema che registra, e in Italia l'ERP ce l'ha il 48,8% delle PMI.