DocFlow - White Paper BPMS

Business Process Management Suite (BPMS)
White Paper
Settembre 2011
Paolo Poto – Docflow Italia Spa
Sommario
I BPMS sono piattaforme software che abilitano l’implementazione e il miglioramento continuo
dell’automazione dei processi operativi, orchestrando e integrando anche sistemi già presenti nel
sistema informatico, accordando così l’esigenza di specializzazione dei sistemi con la trasversalità
dell’orientamento ai processi. I BPMS consentono la definizione del flusso applicativo con un
linguaggio grafico comprensibile dai “clienti interni” dei sistemi informativi: analisti di
organizzazione e process owner.
Keyword: Business Process Management Suite, WorkFlow Management, Model driven
architecture.
1 Introduzione
Un Business Process, o processo gestionale,
è una sequenza di attività eseguite da una o
più organizzazioni per produrre un risultato
utile per i clienti (Motta et al. 2008).
Con il termine Business Process Management
(BPM), invece, si vuole indicare l’emergere
di un approccio complessivo al cambiamento
dei Business Process, che combini il meglio
delle aree relative al miglioramento dei
processi, alla loro gestione, riprogettazione e
alla loro automazione. In altre parole il BPM
è l’insieme delle metodologie e tecnologie
che permettono alle organizzazioni di
analizzare, descrivere e ottimizzare i processi
di business.
Gartner (Sinur et al. 2010) evidenzia come il
BPM leghi esplicitamente l’Information
Technology (IT) alle priorità del business.
Nel presente testo si tenterà una descrizione
delle tecnologie software che realizzano
questo approccio: le Business Process
Management Suite. Saranno quindi descritte
le loro caratteristiche rilevanti e, per tracciare
dei confini, saranno riportati alcuni
significativi confronti presenti in letteratura
con le tecnologie che possiedono un qualche
grado di similarità o sinergia.
Esiste difatti un’ampia varietà di tecnologie
per l’automazione dei processi di business che
si presentano con le più diverse sigle
dell’informatica per le imprese, ad esempio:
WorkFlow Management (WFM), Business
Process Analysis (BPA), Enterprise Resource
Planning (ERP). E questo può generare
confusione.
BPMS pagina 1 di 10
2 Business Process Management
Suite
I BPMS sono degli Integrated Composition
Environment (ICE) che supportano il Business
Process Management.
Un BPMS è un sistema software generico che
guidato dal disegno esplicito dei processi realizza
applicazioni di gestione dei processi operativi.
(M. Weske, et al. 2004)
In questa definizione l’aggettivo “generico”
vuole significare la possibilità di plasmare
con un alto grado di libertà i differenti
processi di business e ogni specifico processo
nel tempo. Questo pone evidenza sulla natura
dei BPMS di framework di sviluppo
applicativo che, oltre ad automatizzare
l’operatività all’interno dei singoli processi,
abilita le diverse fasi di gestione dell’intero
ciclo di vita dei processi di business, con
particolare riferimento al miglioramento
continuo.
I BPMS rendono espliciti gli aspetti di un
processo attraverso la definizione di un
modello. Questo modello è di immediata
comprensione e facilmente modificabile.
L’astrazione del modello rende inoltre
indipendente
la
definizione
dall’implementazione.
Ulteriore attenzione deve essere prestata alla
parola suite che manifesta il fatto che queste
piattaforme siano una collezione integrata di
tecnologie software. Le diverse tecnologie
sono intimamente integrate, in particolare:
dotate di strumenti di gestione e
amministrazione integrati, metodi di sicurezza
comuni, meta modelli condivisi, procedure di
installazione e documentazione comuni, unico
supporto tecnico e un consistente look & feel
delle interfacce utente.
Le funzioni all’interno della suite non sono
duplicate, malgrado ci siano distinti motori
applicativi (server) che rispondono alle
diverse esigenze interoperando. Quindi la
suite, benché composta di diverse tecnologie,
è percepibile come un unico prodotto per la
coerenza architetturale che consente un
passaggio fluido attraverso le diverse fasi del
ciclo di miglioramento dei processi di
business che la suite peculiarmente supporta.
La caratteristica peculiare è quindi che i BPMS
disegnano il processo con la definizione di un
modello esplicito, che coordina le interazioni fra
persone, sistemi e informazioni come aspetti
ugualmente importanti del lavoro.
In fase di esecuzione il motore di BPM agisce
poi come un orchestratore generale,
coordinando tutte le risorse coinvolte
indipendentemente dal fatto che le risorse
software siano state create nel proprio
ambiente o in altre piattaforme.
La necessità di disegnare il processo
attraverso un modello costituito da sequenze
esplicite di attività ha come inevitabile
conseguenza che in genere i BPMS possono
automatizzare solo i processi operativi,
escludendo quindi i processi di livello
strategico, il cui procedere è di solito
scarsamente definibile a priori.
Le componenti delle Suite
Management. (Gartner Group)
di
Business
Process
A detta di Gartner (Sinur et al. 2010), i
prodotti software BPMS sono maturi e una
delle conseguenze è che il set di tecnologie
incluse dai diversi vendor tende ad essere
piuttosto simile. I diversi BPMS sono
essenzialmente differenziati sull’integrazione
delle tecnologie e sulla risultante user
experience piuttosto che sui punti di forza
puramente tecnologici.
I fattori chiave dei BPMS sono:
BPMS pagina 2 di 10

