Processi Aziendali

Prof.
Vincenzo Moscato
Dispense del corso di

SISTEMI INFORMATIVI
a.a. 2016/2017
Indice
Prefazione VII
1 I processi aziendali nei sistemi informativi 1

1.1 Introduzione: la gestione dei processi di business . . . . . . . . . 1
1.2 La classificazione dei processi di business . . . . . . . . . . . . . 2
1.3 L’architettura dei processi di business . . . . . . . . . . . . . . . 5
1.3.1 Il paradigma CRASO . . . . . . . . . . . . . . . . . . . . 6
1.3.2 Modellazione dei processi . . . . . . . . . . . . . . . . . 6
1.3.3 Modellazione della struttura organizzativa . . . . . . . . . 8
1.3.4 La mappa dei processi aziendali . . . . . . . . . . . . . . 9
1.3.5 Schemi di settore . . . . . . . . . . . . . . . . . . . . . . 17
1.4 Il Business Process Management (BPM) . . . . . . . . . . . . . . 22
1.4.1 Definzioni per il BPM . . . . . . . . . . . . . . . . . . . 22
1.4.2 Le componenti di un processo di business . . . . . . . . . 24
1.4.3 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.4.4 Sistemi BPMS . . . . . . . . . . . . . . . . . . . . . . . 28
1.5 Standard per la modellazione e gestione dei processi nel BPM . . 32
1.5.1 Standard grafici per la modellazione: BPMN . . . . . . . 32
1.5.2 Cenni agli standard per l’esecuzione: BPEL . . . . . . . . 38
1.6 La gestione del cambiamento . . . . . . . . . . . . . . . . . . . . 39
1.6.1 Interventi sui processi di business . . . . . . . . . . . . . 39
1.6.2 Miglioramento e Reingegnerizzazione . . . . . . . . . . . 41
VI
Prefazione
Le seguenti dispense sono essenzialmente una rielaborazione delle slide del testo
Sistemi informativi per l’impresa digitale di Giampio Bracchi, Chiara Francalanci,
Gianmario Motta, ed edito da McGraw-Hill nel 2010. Esso rappresenta il libro di
testo adottato nell’ambito del presente corso.
Alcuni contenuti relativi a Pianificazione, Assesment, Fattibilità, Reingegneriz-

zazione sono invece basati sullle monografie (disponibili on-line) di Alessandro
Alessandroni e Grabriele Lazzi.
Si ricorda infine che le seguenti dispense hanno finalità puramente didattiche.

1
I processi aziendali nei sistemi informativi
1.1 Introduzione: la gestione dei processi di busi-

ness
Nella progettazione di un sistema informativo è necessario identificare tutti i suoi
elementi e descriverli in modo preciso, non ambiguo e comprensibile da tutti gli
utenti che partecipano alla progettazione del sistema. I processi rappresentano
chiaramente una delle componenti principali del sistema informativo aziendale
(Enterprise System, ES) da individuare e descrivere in maniera opportuna. Le
tipologie di processi che vengono definiti durante la progettazione di un sistema
informativo sono come già visto nel Capitolo 1:
• processi fisici: descrivono le attività di elaborazione su oggetti fisici del sistema
(per esempio la descrizione di flussi di materiali all’interno di un processo di
produzione);
• processi informativi: sono funzioni che creano, gestiscono, elaborano e forni-
scono informazioni;
• processi aziendali o processi di business: rappresentano funzioni legate all’atti-
vità complessiva dell’organizzazione o dell’impresa (per esempio la produzione
di un’automobile).
In questo Capitolo, focalizzeremo la nostra attenzione sulla gestione dei processi
di business in un contesto aziendale. Come noto, ogni organizzazione possiede dei
processi di business: essi sono una sequenza controllata di attività che portano alla
creazione di un bene o servizio. Il grado di organizzazione (ed automazione) di
questi processi di business determina il successo di un’organizzazione. Per esem-
pio, un appropriato processo di pubblicità può incrementare il bacino di clienti
potenziali dell’organizzazione oppure un idoneo processo manifatturiero assicura
che il prodotto sia di alta qualità, ad un prezzo ragionevole e rispetti i tempi di
mercato. Questo incrementa di conseguenza la soddisfazione del cliente e rende
l’organizzazione competitiva sul mercato. Come ampiamento descritto, i processi
di business possono essere visti come un insieme di attività collegate e correlate
tra di loro che vengono progettate per acquisire un certo input e trasformarlo in
uno specifico output. Per esempio, prendiamo in considerazione il processo di
2 Capitolo 1
business di un’agenzia assicurativa nella quale un cliente richiede di stipulare un

contratto di assicurazione. Questo processo di business è composto da attività che
riguardano: il controllare la credibilità del cliente, ottenere le sue informazioni,
calcolare il suo salario mensile, e molte altre. Tutte queste attività sono collegate
le une con le altre, in modo tale che esse accadano nel giusto momento e nel giusto
ordine. L’input di questo processo di business è la richiesta del cliente e l’output
è il contratto firmato della polizza assicurativa. Fattori come la globalizzazione,
le opportunità di e-business, l’instabilità politica porta ad un mercato caratteriz-
zato da incertezza nel quale un’organizzazione deve costantemente adattarsi. Se
un’organizzazione non cambia e non si adatta al suo ambiente, allora deve affron-
tare il rischio di essere esclusa dal mercato. Quindi i cambiamenti organizzativi
sono fondamentali per la sopravvivenza di un’organizzazione. Tradizionalmente
vengono individuati due tipologie di cambiamenti: quelli rivoluzionari e quelle
evolutivi. I primi sono i cambiamenti di tipo radicale che si concretizzano nei
progetti di reingegnerizzazione dei processi di business e che cambiano completa-
mente le modalità operative di un’organizzazione. Il secondo tipo di cambiamento
è invece più graduale e permette un adattamento delle modalità operative in base
all’evolversi della situazione del mercato. Entrambi questi tipi di cambiamenti
necessitano delle tecniche e metodologie per la loro gestione. In tale scenario,
il Business Process Management (BPM) è una metodologia che facilita la ge-
stione dei cambiamenti che deve affrontare un’organizzazione. In particolare, il
BPM è una disciplina gestionale che si occupa di descrivere e gestire i processi
di business in un’organizzazione. L’obiettivo è quello di raggiungere gli obiettivi
dell’organizzazione allineando i processi di business con questi obiettivi e miglio-
rando di continuo questi processi. I principali problemi da affrontare nell’ambito
del BPM, sia nell’ottica della progettazione di un SI sia in quella della gestione
dei cambiamenti (change management), risultano quelli correlati alla:
• identificazione o mappatura dei processi di business;
• descrizione o modellazione dei processi di business.
Prima di addentrarci nello specifico delle due problematiche, riteniamo utile in-
trodurre dapprima le varie tipologie di processi di business.
1.2 La classificazione dei processi di business

I processi di business possono definire sia strategie di business ad alto livello sia
attività operative secondo il modello in Figura 1.1. Al livello più alto si trovano i
processi di business organizzativi: essi sulla base della strategia di un’organizza-
zione (che di norma definisce la rotta da seguire a lungo termine per sviluppare un
vantaggio competitivo sostenibile sul mercato) e dei relativi obiettivi operativi di
business descrivono le modalità di raggiungimento dei risultati. Questi processi
tipicamente vengono specificati in forma testuale dai loro input, dai loro output,
dai loro risultati attesi e dalle loro dipendenze con gli altri processi di business
organizzativi. Al di sotto di questi esistono i processi di business operativi. A
differenza di quelli organizzativi caratterizzati da funzionalità di business ad alto
I processi aziendali nei sistemi informativi 3
Strategie, Obiettivi
Processi di business
Organizzativi
determina realizza
Operativi
determina realizza
Implementati
Figura 1.1 Classificazione dei processi di business
livello, in questi processi vengono definite nel dettaglio le loro attività e le re-
lazioni tra di esse ma non viene definito alcun tipo di implementazione. Questi
ultimi sono le basi dei processi di business implementati poiché essi contengono
le informazioni sull’esecuzione delle attività dei processi e sull’ambiente tecnico
e organizzativo sul quale essi sono in esecuzione. Un altro tipo di classificazione
riguarda il grado di relazione che un processo di business ha con un altro. Un
processo di business che non ha nessun tipo di legame con l’esterno (altri proces-
si) viene detto funzionale e di norma viene svolto da una sola struttura funzionale
aziendale e spesso sia l’esecutore sia il cliente appartengono alla stessa organiz-
zazione. É questo il caso di molti processi di supporto. Per esempio le analisi
gestionali interessano il reparto amministrazione che raccoglie, elabora e fornisce
rapporti ai reparti della medesima azienda. I reparti che ricevono i rapporti sono
quindi i clienti del processo. Le vendite di un supermercato sono invece esempio
di processi funzionali con clienti esterni. Infatti la richiesta (implicita) proviene
dalla casalinga che preleva e sperabilmente paga la merce alla cassa. Lo stesso
avviene in una variegata serie di interazioni frontali come agli sportelli bancari,
negli sportelli di informazione ed altri. I servizi funzionali possono essere prodotti
a richiesta (come avviene nella spesa al supermercato, che avviene solo se i clienti
entrano nel supermercato) o secondo un calendario predefinito (come avviene nel
4 Capitolo 1
caso dei rapporti gestionali, che sono emessi a scadenze predeterminate). Questi
tipi di processi hanno come obiettivo primario quello di snellire i processi inter-
ni eliminando le attività che non portano valore al processo. Viene definito uno
schema delle risorse dell’organizzazione a cui vengono sistematicamente assegna-
te delle attività del processo in base alla loro competenza. I tradizionali sistemi di
gestione dei workflow sono adatti allo scopo. Quando invece un processo neces-
sita di interagire con un altro allora si parla di processo interfunzionale (se svolto
da più reparti di una stessa organizzazione, mentrei clienti possono essere interni
od esterni) o interorganizzativo, e di coreografie di processi. In questo caso pro-
cessi facenti parte di una coreografia necessitano di tutta una serie di tecnologie
abilitanti al loro scopo. Queste tecnologie riguardano i protocolli di comunica-
zione, il formato dei dati scambiato e il definire una rappresentazione comune
dei vari processi di business. Gli attori dei processi interfunzionali appartengono
a reparti diversi di una stessa organizzazione. I clienti possono essere interni o
esterni. Il primo caso è esemplificato delle evasione degli ordini dei clienti, do-
ve il processo inizia dalla elaborazione delle richieste dei clienti alle vendite, e
coinvolge il reparto di produzione, che assembla il piano di produzione necessa-
rio ad evadere gli ordini, e gli stabilimenti, che eseguono il piano. Nei processi
interorganizzativi i dipartimenti che eseguono il processo appartengono ad orga-
nizzazioni diverse. Consideriamo il ben noto caso di Amazon. Amazon si limita a
raccogliere gli ordini dei clienti, mentre le attività di prelievo dei libri dei depositi
e la spedizione/consegna sono affidate a terzi. Il processo è quindi eseguito da im-
prese diverse ed indipendenti. Analogamente, nella Sanità un esame radiologico
richiede la collaborazione del medico di famiglia, che prescrive l’esame, del labo-
ratorio che lo esegue, della azienda sanitaria che monitora il processo e rimborsa
i costi corrispondenti, e di altre organizzazioni. Un altro tipo di classificazione
dei processi di business può essere fatto sulla base del loro grado di: automa-
zione, ripetizione, strutturazione. Per quanto riguarda il grado di automazione
esistono processi di business che non richiedono l’intervento umano. In questo
caso si parla di processi di business pienamente automatizzati. Un esempio sono
i processi automatizzati di gestione degli ordini al fornitore che effettuano in au-
tomatico la richiesta quando le merci raggiungono il livello di riordino. Esistono
poi processi che non possono essere in alcun modo automatizzati ma richiedono
necessariamente l’intervento umano. Un esempio sono tutte quelle applicazioni
che richiedono l’inserimento manuale di dati al fine di portare a termine un’ope-
razione. Molti processi di business invece richiedono sia attività di tipo manuale
sia attività di tipo automatiche. Rispetto al grado di ripetizione è possibile valu-
tare quale tipo di tecnologia è più adatta a supportare un determinato processo di
business. Nei processi di business dove il grado di ripetizione è alto sono richieste
tecnologie che permettano la modellazione e l’esecuzione automatica dei processi.
Questo tipo di tecnologie comportano un investimento di una certa consistenza ma
consentono la corretta esecuzione dei processi ad alta ripetitività. Esistono invece
dei processi che invece sono caratterizzati da uno scarso o nullo grado di ripetiti-
vità. Questi processi vengono definiti processi di business collaborativi. In questi
processi l’utilizzo delle tecnologie di supporto non ha come obiettivo quello di
ottimizzare l’efficienza ma quello di monitorare il processo e di scoprire eventuali
relazioni causali tra i vari task di progetto. Per ultimo si ha una classificazione dei
processi di business in base al loro grado di strutturazione. Si definisce workflow
di produzione, un processo di business il cui modello descrive perfettamente le sue
attività ed i vincoli tra queste in modo completo. In questo modo il processo si
definisce completamente strutturato. Ad esempio in questi processi sono definiti
tutti i vincoli decisionali del processo in modo che nessun tipo di decisione possa
essere presa da parte di un intervento umano. Questi tipi di processi, inoltre, sono
altamente ripetibili. I sistemi tradizionali di gestione dei workflow sono adatti a
supportarli. Si definisce invece attività ad hoc, un processo che non necessita di
essere definito completamente in quanto deve dare una certa flessibilità all’opera-
tore umano di poter gestire parti del processo in base alla sue competenze. Quindi
questi processi sono caratterizzati da un basso livello di strutturazione e da un alto
livello di flessibilità. Le classificazioni possono avere anche uno scopo descrittivo
o normativo. Le classificazioni descrittive fotografano la situazione esistente di
un’azienda o di un settore rispecchiando le rilevazioni fatte da un’analista. Quelle
normative invece descrivono la struttura dei processi come dovrebbero essere o
come effettivamente sono nelle migliori aziende del settore: questi classificazioni
di riferimento dei processi sono dette best practice. Le classificazioni normative
hanno una grande importanza pratica per due ragioni:
1. forniscono un termine di paragone, in quanto semplificano il confronto tra la
situazione reale attuale e la situazione ideale a cui tendere, permettendo cosı̀ di
individuare e attuare le azioni necessarie per colmare i gap;
2. molte classificazioni best practice sono mappate sui principali pacchetti ERP o
CRM.
Riguardo a quest’ultimo concetto, le società di consulenza hanno messo a punto
delle metodologie integrate di analisi e progettazione dei processi, specializzate
per settore, che comprendono: (i) una lista dei processi strutturata su più livel-
li (ad esempio processo, fase, attività corredata dalla descrizione delle proprietà
dei processi); (ii) il flusso d’esecuzione dei processi (ad esempio il flusso delle
attività); (iii) una serie di strumenti software per il BPM.
1.3 L’architettura dei processi di business

