Archivi categoria: analisi processi business

Problemi tipici nei modelli BPMN

BPMN è la notazione standard per l’analisi dei processi di business. Arricchisce i flowchart tradizionali con la logica ad eventi, ed è molto diffusa.

Un’analisi su oltre cinquecento modelli, pubblicata su IEEE Software July-Aug. 2016, evidenzia i problemi più frequenti nell’uso della notazione, che derivano in genere da una formazione insufficiente, e suggerisce alcune utili correzioni: Learning from Quality Issues of BPMN Models from Industry.

bpmNEXT

bpmNEXT è una conferenza sul Business Process Management, con una particolarità: è pensata come uno scambio di informazioni e di opinioni tra i produttori di strumenti, più che come una vetrina a fini commerciali. Utile, quindi, per farsi un’idea sulle tendenze dei prodotti nel campo dei BPMS (Business Process Management Systems) e del BPMN (Business Process Model and Notation).

Resoconti della conferenza da uno degli organizzatori, Bruce Silver, da Paul Harmon e da Sandy Kemsley.

Process Knowledge Initiative

La Process Knowledge Initiative nasce per promuovere una standardizzazione della terminologia nell’ambito dell’analisi dei processi.

I diversi framework e standard esistenti (tra cui ad esempio BPMN, UML, IDEF, SCOR, VCOR, ITIL, APQC) hanno marciato finora separatamente, per cui il medesimo concetto viene denominato in modo diverso.

Promotori dell’iniziativa di standardizzazione sono il BPM Group della Queensland University of Technology (QUT), l’International Institute of Business Analysts (IIBA), Kemsley Design, la rivista online BPTrends e l’Object Management Group (OMG).

Secondo i promotori, la confusione terminologica costituisce un freno per la diffusione dell’analisi dei processi e del BPM, e l’obiettivo dell’iniziativa è quindi di risolverla, definendo in modo univoco alcuni termini fondamentali.

Per il momento è disponibile, nel wiki dell’iniziativa, una bozza di lavoro del Body of Knowledge.

Dagli obiettivi di business alle architetture software (passando per i requisiti)

Un recente Technical Report del Software Engineering Institute tratta il tema della frequente mancanza delle informazioni necessarie per definire le architetture software.

“C’è un disallineamento profondo e sostanziale tra le informazioni contenute nelle specifiche dei requisiti e quelle di cui gli architetti hanno bisogno. Il disallineamento si evidenzia in due aspetti:

1. La maggioranza dei contenuti di una specifica dei requisiti non determina né contribuisce a definire l’architettura. Le architetture sono soprattutto determinate dai requisiti non funzionali; eppure la parte più consistente delle normali specifiche dei requisiti si focalizza sulle funzionalità del sistema, che hanno un impatto limitato sulla scelta delle architetture. Peggio ancora, molte specifiche specificano poco e male i requisiti non funzionali; molte li ignorano completamente.

2. Parecchie informazioni che sarebbero utili ad un architetto software non si trovano neppure nelle migliori specifiche dei requisiti. Sono informazioni che derivano dagli obiettivi di business dell’organizzazione in cui origina l’esigenza di sviluppo, come ad esempio impiegare le risorse in modo produttivo, ammortizzare gli investimenti fatti in strumenti e tecnologie, rispettare le indicazioni provenienti dalla gestione delle risorse umane, migliorare il posizionamento di mercato dell’organizzazione rispetto alla concorrenza, ed altri aspetti analoghi.”

L’individuazione degli obiettivi di business da cui partire deve avvenire con il coinvolgimento degli stakeholder, attraverso interviste o workshop. Il report propone un modo innovativo di definire gli obiettivi di business, basato sull’analisi di alcuni elementi di base:

  • il soggetto che ha interesse al raggiungimento dell’obiettivo (es. uno sponsor)
  • l’oggetto toccato dall’obiettivo (es. il cliente di cui si desidera migliorare la soddisfazione)
  • il contesto in cui l’obiettivo va interpretato (es. di mercato, o tecnologico, o sociale)
  • le unità di misura utili per valutare se l’obiettivo è stato raggiunto
  • il grado di volatilità dell’obiettivo
  • il valore dell’obiettivo

Il passo successivo consiste nella derivazione dagli obiettivi di business dei requisiti non funzionali (o “requisiti sugli attributi di qualità”, come vengono chiamati nel report), partendo dal presupposto che ogni requisito non funzionale deve trovare la propria ragion d’essere in un obiettivo significativo a livello di business.

Ciò consente, tra l’altro, di analizzare in modo critico eventuali vincoli e requisiti non funzionali precedentemente espressi, per verificarne il fondamento in termini di obiettivi di alto livello.

Il report, “Relating Business Goals to Architecturally Significant Requirements for Software Systems”, a cura di Paul Clements e Len Bass, è scaricabile dal sito del SEI.

Libro su BPMN

Scritto da Stephen White (il coordinatore del gruppo di lavoro che ha prodotto e fa evolvere lo standard) con la collaborazione di Derek Myers: BPMN Modeling and Reference Guide, Future Strategies 2008.

BPMN (Business Process Modeling Notation) è lo standard per la rappresentazione dei processi di business, gestito dall’Object Management Group (OMG).

Il libro non aggiunge nulla a quanto contenuto nella specifica ufficiale OMG, scaricabile gratuitamente – ma è organizzato e scritto in un modo più comprensibile. Alcuni esempi sono diversi rispetto a quelli presenti nella specifica ufficiale – in altri casi, gli esempi sono identici.

Si poteva fare di meglio, dato il livello di competenza degli autori, ma il libro costituisce comunque un’utile introduzione all’argomento.