ottimizzare le performance dei processi di
business che attraversano diverse funzioni
aziendali e possono coinvolgere altre
organizzazioni;
 rendere il processo visibile (esplicito) sia
all’IT sia alle funzioni di business,
attraverso
la
modellazione,
il
monitoraggio
e
l’ottimizzazione,
utilizzando
un
linguaggio
grafico
condiviso fra informatici e process owner;
 saldare il modello formale del processo di
business con l’implementazione nel
sistema informativo;
 abilitare gli analisti di organizzazione e in
generale gli utenti non tecnici alla
modifica del modello e quindi delle
istanze del processo realizzate;
 abilitare la rapida integrazione dei flussi
di processo e i sistemi esistenti.
Fra queste caratteristiche è particolarmente
degno di nota l’uso di un linguaggio
condiviso fra addetti dell’informatica e i loro
colleghi che si occupano di organizzazione e
degli specifici processi. Poiché, sebbene il
disegno del processo attraverso i moduli di
design grafico sia in realtà di solito realizzato
da tecnici IT, è comunque comprensibile
anche per chi è culturalmente distante dal
mondo dello sviluppo software.
Il disegno del modello di un processo realizzato con il
designer di un BPMS. Con la stessa applicazione si
possono disegnare le form per l’input/output dei dati che
saranno poi mostrate come pagine di una web application.
3 BPMS e WorkFlow Management
(WFM)
Negli anni ’90, in concomitanza con la
diffusione delle tecniche di Business Process
Reeingineering, le organizzazioni iniziarono a
integrare le attività svolte a livello
dipartimentale in processi che si estendevano
trasversalmente attraversando le varie
funzioni aziendali. Di conseguenza anche le
infrastrutture del sistema informativo
aziendale seguirono questa tendenza e dunque
le applicazioni e i database iniziarono a
interagire e a scambiare informazioni tra loro.
(Harmon, 2007)
Furono quindi sviluppati strumenti di
WorkFlow per una migliore gestione dei
processi riguardanti l’elaborazione dei
documenti da parte del personale, cioè per
quegli oggetti che nel linguaggio burocratico
sono identificati con il termine “pratica”.
La Workflow Management Coalition (WfMS)
definisce il WorkFlow come l’automazione di
un processo di business, parziale o completa,
durante la quale i documenti, le informazioni
e le attività fluiscono da un attore a un altro
secondo regole procedurali definite.
Ma anche i BPMS automatizzano i processi di
business, anche se con una particolare enfasi
al ciclo del miglioramento continuo.
Identificare la relazione effettiva fra le sigle
WFM e BPMS non è impresa facile.
Esaminando le fasi che metodologicamente
costituiscono il ciclo di BPM e la copertura
funzionale di queste due famiglie di soluzioni
può emergere qualche chiaro indicatore.
Alcuni autori identificano le seguenti fasi:
 Design, quando i processi sono
