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....

10 basic tips for Project Managers

sketch by Luca Ing. Cecchetto (www.venict.it)

10 basic tips for Project Managers

A PM has to add these procedures in his routines.

1. A PM has to expect the unexpected. A good PM anticipates events and is well prepared with his team: he keeps a empty place for the uncertainty factor.

2. A PM has to pays attention to everything: little and big things. A single detail related his team needs opinion and importance.

3. All has to work together. A PM works with a team, so collaboration is a crucial point.

4. A PM has to carefully organize: it's important to keep coordinating or else his project will drift.

5. It's important a PM learns from his adversaries: team and customer will benefit from this.

6. A PM has to create strong relationship between customers and his team members. It's a way to motivate the team.

7. A PM has to update himself with goals. The goals aren't secret and he has to share with the team.

8. A PM has to look after his team. He can’t cater the client’s need unless he doesn’t take care of his team.

9. A PM has to build relationships with his customers. He can keep his client informed about project progresses and can use this way of work to build  relationships.

10. A PM has to explore new visions: Managers have to be aware what other people are observing.

Investing in your communication skills to excel

IT managers who have great communication skills are rare, and is the key skill that set them apart from the crowd.

The young managers should want to invest in their own communication skills.
OK, I realize that for many this is not exciting when compared to other more technical topics, but should be done.

Before you stop reading, consider some of the benefits that will have IT managers who are effective communicators.

1. They get more easily what they want - to be good communicators know how to discuss the business value of their projects and their IT initiatives. When communicating the benefits and justify the cost of things .... management raise their thumbs because he would understand the gain!

2. Develop effective communications with partners - or better yet, develop profitable communications with their customers (managers and area managers). They need to know what's going on with their IT support and be kept updated as this creates trust.

3. Being strong communicators get the respect - no one knows what you're doing unless you communicate it. The effective communicators know how to present their successes IT with facts and numbers, showing how well their IT support is working.

4. Effective communicators motivate their staff - leadership depends on effective communication. Strong communicators gather his troops to give them a vision of the state of the achievements / works, how does a coach with a winning team.

The career will have a whole new path if you develop effective communication skills ... is the key point you need to succeed in its role as a mangement.

Developing all of the following skills you can watch your career take off:

     1) Presentation
     2) Management of the negotiation
     3) Writing of reports
     4) Ability to listen
     5) Ability to attract those who are listening
     5) Coaching and motivation

Investire nelle proprie capacità di comunicazione per eccellere

I responsabili IT che hanno grandi capacità di comunicazione sono rari, ed è la competenza chiave che li distinguono dalla massa degl'altri.

I giovani manager dovrebbero voler investire proprio nelle loro capacità di comunicazione.
OK, mi rendo conto che per molti questo non è eccitante se rapportato ad altri argomenti più tecnici, ma va fatto.

Prima di smettere di leggere, prendete in considerazione alcuni benefici che avranno i manager IT che sono anche comunicatori efficaci.

1. Ottengono più facilmente ciò che chiedono - da buoni comunicatori sanno discutere il valore del business dei loro progetti e delle loro iniziative IT. Quando comunicano i benefici e giustificano il costo delle cose.... il management solleverà i pollici perchè avrà compreso il guadagno!

2. Sviluppano efficaci comunicazioni con i partner - o meglio ancora,  sviluppano comunicazioni proficue con i loro clienti (dirigenti e responsabili di area). I clienti devono sapere cosa sta succedendo con il loro supporto IT e vanno tenuti aggiornati poichè questo crea in loro fiducia.

3. Essendo forti comunicatori ottengono il rispetto - Nessuno sa cosa si sta facendo a meno che non lo comunica. I comunicatori efficaci sanno esporre i loro successi IT con i fatti e con i numeri, dimostrando quanto bene il loro supporto IT stia lavorando.

4. Efficaci comunicatori motivano il proprio personale - la leadership dipende da una comunicazione efficace. Forti comunicatori radunano le proprie truppe per fornire loro una visione dello stato dei successi/lavori , come un allenatore fa con una squadra che vince.

La carriera avrà un percorso del tutto nuovo se si sviluppano capacità di comunicazione efficaci... è il punto chiave necessario per avere successo nel proprio ruolo di mangement.

Sviluppando tutte le seguenti competenze si potrà guardare la carriera decollare:

     1) Presentazione degl'argomenti
     2) Gestione della trattativa
     3) Scrittura delle relazioni
     4) Capacità di ascolto
     5) Capacità d'attrarre chi ci ascolta
     5) Coaching e motivazione

Business manager or technical manager: there is a big difference.

Business manager or technical manager: there is a big difference.
Most IT managers are technical managers and they manage the technology, not the business of IT support: they are so frustrated...
These IT managers are not technology savvy they want to be: they providing technical solutions to address their issues simply does not work very well.
Sometimes they have to do new implementation simply the head of their company was changed and the new head must to do something....
The real problem: the business manager are not technical managers grew, but they arrived from other role.

It's difficult for us to decide: what kind of solution do we give to our client? A client solution (what they would want to have even if useless....) or a technical solution?

Each of us has to decide, but often we have to be to survive in the middle.
is that correct? No, but I do not believe those who told me to stand on one side only. Unfortunately you must also satisfy those who want to change things just because ... because so did those who preceded him ...