Appunti di Economia dei sistemi industriali

PROCESS REDESIGN: Una volta iden<fica< i problemi mediante la fase di analisi, si propone una

riproge*azione del processo in modo tale, per esempio, da eliminare i colli di boIglia. Il processo passa da

una fase “As-Is” ad una fase “To Be” ossia passo da una modellazione descriIva della realtà ad un modello

prescriIvo, ossia propongo come dovrebbe essere il processo.

PROCESS IMPLEMENTATION: Una volta fa*a la riproge*azione, i cambiamen< devono essere implementa<

nel sistema IT che supporta il processo in modo tale che lo stesso venga messo in esecuzione. Questa fase

implica una riconfigurazione del SI per supportare l’esecuzione dei processi.

PROCESS MANAGEMENT SYSTEM: Si ha l’obieIvo principale di coordinare aIvità eseguite all’interno dei

processi. Vengono u<lizza< soFware chiama< PMSs, ossia soFware generici che guida< dai modelli cercano

di coordinare i processi (fungono da “schedulatori”). Prende un modello di processo e capisce come

assegnare i vari task ai partecipan<.

PROCESS MONITORING: Vado a controllare il mio processo in esecuzione per verificare se questo viene

eseguito in maniera complessiva e adeguata. Vengono colleziona< da< dalle istanze in esecuzione che mi

perme*ono di capire se devono ancora apportare delle modifiche (per farlo posso sfru*are aIvità di

“process mining”).

5.BPMN: BUSINESS PROCESS MANAGEMENT NOTATION

Per modellare i processi ho ovviamente bisogno di un linguaggio. Affinché possa essere rimossa l’ambiguità

nella descrizione dei processi risulta essere fondamentale che il linguaggio riesca a specificare nel de*aglio

il processo. Questo è il BPMN u<le sia per la modellazione conce*uale sia per i modelli eseguibili.

Abbiamo principalmente qua*ro aspeI:

-Vocabolario: elemen< di modellazione che il linguaggio mi offre ossia i costruI del linguaggio.

-Sintassi: insieme di regole che mi dicono come gli elemen< vengono combina<

-Seman<ca: dà un significato alle frasi che scriviamo nel linguaggio

-Notazione: insieme di simboli grafici che mi perme*ono di avere una rappresentazione grafica del

vocabolario.

ELEMENTI BASE BPMN

Agvità: ca*ura un lavoro che è eseguito nel processo ed ha durata. [ReQangolo]

Even<: avvengono istantaneamente quindi non hanno durata. Dis<n< in even< inizian< ed even< finali.

[Cerchio]

Gateway: rappresentano nel flusso di controllo che il flusso appunto può diramarsi in rami paralleli

Oppure più rami vanno a congiungersi. [Rombo]

Sequence Flows: Flusso di controllo che rappresenta vincoli di precedenza tra aIvità, even< e gateway

Il modo in cui ques< qua*ro elemen< possono essere u<lizza< è a*raverso una alternanza dei primi tre

elemen< con l’u<lizzo del flusso di controllo. Ogni processo deve necessariamente avere almeno un evento

iniziante e almeno un evento finale. Tu*e le istanze del problema sono indipenden< tra di loro.

TOKENS

Il token definisce il progresso della mia istanza, è un ogge*o astra*o usato per creare una simulazione

descriIva del comportamento del processo. Il token viene creato nello “start event”, a*raversa il processo

mediante il flusso e viene distru*o nell’evento finale. Il token si porta dietro quella che è la storia

dell’istanza e tu*e le rela<ve informazioni. Il token come de*o viene generato solo negli start event e passa

immediatamente alla prima aIvità (poiché gli even< sono istantanei) terminata questa passa alla

successiva fino a che non arriva all’evento finale in cui viene consumato e si distrugge. Il token, arrivato

all’aIvità, l’abilita e rimane al suo interno per tu*a la durata (questo perché l’aIvità al contrario degli

even< ha una durata).

GATEWAYS