(ri)disegnati;
 Configuration, dove il disegno è
implementato configurando un sistema
software;
 Enact, realizzazione dei processi operativi
utilizzando il sistema configurato nella
fase precedente;
 Diagnosis, il processo operativo è
analizzato per identificare eventuali
problemi e per cercare possibili
miglioramenti.
Altri autori fanno esplicitamente riferimento
al ciclo di Deming che prevede una sequenza
logica di quattro punti ripetuti per un
miglioramento continuo:
 Plan, pianificazione;
BPMS pagina 3 di 10



Do, esecuzione del programma, dapprima
in contesti circoscritti;
Check, test e controllo, studio e raccolta
dei risultati e dei feedback;
Act, azione per rendere definitivo e/o
migliorare il processo.
Altrove si possono trovare definizioni simili
come: Design, Enact, Control & Analyze.
Comunque si suddividano le fasi del ciclo del
miglioramento dei processi emergono alcune
differenze fra BPMS e WFM.
Ciclo del BPM e copertura funzionale dei sistemi
software. (M. Weske et al. 2004)
I sistemi di WorkFlow sono dotati di
strumenti
di
disegno
limitati
e,
principalmente, sono carenti di strumenti per
la fase di analisi. I BPMS estendono quindi i
sistemi
di
gestione
dei
WorkFlow
aggiungendo strumenti per la fase di diagnosi,
consentendo
così
l’emersione
di
miglioramenti nella gestione dei processi.
Per questo le BPM Suite sono spesso
considerate l’evoluzione dei sistemi di WFM
degli anni ‘90.
Se poi consideriamo che negli ultimi anni
alcuni vendor di WFM hanno riposizionato i
loro prodotti come BPMS, si può semplificare
pragmaticamente il discorso concludendo che
il WorkFlow è una delle componenti
tecnologiche dei BPMS che ne rappresentano
un’evoluzione.
4 BPMS e Business Process Analysis
(BPA)
Le piattaforme di Business Process Analysis
(BPA) sono strumenti software per la
modellazione, l’analisi e l’ottimizzazione dei
processi. Fra BPMS e BPA esistono alcune
differenze funzionali che devono essere messe
in evidenza. Fondamentalmente le diversità
nascono dal fatto che sono prodotti rivolti a
interlocutori con ruoli e bisogni diversi. E
proprio
questo
rende gli
strumenti
notevolmente diversi, come architettura,
funzioni, interfaccia.
I BPMS hanno come obiettivo l’automazione
dei processi operativi, i BPA sono utilizzati
per definire e documentare i processi, non
solo i processi di produzione, ma anche e
specialmente i processi di controllo, spesso
legati al rispetto di particolari leggi.
Per questo, a differenza dei software di BPA,
le funzioni di modellizzazione offerte dai
sistemi BPMS risultano essere idonee più per
gli sviluppatori IT che per i manager
responsabili dei processi. Simmetricamente le
funzioni di modellazione dei BPA sono adatte
agli analisti dell’organizzazione e completate
da strumenti per la produzione della relativa
documentazione che, di fatto, rappresenta
l’output di questi sistemi.
Non molto diversamente, per altri autori i
software
di
BPA
sono
utilizzati
principalmente per la realizzazione della
Business Process Architecture aziendale e per
i progetti di miglioramento e re-design di
specifici processi di business; i sistemi BPMS
sono invece utilizzati dagli sviluppatori
software per supportare l’esecuzione e il
monitoraggio dei processi aziendali.
In altre parole, le piattaforme software di
BPA sono utilizzate per il disegno di alto
livello dei processi aziendali e per la
produzione del corpo normativo aziendale.
L’output di questi sistemi non è quindi
costituito da regole in grado di guidare un
WorkFlow, ma:


documenti che devono essere resi fruibili
al personale operativo;
documentazione di come l’azienda ha
disposto i controlli interni per ottemperare
ad alcuni obblighi di legge.
Sebbene, quindi, entrambi i sistemi si
occupino della definizione dei processi di
business, i loro ambiti di utilizzo sono in
genere nelle aziende due mondi separati:
 da una parte si definisce il modello
organizzativo di alto livello, con una
particolare attenzione alla compliance con
leggi e regolamenti;
BPMS pagina 4 di 10

dall’altra si realizzano le applicazioni per
automatizzare i processi operativi.
L’integrazione dei due sistemi, cioè il
passaggio dei dati di definizione di alto livello
dei processi disegnati nel BPA al sistema di
puntuale disegno di dettaglio del BPMS, è
suggerito da alcuni autori come una possibile
fonte di efficienza, governance e reale
compliance di processo.
Nella pratica però questo non avviene salvo
che in casi rarissimi. E questo probabilmente
perché la compliance è considerata solo un
costo
che
deve
essere
sostenuto
obbligatoriamente e non una opportunità di
governo coerente dell’impresa.
Di fatto, comunque il disegno di processo del
BPA è insufficientemente dettagliato per
guidare l’automazione del processo, ed è
pertanto necessario un intervento importante
all’interno degli strumenti di disegno del
BPMS. L’avere due versioni diverse del
processo, una di alto livello e documentata,
l’altra dettagliata ed eseguibile, pone però
difficoltà
di
sincronizzazione
delle
informazioni nelle due direzioni (round-trip).
Queste informazioni devono essere poi
comunicate
ai
diversi
stakeholder
dell’azienda, rendendo necessaria così una
rappresentazione con diversi punti di vista e
differente livello di dettaglio. In genere queste
informazioni risiedono in diversi sistemi,
spesso in documenti creati e gestiti con
strumenti di Office Automation.
Ad esempio, le informazioni su di una
applicazione possono essere contenute in
schemi architetturali, diagrammi sul processo
di business, rappresentazioni delle interfacce,
fogli elettronici con i più svariati elenchi di
dati,
documenti
testuali
descrittivi.
L’aggiornamento di tutte queste informazioni
richiede l’intervento coerente sulle diverse
fonti. L’adozione di un tool di EA vuole
proprio rispondere all’esigenza di gestione
efficiente
e
ordinata
dell’intera
documentazione.
In letteratura questo argomento è stato trattato
mettendo in evidenza i due aspetti critici:
 il gap di definizione funzionale dei
processi fra i due diversi sistemi;
 l’interazione fra i due sistemi.

Ma nei BPA sono presenti importanti
strumenti di simulazione e analisi che, se
alimentati con i dati registrati durante
l’esecuzione dei processi da parte del BPMS,
possono fornire un notevole aiuto nel
raggiungimento dell’efficienza e del controllo
in un’ottica di reale compliance.
5 BPMS ed Enterprise Architecture
(EA)
I software architect hanno bisogno di
integrare, analizzare e comunicare un’ampia
varietà di informazioni e dati che riguardano
il sistema informatico, come le tecnologie
utilizzate, le soluzioni, le interfacce, i
business
process,
la
struttura
dell’organizzazione, le strategie.
Secondo Gartner (Wilson et al. 2010), i
requisiti minimi per un tool di EA sono:



la capacità di creare o importare modelli e
artefatti;
funzioni
di
presentazione
delle
informazioni specifiche per i bisogni degli
stakeholder, con rappresentazioni grafiche
e testuali;
robusti e flessibili repository e metamodelli in grado di aiutare i cambiamenti
delle relazioni fra oggetti e i punti di vista
dell’architettura, con la possibilità di
tracciare i cambiamenti;
gestione dei diversi ambienti (sviluppo,
test e produzione).
Molti tool di EA hanno funzioni avanzate di
modellazione, che rispondono ai bisogni degli
architetti del sistema informativo. Queste
funzioni di modellazione si sono nel tempo
arricchite estendendosi in aree come task
management, governance, risk & compliance,
communication & collaboration.
Con l’incremento delle funzioni di
modellazione i tool di EA hanno cominciato a
competere con gli strumenti di BPA.
L’integrazione di EA, BPA e BPMS può
consentire la condivisione delle informazioni
BPMS pagina 5 di 10
sui processi, rendendo la base di conoscenza
consistente.
6 BPMS ed Enterprise Resource
Planning (ERP)
I sistemi ERP automatizzano molti processi
gestionali con una applicazione software
integrata.
Un’importante caratteristica dei sistemi ERP è
la prescrittività, cioè la normazione dei
processi gestionali derivante dal modello
funzionale incorporato nel software. Questo
comporta che l'approccio al progetto ERP è
l'esatto contrario di quanto avveniva e avviene
con lo sviluppo di un sistema informatico su
misura dove è il software che si adatta
all'azienda. (Bracchi et al. 2010)
L'impatto organizzativo della prescrittività
può essere elevato perché costringe
un'azienda
a
conformare
il
suo
comportamento allo standard previsto dal
sistema. (Bracchi et al. 2010)
Quindi quando si sceglie un prodotto di un
vendor di ERP con una vasta base installata,
si acquista in realtà una soluzione
organizzativa one best fit, cioè un modo di
fare le cose che dovrebbe rispondere al
meglio a determinate condizioni di mercato.
Questo corrisponde dal punto di vista
epistemologico
alla
concezione
dell’organizzazione come “sistema organico
aperto”, visione dei fenomeni organizzativi
oggi molto presente nelle imprese e nelle
società di consulenza direzionale. In altre
parole, se si pensa che esista una soluzione
migliore di tutte le altre per organizzare e
svolgere determinate attività dell’impresa,
adottare l’ERP di maggior successo garantisce
la migliore organizzazione dei processi
operativi.
Sebbene le piattaforme ERP consentano sia
parametrizzazione sia vera e propria
personalizzazione, il disegno dei processi è
quasi completamente imposto dal sistema, ed
è in realtà proprio questo il punto di forza
degli ERP, coerentemente con il concetto di
one best fit.
Invece, la spiegazione soggettivistica dei
fenomeni organizzativi, per la quale è il
soggetto che è emergente rispetto al sistema,
prevede che ogni azienda sia necessariamente
diversa dalle altre organizzazioni per storia,
cultura e valori.
Con tali premesse non si può credere nel
concetto di one best fit e l’omologazione di
conseguenza deve essere vista come una
perdita delle caratteristiche particolari che
rendono l’impresa unica e per questo efficace
sul mercato.
In questo caso, l’adozione di un ERP deve
necessariamente
limitarsi
ai
processi
istituzionali, cioè quei processi omogenei nei
diversi settori perché sostanzialmente
rispondenti a obblighi normativi. Difatti,
anche con una visione soggettivistica dei
fenomeni organizzativi, molti processi di
supporto non rappresentano una competenza
distintiva.
Ecco allora che l’acquisizione di una
soluzione standard ampiamente collaudata per
l’area Amministrazione Finanza e Controllo
non rischia di compromettere un vantaggio
competitivo basato su competenze distintive.
Invece, per i processi core, nella concezione
dell’azienda come realtà unica e irripetibile, è
necessariamente il software che deve adattarsi
al modo di lavorare dell’azienda e non il
contrario.
In questo caso i BPMS, per la loro natura di
strumenti
facilmente
plasmabili,
rappresentano
quindi
una
soluzione
preferibile.
7 BPM e Service Oriented
Architecture (SOA)
SOA è una architettura software che abilita il
coordinamento
dei
sistemi
distribuiti
supportando i business process, e non deve
essere confuso con le Suite di BPM.
BPM è una disciplina di gestione
dell’organizzazione orientata ai processi
assistita dalle tecnologie informatiche, mentre
SOA è un paradigma architetturale
informatico.
BPMS pagina 6 di 10
Secondo Gartner (Hill et al. 2006), il BPM
organizza le persone per una maggiore agilità,
mentre SOA organizza le tecnologie per una
maggiore agilità.
I BPMS in fase di orchestrazione delle diverse
attività in genere sfruttano i servizi SOA. Ma
un BPMS può anche automatizzare delle
attività utilizzando sistemi non SOA, ad
esempio accedendo direttamente ai database
o richiamando moduli funzionali in tecnologia
proprietaria.
È
possibile
difatti
implementare
un’architettura SOA senza sfruttare le
capacità di modellazione e manutenzione dei
processi di un BPMS, così come è possibile
utilizzare un BPMS in una architettura non
SOA.
Ma l’adozione di un BPMS in una architettura
SOA può offrire i migliori vantaggi in termini
di agilità dei processi e riusabilità dei
componenti.
rifiuto dell’idea di sostituire il sistema con
una nuova tecnologia, anche se quest’ultima
potrebbe essere in grado di andare incontro
alle esigenze attuali di integrazione dei
sistemi per la gestione per processi end-toend.
Altra metafora particolarmente adatta a
descrivere la situazione di molte aree del
sistema informativo aziendale è quella dei
silos, cioè delle torri che immagazzinano dati
senza comunicare con il mondo esterno se
non con le proprie interfacce applicative.
Ma i BPMS possono facilmente orchestrare le
funzioni dei sistemi esterni, mascherando
interfacce utente obsolete e riuscendo a
integrare anche i sistemi legacy più antiquati.
Per fare questo esistono connettori pronti per
molte tecnologie o abili metodi per
colloquiare anche con sistemi monolitici a
interfaccia carattere.
BPMS
BPMS
L’orchestrazione dei silos lungo il processo.
Uno schema della relazione fra SOA e BPMS.
(Gopala et al. 2006)
8 BPMS e Sistemi Legacy
Per sistema Legacy si intende un sistema
informatico in produzione da molto tempo
che continua a essere usato perché
l’organizzazione non vuole o non può
rimpiazzarlo per motivi economici od
organizzativi.
Nella realtà aziendale, con particolare
riferimento alle grandi organizzazioni che
hanno affrontato da qualche tempo
l’informatizzazione, alcune attività sono
oramai automatizzate in maniera efficace, e
con tramandata memoria di un percorso
doloroso per arrivare a un risultato
soddisfacente. Questo causa un invincibile
È questo un valore aggiunto del BPMS
particolarmente
apprezzato,
poiché
preservando gli investimenti passati e
rispettando la specializzazione dei sistemi,
introduce comunque tutti i vantaggi della
gestione per processi.
9 I processi di business collaborativi
Recentemente il tema dei processi di business
destrutturati sta uscendo dall’angusto ambito
dell’enterprise social network, concepito
come un mero adattamento dei social network
internet, per arricchirsi dei concetti di
processo collaborativo e di case management.
Questa
evoluzione
rappresenta
il
riconoscimento che l’azienda sia un sistema
sociale e che le prassi, l’organizzazione
BPMS pagina 7 di 10
informale e i processi decisionali, sebbene
non siano automatizzabili rigidamente,
possano comunque sfruttare le tecnologie
informatiche per raggiungere maggiori livelli
di efficienza e controllo.
Per fare un esempio, la decisione aziendale di
un acquisto entra nel sistema gestionale
tipicamente quando è oramai tutto deciso, e la
registrazione di una Richiesta di Acquisto
(RDA) di fatto avviene nella fase
immediatamente precedente all’emissione
dell’ordine. Tutte le attività destrutturate
(come
la
definizione
del
bisogno,
l’assegnazione del budget, l’identificazione
dei fornitori e la raccolta delle offerte) in
genere vivono di e-mail, fogli Excel e
documenti salvati in un sistema documentale
o addirittura sui file system delle persone
coinvolte. Gli attori del processo non sono
identificabili a priori e il processo stesso,
come sequenza di attività, non ripete quasi
mai lo stesso iter.
Mentre i BPMS funzionano egregiamente sui
processi strutturati, cioè a bassa variabilità, e
la loro adozione ha garantito ottimi risultati,
per i processi che coinvolgono i knowledge
worker, cioè i processi ad alta variabilità o il
cui output non è definibile a priori, gli attuali
prodotti sono carenti, proprio negli strumenti
collaborativi.
Cominciano, però, a nascere nelle aziende
interessanti implementazioni di processi
collaborativi con le tecnologie di BPM, ma
questo ha richiesto l’integrazione con
tecnologie esterne in grado di colmare le
carenze e la rigidità attuale, ad esempio con
strumenti di gestione dinamica dei flussi,
piattaforme per il co-editing, integrazione
dell’e-mail.
Per la dinamicità dei flussi, le funzioni di
supporto rapido ai cambiamenti nel processo,
da parte di qualsiasi ruolo e in qualsiasi
momento, sono in genere identificate con
l’etichetta Dynamic BPM. Si tratta di un
insieme di discipline e tecnologie che
abilitano le persone e i sistemi a rispondere in
tempi appropriati ai cambiamenti resi
necessari dalle esigenze implicite ed esplicite
dei processi. (Dixon et al. 2011)
La tematica delle e-mail, invece, prevede
molteplici aspetti:
 l’utilizzo di messaggi automatici per