Prima di procedere con l’analizzare nel dettaglio come possono essere descritti e
modellati i processi di business, si riporta come questi possano essere analizzati
all’interno del sistema organizzativo aziendale. Uno dei modelli più diffusi, atto
a rappresentare il sistema organizzativo aziendale in tutte le sue parti ed i relativi
processi, utilizza tre diversi livelli di astrazione:
• Azienda – a tale livello sono descritti i processi di business. La rappresentazione
più semplice è un albero dove: la radice è l’azienda in questione, i nodi sono le
classi di processi e le foglie i singoli processi. Tale modellazione risulta fonda-
mentale per la progettazione dei sistemi e dei processi in quanto: fornisce una
visione complessiva delle aree aziendali informatizzabili e consente di mappare
la strategia d’informatizzazione sui processi dell’azienda.
6 Capitolo 1
• Processo – a tale livello vengono individuate le attività base di un processo

di business. Come visto, esistono diversi formalismi per modellare le attività
elementari di un processo con le relative relazioni di precedenza e sequenza.
Anche questa tipologia di modellazione è fondamentale per la progettazione in
quanto definisce quali attività sono svolte, da chi le attività sono svolte, quali
sono gli output del processo ed altri elementi di interesse.
• Attività – a tale livello sono individuati i contenuti delle singole attività ele-
mentari costiutenti un processo. Un’attività può includere: azioni compiute da
persone (es. prelevare materiale da un magazzino) e azioni sul sistema (es. regi-
strare il prelievo). Un’attività può essere descritta da particolari diagrammi (es.
use case) o schemi di flusso, oppure da descrizioni testuali variamente struttu-
rate. Tale modellazione è fondamentale per la progettazione in quanto definisce
il comportamento operativo del processo.
In particolare questo paragrafo ha l’obiettivo di illustrare metodi e modelli che
rispondono alle domande: Come possono essere descritti ad alto livello i processi
(analisi strategica) ? Quali sono i processi di una impresa (mappatura)?
1.3.1 Il paradigma CRASO

Il paradigma che utilizzeremo per la modellazione è quello CRASO. Esso permet-
te di modellare i processi di business come particolari cicli end to end (da e verso
il cliente). L’acronimo CRASO deriva dai seguenti elementi:
• C – Client: il cliente che riceve i risultati in risposta ad una richiesta;
• R – Request: la richiesta (almeno una) emessa da un cliente;
• A – Activity: una sequenza di attività interconnesse che sono eseguite da una o
più unità organizzative;
• S – organizationS: le varie unità organizzative che riuniscono gli attori che sono
coinvolti nel processo in quanto eseguono una o più attività;
• O – Output: l’output formato dai risultati consegnati al cliente (può essere
materiale o immateriale e consistere di prodotti e/o servizi).
La figura 1.2 mostra come è possibile modellare un processo di business end to
end attraverso il paradigma CRASO. Per processi interfunzionali o interorganiz-
zativi, il modello CRASO è organizzato “ad isole” e gli attori percepiscono so-
lo la loro isola e ribaltano al cliente l’onere di costruire la catena di servizio.
La Figura 1.3 riporta lo schema CRASO per un processo di business a) funzio-
nale (reporting), b) interfunzionale (approvvigionamento) e c) interorganizzativo
(e-commerce).
1.3.2 Modellazione dei processi

La modellazione dei processi di business può essere di due differenti tipologie.
Da un lato, è possibile modellare la struttura di un processo di business andando
ad individuare le singole attività in cui può essere decomposto. Le tipologie di
Figura 1.2 Modello CRASO per un processo di business
relazioni tra le attività sono in questo caso o scomposizioni (part of ) o specializ-

zazioni (is a). La scomposizione intercorre fra un elemento e i suoi componenti
(es. un’auto è composta da meccanica, scocca, allestimento e impianto elettrico).
La specializzazione indica che un dato elemento può avere diverse caratteristiche
(es. un’auto può essere a due o quattro ruote motrici). Il formalismo più diffuso
per tale tipo di modellazione è chiaramente è quello che fa uso di alberi (tasso-
nomie). Dall’altro lato, vi è la necessità di modellare i flussi informativi trai vari
processi e tra le attività di uno stesso processo, nonché le loro regole di esecu-
zione. In questo, come visto nel Capitolo precedente, i diagrammi di flusso o gli
activity diagram rappresentano la soluzione più utilizzata. Si consideri come caso
di studio l’azienda NIKE. Come noto, l’azienda progetta e vende calzature, abbi-
gliamenti e accessori marchiati ma affida a terzi la produzione e la distribuzione.
Per comprare un articolo, Nike individua i potenziali fornitori che potrebbero sod-
disfare le sue esigenze. Stabilito il contatto, NIKE precisa le caratteristiche della
fornitura richiesta: oggetto e quantità della fornitura, località di consegna, quale
periodo e frequenza. Ciò può essere eseguito in vari modi. I fornitori inviano a
NIKE le loro offerte e viene selezionato il fornitore da cui servirsi. La fornitu-
ra attiva la procedura di pagamento, che varia a seconda dei casi. Una possibile
modellazione strutturale e gerarchica del processo di business relativo agli acqui-
sti per la NIKE è mostrata in Figura 1.4 Come si può osservare, la struttura di
un processo è rappresentata da un albero in cui: la radice rappresenta l’intero
processo, i nodi sono attività complesse e le foglie le attività elementari (ovvero
attività atomiche ed omogenee rispetto a attore, frequenza, tecnologia e regole).
Il processo comprende attività sia di Nike sia del fornitore e relazioni di scom-
posizione e specializzazione tra le attività stesse. La modellazione del flusso di
informazioni all’interno del processo di acquisti è invece mostrata in Figura 1.5.
L’activity diagram presentato include le attività, il flusso di esecuzione, i punti
8 Capitolo 1
Figura 1.3 Schemi CRASO per differenti tipi di processi di business
di scelta, l’input/output e le organizzazioni (swim pools). Esso può essere con-

siderato un’estensione del diagramma CRASO. La rappresentazione gerarchica è
chiaramente una base di partenza per il corrispondente flusso: le attività elemen-
tari sono posizionate in colonne, corrispondenti all’organizzazione che le svolge
e si modella la sequenza delle attività per successione temporali o scelta.
1.3.3 Modellazione della struttura organizzativa

La modellazione della struttura organizzativa di un’azienda che interagisce con i
processi di business può avvenire con i classici organigrammi presentati nel Ca-
pitolo 1. In particolare, risulta possibile modellare la struttura organizzativa nel
suo complesso (livello macro) o a livello di singola area organizzativa (livello mi-
cro). La Figura 1.6 riporta la macrostruttura organizzativa dell’azienda NIKE,
mentre la Figura 1.7 modella la microstruttura relativa all’area “Ricevimento e
Magazzino” . Un altro modello molto utile, e complementare a quello degli
organigrammi, per rappresentare i ruoli delle singole unità organizzative all’inter-
no dei processi aziendali è il cosiddetto LRC (Linear Responsibility Charting),
noto anche come matrice processi/unità organizzative. Con tale matrice si indi-
cano per ogni processo le strutture organizzative che vi partecipano e con quale
ruolo (P partecipazione attiva, C partecipazione come cliente o specificando le
singole azioni). Le colonne includono sia strutture interne sia attori esterni (ad es:
Fornitori, Clienti esterni). La figura 1.8 mostra un esempio di matrice LRC.
Figura 1.4 Modellazione gerarchica per il processo di acqusiti
1.3.4 La mappa dei processi aziendali

Di norma, come già visto in parte nel Capitolo 1, si è solito suddividere i processi
aziendali in tre famiglie funzionali:
• processi manageriali (management process): processi per la pianificazione stra-
tegica, il controllo di gestione, di business intelligence, ecc. aventi l’obiettivo
di “governare” l’azienda;
• processi primari (primary process): ad esempio i processi di produzione/erogazione
di prodotti/servizi con lo scopo di servire i clienti di un’azienda;
• processi di supporto (support process): processi di contabilità, gestione di risor-
se (umane, investimenti, patrimonio, ecc.), supporto al business (servizi IT, ser-
vizi generali, ecc.), ecc. con lo scopo di fornire servizi all’azienda ed adempiere
agli obblighi di legge.
E’ possibile definire una mappa, per ogni tipologia di processo, che specifica nel
dettaglio i processi e le attività aziendali tipiche di quella famiglia.
Processi di supporto La Figura 1.9 descrive la mappa dei processi di busi-

ness di supporto. I processi legati all’amministrazione riguardano essenzialmente
la contabilità che può essere: i) sezionale ( registra transazioni a debito e credito
conseguenti ad attività aziendali verso terzi come ad esempio fornitori , clienti
, banche, ecc.), ii) istituzionale (include l’elaborazione del bilancio e delle co-
municazioni societarie complementari), iii) gestionale ( risponde a scopi interni
e cattura transazioni intraziendali i cui debitori e creditori sono strutture dell’im-
presa, alimentando i sistemi di controllo di gestione). I processi di gestione delle
risorse umane (human resource management) riguardano le seguenti attività:
10 Capitolo 1
Figura 1.5 Diagramma di flusso per il processo di acqusiti
• Pianificazione - Determina il fabbisogno di addetti confrontando l’evoluzio-

