BPMN (Business Process Model and Notation) è il linguaggio standard per disegnare i processi aziendali: un insieme di simboli che business e IT leggono allo stesso modo e che, nella versione 2.0, un motore può eseguire. Saper leggere e scrivere un diagramma BPMN è la competenza centrale di chiunque lavori con i processi — e padroneggiare i gateway è ciò che separa un bel disegno da un processo che funziona.
Questa guida percorre i simboli BPMN raggruppati per famiglie, con un SVG di ciascuno, spiega i quattro gateway e l'errore classico che provoca un blocco, e si conclude con un diagramma BPMN completo di approvazione fatture. È il complemento pratico della nostra guida Che cos'è il BPM?.
BPMN è l'acronimo di Business Process Model and Notation: modello e notazione dei processi aziendali. È lo standard internazionale per rappresentare graficamente il funzionamento di un processo, mantenuto dall'Object Management Group (OMG) e recepito come norma ISO/IEC 19510. Il suo obiettivo è che lo stesso diagramma sia compreso da tre pubblici che normalmente parlano linguaggi diversi: l'analista di business che conosce il processo, il responsabile che lo approva e il team tecnico che lo implementa.
La grande differenza tra il BPMN e un semplice diagramma di flusso è la semantica precisa. In un diagramma di flusso, un rombo significa «una decisione» e ogni autore lo disegna a modo proprio. In BPMN, un rombo con una X all'interno è un gateway esclusivo dal comportamento definito al millimetro, distinto dal rombo con un segno + (parallelo). Questa precisione è ciò che consente al diagramma BPMN 2.0 di essere eseguibile: un motore di processi lo interpreta direttamente e lo trasforma in un'applicazione reale, senza che nessuno debba «tradurlo» in codice perdendo sfumature lungo il percorso.
Conviene collocare il BPMN nella disciplina più ampia che serve. Il BPMN è la notazione usata nella fase di modellazione del ciclo di vita BPM; se desidera il quadro completo — che cos'è la gestione per processi, in cosa si distingue da un workflow o dall'RPA e come si implementa — inizi dalla guida pilastro Che cos'è il BPM?.
In una frase: il BPMN sta ai processi come il pentagramma sta alla musica. Un linguaggio comune che chiunque può leggere e che una macchina può eseguire. Questa guida le insegna a leggerlo e a scriverlo bene.
BPMN 2.0 definisce decine di simboli, ma non occorre memorizzarli tutti. Quattro famiglie coprono l'immensa maggioranza dei diagrammi di business: eventi, attività, gateway e flussi di sequenza. Attorno a loro, due elementi di organizzazione — corsie (responsabilità) e artefatti (annotazioni e oggetti dati) — completano il quadro.
Cerchi. Qualcosa che accade: avvia, interrompe o termina il processo.
Rettangoli arrotondati. Il lavoro: compiti e sottoprocessi.
Rombi. Decisioni: il flusso si dirama o si sincronizza.
Frecce. L'ordine: collegano gli elementi in sequenza.
Un pool rappresenta un partecipante (un'organizzazione o un sistema); al suo interno, le corsie (lane) dividono il lavoro per ruolo o reparto. Collocano ogni attività sotto un responsabile chiaro. Lo vediamo in dettaglio nella sezione 6.
Non alterano il flusso, lo documentano: oggetti dati (un documento che entra o esce da un compito), annotazioni di testo (note per il lettore) e gruppi (riquadri che raggruppano visivamente). Utili affinché il diagramma si legga da solo.
Un evento è qualcosa che accade durante il processo. Si disegna sempre come un cerchio, e lo spessore del tratto ne indica la posizione nel flusso: l'evento di inizio ha tratto sottile, l'intermedio è un doppio cerchio e quello di fine ha tratto spesso. Questa regola, da sola, le permette già di leggere a colpo d'occhio da dove entra ed esce un processo.
Inoltre, un'icona all'interno del cerchio indica il tipo di evento: una busta è un evento messaggio (arriva o viene inviato qualcosa), un orologio è un timer (scade una scadenza), un fulmine è un errore e un triangolo è un segnale (un avviso che più processi possono ascoltare contemporaneamente).
Il processo si avvia quando arriva qualcosa dall'esterno: un'e-mail, un modulo web inviato, una fattura ricevuta. È il trigger più comune nei processi aziendali.
Fa attendere il flusso («attendi 3 giorni») oppure, agganciato al bordo di un compito, lo interrompe se la scadenza scade. È la base degli inoltri automatici per SLA.
Cattura un guasto di un compito o sottoprocesso e devia il flusso su un ramo di gestione degli errori, senza interrompere l'esecuzione.
Chiude un percorso del processo. Un diagramma può avere più eventi di fine (approvato, rifiutato, annullato): non è un errore, è una best practice per distinguere gli esiti.
Un'attività è il lavoro che viene svolto, e si disegna come un rettangolo con gli angoli arrotondati. Ciò che distingue un tipo di compito da un altro è una piccola icona nell'angolo in alto a sinistra: una persona per il compito utente, degli ingranaggi per il compito di servizio, una mano per il compito manuale, una pergamena per il compito script e una tabella per il compito di regola di business (business rule).
Quando un'attività racchiude a sua volta un altro processo, è un sottoprocesso (con un segno + sul bordo inferiore, che indica che può essere espanso) o una call activity (bordo spesso) che invoca un processo riutilizzabile definito a parte. E i marcatori alla base del compito indicano ripetizione: un ciclo (↻) o tre barre di multi-istanza (lo stesso compito per più elementi contemporaneamente, per es. «richiedere un preventivo a 3 fornitori»).
Un dettaglio che conta per l'esecuzione: il tipo di compito non è decorativo. In un motore BPMN, un compito utente genera una voce nella casella di una persona; un compito di servizio attiva una chiamata a un sistema o a un'API; uno di regola valuta una tabella decisionale. Per questo modellare bene il tipo di ciascun compito è ciò che rende il diagramma direttamente eseguibile. Un compito di servizio può essere risolto da codice, da un bot RPA o da un agente IA governato — il diagramma non cambia.
I gateway sono il cuore della logica di un processo e la parte che genera più dubbi. Si disegnano sempre come un rombo, e un simbolo interno ne definisce il comportamento. Ce ne sono quattro da padroneggiare. La regola mentale: un gateway divergente apre percorsi e quello convergente li riunisce; usare il tipo sbagliato nel riunirli è la causa numero uno dei processi che si bloccano.
Il flusso prende un solo percorso, il primo la cui condizione è vera. È l'«if/else» del processo. Esempio: «l'importo supera 5.000 €?» → Sì, va all'approvazione del direttore; No, viene contabilizzato direttamente. Si esegue solo uno dei due rami.
Attiva tutti i percorsi simultaneamente, senza condizioni. Esempio: all'assunzione di una persona, in parallelo si prepara la dotazione informatica, la si registra in busta paga e si richiede il badge di accesso. La convergenza parallela attende che terminino tutti prima di proseguire.
Attiva tutti i percorsi la cui condizione è soddisfatta, da uno a tutti. Esempio: un reclamo può richiedere, a seconda del caso, una revisione legale, una revisione tecnica o entrambe. La convergenza inclusiva attende solo i rami che si sono effettivamente attivati.
Il percorso non è deciso da una condizione sui dati, ma da quale evento si verifica prima. Esempio: dopo l'invio di un preventivo, il processo attende: se arriva l'accettazione del cliente, va alla fatturazione; se scade il termine di 15 giorni (timer), va al follow-up commerciale.
L'errore più frequente nella modellazione BPMN: aprire il flusso con un gateway esclusivo (dove si attiva un solo ramo) e poi provare a chiuderlo con un gateway parallelo di convergenza. Il parallelo attende l'arrivo di tutti i rami — ma poiché l'esclusivo ne ha attivato solo uno, gli altri non arrivano mai. Il processo resta in attesa per sempre: questo è un deadlock (blocco).
La regola per evitarlo: chiuda con lo stesso tipo con cui ha aperto. Ciò che è divergito in un esclusivo si riunisce in un esclusivo; il parallelo, in parallelo; l'inclusivo, in inclusivo. Far coincidere apertura e chiusura elimina l'immensa maggioranza dei blocchi.
Un diagramma BPMN non mostra solo che cosa accade, ma chi lo fa. A questo servono le corsie (swimlane). Immagini una piscina vista dall'alto: il grande rettangolo è il pool (il partecipante completo, per es. «La nostra azienda») e le fasce orizzontali al suo interno sono le corsie, una per ruolo o reparto: Finanza, HR, il sistema. Ogni compito si disegna nella corsia del responsabile che lo esegue — così, leggendo in verticale, sa di chi è ciascun passo.
La distinzione chiave è quando usare una corsia e quando un pool separato:
Quando tutti i partecipanti appartengono alla stessa organizzazione e condividono il processo. I compiti si collegano con flussi di sequenza (frecce piene) che passano da una corsia all'altra. Esempio: la Finanza e il sistema ERP nel processo delle fatture.
Quando interviene un'altra organizzazione (un cliente, un fornitore, una pubblica amministrazione) il cui processo interno non controlla né vede. I pool non si collegano con flussi di sequenza, ma con flussi di messaggio (frecce tratteggiate): scambiano solo comunicazioni.
Questa regola evita un errore comune: inserire il cliente come una corsia in più all'interno del proprio pool. Lei non orchestra i compiti interni del cliente — gli invia e riceve solo messaggi. Modellarlo come pool separato chiarisce il confine di responsabilità e rende il diagramma onesto su ciò che lei controlla davvero.
Mettiamo tutto insieme in un diagramma reale. Modelliamo l'approvazione di una fattura con un pool a due corsie — Finanza (le persone) e Sistema (i passi automatici) — un evento di inizio di tipo messaggio, un compito di servizio di OCR, un gateway esclusivo che decide in base all'importo, un compito utente di approvazione, la registrazione nell'ERP e un evento di fine.
Lo legga seguendo le frecce: la fattura arriva e avvia il processo nella corsia Sistema; il compito di servizio OCR estrae importo, fornitore e scadenza; il gateway esclusivo guarda l'importo. Quelle sotto i 5.000 € non hanno bisogno di una persona e vanno dirette all'ERP; quelle che lo superano salgono alla corsia Finanza, dove una persona approva prima che il sistema le registri. Un unico evento di fine segna «contabilizzata».
Noti ciò che il diagramma rende esplicito senza una sola riga di prosa: quali passi sono automatici e quali umani (le corsie), dove si trova la decisione e con quale criterio (il gateway e la sua etichetta), e quando interviene una persona (solo al di sopra della soglia). È questa la potenza del BPMN: documenta, comunica e — in BPMN 2.0 — viene eseguito, tutto con lo stesso disegno. È proprio il tipo di processo che troverà pronto da attivare nel catalogo di modelli BPM.
Ecco la differenza che ha cambiato il mercato. Nel mondo dei diagrammi di flusso di una volta, il disegno era documentazione: qualcuno lo approvava, e poi un team lo «traduceva» in codice. In quella traduzione si perdevano sfumature, si introducevano scostamenti e, sei mesi dopo, il diagramma e la realtà non coincidevano più.
Con BPMN 2.0 su un motore di processi, non c'è traduzione: il diagramma è il programma. Il motore legge l'XML del modello (BPMN 2.0 definisce un formato di interscambio standard) e lo esegue così com'è. Quando il flusso raggiunge un compito utente, il motore crea la voce nella casella della persona; in un compito di servizio, chiama il sistema; in un gateway, valuta la condizione e sceglie il ramo. Ciò che il business ha validato è, letteralmente, ciò che gira in produzione.
Su una piattaforma BPM low-code questo va un passo oltre: oltre al diagramma, progetta i moduli, le regole e le integrazioni in modo visuale, senza programmare. Le fasi di modellazione ed esecuzione del ciclo di vita BPM si fondono in una sola. Per questo il primo processo in produzione si misura in settimane, non in mesi.
Se vuole vedere come si costruisce un processo BPMN eseguibile dall'inizio alla fine, guardi la piattaforma BPM low-code di Dokuflex; e per il contesto completo della disciplina, la guida Che cos'è il BPM?.
Un diagramma BPMN tecnicamente corretto può comunque restare illeggibile. Queste convenzioni, semplici, fanno la differenza tra un modello che si comprende da solo e uno che richiede spiegazioni:
«Approvare la fattura», «Registrare nell'ERP», «Notificare il cliente». Non «Fattura» né «Gestione»: un compito è un'azione. Gli eventi, invece, si nominano come sostantivo o stato («Fattura ricevuta», «Contratto firmato»).
Disegni il flusso principale su una linea retta orizzontale e lasci le eccezioni e i rifiuti uscire verso l'alto o verso il basso. Il lettore deve poter seguire il caso normale senza sforzo e vedere le deviazioni come rami.
Le frecce che si incrociano sono il segnale visivo di un diagramma disordinato. Riorganizzi la posizione dei compiti finché i flussi non si sovrappongono; quasi sempre è possibile.
Se un processo cresce troppo, smette di essere leggibile. Incapsuli i blocchi in sottoprocessi espandibili: il diagramma di primo livello racconta la storia, e ogni sottoprocesso fornisce il dettaglio a chi ne ha bisogno.
Ciò che apre un esclusivo, lo chiude un esclusivo; il parallelo, un parallelo. È la regola che evita i deadlock della sezione 5. E etichetti sempre i rami di un esclusivo (Sì/No, <5.000/>5.000).
Un processo evolve. Conservi versioni del modello e, nel motore, mantenga in coesistenza la versione vecchia per le pratiche in corso e quella nuova per quelle che partono. Cambiare il diagramma non dovrebbe rompere ciò che è già in esecuzione.
E un errore di fondo al di là della notazione: non modelli il processo che vorrebbe avere, modelli quello che ha — comprese le sue eccezioni reali — e poi lo migliori. Un diagramma idealizzato che ignora i casi difficili si rompe il primo giorno in produzione.
BPMN è l'acronimo di Business Process Model and Notation (modello e notazione dei processi aziendali). È lo standard internazionale, mantenuto dall'Object Management Group (OMG) e recepito nella norma ISO/IEC 19510, che definisce un linguaggio grafico per disegnare i processi in modo che chiunque li comprenda e, in BPMN 2.0, un motore possa eseguirli.
No. Un diagramma di flusso classico è informale: ogni autore usa i simboli a modo proprio e non è eseguibile. BPMN 2.0 è uno standard con semantica precisa: ogni simbolo ha un significato definito (eventi di tipo messaggio o timer, gateway esclusivi o paralleli, corsie per responsabile) e un motore BPM può interpretare il diagramma e metterlo in produzione senza reinterpretarlo.
Il gateway inclusivo (rombo con un cerchio all'interno, simbolo O). Attiva tutti i percorsi la cui condizione è vera, da uno a tutti contemporaneamente. Se può essere vera una sola condizione usa l'esclusivo (X); se vuoi lanciare sempre tutti i percorsi in parallelo, senza condizione, usa il parallelo (+). Ricorda di chiudere la divergenza inclusiva con un altro gateway inclusivo di convergenza per sincronizzare correttamente.
Per disegnare basta qualsiasi editor che supporti lo standard (compresi editor gratuiti basati su bpmn.io). Ma il valore del BPMN 2.0 è che il diagramma è eseguibile: su una piattaforma BPM low-code lo stesso diagramma che validi con il business diventa l'applicazione reale, con moduli, regole e integrazioni, senza doverlo ridisegnare in un altro strumento.
Sì. Un'attività di un processo BPMN può essere eseguita da una persona, da un servizio, da un bot RPA o da un agente IA. Modellare il passo di IA come attività di servizio all'interno del diagramma mantiene la tracciabilità: il gateway successivo decide in base al risultato o al livello di confidenza, e il flusso viene scalato a un'attività utente quando l'IA non raggiunge la soglia (human-in-the-loop).
Anche se BPMN 2.0 definisce decine di simboli, quattro gruppi coprono il 90% dei diagrammi reali: eventi (inizio, intermedio, fine), attività (compiti e sottoprocessi), gateway (esclusivo, parallelo, inclusivo e basato su eventi) e flussi di sequenza, organizzati in corsie. Con questo sottoinsieme si modella quasi tutti i processi aziendali.
Porti il processo che ha già disegnato — fatture, ferie, onboarding — e le mostriamo lo stesso diagramma BPMN in esecuzione in Dokuflex in una demo di 30 minuti. Senza impegno e con il suo caso, non con uno di laboratorio.