Realizzare Documentazione: posso usare la BPMN?

Come spesso accade quando si deve presentare un argomento a chi è completamente a digiuno, nell’ultimo periodo mi sono ritrovato spesso a dover “raccontare” la BPMN partendo da zero.

Ad onor del vero i miei interlocutori masticavano già altre metodologie notazionali però volevano comprendere se attraverso la BPMN fosse possibile produrre la documentazione necessaria a tracciare un processo, garantendone la facilità d’aggiornamento e la scalabilità.

Quindi più che della BPMN per il BPM (in senso stretto), le richieste vertevano sulla BPMN orientata al documentation management per mezzo di BPD (business Process Diagram). Per soddisfare questa esigenza ho realizzato uno schemino riassuntivo dei simboli del BPMN (non una completa reference come può essere il classico poster che molti siti forniscono) e un breve caso di studio, semplice e alla portata di tutti.

Provo a condividere il tutto qui nel blog. Partiamo dallo schemino riassuntivo dei simboli (mancano varie cose, come coreografie , eccezioni, etc... poichè lo scopo è esplicitare l’elenco dei soli elementi che possono tornarci utili per l’esempio):

Categoria	Nome	Definizione	Simbolo
Swim Lanes Rappresentano I partecipanti ad un processo	Pool	Definisce un gruppo di partecipanti interni od esterni al processo
	Lane	Definisce un preciso partecipante o un preciso ruolo
Flow Objects Rappresentano ciò che succeed durante un processo.	Event	Mostra ciò che può accadere o è accaduto durante un processo.
	Activity	Operazioni/Compiti eseguiti da un partecipante.
	Gateway	Controlla la sequenza e il flusso di un processo
Data Rappresentano le informazioni usate o create durante un processo .	Data Object	Informazione richiesta o prodotta da un Activity: il suo ciclo di vita è limitato all’Activity stessa.
	Data Store	Informazione richiesta o prodotta da un Activity e resa persistente attraverso il suo salvataggio.
	Message	Contiene il contenuto della comunicazione tra due partecipanti.
Artefacts Decorano ed estendono gli elementi dei processi.	Group	Raggruppa elementi accomunati da qualche criterio d’analisi.
	Annotation	Aggiunge ulteriori informazioni ad un element.
Connecting Objects Connettono due elementi.	Sequence Flow	Connessione tra Flow Object di un processo; evidenzia il percorso d’esecuzione tra le Activity .
	Message Flow	Mostra il flusso di un messaggio tra i partecipanti o i processi.
	Association	Collega elementi Data a Flow Object e ne mostra la direzione.

Come caso di studio è conveniente prendere qualcosa comunemente conosciuto ma che al tempo stesso rappresenti un processo con una implicita connotazione commerciale: sono le caratteristiche che il nostro interlocutore si aspetta di incontrare in un esempio. La scelta ricade sul classico ordine al bar. Questa tipologia di esempio arricchisce la stragrande maggioranza della letteratura dei processi, perciò la scleta non è così originale...

Fissiamo alcune caratteristiche legate al caso di studio. Le bevande che possono essere ordinate saranno solo 5, suddivise in due macro categorie:

Caffè	Cappuccino Caffè latte Espresso
Thè	English Breakfast Early Grey

Per chi ha mai frequentato uno Starbucks (o altra grande catena) sarà più semplice immaginare il processo suddiviso nei successivi punti :

• Il cliente fa l’ordine e paga alla cassa.
• L’ordine viene trasferito al barista che lo dovrà preparare.
• In base all’ordine (caffè o thè) varierà la tipologia di passi per prepararli.
• L’ordine , una volta che è stato preparato, viene passato al cliente.
• Il barista può richiedere altra materia prima (chicchi di caffè, etc..) a chi si occupa delle scorte.
• Il cliente può aggiungere latte, zucchero e/o miele al proprio ordine servendosi da solo dal bancone.

Per prima cosa rappresentiamo l’intero processo e i vari attori che vi partecipano. Poi scenderemo ad un maggior dettaglio per una delle Activity: sceglieremo la ricezione dell’ordine poichè è quella a cui di certo ognuno di noi almeno una volta vi ha partecipato, quindi sarà più semplice comprenderne le dinamiche.

------

Di Sicuro i due diagrammi non saranno esaustivi perchè mancano varie logiche, ad esempio la gestione delle eccezioni (il cliente non ha i soldi al momento del pagamento, non posso preparare una bevanda per assenza della materia prima, etc...), però fanno comprendere all’interlocutore , che si suppone sia a diugiono di BPMN ma non di Business Analysis Know-how, come sia semplice e veloce raccontare un processo, documentarlo, identificarne subito gli attori ed evidenziare le parti automatiche da quelle manuali.

Io sfrutto la semplicità degli schemi per ricrearli rapidamente ogni volta davanti a chi mi ascolta. Che tool usare:  trovo la piattaforma Aris Express un’ottima amica , ma è soggettivo....

Not only a role for lane