ne del capitale umano con il profilo delle competenze derivanti dalla strategia
aziendale. La differenza tra il profilo del capitale umano risultante dall’evolu-
zione naturale e quello ottimale viene colmato attraverso selezione, riqualifica-
zione, addestramento.
• Relazioni aziendali - Ad esempio la negoziazione con rappresentanze sindacali
o relazioni con altri attori del sistema.
• Gestione operativa - Rispecchia il ciclo di gestione del personale dell’impresa:
– ricerca, selezione, assunzione normalmente affidate in outsourcing,
– comunicazioni al personale,
– valutazione periodica delle prestazioni e del potenziale e gestione carriera,
– formazione, addestramento come corsi, tirocini, affiancamento,
– rilascio e ricollocazione professionale di personale interno.
• Amministrazione - Ad esempio rilevazione presenze, calcolo retribuzioni, adem-
pimenti fiscali e previdenziali, ecc.
I processi riguardanti i servizi informativi si occupando di:
• Pianificazione: programma i fabbisogni IT dell’organizzazione.
• Client management: attività di supporto alle funzioni organizzative dell’impre-
sa che sono clienti dei servizi informatici finalizzate all’analisi ed alla formaliz-
zazione delle esigenze dei processi di business.
Figura 1.6 Macrostruttura organizzativa
• Progettazione: copre il ciclo vitale del progetto del sistema informatico dal-
la analisi delle esigenze al “go live” assistito da sistemi di ausilio di Project
Management e di Document Management. Viene inclusa l’attività di manuten-
zione.
• Esercizio dei sistemi: amministrazione della base dati, gestione e manutenzione
del software, conduzione dei data center, supporto alla informatica distribuita,
ecc.
• Gestione delle prestazioni: definizione dei livelli di servizio (Service Level
Agreement, SLA) e mantenimento del livello di servizio a frontedi malfunzio-
namenti.
Chiaramente l’outsourcing (esternalizzazione dei servizi verso terzi) trasforma i
processi di servizio sia nell’impresa cliente sia nell’impresa fornitrice. Nell’im-
presa fornitrice il processo di supporto diviene processo primario di servizio. Nel-
l’impresa cliente si crea uno specifico processo di gestione delle prestazioni, ba-
sato su accordi di servizio (SLA). L’outsourcing crea un caratteristico schema che
separa le attività di governo e controllo del servizio dell’impresa cliente e quelle
da parte delle imprese fornitrici.
Processi manageriali Tutti i processi decisionali si fondano invece sul ciclo