I gateways sono un meccanismo a*raverso il quale si decide quali strade un token deve prendere (la cui

funziona è quindi quella di instradamento, anche chiamato rou<ng, dei token. In un gateway i token o si

fondano oppure si “gemmano, spli*ano, dividono” in più token. Esistono dunque due gateways:

Split Gateways: pun< dove il flusso del processo diverge ossia i token vengono “spli*a<” (una freccia in

Ingresso e molteplici in uscita).

Join Gateways: pun< dove il flusso del processo converge ossia i token vengono fusi. (molteplici frecce in

Entrata, un'unica uscita).

Entrando nel de*aglio dei gateways abbiamo:

EXCLUSIVE GATEWAYS (XOR)

È un punto in cui il flusso di controllo prende uno o più path

alterna<vi (soltanto uno può essere preso). Rappresenta

dunque un punto di decisione dove esiste una condizione sulla

base della quale il token va su un determinato flusso di

controllo piu*osto che su un altro. (quindi una delle condizioni

deve essere necessariamente vera). Se il token raggiunge uno

xor-split vi è una immediata valutazione della condizione sul

gateway in modo tale da instradare il token, se invece dovesse

raggiungere uno xor-join non vi sarà nessuna valutazione della

condizione ma verrà immediatamente instradato nell’unica

uscita. Come de*o, quando arrivo in un gateway split devo

valutare quale path seguire. Posso stabilire una condizione di

default a*raverso la quale se nessuna condizione viene verificata il token sceglierà quella di default. La

condizione di default è quindi un meccanismo automa<co di fuga nel caso in cui tu*e le condizioni sono

false.

PARALLEL GATEWAYS(AND):

Indica una posizione all’interno di un processo dove il flusso di

controllo può prendere più cammini paralleli (parallelo significa

che le aIvità vengono svolte in maniera contemporanea).

Quando arrivo su un parallel split devo essere in grado di generare

un numero di token pari al numero di archi uscen< dal parallel

split. Quando il token arriva al parallel gateway non viene valutata

nessuna condizione ma il token si spli*a (si gemma) e ques<

vanno ad aIvare tu*e le rela<ve aIvità raggiungibili dal parallel

split. Una volta aver creato rami paralleli vi è la necessità di

sincronizzarli e ricongiungerli ad un unico flusso di controllo, per

farlo u<lizziamo il parallel gateway join (punto di

sincronizzazione). Questo si aspe*erà in entrata un numero di

token pari al numero di archi in entrata. Quando arriva il primo token al parallel-join questo non va avan<

ma viene tra*enuto nel gateway, successivamente arriva il secondo token, il parallel nota che il numero di

token è pari al numero di archi entran< e quindi vengono fusi in un unico token che può dunque avanzare

nel flusso.

INCLUSIVE GATEWAYS(OR):

è un meccanismo di decisione in cui più di una uscita è possibile

in un punto di decisione, ci perme*e di specificare una

condizione ma non obbliga che una e una solo delle condizioni

venga verificata ma possono verificarsi più condizioni

contemporaneamente. Contrariamente a quanto accade nello

XOR il token per poter prendere più strade deve gemmarsi per

tuI quei rami che soddisfano la condizione. Quindi l’OR-SPLIT

prende in ingresso un token e genera dinamicamente in base

alle condizioni un numero di token pari al numero di condizioni

vere, vi è inoltre un vincolo che almeno una condizione deve

essere vera.

Questo è un elemento pericoloso: nel caso dell’OR-JOIN per

andare avan< dobbiamo sapere quante condizioni erano vere

nell’OR-SPLIT perché ovviamente nell’OR JOIN non abbiamo un numero di token “fissi” in ingresso oppure

un numero di token pari al numero di archi entran< (come nel parallel).

È come se avessimo bisogno di una “palla di vetro” per sapere di quan< token in ingresso ha bisogno per

fonderli e poi mandarli avan< nel flusso. Viene u<lizzato in casi molto par<colari e in casi in cui risulta

essere facile capire quan< token vengono genera< nell’OR-SPLIT.

REWORK AND REPETITION

(RILAVORAZIONE E RIPETIZIONE). Andiamo a valutare ora stru*ure che non sono lineari, ossia le aIvità non sempre si

svolgono una sola volta, ma è necessario a*uare una ripe<zione della stessa nel caso in cui qualcosa fallisce. Quindi

possono esserci aIvità che vengono svolte più volte. Per farlo si u<lizza lo XOR-GATEWAY in maniera par<colare:

Ho in primis uno XOR-JOIN dal quale il flusso confluisce poi in una aIvità, terminata l’aIvità il flusso converge in uno

XOR-SPLIT in cui una delle possibili diramazioni rientra nello XOR JOIN prima citato.

Quello descri*o è un blocco di ripe<zione, ossia una porzione del processo che viene ripetuta. In un ciclo di questo

<po è necessario che ci sia almeno un’aIvità di decisione in modo tale che alla successiva domanda possiamo andare

avan< o eventualmente tornare indietro e ripetere il ciclo. (Ciclo “do un<l” ossia ripeto l’aIvità finché la domanda non

viene verificata altrimen< torno indietro e ripeto il ciclo, quando invece la domanda è verificata si procede nell’altra

diramazione dello XOR SPLIT e il blocco di ripe<zione non viene svolto).

DATA PERSPECTIVE (PROSPETTIVA DEI DATI)

Si occupa di individuare i business object, ossia quali sono gli oggeI necessari al processo.

Esistono 2 <pi di oggeI:

!OggeI fisici o digitali che riguardano documen< e trasferiscono informazione

!OggeI materiali (per esempio scatola amazon che con<ene il pacco)

Gli elemen< principali sono:

-Gli oggeI vengono rappresenta< con “data objects” (foglio con ripiegatura al lato) sono u<lizza< per

rappresentare da<, documen< in ingresso o uscita dalle aIvità (fa*ura, ricevuta…). Ques< non persistono

oltre al ciclo di vita dell’istanza del processo.

-Poi abbiamo i data stores che sono i “contenitori” dei data objects che persistono oltre al ciclo di vita

dell’istanza del processo (archivi per esempio).

-Un altro costru*o sono le associazioni u<lizzate per collegare i data objects al data store da cui l’ogge*o

fluisce (entra oppure viene recuperato)

-Una collezione di oggeI, collezione di informazioni e data objects in maniera ordinata (lista della spesa).

Termina una volta che l’istanza finisce

Data

Data

Object Directed association Collezione

I data objects possono avere uno stato che rappresentano come il documento, l’ogge*o viene aggiornato

durante il processo. Lo stato viene solitamente indicato so*o il nome del data objects tra parentesi quadre.

Il “data flow” rappresenta come i da< si muovono in input/output da una aIvità. Il data flow nel BPMN è

disaccoppiato dal sequence flow che rimane comunque colui che guida l’intero processo.

Tramite l’u<lizzo di annotazioni testuali (TEXT ANNOTATIONS) possiamo aggiungere maggiori informazioni

al modello in modo tale da comprenderlo al meglio evitando ambiguità. Le annotazioni testuali non hanno

effe*o sul flusso del token ma servono per chiarire meglio il processo.

RESOURCE PERSPECTIVE E COLLABORATION DIAGRAMS

La resource perspec<ve è una aIvità par<colare che si occupa di rappresentare chi sono gli autori del

processo. Viene definita risorsa qualsiasi cosa implicata nell’esecuzione di una aIvità del processo.

!Risorse aIve=autonome, in grado di eseguire autonomamente l’aIvità

!Risorse passive= non godono di vita propria ma vengono manovrate da altre

(per esempio: la fotocopiatrice è una risorsa passiva mentre l’utente è una risorsa aIva).

Nel BPM vengono rappresentate solo risorse aIve, autonome e che godono di vita propria. Solitamente

non è conveniente modella le risorse separatamente, ma andiamo per esempio a modellare le “classi” delle

risorse classificate a*raverso un fa*ore di classificazione (ossia a*raverso, per esempio, cara*eris<che

comuni). Una classe di risorse comprende un gruppo di risorse aIve potenzialmente intercambiabili.

Una classe di risorse potenzialmente può rappresentare:

-ruolo: criterio per cui determino la classe è la competenza, skill, qualifica… ossia in base a cosa quella

risorsa sa fare

-gruppo: criterio di classificazione basato sulla stru*ura dell’organizzazione (come, per esempio, la divisione

dei repar< organizza<vi)

Nel BPMN le classi di risorse vengono rappresentate u<lizzando una “POOL”, queste rappresentano delle

unità organizza<ve indipenden<, ossia non condividono nessun sistema che gli perme*erebbe di

comunicare implicitamente. Quindi devono comunicare in maniera esplicita a*raverso l’u<lizzo di messaggi.

All’interno di una singola pool possono esserci so*oclassi di risorse. Quindi possiamo avere delle “LANE”

(corsie di nuoto all’interno della pool) che rappresentano i ruoli e le risorse organizza<ve interne.

MULTIPLE BUSINESS PARTIES + MESSAGE

Nei processi ci sono più soggeI organizza<vamente indipenden< che quindi comunicano tramite scambio

di messaggi e perciò bisogna in qualche modo rappresentarli. Le business party indipenden< le

rappresen<amo a*raverso l’u<lizzo di “pools”, all’interno delle singole “pool” meIamo even<, aIvità,

gateway che modellano la specifica porzione del business process.

Per modellare le interazioni tra le varie pool di due organizzazioni che collaborano u<lizzo i messaggi. Non

possiamo però, per farlo, u<lizzare il sequence flow ma andiamo a rappresentare il flusso dei messaggi

ossia il flusso di informazioni tra due classi (pool) separate.

Per farlo u<lizziamo una freccia tra*eggiata bianca con un pallino. Il pallino indica il mi*ente del messaggio,

la freccia bianca indica il des<natario del messaggio. Il flusso di messaggio può essere anche u<lizzato per

rappresentare lo scambio di materiale tra organizzazioni (delivery del prodo*o fisico).

Ovviamente deve esserci una aIvità che manda il messaggio e una che lo riceve.

-Se il messaggio non è a*accato dire*amente ad una aIvità ma ai bordi della pool significa che il

messaggio parte da quel “party” (oppure analogamente arriva in quel “party”)

-se a*acco il messaggio dire*amente ad una aIvità/evento dentro la pool, quella allora sala l’aIvità/

evento che invia/riceve il messaggio.

L’aIvità mi*ente invierà il messaggio quando l’aIvità sarà completata mentre l’aIvità des<nataria non

inizierà il suo “lavoro” finché il messaggio non verrà ricevuto.

Possiamo quindi individuare un nuovo evento di inizio, lo START MESSAGE EVENT: Questo evento avvia un

determinato processo quando appunto viene ricevuto un messaggio che può

provenire o dal bordo di un altro processo (per esem