A classic misunderstanding of beginners is the one-role-per-lane fake limit.
This misunderstanding drives them to the problem:

How can I modelling a unique process with different roles where some activities don't apply to some roles?

In the net I find some funny , complex, uncomplete or wrong solutions: the follow image shows one of those.

The guy explains his theory and his doubts:
"there is a way to model this, using split and join gateways.....
On the left hand side you see a split and join activity for two scenarios for roles A and C going through the same processes. They are defined in such a way that they would have a different start event. (For example a telephone call and an e-mail starting a sales process).

In the right hand side, we see a split (exclusive) with two end events for roles A and B. The two end events imply that there are two different end-states possible based on the role handling the processes; a third end-state is possible with the end event for role C.

There are many ways in which your scenario can be modeled to be sufficient, however more information is needed.

For example, is there only one type of outcome? (then you should use a exclusive or join and one end-state, with a responsible person for this end event in the correct lane)

Are there escalations for the roles? (Then model with intermediate events and show that it is an escalation and rename the processes to resemble the escalated activity chain).

Are the processes or activities on the same level of detail? (Are there activities and processes that are represented as subprocesses? Model with care, and apply them within the correct process descriptions)

Are the incoming events one and the same? (Use split exclusive or signs and make explicit when what flow is required)"

One-role-per-lane fake limit rules! :)

The real rule for BPMN is usually to combine the roles to represent a scenario. If you want to have only one activated role per activity the model would look like this...

How can I assign the lanes to multiple roles?
I don't!!! I kill the problem using a simple tecnique: I can replace Role A with Manager (Client Executive), Role A/B with Front Office Management (Client Executive + Client Administrator) and Role A/B/C with Front Office Staff (Client Executive + Client Administrator + Client Executive).
I can build a Function Allocation Diagram to do all the work for me i.e. build all the relationships I need to all the relevant objects.

This way to work has a gain:
I can have a nice view on the resposibilities using Matrix model, RECI report and the other ways to generate a two dimentional view on asserted relations between two object types.

Best regard and thanks to Mr. Damian Gawlowski and Ivo Velitchkov

BPM: Modeling o Management?

A volte si usa parlare di Management mentre si fa Modeling. Quanto si intersecano questi due termini?
Di seguito la mia visione delle cose....


Il ciclo di vita di un Business Process si può rappresentare con un classico loop, che lo suddivide in 4 macrofasi:


Design
Modeling
Execution
Monitoring
Optimization

Molti definiscono questo ciclo come BPM (dove la M sta per Management) lifecycle.
Io non mi identifico tra queste persone, tant'è che ho scritto più in alto solo BP Business Process. Da cosa dipende questa mia posizione?
Vediamolo subito.


Premetto che per me la M di Management non ha il valore che le si da quando si parla di Project Management.
Considerata la mera traduzione di Management, che si traduce con Gestione, mi viene naturale collocare quest'ultimo nelle fasi che vanno dall'esecuzione al monitoraggio (coadiuvato dalla scelta dei dovuti KPI da controllare). Infatti nella nostra lingua la gestione raramente comprende le fasi di analisi, che vengono sempre viste come precedenti al puro "gestire".
Dall'altra parte vi è il Modeling che io identifico solo nelle fasi di Design e di Modeling (per l'appunto!!!). Questa mia puntualizzazione prende vita dall'idea che fare un modello consista nel progettarlo (design) e disegnarne un modello (modeling).


Volontariamente ho saltato l'Ottimizzazione. Perchè? Semplicemente perchè per sapere cosa ottimizzare bisogna averne monitorato le performance, quindi aver GESTITO adeguatamente bene lo screening degli indicatori di performance, nonche' il processo; successivamente , il risultato dell'ottimizzazione servirà per alimentare la re-ingegnerizzazione e nuovamente il design.
Se rappresentiamo l'ottimizzazione come una sorta di TUNING, capiamo meglio come mai questa fase per me è una sorta di ponte che nasce nel Management e termina dentro al Modeling. E' cioe' una fase che partecipa ad entrambe le definizioni di quella benedetta M...


Infatti il tuning inizia migliorando , magari già in produzione, il processo esistente e in un secondo momento trasferendo tali miglioramenti e consolidandoli nella nuova versione del modello.
Perciò , mentre il processo è in esecuzione si verificano e controllano gl'esiti dell'ottimizzazione, poi li si rendono più efficienti integrandoli nel modello in modo definitivo.


Qui però devo essere onesto e avvisare di un possibile problema in cui si rischia di incorrere: execution significa esecuzione e mai e poi mai lo si deve far diventare un "test in produzione". Si deve rilasciare in produzione solo qualcosa di certo!
Alla luce di questo io trovo pericoloso fare un tuning invasivo al processo in produzione. Meglio piccole pezze atte solo a risolvere questioni serie (quindi indispensabili), altrimenti l'ottimizzazione va solo pensata\progettata ma non integrata in ciò che è in esecuzione.


Cosiddette questioni di M...