di controllo dei sistemi informativi direzionali (visto nel Capitolo 1) che include
(vedi Figura 1.10):
• pianificazione: attività nelle quali si definiscono gli obiettivi (es. aumento
vendite);
12 Capitolo 1
Figura 1.7 Microstruttura organizzativa
Figura 1.8 Esempio di LRC
• controllo: analisi periodica che confronta i risultati ottenuti con gli obiettivi
prefissati ed analizza gli scostamenti (es. vendite effettive verso obiettivi di
vendita);
• azioni correttive: attività con cui si agisce per allineare i risultati e/o gli obiettivi
del piano (es. diminuire i prezzi).
La piramide di Atnhony (vista nel Capitolo 1) oltre ad essere un modello utilizzato
per la rappresentazione funzionale di un’azienda permette anche di classificare
(mappare) i processi direzionali sui tre livelli della piramide stessa (vedi Figura
1.11:
• pianificazione strategica: fissa gli obiettivi complessivi dell’impresa (es. quali
Figura 1.9 Mappa dei processi di supporto
Figura 1.10 Ciclo di controllo dei processi dei processi decisionali
prodotti introdurre e in quali mercati entrare) (attività strategiche).

• controllo direzionale: definisce gli obiettivi economici (es. budget) e verifica i
risultati ottenuti (attività tattiche);
• controllo operativo: agisce in tempo reale sulle singole attività esecutive (es.
fabbricazione di una automobile) e assicura che procedano nel modo prefissato.
In particolare, la pianificazione strategica viene eseguita “ogni qualvolta serve”

e descrive i progetti che attuano la strategia (R&S, organizzativi, di mercato).
L’analisi dei concorrenti e del mercato è oggi fortemente potenziata dalle enormi
masse di informazioni disponibili e dalle tecnologie di business intelligence (BI).
14 Capitolo 1
Figura 1.11 Tipologie di processi decionali con riferimento ai livelli della piramide
di Anthony
Il processo strategico è il processo manageriale più strutturato grazie alle ricerche

di Kaplane Norton sulla Balanced Score Card (BSC). Essa è un modello molto
diffuso che consente di descrivere e bilanciare e gli obiettivi strategici:
• di breve periodo (redditività),
• di medio periodo (presenza sul mercato e sui clienti ed efficienza dei processi
interni),
• di lungo periodo ( sviluppo delle risorse umane, delle tecnologie, R&S);
ma anche di controllarli, assegnando tali obiettivi ai manager e monitorando i
relativi piani azione. Sulla base degli obiettivi descritti, la BSC si propone di
analizzare un’organizzazione da quattro prospettive (vedi Figura 1.12) a ciascuna
delle quali è associato un insieme di indicatori (Key Performance Indicators, KPI):
• Finanziaria: si tratta dei classici indicatori di tipo economico e finanziario atti
a quantificare il valore dell’azienda per gli azionisti.
• Cliente: si tratta dello sviluppo di indicatori che consentano di identificare le
tipologie di clienti e processi che generano prodotti e servizi per tali tipologie.
Tipici indicatori: livello di servizio, soddisfazione del cliente, fidelizzazione.
• Processi: si tratta dei processi di business interni i cui indicatori consentono al
management di tenere sotto controllo il funzionamento dell’organizzazione.
• Crescita e innovazione: si tratta di indicatori che caratterizzano le attività di
formazione e gli atteggiamenti culturali verso l’innovazione sia al livello indi-
viduale che da parte dell’organizzazione nel suo complesso.
I KPI relativi alle quattro prospettive della BSC vengono rappresentati in appositi
strumenti di reporting, detti cruscotti gestionali - simili ai cruscotti presenti negli
Figura 1.12 Schema della Balanced Scorecard
autoveicoli - che rappresentano il front-end di complessi software specializzati

disponibili presso tutti i principali vendor di sistemi di BI. La definizione dei KPI
si basa su tre differenti dimensioni:
• la formula - che consente di calcolare il valore effettivo del relativo indicatore;
• il target - cioè il valore atteso dell’indicatore, anch’esso determinato con una
formula, per il confronto con il valore effettivo dell’indicatore stesso;
• lo scoring - cioè il punteggio funzione della formula e del target.
Il controllo direzionale ha di solito una frequenza annuale e coincide con l’esercizio
di bilancio. La fase di controllo è tipicamente mensile e consiste nell’analisi dei
risultati nei centri di costo e di profitto. L’analisi avviene in comitati di direzione:
ogni dirigente presenta i suoi risultati e propone eventuali azioni correttive. Il con-
trollo direzionale è il processo più tipicamente “orizzontale”: è cioè praticamente
invariante rispetto all’impresa che lo adotta. Per il controllo operativo, lo schema
più classico è quello che si ritrova nelle aziende manifatturiere. Esse adottano
un ciclo di pianificazione annuale, mensile e settimanale - detta programmazione
operativa - ed un ciclo di schedulazione che arriva ai minimi dettagli operativi.
Viene poi effettuata un’analisi degli scostamenti rispetto agli obiettivi prefissati,
tipicamente con cadenza mensile, e la relativa definizione delle azioni correttive.
É necessario infine classificare il processo decisionale cioè il modo in cui il ma-
nager decide una data azione. A tale scopo, la griglia di Gorry e Scott-Morton è
uno dei modelli più diffuso (vedi Figura 1.13) in quanto incrocia i vari livelli di
controllo di Antony con le tipologie decisionali (strutturate, semistrutturate, non
strutturate). Vale la seguente classificazione:
• Una decisione è strutturata se riconducibile ad una regola logica o algebrica.
16 Capitolo 1
• Una decisione è destrutturata se è presa in base a cognizioni o emozioni sog-

gettive
• Una decisione è semistrutturata se sono definiti gli output ma non è predefinita
una regola.
Figura 1.13 Schema della griglia di Gorry e Scott-Morton
Chiaramente maggiore è il grado di strutturazione di un processo e delle infor-

mazioni che tratta, più facilmente questo potrà essere informatizzato (es. sistemi
software per la gestione del riordino delle scorte).
Processi primari Esistono vari modelli nella letteratura che possono essere
utilizzati per descrivere i processi primari di un’azienda come ad esempio la cate-
na del valore di Porter, già analizzata nel Capitolo 1. Altre autori propongono una
classificazione a livelli dei processi primari, che distingue le classi di processi in
ragione dell’obiettivo che si propongono, del tipo di output /servizio che produco-
no e, non ultimo, del tipo di informazioni che elaborano. Tali classi (vedi Figura
1 1.14) comprendono attività di:
1. Pianificazione delle operazioni,
2. Esecuzione,
3. Monitoraggio e rilevazione degli eventi,
4. Controllo,
5. Gestione delle informazioni.
Ciascun livello di processo, dato il proprio caratteristico profilo, corrisponde a un
diverso ruolo dei sistemi IT. Per esempio, nella pianificazione il sistema deve ela-
borare un risultato ottimale, con il vantaggio di bilanciare centinaia di vincoli e di
obiettivi. Nella esecuzione, deve elaborare le transazioni tipiche dei flussi infor-
mativi o gli eventi tipici dei flussi fisici. Nel monitoraggio, deve rilevare eventi e/o
avanzamento di un processo. Nel controllo deve attuare un circuito di feedback,
che corregge la esecuzione in ragione degli obiettivi assegnati. Nella gestione
delle informazioni deve generare e strutturare le centinaia di parametri necessari
ed ad attuare i processi informatizzati. L’incrocio fra livelli e domini individua
i potenziali moduli ES. Nel settore manifatturiero, i domini sono Approvvigio-
namento (Inbound Logistics), Produzione (Operations), Vendite e Distribuzione
Figura 1.14 Classficazione dei processi primari
(Outbound Logistics). Un potenziale modulo ES è quindi la Pianificazione (livel-

lo) della Produzione (dominio). La matrice dei domini e dei livelli è brevemen-
te, illustrata ed esemplificata sul caso della impresa manifatturiera, è riportata in
Figura 1.15.
Business Process Map Le Business process map sono cataloghi struttura-

ti di processi di business a livello di impresa. La Figura 1.16 riporta la mappa
dei processi di una industria meccanica secondo SAP, mentre la Figura 1.17 ri-
porta una possibile mappa dei processi di un autonoleggiatore. Con riferimento
alla mappatura dei processi di business, alcune aziende hanno messo a punto una
knowledge base per vari livelli di impresa, processi, attività, collegate anche con
le relative soluzioni software . Nel mondo dei sistemi integrati ERP, ARIS (Ar-
chitecture of Integrated Information Systems) correla, per ogni livello, le strutture
organizzative, i dati, le funzioni aziendali ed i prodotti dei processi alla descrizio-
ne del flusso (controllo) delle attività dei processi di business (vedi Figura 1.18).
1.3.5 Schemi di settore

Attualmente, alcuni dei modelli più utilizzati per descrivere i processi di busi-
ness sono costituti dai cosiddetti schemi di settore. Gli schemi di settore descri-
vono l’architettura dei processi nelle imprese di un determinato settore. La de-
scrizione è per livelli d’impresa, processi ed attività ed include struttura, flusso,
organigramma aziendale, classi di informazioni ed altro. Ad esempio:
18 Capitolo 1
Figura 1.15 Moduli ES per processi primari
• nella Pubblica Amministrazione i governi dell’Unione Europea hanno suggerito

una tassonomia comune dei servizi basata sugli eventi della vita dei cittadini e
delle imprese;
• nell’Industria Manifatturiera un consorzio di circa mille imprese del mondo
ha sviluppato lo schema di riferimento SCOR (Supply-Chain Operations Re-
ference) della supply chain (catena di distribuzione) e DCOR (Design Chain
Operations Reference) della progettazione;
• nelle Telecomunicazioni il consorzio TMForum ha pubblicato una mappa ope-
rativa di settore detta eTOM (enhanced Telecom Operation Map).
Alcuni schemi invece non sono pubblici, ma proprietari e vengono utilizzati in
esclusiva da aziende di consulenza.
Il modello SCOR Prima di illustrare la struttura dello SCOR conviene definire

che è una supply chain. Una supply chain è una sequenza di stabilimenti (facility)
collegati da direttrici di trasporto. Le facility possono essere di produzione e/o
di immagazzinamento. Le direttrici di trasporto possono valersi di diverse mo-
dalità, come ferrovia, strade, aerei, navi. Una classica supply chain è l’industria
automobilistica, che include:
• produttori di componenti, cioè pneumatici, ruote, componenti meccanici vari;
• produttori di motori ed assemblatori finali, cioè le fabbriche automobilistiche
per antonomasia;
• distributori e concessionari.
Il flusso dei beni e servizi all’interno della supply chain può operare secondo
diverse modalità:
Figura 1.16 Schema della Business Process Map per un’industria meccanica
• Make To Stock (MTS): è il caso classico di chi produce per il magazzino e vende
su listino, come avviene per gli elettrodomestici;
• Assemble To Order (ATO): il cliente sceglie fra le opzioni presenti a listino ed
il prodotto è composto specificatamente per ciascun ordine; è il caso dell’indu-
stria automobilistica dove il cliente sceglie gli allestimenti, e ciascuna vettura é
assemblata per un singolo cliente;
• Make to Order (MTO): il prodotto é fabbricato solo su ordinazione, come nel
caso di una sartoria che confeziona i vestiti a partire solo se ordinati dal cliente;
è anche il caso degli aerei che sono prodotti su commessa delle varie compagnie
aeree; tuttavia la progettazione è fatta una volta per tutte e il cliente compra un
prodotto già progettato e definito;
• Purchase to Order (PTO)/ Engineer to Order (ETO): è il caso di prodotti che
sono disegnati su specifica del cliente, come avviene nel settore cantieristico,
dove le navi sono progettate e realizzate su commessa, o nelle aziende di ascen-
sori, dove gli ascensori di un grattacielo sono progettati e prodotti di volta in
volta; non solo la progettazione ma anche gli approvvigionamenti e la scelta dei
fornitori avvengono di volta in volta.
La Figura mostra un esempio della catena di distribuzione per le industrie automo-

bilistiche. Secondo il modello SCOR esistono 5 processi gestionali fondamentali
volti al soddisfacimenti della domanda del cliente che possono descrivere supply
chain di diversa complessità:
• Plan: sviluppa le linee di azione volte all’acquisizione del risorse necessarie;

20 Capitolo 1
Figura 1.17 Schema della Business Process Map per un’azienda di autonoleggio
• Source: riguarda negoziazione, approvvigionamento, ricevimento di materiali,

prodotti e servizi (corrisponde alla logistica in entrata della catena del valore di
Porter);
• Make: realizza i prodotti (corrisponde alle operations della catena del valo-
re di Porter, ed include la realizzazione di prodotti attraverso miscelazione,
separazione, lavorazione meccanica, trasformazioni chimiche);
• Deliver: consegna i prodotti finiti ed include le operazioni di preparazione,
spedizione, trasporto (corrisponde alla logistica in uscita della catena del valore
di Porter);
• Return: riguarda la resa dei materiali dal cliente della catena al fornitore (per
esempio materiali resi perché non hanno superato il collaudo o la certificazione
di qualità, oppure prodotti finiti difettosi resi dal cliente finale).
SCOR, inoltre, identifica anche processi Enable per la gestione delle informazio-
ni. Lo schema SCOR è in particolare articolato su successivi livelli di dettaglio
(vedi Figura 1.20):
1. Top level, che include le macro classi di processo (Plan, Source, ecc.);
2. Configuration level, che suddivide le macroclassi in tipologie;
3. Process element level, che corrisponde alle fasi dei processi;
Figura 1.18 Modello ARIS
4. Iimplementation level, che descrive come la singola impresa svolge una data
attività del livello 3; questo livello é disegnato di volta in volta dall’analista,
che dettaglia la mappa SCOR con opportune tecniche di modellazione.
Lo schema SCOR, prevede anche si descrivere le proprietà di ciascun process

element. Ogni scheda contiene:
• Una descrizione testuale del process element;

• I criteri con cui sono misurate le prestazioni gestionali del processo dal pun-
to di vista dell’affidabilità (reliability), della reattività (responsiveness), del-
la flessibilità (flexibility), dell’efficienza (cost), delle implicazioni patrimoniali
(asset);
• Soluzioni (best practices) che descrivono le soluzioni paradigmatiche adottate
per svolgere il process element ovvero per informatizzarlo e che mettono in luce
le particolarità che rendono competitive le soluzioni; per esempio una pianifi-
cazione della produzione in una supply chain è eccellente se bilancia domanda
e offerta.
22 Capitolo 1
Figura 1.19 Esempio di supply chain
1.4 Il Business Process Management (BPM)

1.4.1 Definzioni per il BPM
Il Business Process Management (BPM) è il risultato della convergenza di diverse
discipline, tra le quali troviamo: modellazione dei processi di business, la gestione
della qualità, la computazione distribuita, la gestione dei workflow e la reingegne-
rizzazione dei processi. Nella letteratura, esistono diverse definizioni di Business
Process Management. Secondo Horak, il Business Process Management è un ap-
proccio sistematico e strutturato per analizzare, migliorare, controllare e gestire i
processi di business con lo scopo di migliorare la qualità dei prodotti e dei servizi.
Un’altra definizione di BPM è quella data da Weske: il BPM è un sistema il cui
scopo è quello di supportare i processi di business utilizzando metodi, tecniche e
software per progettare, mettere in esecuzione, controllare e analizzare i processi
operativi che coinvolgono esseri umani, organizzazioni, applicazioni, documenti
e altre fonti di informazione. L’ultima definizione che citeremo è quella data da
Gartner: un sistema BPM è un sistema composto da servizi e strumenti che sup-
portano in modo esplicito la gestione del processo di business (analisi, definizione,
esecuzione, monitoraggio e amministrazione). Dall’unione delle tre definizioni di
Business Process Management è possibile ricavarne una che descrive in modo
completo un sistema BPM.
Definizione 1.4.1 (Business Project Management). Il Business Process Manage-
Figura 1.20 Livelli SCOR
ment è una disciplina gestionale che utilizza un approccio sistematico e strut-

turato con il fine di supportare la gestione esplicita di un processo di business
utilizzando metodi, tecniche e strumenti, che coinvolgono esseri umani, organiz-
zazioni, applicazioni, documenti e altre fonti di informazione, con lo scopo di
raggiungere gli obiettivi di business dell’organizzazione allineando i processi di
business a questi obiettivi.
Attualmente, il BPM utilizza appositi sistemi software (Business Process Ma-

nagement Systems, BPMS) che permettono di definire i processi di business me-
diante l’utilizzo di notazioni adatte allo scopo, di metterli in esecuzione e di con-
trollarne l’esito (prima della implementazione effettiva), facilitando tutte le attività
del BPM. Ai fini del BPM, ogni processo di business può essere visto come uno
o più workflow, che collaborano tra di loro e sono eseguiti in coordinazione con
l’ambiente esterno, al fine di raggiungere un obiettivo aziendale comune (business
goal). Il concetto di workflow viene definito dal Workflow Management Coalition
24 Capitolo 1
(WfMC)1 e può essere espresso come segue:

Definizione 1.4.2 (Workflow). Un workflow è l’automazione di una sequenza di
attività di un processo di business.
A tale proposito, il WfMC ha definito lo standard XPDL (XML Process Defi-
nition Language) che è un linguaggio basato su XML che ha come scopo quello di
definire una rappresentazione univoca del modello di processo di business in modo
tale che possa essere interpretato da diversi sistemi BPM. Nella pratica, esistono
altri enti e consorzi che hanno definito standard nell’ambito dei sistemi BPM. Uno
di questi è l’Object Management Group (OMG) che ha definito uno standard per
la modellazione grafica di un processo di business: la notazione BPMN (Business
Process Management Notation). Un altro ancora è il consorzio OASIS (Organiza-
tion for the Advancement of Structured Information Standards) che ha definito lo
standard BPEL (Business Process Execution Language). In particolare, BPEL è
uno standard di esecuzione che permette al processo di business di essere eseguito
indifferentemente su tutti gli strumenti BPM che supportano questo standard. L’a-
dozione di questi standard da parte degli strumenti BPM è importante dal punto di
vista dell’interoperabilità. Oltre agli strumenti che devono supportare gli standard
descritti, un sistema BPM deve presentare uno strumento che metta in esecuzione
il processo di business descritto. Questo strumento è il BPM engine che permette
di assegnare l’esecuzione di un’attività del workflow ad una specifica risorsa. Una
volta che il processo di business è in esecuzione, lo strumento BPM deve fornire
uno strumento per potere monitorare lo stato del processo e raccogliere metri-
che sulle prestazioni della sua esecuzione. Questi componenti sono il Business
Activity Monitoring (BAM) e il Business Cockpit.
1.4.2 Le componenti di un processo di business

Di seguito si esamino invece le parti costituenti di un processo di business, utiliz-
zando il gergo tipico del BPM. Definiamo con il termine “caso” (case) la gene-
razione di un particolare output di processo a partire da un dato input. Un caso
richiede che un “processo” (process) sia eseguito. Un processo consiste in un in-
sieme di “task” che devono essere espletati ai fini del suo completamento e di un
insieme di “condition” (condition) che determinano l’ordine dei singoli task. Un
task può essere considerato come un processo che non può essere diviso ulterior-
mente e che viene svolto nel suo insieme da una “risorsa” (resource). Chiamiamo
“attività” (activity) l’esecuzione di un task da parte di una risorsa. Una risorsa è
quindi il nome generico che viene assegnato ad una persona, macchina o gruppo di
persone e macchine che possono eseguire attività specifiche. Ciò non significa che
una risorsa necessariamente debba portare a termina l’attività per la quale è stata
assegnata. Tuttavia con il suo assegnamento essa diventa responsabile dell’esito
di tale attività. Due o più task che devono essere eseguiti seguendo un determinato
1
Il WfMC è un consorzio formato da sviluppatori, analisti e ricercatori che si occupano di
definire degli standard per la gestione dei processi di business e dei relativi workflow.
ordine sono chiamati sequenza. Quando è necessario scegliere tra due o più task
per il proseguimento del flusso di processo ci troviamo nel caso di selezione tra
più task. Ci sono task che possono anche essere eseguiti in parallelo: questi ultimi
devono essere completati ad esempio prima che il task successivo possa entrare
in esecuzione. E’ possibile ripetere l’esecuzione di più task durante l’esecuzione
di un processo: questa operazione è chiamata iterazione. Ricapitolando possiamo
identificare quattro meccanismi di base nella struttura di un flusso di un processo:
• sequenza,
• selezione,
• parallelizzazione,
• iterazione.
Tali costrutti permettono la cosiddetta sincronizzazione trai task di un processo.
1.4.3 Workflow
Come già introdotto, un workflow può essere visto come l’automazione completa
o parziale di un processo di business durante la quale documenti, informazioni e
task vengono passati da un partecipante (persona o applicazione informatica) ad
un altro affinché si possa raggiungere un obiettivo comune, utilizzando un insie-
me predefinito di regole. Un workflow può essere visto come un componente di
un processo di business, in quanto consiste in una sequenza di attività specifiche
di una particolare applicazione attuate attraverso insiemi di istruzioni predefini-
ti, coinvolgendo sia procedure automatizzate che manuali. Un workflow viene di
solito descritto attraverso tre modelli:
• modello di processo;
• modello informativo;
• modello organizzativo.
Per descrivere i tre modelli verranno utilizzati gli standard introdotti dal WfMC
(Workflow Management Coalition) e quelli del WIDE (Workflow on Intelligent
and Distributed database Environment).
Modello di processo I componenti fondamentali di un workflow sono:

• Processo - un processo è definito come la rappresentazione formale di un pro-
cesso di business in modo tale che la sua manipolazione sia possibile per mezzo
di un Workflow Management System (WfMS). Questo è composto da un insieme
di attività, da relazioni tra queste attività, da criteri di inizio e terminazione del
processo e da informazioni circa le singole attività, i partecipanti, i documenti
e i dati relativi, le applicazioni software richieste.
• Partecipante - un partecipante di un workflow è una risorsa che esegue il lavoro
associato ad una particolare istanza di task. Il lavoro viene generalmente riferito
ad un elemento di task contenuto all’interno della lista del partecipante. Questo
può essere una risorsa umana, un’applicazione software, una parte specifica di
hardware in grado di eseguire un task.
26 Capitolo 1
• Work list - ogni partecipante del workflow ha la sua lista di task da esegui-
re. Questa work list può anche essere assegnata ad un gruppo di agenti (lista
condivisa).
La Figura 1.21 descrive la terminologia utilizzata per descrivere i componenti di
un workflow. Altre componenti di un workflow utili alla sua modellazione sono
Figura 1.21 Componenti di un workflow
inoltre le seguenti:
• Sotto processo - Processo che viene attivato da un altro processo (istanziato) e
che rappresenta parte del processo totale.
• Blocco di attività - un insieme di attività contenute nella definizione di processo
che condividono una o più proprietà che permettono ad un WfMS di svolgere
alcune azioni rispetto a questo gruppo. Ad ogni singola attività viene assegnato
uno stato.
• Deadline - un vincolo di schedulazione temporale che richiede che una certa
attività venga completata in un certo intervallo di tempo.
• Instradamento (Routing) - come vengono connesse tra loro i diversi blocchi di
attività. Sono possibili due tipi di instradamento: sequenziale (le attività vengo-
no eseguite in sequenza sotto un singolo thread di esecuzione e parallelo (due
o più istanze di attività vengono eseguite in parallelo all’interno del workflow,
dando origine a thread multipli di controllo). La Figura 1.22 descrive i costrut-
ti AND-Join, AND-Split, OR-Join e OR-Split che possono essere usati per la
sincronizzazione.
• Ciclo - ripetizione di una stessa attività o di una sequenza di attività finché non
viene soddisfatta una determinata condizione.
• Pre-post condizioni - una pre-condizione è un’espressione logica che viene va-

lutata dal workflow engine per decidere se iniziare un’istanza di un particolare
processo. In modo opposto, una post-condizione è un’espressione logica che
viene valutata dal workflow engine per decidere se un’istanza di un particolare
processo può definirsi completata.
Figura 1.22 Sincronizzazione in un workflow
Modello informativo Il modello informativo di un workflow descrive le in-

formazioni ricevute, modificate o prodotte da un workflow. Secondo il modello
WIDE, il modello informativo di un workflow può essere definito in tre diverse
modalità:
• attraverso uno schema variabili del workflow;
• attraverso un database condiviso con altri workflow;
• attraverso documenti che vengono scambiati tra i diversi workflow.
Modello organizzativo Il modello organizzativo di un workflow descrive

invece:
• la struttura dell’organizzazione;
• i partecipanti al processo di workflow;
• l’autorizzazione che ha un partecipante per eseguire una determinata attività del
processo di workflow.
28 Capitolo 1
Nel modello di workflow WIDE, un partecipante ad un processo di workflow

viene chiamato agente. Con l’entità agente possono essere descritte ulteriori
sotto-entità:
• Attore (Actor): è una risorsa di esecuzione individuale. Può essere umano op-
pure un agente software. Un Attore può essere specificato utilizzando diversi
attributi tra cui la sua disponibilità.
• Gruppo (Group): è un insieme di attori che possiedono comuni caratteristiche
(ad esempio appartengono tutti ad una particolare unità dell’organizzazione).
• Funzione di organizzazione (Organization function): descrive una funzione che
può essere eseguita da un gruppo o da un attore individuale. Viene assegnato
un attributo di tipo capacità di esecuzione (skill).
La struttura di un’organizzazione viene specificata attraverso le relazioni che ven-

gono definite tra queste entità. I modello organizzativo di un processo di work-
flow definisce anche i meccanismi di autorizzazione dei vari agenti. Ogni task del
workflow deve essere eseguito da agenti autorizzati. Per questo c’è la necessità
di specificare quali agenti possono eseguire i vari task. In questo modo, gli agen-
ti possono monitorare i task di loro competenza che devono essere eseguiti e di
verificare se ci sono azioni da intraprendere. A questo proposito si introduce il
concetto di ruolo. Un ruolo è una descrizione generica delle entità a cui è per-
messo eseguire uno specifico task. I ruoli vengono definiti separatamente dagli
agenti e dalla struttura organizzativa e possono riferirsi ad un uno o più task del
workflow.
Cenni all’architettura di un WfMS L’architettura di un WfMS contiene

i sottosistemi e ruoli descritti in Figura 1.23. In particolare, si distinguono le
seguenti componenti.
• Workflow Modelling che fornisce i mezzi per poter modellare i processi di

business.
• Workflow Model Repository che si occupa di immagazzinare i modelli di work-
flow che sono stati creati.
• Workflow Engine che è responsabile dell’attuazione dei processi di workflow.
Esso in particolare permette la creazione e l’attuazione di un’istanza di work-
flow quando questa viene richiesta.
1.4.4 Sistemi BPMS

Come visto il BPM supporta in modo esplicito la gestione dei processi di busi-
ness. Questo significa che i processi di business devono essere definiti in modo
“esplicito”. Processi di business “impliciti” sono insiti nei pattern di lavoro degli
impiegati di un’organizzazione o nella logica applicativa delle applicazioni. Ren-
dere i processi di business espliciti richiede che un modello di processo di business
debba essere prodotto nel quale i processi di business possano essere definiti in
Figura 1.23 Architettura di un WfMS
maniera precisa. Questo modello dovrebbe essere analizzato e migliorato se ne-

cessario. Deve essere possibile decidere se implementare il modello con o senza
un supporto informatico, e se rendere disponibile all’esterno dell’organizzazione
il processo di business. Quando viene implementato un processo di business sen-
za il supporto informatico devono essere create nuove politiche e pattern di lavoro
a cui i partecipanti del processo di business devono adeguarsi. Nel caso il sup-
porto informatico sia disponibile, il modello del processo di business viene reso
eseguibile e deve essere progettato un ambiente di esecuzione in grado di suppor-
tarlo. L’ambiente di esecuzione di un processo di business consiste di un engine
di esecuzione del processo di business. Questo deve essere in grado di:
• eseguire i processi di business eseguibili;
• gestire le modalità di interazione con l’ambiente esterno;
• gestire le funzionalità definite nel processo di business.
Un modello di processo di business eseguibile può essere tradotto in codice ed
essere eseguito da un engine di esecuzione del processo di business. Gli utenti
possono interagire con i processi di business in esecuzione e i manager possono
monitorarli e controllarli. I processi di business in esecuzione e quelli terminati
possono essere analizzati per trovare margini di miglioramento, creando un ciclo
continuo di miglioramento del processo di business. Le operazioni citate possono
essere racchiuse in un ciclo di vita di un processo di business. La Figura 1.24
mostra lo schema del ciclo di vita di un processo di business e i corrispettivi
30 Capitolo 1
componenti di un sistema BPM. Il ciclo di vita di un processo di business è diviso
Figura 1.24 Ciclo di vita di un processo di business
in fasi che sono collegate le une con le altre. Le fasi sono organizzate in una
struttura ciclica, mostrando le loro dipendenze logiche. Queste dipendenze non
implicano il rispettare uno stretto ordine temporale per l’esecuzione delle fasi.
Infatti molte attività di progetto e di sviluppo vengono condotte durante ciascuna
di queste fasi. Le fasi di un processo di business possono essere mappate nelle
corrispettive metodologie e tecnologie che formano i componenti di un sistema
di Business Process Management (BPMS). Descriviamo ora queste fasi e le loro
corrispettive funzionalità.
Progettazione ed Analisi (Design & Analysis) In questa fase i processi

di business vengono identificati, rivisti, validati e rappresentati con dei modelli
di processi di business. La notazione grafica esprime i modelli di processi di bu-
siness in modo esplicito. Tecniche di modellazione di un processo di business
come la validazione, simulazione e la verifica vengono utilizzate durante questa
fase. Per quanto concerne le tecniche di modellazione e validazione, gli strumenti
BPM mettono a disposizione un ambiente di modellazione che permette di descri-
vere il processo di business con un determinato formalismo di essi nel capitolo e
di validare il modello. Le tecniche di simulazione possono essere utilizzate per
supportare la validazione del modello. Infatti tramite la simulazione è possibile

scoprire quelle sequenze di esecuzione che mostrano dei bottleneck prestazionali
durante la loro esecuzione e di verificare la correttezza del loro comportamento.
La maggior parte dei sistemi BPM forniscono un ambiente di simulazione che può
essere usato in questa fase.
Configurazione (Configuration) Una volta che il modello del processo di

business viene progettato e verificato, il processo di business deve essere imple-
mentato. Un sistema BPM fornisce dei componenti software dedicati a questo
scopo. Questi componenti si occupano di fornire le informazioni tecniche neces-
sarie che facilitano l’attivazione del processo nel BPMS. Il sistema BPM deve
essere configurato secondo l’ambiente organizzativo e in base ai processi di bu-
siness che devono essere messi in esecuzione. La configurazione deve includere
sia le interazioni degli utilizzatori del sistema con esso sia l’integrazione dei si-
stemi software esistenti con il BPMS. La configurazione di un BPMS potrebbe
coinvolgere aspetti transazionali quindi deve essere configurato in modo tale da
garantire l’applicazione delle proprietà ACID richieste dalle transazioni definite
nel processo di business. Inoltre in questa fase devono essere raccolte le informa-
zioni necessarie circa i requisiti minimi di risorse che il sistema BPMS richiede
per la sua esecuzione. Una volta terminata la configurazione, l’implementazione
del processo di business deve essere testata. A livello di processo, vengono effet-
tuati dei test di integrazione o di performance che sono importanti per individuare
potenziali problemi a tempo di esecuzione del processo.
Attivazione (Enactment) Terminata la fase di configurazione, le istanze dei

processi di business possono essere attivate. La fase di attivazione del processo
riguarda tutti gli aspetti coinvolti nell’esecuzione del processo. All’inizio del-
la fase di attivazione, le istanze dei processi di business vengono inizializzate in
modo da soddisfare i requisiti di business di un’organizzazione. L’iniziazione di
un’istanza di un processo tipicamente segue un determinato evento (ad esempio
il ricevimento di un ordine spedito da un cliente). Un sistema BPM deve essere
in grado di controllare attivamente l’esecuzione delle istanze e fornire meccani-
smi per l’orchestrazione di queste istanze, in modo da garantire che le attività di
processo vengono eseguiti secondo i vincoli di esecuzione specificati nel modello
di processo. Un altro componente importanti del BPMS di questa fase è quello
che permette il monitoraggio per visualizzare lo stato delle istanze dei processi di
business. Il monitoraggio del processo è un meccanismo importante per fornire
informazioni accurate sullo stato delle esecuzioni. Il BPMS deve essere in grado
di raccogliere i dati significativi sull’esecuzione delle istanze di business, tipica-
mente sotto forma di file di log. Questi file di log consistono di insiemi ordinati di
record che indicano eventi che sono accaduti durante le varie esecuzioni. Queste
informazioni sono la base per valutare i processi nella fase di analisi.
Valutazione (Evaluation) La fase di valutazione utilizza le informazioni di-

sponibili per valutare e migliorare i modelli dei processi di business e le loro
32 Capitolo 1
implementazioni. I BPMS utilizzano i file di log raccolti nella fase precedente per
valutarli utilizzando sistemi quali i business activity monitoring e i business coc-
kpit. Questi ultimi utilizzano tecniche di data mining per cercare di identificare
la qualità di un modello di processo di business e il grado di adeguatezza rispet-
to l’ambiente di esecuzione. Il business activity monitoring serve a identificare
quali attività del processo di business ad esempio consumano più risorse oppure
non sono state completate in base ai vincoli previsti dal modello di processo di
business. Queste analisi vengono effettuate a tempo di esecuzione in modo da
intervenire direttamente sull’istanza del processo. Il business cockpit,invece, si
occupa di analizzare i dati raccolti a posteriori rispetto l’esecuzione del processo.
Lo scopo di questo strumento è quello di mettere in relazione i vari dati prodotti
da varie istanze dello stesso processo di business in modo da identificare quelle
parti del modello che devono essere migliorate.
1.5 Standard per la modellazione e gestione dei pro-

cessi nel BPM
In questo paragrafo verranno illustrati gli standard applicabili agli strumenti BPM.
Come vedremo, questi possono essere di tre tipologie: standard grafici di modella-
zione, standard per i formati di interscambio dei modelli dei processi di business e
standard di esecuzione dei processi di business. La conformità agli standard è una
caratteristica chiave di ogni strumento BPM, in quanto gli consente di poter intera-
gire con altri strumenti BPM in un linguaggio che sia comune ad entrambi. Inoltre
l’importanza di avere degli standard ben definiti permette di dare uniformità alla
rappresentazione di un processo di business e di unificare le molteplici soluzioni
descrittive già esistenti. Gli standard che vengono presi in considerazione sono
BPMN per la modellazione e BPEL per l’esecuzione.
1.5.1 Standard grafici per la modellazione: BPMN

Gli standard grafici permettono agli utenti di esprimere sotto forma di diagramma
il flusso informativo, i punti di decisione e i ruoli dei processi di business. Rispetto
alle altre tipologie di standard, gli standard grafici sono quelli più human-readable
e facili da comprendere senza che siano necessarie conoscenze tecniche specifi-
che. Tra gli standard più importanti troviamo: Business Process Management
Notation (BPMN) (che analizzeremo nel dettaglio), Activity Diagram UML (già
introdotto nel Capitolo 1) ed Event-driven Process Chain (EPC). BPMN è una
notazione di modellazione per processi di business definito dall’Object Manage-
ment Group (OMG), che mira a diventare uno standard de facto tra i vari standard
grafici di modellazione di processi di business. La notazione nasce dall’esigenza
di creare un linguaggio di modellazione che fosse in grado di eliminare il gap tec-
nico esistente tra le descrizioni dei processi di business per mezzo di diagrammi di
flusso e le descrizioni di quest’ultime in un linguaggio di esecuzione. Per mezzo
di questa notazione è infatti possibile mappare la descrizione visuale di un pro-
cesso di business, descritta direttamente dagli analisti di business, nel linguaggio

di esecuzione appropriato. Per vedere come BPMN risolve i problemi di modella-
zione descriveremo le componenti grafiche di un diagramma BPMN sfruttando la
divisione in due gruppi suggerita da OMG. Il primo gruppo contiene gli elementi
di base della notazione con i quali è possibile creare dei modelli della maggior
parte dei processi di business. Il secondo gruppo, oltre a contenere gli elementi
del primo, contiene inoltre una serie di formalismi grafici che consentono di ri-
solvere situazioni di modellazione complesse. Il primo gruppo degli elementi di
base della notazione contiene 11 formalismi grafici per mezzo dei quali è possibi-
le descrivere la maggior parte dei processi di business. Questi formalismi grafici
sono divisi in 4 categorie:
1. Oggetti di flusso (Flow Objects): Eventi (Event), Attività (Activity) e Gateways;
2. Oggetti di connessione (Connecting Objects): Flusso di sequenza (Sequence
Flow), Flusso di messaggio (Message Flow) ed Associazione (Association);
3. Swimlanes: Pools e Lanes;
4. Artefatti (Artifacts): Oggetto di dati (Data Object), Gruppo (Group), Annota-
zione (Annotation).
La Figura 1.25 mostra le notazioni grafiche di base di BPMN. Di seguito sono
Figura 1.25 Notazioni grafiche di base del BPMN
descritti nel dettaglio i vari elementi con le relative estensioni.
Evento Un evento è qualcosa che accade durante il corso del processo di bu-
siness. Questi eventi influiscono sull’esito del flusso del processo e solitamente
sono caratterizzati da una causa (trigger) e da un effetto (result). Vengono rappre-
sentati per mezzo di cerchi e ne esistono tre di base: gli eventi di inizio (indicano
34 Capitolo 1
che un particolare processo ha inizio e vengono rappresentati con un cerchio),

intermedi al processo (influiscono sull’andamento del flusso di processo ma non
iniziano ne terminano il processo e vengono rappresentati con un doppio cerchio)
e di fine (indicano la terminazione di un processo e vengono rappresentati con un
cerchio il cui bordo è in grassetto). Per quanto riguarda la loro tipologia, nella
notazione avanzata, essi possono essere di tipo catching se reagiscono a un qual-
che trigger che li metta in esecuzione oppure possono essere di tipo throwing se
creano un qualche risultato. Ogni tipo di evento è indicato da un simbolo che
ne identifica la funzione. Gli eventi di catching vengono indicati con il simbolo
non riempito mentre quelli di throwing con il simbolo riempito. In particolare, si
distinguono:
• eventi di tipo message: indicano che un messaggio è arrivato da parte di un
partecipante oppure è il risultato dell’evento;
• eventi di tipo timer: sono solo di tipo catching e rimangono in ascolto di un
trigger temporale che decide il momento della loro esecuzione;
• eventi di tipo error: indicano che si è verificato un errore all’interno del flusso
di processo (possono essere solo intemerdi e di fine);
• eventi di tipo cancel: vengono utilizzati per annullare gli effetti di una transa-
zione di business definita all’interno di un sotto-processo;
• eventi di tipo compensation: vengono utilizzati per la gestione delle eccezio-
ni che possono verificarsi all’interno di un processo e servono per effettuare
compensazione;
• eventi di tipo conditional: questi eventi si attivano quando una condizione
diventa vera.
• eventi di tipo link: rappresentano un meccanismo grazie al quale è possibile
collegare due sezioni di un processo (vengono utilizzati per creare situazioni
cicliche oppure per evitare lunghe sequenze di flusso);
• eventi di tipo signal: viene inviato un segnale all’interno del processo che viene
diffuso in modalità broadcast a tutti i partecipanti a differenza dei messaggi che
hanno una sorgente e un destinatario definiti;
• eventi di tipo terminate: vengono utilizzati per terminare immediatamente tutte
le attività all’interno di un processo;
• eventi di tipo multiple: indicano l’esistenza di molteplici trigger riguardanti
l’evento.
La Figura 1.26 riassume le notazioni grafiche per tutte le tipologie di eventi.
Attività Attività è un termine generico per indicare il lavoro che svolge un qual-
che entità. Un’attività può essere atomica o composta. I tipi di attività che fanno
parte del modello di processo sono: task e sotto-processo (rappresentati con trian-
goli arrotondati). In particolare: un task rappresenta un’unità atomica di attività
che è inclusa all’interno di un processo e viene utilizzato quando l’attività non è
ulteriormente decomponibile; un sotto-processo è un’attività composta che vie-
ne inclusa all’interno di un processo (graficamente nella notazione avanzata può
essere visualizzata completamente oppure viene visualizzata in modalità “collas-
Figura 1.26 Notazioni grafiche per gli eventi in BPMN
sata” con il simbolo ‘+’ che sta ad indicare questa tipologia). La Figura 1.27
mostra le notazioni grafiche utilizzate per le attività.
Gateway Un gateway viene utilizzato per controllare la divergenza e la conver-

genza di un flusso di sequenza. Quindi determinerà le operazioni di branching, di
forking, di merging e di joining dei vari percorsi di flusso. Viene rappresentato
come un rombo. Esistono, nella notazione avanzata, diverse tipologie di gateway:
• gateway esclusivi: definiscono una scelta da fare nel flusso di processo (questa
scelta può essere basata su dati oppure su un evento);
• gateway inclusivi: definiscono una o più scelte che vengono prese nel flusso di
processo (la scelta di un percorso nel flusso di processo non esclude le altre);
• gateway complessi: sono stati definiti per trattare quelle situazioni che non è
possibile affrontare con gli altri tipi di gateway (ad esempio l’unione di più
gateway);
• gateway paralleli: definiscono l’esecuzione di più attività in parallelo.
La Figura 1.28 mostra le notazioni grafiche utilizzate per i gateway.

36 Capitolo 1
Figura 1.27 Notazioni grafiche per le attività in BPMN
Figura 1.28 Notazioni grafiche per i gateway in BPMN
Flusso di sequenza Un flusso di sequenza viene utilizzato per mostrare l’or-

dine con cui vengono eseguite le attività all’interno del processo. La notazione
avanzata BPMN definisce diversi flussi di sequenza del processo di business: i)
flusso di default (viene utilizzato nelle decisioni di flusso di processo, sia inclusi-
ve che esclusive, e stabilisce quale sia la condizione di flusso di default ed il suo
simbolo è caratterizzato dall’avere uno slash diagonale all’inizio della linea); ii)
flusso di eccezione (viene utilizzato per definire le deviazioni del flusso di proces-
so rispetto al flusso normale attivate mediante l’utilizzo di un evento intermedio);
iii) flusso condizionale (un flusso di sequenza avente un’espressione condizionale
che viene valutata a runtime per determinare quale flusso dovrà seguire il proces-
so). La Figura 1.29 mostra le notazioni grafiche utilizzate per i flussi di sequenza.
Figura 1.29 Notazioni grafiche per i flussi di sequenza in BPMN
Flusso di messaggio Un flusso di messaggio viene utilizzato per mostrare il