coinvolgere o sollecitare un attore al
momento giusto e comunicando il
contesto di riferimento;
 l’inclusione delle e-mail rilevanti nel
flusso di lavoro, con archiviazione
ordinata nel repository del processo e
associazione alla corretta fase di lavoro.
Inoltre, per l’analisi dei processi e il
miglioramento, comincia ad assumere un
certo interesse la Social Network Analysis for
BPM, che si concreta con l’analisi delle email e di altri documenti, evidenziando così le
relazioni fra gruppi e persone al fine di
comprendere le strutture sociali e le
interdipendenze dell’organizzazione, con
l’obiettivo di migliorare l’operatività e
l’organizzazione dei processi, riconoscendo
così
l’importanza
dell’organizzazione
informale.
10 Stato del mercato
Il valore totale stimato del mercato dei BPMS
per il 2009 è di 1,9 miliardi di dollari, con un
incremento del 15% rispetto all’anno
precedente (“Magic Quadrant for Business
Process Management Suites” Gartner Group,
Ottobre 2010).
Si prevede inoltre che il 67% delle aziende
nel corso del 2010 avrà aumentato gli
investimenti in BPMS (“2010 BPM Summit
Attendee Surveys” Gartner Group).
Altre informazioni disponibili che possono
aiutare a comprendere il mercato dei BPMS
sono:


il 75% delle aziende che utilizzano i
BPMS ha ottenuto vantaggi maggiori del
milione di dollari (“2011 BPM Excellence
Awards Nominees”);
l’82% delle aziende ha recuperato
l’investimento entro un anno (“2011 BPM
Excellence Awards Nominees”).
BPMS pagina 8 di 10


Responsabilità della decisione di adozione dei BPMS (1
non responsabile, 7 completamente responsabile). (“2010
Gartner CIO Survey”)
I settori che risultano trainare il mercato dei
BPMS sono i servizi finanziari, cioè banche e
assicurazioni. Difatti le Suite di BPM
sembrano essere più appetibili nel settore dei
servizi, dove la produttività umana e
l’efficacia sono critiche per la performance
del processo. (“Magic Quadrant for Business
Process Management Suites” Gartner Group,
Ottobre 2010)
Infine, i quattro più importanti scenari di
utilizzo dei BPMS sono:
 supporto al miglioramento continuo dei
processi;
 implementazione di soluzioni di processo
specifiche per il settore o per l’azienda;
 iniziative di business trasformation;
 supporto al ridisegno del sistema
informativo in un’ottica SOA/BPM.
(“Magic Quadrant for Business Process
Management Suites” Gartner Group, Ottobre
2010)
11 Conclusioni
La natura infrastrutturale dei BPMS e gli
investimenti da loro richiesti in licenze d’uso
determinano l’adozione di questi strumenti
per programmi di sviluppo di un certo respiro
e non per un singolo progetto. Le
caratteristiche in grado di fornire maggior
valore sono:
 supporto al miglioramento continuo;
 definizione del processo di business con
