BPMN, UML o diagramma di flusso: quale scegliere

BPMN o UML? La scelta dipende da ciò che si desidera rappresentare. BPMN descrive i processi aziendali e il flusso di lavoro tra i partecipanti; UML rappresenta la struttura e il comportamento del software. Un diagramma di flusso, invece, offre un modo rapido e informale per illustrare passaggi e decisioni. A prima vista le tre notazioni possono sembrare simili, ma ciascuna risponde a esigenze diverse.

Questa pagina confronta gli scopi delle diverse notazioni, presenta una tabella per aiutarLa a scegliere e spiega perché modelliamo con BPMN 2.0 invece di adottare una notazione proprietaria.

Cosa rappresenta ciascuna notazione?

BPMN 2.0 è l’acronimo di Business Process Model and Notation. È gestito dall’Object Management Group (OMG) e rappresenta i processi aziendali: partecipanti, attività, sequenze, decisioni ed eventi che avviano o interrompono il lavoro. I simboli e le regole per collegarli sono definiti, quindi è possibile convalidare i modelli rispetto a tali regole. BPMN 2.0 definisce inoltre un formato XML per scambiare modelli tra strumenti diversi. Per un’introduzione alla notazione, consulti la guida a BPMN 2.0.

UML è l’acronimo di Unified Modeling Language. È anch’esso uno standard OMG e serve a descrivere i sistemi software e il loro comportamento. Comprende diagrammi di classi, componenti, distribuzione, sequenza, attività, macchine a stati e casi d’uso. I diagrammi di attività sono quelli che più spesso si sovrappongono alla modellazione dei processi.

I diagrammi di flusso rappresentano passaggi e decisioni con forme e frecce. Non esistono uno standard di riferimento né un insieme di regole fisse, perciò i team si affidano a convenzioni locali: sono rapidi da disegnare, ma due persone possono interpretarli in modo diverso. Anche il nome varia, da flow chart a flow-chart, fino al comune errore di battitura flow charter, ma si tratta sempre dello stesso tipo di diagramma informale.

BPMN, UML o diagramma di flusso: come scegliere?

Individui il risultato da produrre e scelga la notazione indicata nella colonna centrale.

La domanda non è quale notazione risulti più familiare, ma cosa deve comunicare il diagramma e chi dovrà usarlo dopo che lo avrà disegnato.

Come può adottare una notazione insieme al team? Per prima cosa, concordate in una frase quale risultato volete ottenere e non scegliete in base allo strumento: le preferenze di un fornitore o di una vecchia licenza non sono un criterio per decidere la notazione. Se entrambe le notazioni sono adatte, scelga quella che più persone possono interpretare senza aiuto e documenti le convenzioni aggiuntive, per esempio quelle relative a nomi, disposizione e livello di dettaglio, così il modello successivo non dovrà inventarne di nuove. Per verificare che il diagramma sia chiaro, lo mostri a una persona che non ha partecipato al workshop e le chieda cosa succede dopo. Se non sa rispondere, di solito il problema non è la notazione.

Perché BPMN e UML sembrano simili?

Sia un diagramma di attività UML sia un diagramma di processo BPMN possono usare rettangoli arrotondati per le attività, rombi per le decisioni e barre per i percorsi paralleli. A prima vista possono sembrare molto simili.

Il significato delle forme, però, è diverso. Un diagramma di attività UML descrive il comportamento in un contesto software o di sistema. Un diagramma BPMN descrive il lavoro svolto dai partecipanti, che possono essere persone, reparti e sistemi. BPMN include elementi specifici per partecipanti, lane, flussi di messaggi ed eventi, mentre i diagrammi di attività UML non rappresentano questi concetti dei processi aziendali nello stesso modo.

È possibile combinare BPMN, UML e diagrammi di flusso?

Sì, purché ogni diagramma indichi chiaramente la notazione utilizzata:

• Documenti il processo aziendale in BPMN e il software che lo supporta in UML. Mantenga esplicito il collegamento, per esempio usando un nome o un identificatore condiviso.
• Utilizzi UML per la progettazione del software anche quando è inserito in un processo BPMN. Ogni modello risponde a una domanda diversa.

Il problema non è usare più notazioni nella stessa organizzazione: lo facciamo anche noi. Il problema è mescolarle in un unico diagramma senza dichiararlo. Se chi legge non riesce a capire se una forma rappresenta un’attività, un elemento software o un passaggio informale, non può fidarsi del diagramma.

Quando è preferibile un diagramma di flusso?

La scelta tra BPMN e un diagramma di flusso è la stessa, ma su scala ridotta; di solito, la differenza riguarda la manutenzione. Un diagramma di flusso è più adatto a una procedura breve, a uno schema preparato durante un workshop o a una spiegazione occasionale: pochi passaggi e una decisione, senza una struttura che al team non serve ancora.

Scelga BPMN quando il diagramma deve essere letto in modo coerente, verificato rispetto alle regole della notazione, rivisto il trimestre successivo o condiviso tra team. Se ha dei dubbi, prepari prima uno schema e formalizzi il processo in BPMN quando sarà utile disporre di un modello. Per una panoramica più ampia dei tipi di diagramma, consulti la guida alla mappatura dei processi; se invece sta abbandonando un vecchio strumento per creare diagrammi, legga le alternative a Visio per BPMN.

E i diagrammi di flusso che il team ha già creato? Li consideri un punto di partenza, non il modello definitivo. Uno schema preparato durante un workshop è spesso il modo più rapido per concordare l’ambito; quando il processo diventa importante, ridisegnarlo in BPMN richiede un’ora o due. Il diagramma di flusso resta così una bozza, non un’alternativa. È meglio evitare di mantenere lo stesso processo in due notazioni: nessuna delle due versioni sarebbe autorevole e la riunione finirebbe per concentrarsi su quale sia quella aggiornata.

Come mantenere portabile un modello BPMN?

Crei il diagramma in un ambiente che rispetti lo standard della notazione e consenta di esportare il file. ProcessMind permette di modellare in BPMN 2.0 nel browser e importa ed esporta file BPMN, così il diagramma non resta vincolato al prodotto con cui è stato creato. Può inoltre mantenere il modello accanto al processo individuato tramite Process Mining, per confrontare il processo previsto con quello registrato dai sistemi.

Scopra come funziona l’ambiente di modellazione di ProcessMind oppure consulti gli elementi BPMN supportati.