flusso di messaggi tra due partecipanti che sono preparati a spedirli e a riceverli.
Associazione Un’associazione viene utilizzata per associare informazione agli

oggetti di flusso. Oggetti testuali e grafici non di flusso possono essere associa-
ti con quelli di flusso. Un’associazione può avere una direzione per indicare il
destinatario delle informazioni che trasporta, qualora sia opportuno.
Pool Un pool rappresenta un partecipante in un processo. Inoltre serve anche

da contenitore grafico per partizionare un insieme di attività da altri pool.
Lane Un lane rappresenta una sotto-partizione all’interno del pool che si esten-
de per l’intera lunghezza del pool sia in orizzontale che in verticale. Viene utiliz-
zato per organizzare e categorizzare le attività.
Oggetto di dati Un oggetto di dati non ha alcun effetto sul flusso di sequenza
o di messaggio ma fornisce informazioni circa quelle attività che richiedono di
essere eseguite oppure su cosa producono.
Gruppo Un gruppo rappresenta un insieme di attività appartenenti ad una sin-

gola categoria. Questo tipo di gruppo non influisce sul flusso di sequenza delle
attività all’interno del gruppo. Dato che le categorie possono essere utilizzate per
scopi di documentazione o di analisi, i gruppi rappresentano l’unico modo per
visualizzarle all’interno del diagramma.
Annotazione Le annotazioni testuali sono un meccanismo per il modellista