un linguaggio comprensibile dal cliente
interno dell’applicazione (process owner),
con evidenti vantaggi in comunicazione,
comprensione e coinvolgimento nei
progetti;
capacità di orchestrare i sistemi
specializzati esistenti all’interno di un
flusso di processo end-to-end;
essere un indispensabile elemento
dell’architettura SOA.
Comunque, se si ritiene che le competenze
distintive dell’organizzazione non debbano
essere compromesse omologando i processi
con soluzioni con un alto livello di
prescrittività, il BPMS sembra essere la scelta
obbligata.
Infine, il BPMS consente l’automazione di
tutti quei processi che, poiché variabili e
destrutturati, finiscono per essere trascurati
dalle applicazioni tradizionali, mentre la loro
automazione potrebbe dare buoni risultati in
termini di controllo ed efficienza.
Bibliografia
Designing business processes for business
performance: a framework
G. Motta, G. Pignatelli
Business And Information (BAI), Seoul, 2008
Magic Quadrant for Business Process
Management Suites
Jim Sinur, Janelle B. Hill
Gartner, 18 October 2010
Advances in business process management
M. Weske, W.M.P. van der Aalst, H.M.W.
Verbeek
Data & Knowledge Engineering 50(2004)1–8
Business Process Management: A Survey
W.M.P. van der Aalst, A.H.M. ter Hofstede,
and M. Weske
Business Process Management: the Third
Wave
Howard Smith and Peter Finger
On the Suitability of BPMN for Business
Process Modelling
P. Wohed, W.M.P. van der Aalst, M. Dumas,
A.H.M. ter Hofstede, N. Russell
BPMS pagina 9 di 10
Elements of a business process
management system: theory and practice
Duncan R. Shaw, Christopher P. Holland,
Peter Kawalek, Bob Snowdon, Brian
Warboys
Business Process Management Journal
Vol. 13 No. 1, 2007pp. 91-107
Business Process Management: Getting
Work in Order
Virginia Citrano
Baseline, Giugno 2007
Implementing BPM systems: the role of
process orientation
Hajo A. Reijers
Business Process Management Journal
Vol. 12 No. 4, 2006 pp. 389-409
The new industrial engineering
information technology and business
process redesign
Thomas H. Davenport, James E. Short
Sloan Management Review, summer 1990 Vol
31. No. 4
An Evaluation Framework for Business
Process Management Products
Stefan R. Koster, Maria-Eugenia Iacob, Luís
Ferreira Pires
Round-trip iterative business process
modelling between BPA and BPMS tools
Melissa Cheung and Jan Hidders
Business Process Management Journal
Vol. 17 No. 3, 2011 pp. 461-494
Designing Compliant Business Processes
with Obligations and Permissions
Stijn Goedertier and Jan Vanthienen
BPM 2006 Workshops, LNCS 4103, pp. 5–14,
2006
Business Process Change. A guide for
business managers and BPM and Six
Sigma professionals
P. Harmon
Morgan Kaufman, 2007
An assessment of facilitators and inhibitors
for the adoption of enterprise application
integration technology
Bouchaib Bahli and Fei Ji
Business Process Management Journal
Vol. 13 No. 1, 2007 pp. 108-120
Magic Quadrant for Enterprise
Architecture Tools
Chris Wilson, Julie Short
Gartner, 28 October 2010
Sistemi informativi d'impresa
Bracchi, Francalanci, Motta
McGraw-Hill, 2010
Note epistemologiche - Razionalità e
benessere. Studio interdisciplinare
dell’organizzazione
B. Maggi
Etas Milano, 1990
Web services and business process
management
F. Leymann, D. Roller, M.-T. Schmidt
IBM Systems Journal, Vol 41, No 2, 2002
BPM and SOA: A Strategic Alliance
Gopala Krishna Behara
BPtrend, May 2006
Hype Cycle for Business Process
Management, 2011
John Dixon, Teresa Jones
Gartner, 25 July 2011
2010 BPM Summit Attendee Surveys
Business Process Management Summit 2010
Gartner, 2010
2011 BPM Excellence Awards Nominees
Gartner, 2011
2010 Gartner CIO Survey
Gartner, 2010
BPMS pagina 10 di 10