per fornire ulteriori informazioni a chi legge il diagramma di processo.
38 Capitolo 1
Transazioni La notazione BPMN permette di definire parti del processo come

transazioni. Nella notazione BPMN una transazione è un sotto-processo che con-
tiene un flusso che è sottoposto ai meccanismi di gestione delle transazioni. Essa
viene rappresentata con doppio riquadro come mostra la Figura 1.30. Per gestire
il fallimento di una transazione, BPMN permette di modellizzare il meccanismo
di “compensazione”: questo permette al flusso di processo interno ad una transa-
zione di deviare dal flusso normale in modo tale da rendere consistente il risultato
della transazione. La Figura 1.31 mostra il diagramma BPMN per un processo
Figura 1.30 Notazioni grafiche per le transazioni in BPMN
di business relativo ad una votazione tramite e-mail. Questo processo è descritto

nella documentazione della specifica della notazione BPMN da parte del WfMC.
Il modello descritto mira a risolvere dei problemi inerenti ad un processo di vota-
zione per mezzo di e-mail per prendere delle decisioni sulla risoluzione di diversi
problemi. Il punto di vista di questo processo è quello del manager, della lista dei
problemi e della discussione che la coinvolge. I membri votanti del gruppo di la-
voro sono considerati come dei partecipanti esterni del processo che comunicano
con il manager per mezzo di messaggi.
1.5.2 Cenni agli standard per l’esecuzione: BPEL

Gli standard di esecuzione permettono ai processi di business progettati di esse-
re distribuiti nei sistemi BPM e di essere eseguiti dai BPM engine. Attualmente
esiste uno standard che viene utilizzato da diversi produttori di strumenti BPM:
BPEL (Business Process Execution Language). BPEL è un linguaggio basato su
XML per specificare processi di business nel contesto dei Web Service specificato
dal consorzio OASIS (Organization for the Advancement of Structured Informa-
tion Standards). In BPEL, i processi di business possono essere descritti come:
i) processi di business eseguibili (modelli che descrivono i dettagli del processo
e il comportamento di un partecipante all’interazione di business), ii) protocolli
di business (descrizioni che specificano le modalità di scambio di messaggi tra le
parti coinvolte nel protocollo, senza rivelare il comportamento interno e i dettagli
Figura 1.31 Esempio di processo in BPMN
del processo). Le descrizioni del processo per i protocolli di business vengono

chiamati processi astratti. Dalle due descrizioni si evince che la logica completa
di un processo di business viene descritta mediante un processo eseguibile men-
tre le procedure di scambio dei messaggi tra i partecipanti vengono modellizzate
mediante i processi astratti.
1.6 La gestione del cambiamento
1.6.1 Interventi sui processi di business

Come anticipato le attività di “miglioramento” o “cambiamento” dei processi di
business di un’azienda avvengono a seguito di modifiche di natura organizzativa
che possono essere imposte o pianificate. I passaggi più significativi per qualun-
que intervento sui processi di business sono quelli della diagnosi della situazione
attuale (assessment - as is) e della riprogettazione vera e propria (to be). La fase
di diagnosi dei processi mira ad evidenziare su quali componenti del processo e su
quali attività del processo si concentrano le attuali criticità ed in che cosa consisto-
no, nonché a stabilire delle misure capaci di quantificarle e pertanto utilizzabili per
definire obiettivi concreti di cambiamento osservabili, quantificabili e quindi ve-
rificabili. Queste indicazioni rappresentano pertanto dei “requisiti” per la succes-
siva fase di riprogettazione. La fase di riprogettazione vera e propria costituisce,
come è ovvio, un passaggio non completamente schematizzabile in attività prede-
finite, in cui l’utilizzo delle tecniche di analisi e la definizione di criteri di scelta
tra le diverse soluzioni possibili si coniuga con l’uso dell’esperienza e della crea-
tività. Non esistono pertanto ricette sempre valide per riprogettare i processi. Il
ridisegno del flusso del processo rappresenta certamente un aspetto fondamentale
dell’intervento. Ridisegnare il flusso del processo significa sostanzialmente:
40 Capitolo 1
• eliminare le attività che non aggiungono valore al prodotto/servizio (ad es. le

ridondanze e le attività di controllo inappropriate o inefficaci);
• razionalizzare le attività necessarie, cercando di eliminare i colli di bottiglia e
di rivedere l’organizzazione degli adempimenti che generano ritardi;
• rendere il processo più flessibile ed adattabile, concentrandosi, ove necessario,
sulla gestione delle “eccezioni” alla regola;
• prevenire la possibilità di errori e di ricicli, sia assicurando informazioni ade-
guate, sia coinvolgendo preventivamente l’utilizzatore finale del servizio;
• imparare dai casi di eccellenza (best practices), imitando soluzioni provate co-
me efficaci;
• inserire il controllo nelle normali attività;
• ridurre drasticamente l’utilizzo di documenti cartacei.
Queste ed altre direzioni di intervento possono essere sviluppate in maniera inte-

grata con lo sviluppo dei sistemi informatici e costituiscono certamente un aspetto
importante della reingegnerizzazione. Il ridisegno del flusso tuttavia non è il solo
campo di azione della reingegnerizzazione, in quanto occorre anche prendere in
considerazione la possibilità di modificare le caratteristiche del prodotto/servizio,
o affrontare il problema delle risorse umane coinvolte nel processo o questioni
logistiche. In sostanza riprogettare significa elaborare un insieme di proposte che
rispondano alla necessità di soddisfare i requisiti evidenziati dalla fase di diagno-
si: all’interno di tale insieme vi sarà probabilmente la revisione del flusso, ma si
potranno affrontare anche gli altri aspetti che generano criticità. Dal punto di vista
delle necessità di intervento sulle tecnologie dell’informazione, la riprogettazione
porterà alla esatta definizione di tutti i requisiti funzionali per il successivo inter-
vento realizzativo. É ovviamente possibile che emergano più soluzioni alternative,
diversi insiemi di interventi. Una delle attività della fase di riprogettazione sarà
pertanto quella di confrontare le varie soluzioni e di scegliere in base a criteri di
garanzia di raggiungimento degli obiettivi ed, ovviamente, di economicità (studio
di fattibilità). Si vuole sottolineare che si sta parlando qui di alternative in termi-
ni di programma complessivo di cambiamento e non di alternative tecnologiche.
Come per la modellazione, anche per le fasi di diagnosi e analisi sono disponibili
svariate tecniche. La scelta delle tecniche da impiegare concretamente sarà in-
fluenzata principalmente dagli obiettivi dell’intervento. E’ evidente, ad esempio.
che la tecnica di Activity Based Costing (che mira ad individuare e quantificare le
principali componenti di costo di un prodotto/servizio e a correlarle alle attività
componenti) oppure la tecnica del Critical Path Method (che mira a individuare il
cammino critico, in termini di tempo per il completamento del processo) saranno
importanti per interventi che tendono ad obiettivi di efficienza in termini di costi e
tempi. Analogamente le tecniche di Quality Function Deployment o di rilevazione
della Customer Satisfaction saranno particolarmente utili nella ricerca di una mi-
gliore qualità del servizio fornito all’utenza. Tecniche di Benchmarking potranno
essere utili in una pluralità di interventi.
1.6.2 Miglioramento e Reingegnerizzazione

L’intervento sui processi ruota intorno a due paradigmi: il miglioramento incre-
mentale o continuo e la reingegnerizzazione, ossia il cambiamento radicale.
Il miglioramento continuo e la “qualità totale” L’approccio Total Qua-

lity Management (TQM - noto in italiano, impropriamente, come Qualità Totale)
è la sintesi di una serie di riflessioni sulla qualità dei prodotti/servizi e sulle for-
me organizzative adatte ad ottenerla, sviluppatesi negli ultimi decenni prima negli
Stati Uniti, poi in Giappone, ed a livello internazionale. L’approccio TQM è ca-
ratterizzato dalla “continuità”, per cui il miglioramento deriva da un ininterrotto
ripetersi di momenti organizzati di verifica e cambiamento, che coinvolgono tut-
ta l’organizzazione (e, in certi casi, anche attori esterni quali, ad. es. clienti e
fornitori). Altre ipotesi di fondo, su cui si base il TQM, sono:
• l’obiettivo di servire i clienti fornendo loro beni e servizi della più elevata
qualità possibile, la cui misura è la soddisfazione dei clienti serviti;
• l’importanza data alla combinazione fra innovazione e continui e graduali mi-
glioramenti ai prodotti ed ai processi, introdotti dal personale di tutti i livelli
(idea nota con il termine giapponese kaizen, ovvero miglioramento continuo);
• la capacità dell’organizzazione di autocoordinarsi su base volontaria, con un
controllo orientato più al processo che al suo risultato;
• un’ampia e tempestiva diffusione delle informazioni, necessaria al coordina-
mento orizzontale che può sostituire, il coordinamento gerarchico;
• il cambiamento culturale, con formazione continua, comunicazione, mobilità
interna;
• l’integrazione con clienti e fornitori, trasformandoli in partner del proprio pro-
cesso e in partecipanti nel proprio flusso informativo.
Basandosi su questi principi, sono state sviluppate svariate metodologie per l’a-
nalisi e la diagnosi dei processi. Si tratta in genere di metodologie che, sempre
mettendo al centro della valutazione il concetto di processo di servizio, si basano:
• su misurazioni del processo e dei suoi risultati in termini di conformità agli stan-
dard, adeguatezza allo scopo (efficacia), tempi e costi del processo (efficienza);
• sulla rilevazione delle esigenze e delle indicazioni dei vari attori del proces-
so, esigenze poi espresse in termini quantitativi attraverso metriche adeguate e
valutate, dal punto di vista della priorità, sulla base dei fattori critici di successo;
• sulla relazione tra gli specifici processi osservati e aspetti generali e sistemici
dell’organizzazione (cultura, strategie, gestione delle risorse).
Queste metodologie individuano problemi, cause, aree e direzioni di intervento,
passaggi necessari nei progetti di cambiamento. Implicano l’uso di numerose
tecniche, che vengono continuamente aggiornate ed arricchite, tra le quali : tec-
niche di rilevazione e di controllo della qualità dei processi/prodotti. tecniche di
diagnosi e prevenzione degli errori, tecniche di progettazione dei processi e dei
prodotti per la qualità, tecniche di rilevazione della soddisfazione del cliente. Una
42 Capitolo 1
delle tecniche più importanti per affrontare i problemi sopra identificati è il Qua-
lity Function Deployment (QFD), nata in Giappone verso la fine degli anni 70,
in ambito manifatturiero, come risultato di studi e ricerche nell’ambito dell’as-
sicurazione di qualità e di value engineering. QFD è un termine che traduce i
seguenti caratteri giapponesi: Hin Shitsu (qualità, caratteristiche, attributi, pro-
prietà), Ki No (funzione, meccanizzazione), Ten Kai (dispiegamento, diffusione,
sviluppo, evoluzione). Esso consiste in un sistema di interpretazione e di trasposi-
zione delle esigenze del cliente in requisiti e caratteristiche del prodotto/servizio
fornito ed in modalità operative per ottenerle. In sostanza la metodologia, dopo
l’identificazione dei clienti di riferimento e degli obiettivi aziendali, mira:
• a identificare con precisione le aspettative dei clienti, sia dettagliandole progres-
sivamente, sia esprimendole con indici numerici, riferiti a variabili misurabili;
• a individuare le caratteristiche del prodotto/servizio atte a rispondere alle esi-
genze individuate, mettendole in relazione con le esigenze secondo una scala di
priorità;
• a individuare le modalità operative (i processi) di produzione più adatti a rea-
lizzare le caratteristiche esaminate, anch’esse con una relazione che esprime le
priorità.
La tecnica si basa sulle matrici di relazione, matrici che nel caso del QFD sono
spesso chiamate casa della qualità ed che incrociano richieste del cliente e carat-
teristiche del prodotto (vedi Figura 1.32). Le matrici si possono arricchire di altri
Figura 1.32 QFD: matrici di relazione
elementi (valutazione del cliente, strategia aziendale, correlazioni tra esigenze e

correlazioni tra caratteristiche, ecc.) e possono essere specializzate sugli specifici

contesti, in primo luogo tra produzione industriale ed erogazione di servizi. Una
diffusa modalità di applicazione del QFD prevede quattro passaggi successivi che
fanno riferimento alle quattro fasi classiche del ciclo di sviluppo di un prodot-
to/servizio: pianificazione del prodotto, sviluppo del progetto, pianificazione dei
processi, pianificazione della produzione. In ognuna delle fasi, attraverso l’utiliz-
zo della matrice, si passa da caratteristiche desiderate a soluzioni per ottenerle (da
“che cosa” a “come ”) e, in ogni passaggio, il precedente “come” diventa il nuovo
“che cosa”.
La reingegnerizzazione dei processi (Business Process Reenginee-

ring, BPR) Il concetto di Business Process Reengineering (BPR) nasce all’ini-
zio degli anni 90, principalmente per impulso di Michael Hammer che parte dalla
constatazione degli scarsi risultati raggiunti dalle organizzazioni che hanno appli-
cato le tecnologie dell’informazione lasciando invariati i loro processi di lavoro:
“...è tempo di smettere di pavimentare sentieri per le mucche. Invece di rivestire
di silicio e software i nostri processi obsoleti, dobbiamo dimenticarli e ripartire da
capo. Dobbiamo reingegnerizzare il nostro business: usare la forza delle moderne
tecnologie dell’informazione per ridisegnare i nostri processi per ottenere dram-
matici miglioramenti dei risultati”. Hammer individua alcuni principi generali che
debbono guidare la reingegnerizzazione dei processi:
• riorganizzarsi a partire dai prodotti/servizi forniti, non dalle attività;
• coinvolgere gli utilizzatori dei prodotti/servizi nei processi produttivi;
• inserire la gestione delle informazioni all’interno del lavoro reale che le genera;
• considerare le risorse geograficamente distribuite come se fossero centralizzate;
• collegare linee parallele di attività piuttosto che integrare i risultati;
• collocare i punti di decisione dove l’attività viene svolta e inserire il controllo
all’interno dei processi;
• acquisire le informazioni solo una volta, alla fonte.
Il BPR nasce pertanto come completo ripensamento e radicale ridisegno dei fon-
damentali processi di un’organizzazione, teso al raggiungimento di fortissimi mi-
glioramenti nei risultati. L’accento è quindi sulla discontinuità, sul “salto” in ter-
mini di prestazioni, sulla completa assenza di vincoli nella riprogettazione. Il Bu-
siness Process Reengineering, in senso proprio, è quindi un intervento che deve
rispondere a queste caratteristiche. Successivamente altri autori e altre esperienze
hanno mitigato questi concetti. Thomas H. Davenport suggerisce la necessità di
combinare l’approccio radicale con iniziative e metodi miranti al miglioramento
continuo delle prestazioni. Davenport si concentra sull’utilizzo delle tecnologie
come “fattore abilitante”, integra l’intervento tecnologico con il cambiamento or-
ganizzativo, enfatizza la necessità di gestire correttamente i progetti di cambia-
mento allo scopo di minimizzarne i rischi, consiglia il coinvolgimento dei clienti
all’interno dei gruppi di lavoro per la reingegnerizzazione. In generale Davenport
propone un approccio più strutturato e controllato che alterna momenti di reinge-
gnerizzazione radicale con fasi di controllo e miglioramento continuo. H. James
44 Capitolo 1
Harrington utilizza la dizione di “ridisegno” dei processi (Business Process Rede-

sign) per sottolineare il proprio orientamento verso la soddisfazione delle esigenze
di organizzazioni che mirano ad un più contenuto (e meno rischioso) cambiamen-
to. Harrington propone dieci requisiti necessari all’ottenimento dei risultati: l’or-
ganizzazione deve credere nell’importanza del cambiamento; ci deve essere una
visione che tratteggia il desiderato stato futuro dell’organizzazione; gli ostacoli
al cambiamento debbono essere individuati e rimossi; l’intera organizzazione de-
ve essere coinvolta e operare per il cambiamento; i dirigenti dell’organizzazione
debbono modellare i processi e fornire l’esempio; occorre formazione e addestra-
mento per costruire le nuove professionalità; debbono essere individuate metriche
per la quantificazione dei risultati e definito un sistema di misurazioni; occorre
verificare sempre i feedback; occorre prevenire con corrette indicazioni i compor-
tamenti indesiderati; debbono essere impiantati un sistema di valutazione e mec-
canismi premianti. Daniel Morris e Joel Brandon sostengono che le metodologie
di reingegnerizzazione sono soltanto degli strumenti che debbono essere usati in
un più ampio contesto di cambiamento organizzativo. Individuano tre compo-
nenti fondamentali del cambiamento ossia il posizionamento (la definizione di
uno scenario di riferimento e di una visione di medio-lungo periodo), i tradizio-
nali metodi di gestione dei progetti (che realizzano il cambiamento), le tecniche
di reingegnerizzazione (che forniscono i mezzi per il cambiamento). Morris e
Brandon identificano sette fattori critici di successo: l’utilizzo di una metodologia
generale e sistematica; la gestione coordinata del cambiamento in tutte le unità or-
ganizzative coinvolte nel/i processo/i su cui si interviene; il ciclico susseguirsi di
fasi di valutazione, pianificazione, realizzazione; la capacità di analizzare l’impat-
to del cambiamento; la modellazione e la simulazione dei cambiamenti previsti;
la continuità dell’intervento; l’integrazione di tutti i parametri per la valutazio-
ne dei risultati dell’organizzazione. Sotto il nome BPR si trovano oggi ipotesi e
approcci anche considerevolmente diversi tra loro, che si differenziano principal-
mente per ampiezza dell’area di intervento, per radicalità del cambiamento e per
diversa accentuazione degli obiettivi di efficacia o efficienza. Il governo federale
degli Stati Uniti ha diffuso uno schema di riferimento che cerca di sintetizzare le
caratteristiche principali dei vari approcci alla revisione dei processi. Si riporta
in Figura 1.33 di seguito la matrice proposta. Tra le caratteristiche essenziali del
BPR si annoverano pertanto la riprogettazione radicale, l’obiettivo della disconti-
nuità delle prestazioni, l’utilizzo delle tecnologie dell’informazione, integrate con
gli interventi organizzativi. La caratteristica principale della reingegnerizzazione
consiste nel guardare ai processi come se si trattasse di ripensarli ex novo, senza
essere condizionati da come si svolgono attualmente, ma immaginando soluzio-
ni alternative anche radicali, cioè molto lontane dalla situazione vigente. Alcuni
esempi tipici di principi di riprogettazione radicale sono i seguenti:
• Mettere le attività in parallelo anziché in sequenza: spesso la sequenza del-

le attività non è dettata da un ordine “naturale”, ma è imposta artificialmente,
secondo modelli di organizzazione del lavoro tradizionali. La reingegnerizza-
zione si chiede sempre se non sia possibile modificare la sequenza delle attività,
fino ad eliminarla, mettendo le attività in parallelo. In questo modo si posso-
Figura 1.33 Caratteriche della revisione dei processi
no raggiungere forti miglioramenti del tempo totale “di attraversamento” del

processo, perché si eliminano i tempi morti di attesa.
• Ricomposizione di attività frammentate: spesso attività leggermente diverse so-
no assegnate a persone o uffici diversi, nell’idea che la specializzazione spinta
delle mansioni migliori l’efficienza della singola attività; in effetti, l’efficien-
za globale del processo peggiora, per effetto dei tempi di coordinamento. La
reingegnerizzazione dei processi tende a ricomporre attività frammentate, in-
troducendo nuove mansioni, a cui spesso viene dato il nome di case manager,
cioè “gestore del caso”, perché nella nuova mansione sono raccolte tutte le at-
tività che servono a dare una risposta esauriente, tempestiva e personalizzata al
singolo caso, cioè alla singola richiesta del cliente;
• Categorizzazione e differenziazione dei flussi nei processi: spesso accade che
vengano trattati allo stesso modo (con le stesse regole, gli stessi tempi, la stes-
sa qualità) richieste o casi diversi, solo perché incanalati nello stesso processo.
Questo effetto di “appiattimento” viene superato nella reingegnerizzazione che
non tende - come tradizionalmente si tende a fare - a separare i processi in
presenza di richieste diverse, ma a differenziare le richieste e a trattarle come
versioni diverse nell’ambito dello stesso processo. L’applicazione di questo
principio di reingegnerizzazione richiede in genere l’identificazione all’ingres-
so del tipo di richiesta, e la “tracciatura” del caso - cioè, le informazioni sul
singolo caso seguono continuamente il caso lungo tutto il processo.
• Eliminazione di attività che non danno valore: la reingegnerizzazione si po-
ne sempre il problema del perché viene svolta un’attività: se un’attività viene
svolta per es. per correggere varianze insorte lungo il processo (es. controlli
di qualità), la reingegnerizzazione tende a eliminare questo tipo di attività e a
46 Capitolo 1
concentrare i controlli là dove si formano le varianze (per es. all’ingresso).

Per quanto riguarda la discontinuità nelle prestazioni, la reingegnerizzazione ha lo
scopo di cambiare radicalmente i processi, partendo dalla premessa che i processi
attuali siano in genere altamente inefficienti o inefficaci. La radicalità si ottiene
esaminando le precondizioni e le ipotesi su cui si basa il modo di funzionare dei
processi di un’organizzazione e intervenendo su queste fondamenta. Se riesce
a incidere sulle regole di base che condizionano il funzionamento dei processi,
la reingegnerizzazione può raggiungere miglioramenti discontinui dell’ordine del
50-60% e più nelle componenti della prestazione complessiva di processo (costi,
tempi, qualità). La caratteristica di puntare a obiettivi radicali di discontinuità nei
livelli di prestazione ha alcune conseguenze:
• in primo luogo, il BPR non può limitarsi all’analisi dei flussi operativi dei pro-
cessi, ma deve mettere in discussione numerosi aspetti organizzativi che inci-
dono sul funzionamento dei processi, come le strutture organizzative (suddivi-
sione delle responsabilità), le competenze e le capacità del personale, i sistemi
tecnologici e informatici, i valori e la cultura organizzativa;
• di conseguenza, il BPR è quindi un’attività complessa e piena di rischi, che
ha come condizione essenziale una forte leadership istituzionale e politica e
una grande attenzione ai problemi di gestione del cambiamento (change mana-
gement), che non devono essere posposti al termine della riprogettazione, ma
affrontati fin dall’inizio.
Proprio per queste difficoltà si sono andati evolvendo nel tempo approcci integra-
ti di innovazione dei processi che cercano di combinare la reingegnerizzazione
radicale con il miglioramento incrementale. In effetti, il BPR non deve essere
visto come un’attività isolata svolta una tantum, quanto piuttosto inserita in pro-
cessi di miglioramento diffusi che rendano sostenibile nel tempo il cambiamento
introdotto in maniera radicale con il BPR. In relazione all’utilizzo di tecnologie in-
formatiche integrate con l’organizzazione, è evidente che il tipo di riprogettazione
radicale messo in evidenza è dovuto, oltre che alla riprogettazione organizzativa
(parallelismi invece di sequenzialità, ricomposizione di mansioni, eliminazione
di attività inutili, ecc.) all’introduzione di tecnologie ICT che rendono possibi-
le superare le ragioni che in passato avevano condotto a mettere in sequenza le
attività, a separare le mansioni, a introdurre attività di controllo, ecc. In genere,
l’intervento complessivo sul processo è realizzato grazie a tecnologie che sono
in grado di rendere condivise informazioni che tradizionalmente erano appannag-
gio esclusivo di una sola unità organizzativa. Questa caratteristica di trasversalità
organizzativa è un aspetto ineliminabile del BPR.
Indice analitico
Balanced Score Card (BSC), 14 Organizzativo, 2

Business Intelligence (BI), 13 Workflow, 23, 25
Business Process Execution Language
(BPEL), 38 Quality Function Deployment (QFD), 42
Business Process Management (BPM),
2, 22 Total Quality Management (TQM), 41
Business Process Management Notation
Workflow Management System (WfMS),
(BPMN), 32
25, 28
Business Process Management Systems
(BPMS), 23, 28
Business Process Map, 9, 17
Modello SCOR, 18
Processi di supporto, 9
Processi manageriali, 11
Processi primari, 16
Schemi di settore, 17
Business Process Reengineering (BPR),
43
Griglia di Scott-Morton, 15
Key Performance Indicators (KPI), 14
Linear Responsibility Charting, 8
Organigramma, 8
Macrostruttura, 8
Microstruttura, 8
Paradigma CRASO, 6
Piramide di Anthony, 12
Processo di business, 1
Componenti, 24
Funzionale, 3
Implementato, 3
Interfunzionale, 4
Interorganizzativo, 4
Operativo, 2
47

Processi Aziendali

Caricato da

Copyright:

Formati disponibili

Processi Aziendali

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Processi Aziendali

Caricato da

Copyright:

Formati disponibili

Prof.

Dispense del corso di

1 I processi aziendali nei sistemi informativi 1

Alcuni contenuti relativi a Pianificazione, Assesment, Fattibilità, Reingegneriz-

Si ricorda infine che le seguenti dispense hanno finalità puramente didattiche.

1.1 Introduzione: la gestione dei processi di busi-

business di un’agenzia assicurativa nella quale un cliente richiede di stipulare un

1.2 La classificazione dei processi di business

Figura 1.1 Classificazione dei processi di business

1.3 L’architettura dei processi di business

• Processo – a tale livello vengono individuate le attività base di un processo

1.3.1 Il paradigma CRASO

1.3.2 Modellazione dei processi

Figura 1.2 Modello CRASO per un processo di business

relazioni tra le attività sono in questo caso o scomposizioni (part of ) o specializ-

Figura 1.3 Schemi CRASO per differenti tipi di processi di business

di scelta, l’input/output e le organizzazioni (swim pools). Esso può essere con-

1.3.3 Modellazione della struttura organizzativa

Figura 1.4 Modellazione gerarchica per il processo di acqusiti

1.3.4 La mappa dei processi aziendali

Processi di supporto La Figura 1.9 descrive la mappa dei processi di busi-

Figura 1.5 Diagramma di flusso per il processo di acqusiti

• Pianificazione - Determina il fabbisogno di addetti confrontando l’evoluzio-

Figura 1.6 Macrostruttura organizzativa

Processi manageriali Tutti i processi decisionali si fondano invece sul ciclo

Figura 1.7 Microstruttura organizzativa

Figura 1.8 Esempio di LRC

Figura 1.9 Mappa dei processi di supporto

Figura 1.10 Ciclo di controllo dei processi dei processi decisionali

prodotti introdurre e in quali mercati entrare) (attività strategiche).

In particolare, la pianificazione strategica viene eseguita “ogni qualvolta serve”

Il processo strategico è il processo manageriale più strutturato grazie alle ricerche

Figura 1.12 Schema della Balanced Scorecard

autoveicoli - che rappresentano il front-end di complessi software specializzati

• Una decisione è destrutturata se è presa in base a cognizioni o emozioni sog-

Figura 1.13 Schema della griglia di Gorry e Scott-Morton

Chiaramente maggiore è il grado di strutturazione di un processo e delle infor-

Figura 1.14 Classficazione dei processi primari

(Outbound Logistics). Un potenziale modulo ES è quindi la Pianificazione (livel-

Business Process Map Le Business process map sono cataloghi struttura-

1.3.5 Schemi di settore

Figura 1.15 Moduli ES per processi primari

• nella Pubblica Amministrazione i governi dell’Unione Europea hanno suggerito

Il modello SCOR Prima di illustrare la struttura dello SCOR conviene definire

La Figura mostra un esempio della catena di distribuzione per le industrie automo-

• Plan: sviluppa le linee di azione volte all’acquisizione del risorse necessarie;

• Source: riguarda negoziazione, approvvigionamento, ricevimento di materiali,

Figura 1.18 Modello ARIS

Lo schema SCOR, prevede anche si descrivere le proprietà di ciascun process

• Una descrizione testuale del process element;

Figura 1.19 Esempio di supply chain

1.4 Il Business Process Management (BPM)

Figura 1.20 Livelli SCOR

ment è una disciplina gestionale che utilizza un approccio sistematico e strut-

Attualmente, il BPM utilizza appositi sistemi software (Business Process Ma-

(WfMC)1 e può essere espresso come segue:

1.4.2 Le componenti di un processo di business

Modello di processo I componenti fondamentali di un workflow sono:

Figura 1.21 Componenti di un workflow