Appunti di Economia dei sistemi industriali

Process redesign

Process redesign: Una volta identificati i problemi mediante la fase di analisi, si propone una riprogettazione del processo in modo tale, per esempio, da eliminare i colli di bottiglia. Il processo passa da una fase “As-Is” ad una fase “To Be”, ossia passo da una modellazione descrittiva della realtà ad un modello prescrittivo, ossia propongo come dovrebbe essere il processo.

Process implementation

Process implementation: Una volta fatta la riprogettazione, i cambiamenti devono essere implementati 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

Process management system: Si ha l’obiettivo principale di coordinare attività eseguite all’interno dei processi. Vengono utilizzati software chiamati PMSs, ossia software generici che guidati dai modelli cercano di coordinare i processi, fungono da “schedulatori”. Prende un modello di processo e capisce come assegnare i vari task ai partecipanti.

Process monitoring

Process monitoring: Vado a controllare il mio processo in esecuzione per verificare se questo viene eseguito in maniera complessiva e adeguata. Vengono collezionati dati dalle istanze in esecuzione che mi permettono di capire se devono ancora apportare delle modifiche, per farlo posso sfruttare attività 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 dettaglio il processo. Questo è il BPMN utile sia per la modellazione concettuale sia per i modelli eseguibili.

Abbiamo principalmente quattro aspetti:

• Vocabolario: elementi di modellazione che il linguaggio mi offre, ossia i costrutti del linguaggio.
• Sintassi: insieme di regole che mi dicono come gli elementi vengono combinati.
• Semantica: dà un significato alle frasi che scriviamo nel linguaggio.
• Notazione: insieme di simboli grafici che mi permettono di avere una rappresentazione grafica del vocabolario.

Elementi base BPMN

Attività: cattura un lavoro che è eseguito nel processo ed ha durata. [Rettangolo]

Eventi: avvengono istantaneamente quindi non hanno durata. Distinti in eventi inizianti ed eventi 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 attività, eventi e gateway.

Il modo in cui questi quattro elementi possono essere utilizzati è attraverso una alternanza dei primi tre elementi con l’utilizzo del flusso di controllo. Ogni processo deve necessariamente avere almeno un evento iniziante e almeno un evento finale. Tutte le istanze del problema sono indipendenti tra di loro.

Tokens

Il token definisce il progresso della mia istanza, è un oggetto astratto usato per creare una simulazione descrittiva del comportamento del processo. Il token viene creato nello “start event”, attraversa il processo mediante il flusso e viene distrutto nell’evento finale. Il token si porta dietro quella che è la storia dell’istanza e tutte le relative informazioni. Il token come detto viene generato solo negli start event e passa immediatamente alla prima attività, poiché gli eventi 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’attività, l’abilita e rimane al suo interno per tutta la durata, questo perché l’attività al contrario degli eventi ha una durata.

Gateways

I gateways sono un meccanismo attraverso il quale si decide quali strade un token deve prendere, la cui funzione è quindi quella di instradamento, anche chiamato routing, dei token. In un gateway i token o si fondano oppure si “gemmano, splittano, dividono” in più token. Esistono dunque due gateways:

• Split gateways: punti dove il flusso del processo diverge, ossia i token vengono “splittati”, una freccia in ingresso e molteplici in uscita.
• Join gateways: punti dove il flusso del processo converge, ossia i token vengono fusi, molteplici frecce in entrata, un’unica uscita.

Entrando nel dettaglio dei gateways abbiamo:

Exclusive gateways (XOR)

È un punto in cui il flusso di controllo prende uno o più path alternativi, 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 piuttosto 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 detto, quando arrivo in un gateway split devo valutare quale path seguire. Posso stabilire una condizione di default attraverso la quale se nessuna condizione viene verificata il token sceglierà quella di default. La condizione di default è quindi un meccanismo automatico di fuga nel caso in cui tutte 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 attività 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 uscenti dal parallel split. Quando il token arriva al parallel gateway non viene valutata nessuna condizione ma il token si splitta, si gemma, e questi vanno ad attivare tutte le relative attività 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 utilizziamo il parallel gateway join, punto di sincronizzazione. Questo si aspetterà in entrata un numero di token pari al numero di archi in entrata. Quando arriva il primo token al parallel-join questo non va avanti ma viene trattenuto nel gateway, successivamente arriva il secondo token, il parallel nota che il numero di token è pari al numero di archi entranti 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 permette di specificare una condizione ma non obbliga che una e una sola 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 tutti 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 avanti 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 entranti, come nel parallel.

È come se avessimo bisogno di una “palla di vetro” per sapere di quanti token in ingresso ha bisogno per fonderli e poi mandarli avanti nel flusso. Viene utilizzato in casi molto particolari e in casi in cui risulta essere facile capire quanti token vengono generati nell’OR-SPLIT.

Rework and repetition

Rework and repetition (rilavorazione e ripetizione). Andiamo a valutare ora strutture che non sono lineari, ossia le attività non sempre si svolgono una sola volta, ma è necessario attuare una ripetizione della stessa nel caso in cui qualcosa fallisce. Quindi possono esserci attività che vengono svolte più volte. Per farlo si utilizza lo XOR-GATEWAY in maniera particolare: ho in primis uno XOR-JOIN dal quale il flusso confluisce poi in una attività, terminata l’attività il flusso converge in uno XOR-SPLIT in cui una delle possibili diramazioni rientra nello XOR JOIN prima citato.

Quello descritto è un blocco di ripetizione, ossia una porzione del processo che viene ripetuta. In un ciclo di questo tipo è necessario che ci sia almeno un’attività di decisione in modo tale che alla successiva domanda possiamo andare avanti o eventualmente tornare indietro e ripetere il ciclo. Ciclo “do until”, ossia ripeto l’attività finché la domanda non viene verificata altrimenti torno indietro e ripeto il ciclo, quando invece la domanda è verificata si procede nell’altra diramazione dello XOR SPLIT e il blocco di ripetizione non viene svolto.

Data perspective

Data perspective (prospettiva dei dati). Si occupa di individuare i business object, ossia quali sono gli oggetti necessari al processo.

Esistono 2 tipi di oggetti:

• Oggetti fisici o digitali che riguardano documenti e trasferiscono informazione.
• Oggetti materiali, per esempio scatola Amazon che contiene il pacco.

Gli elementi principali sono:

• Gli oggetti vengono rappresentati con “data objects”, foglio con ripiegatura al lato, sono utilizzati per rappresentare dati, documenti in ingresso o uscita dalle attività, fattura, ricevuta. Questi 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 costrutto sono le associazioni utilizzate per collegare i data objects al data store da cui l’oggetto fluisce, entra oppure viene recuperato.
• Una collezione di oggetti, collezione di informazioni e data objects in maniera ordinata, lista della spesa. Termina una volta che l’istanza finisce.

Data DataObject Directed association Collezione.

I data objects possono avere uno stato che rappresentano come il documento, l’oggetto viene aggiornato durante il processo. Lo stato viene solitamente indicato sotto il nome del data objects tra parentesi quadre. Il “data flow” rappresenta come i dati si muovono in input/output da una attività. Il data flow nel BPMN è disaccoppiato dal sequence flow che rimane comunque colui che guida l’intero processo.

Tramite l’utilizzo 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 effetto sul flusso del token ma servono per chiarire meglio il processo.

Resource perspective e collaboration diagrams

La resource perspective è una attività particolare che si occupa di rappresentare chi sono gli autori del processo. Viene definita risorsa qualsiasi cosa implicata nell’esecuzione di una attività del processo.

• Risorse attive = autonome, in grado di eseguire autonomamente l’attività.
• Risorse passive = non godono di vita propria ma vengono manovrate da altre, per esempio: la fotocopiatrice è una risorsa passiva mentre l’utente è una risorsa attiva.

Nel BPM vengono rappresentate solo risorse attive, autonome e che godono di vita propria. Solitamente non è conveniente modellare le risorse separatamente, ma andiamo per esempio a modellare le “classi” delle risorse classificate attraverso un fattore di classificazione, ossia attraverso, per esempio, caratteristiche comuni. Una classe di risorse comprende un gruppo di risorse attive 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 struttura dell’organizzazione, come, per esempio, la divisione dei reparti organizzativi.

Nel BPMN le classi di risorse vengono rappresentate utilizzando una “POOL”, queste rappresentano delle unità organizzative indipendenti, ossia non condividono nessun sistema che gli permetterebbe di comunicare implicitamente. Quindi devono comunicare in maniera esplicita attraverso l’utilizzo di messaggi. All’interno di una singola pool possono esserci sottoclassi di risorse. Quindi possiamo avere delle “LANE”, corsie di nuoto all’interno della pool, che rappresentano i ruoli e le risorse organizzative interne.

Multiple business parties e message

Nei processi ci sono più soggetti organizzativamente indipendenti che quindi comunicano tramite scambio di messaggi e perciò bisogna in qualche modo rappresentarli. Le business party indipendenti le rappresentiamo attraverso l’utilizzo di “pools”, all’interno delle singole “pool” mettiamo eventi, attività, gateway che modellano la specifica porzione del business process.

Per modellare le interazioni tra le varie pool di due organizzazioni che collaborano utilizzo i messaggi. Non possiamo però, per farlo, utilizzare il sequence flow ma andiamo a rappresentare il flusso dei messaggi, ossia il flusso di informazioni tra due classi, pool, separate.

Per farlo utilizziamo una freccia tratteggiata bianca con un pallino. Il pallino indica il mittente del messaggio, la freccia bianca indica il destinatario del messaggio. Il flusso di messaggio può essere anche utilizzato per rappresentare lo scambio di materiale tra organizzazioni, delivery del prodotto fisico.

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

• Se il messaggio non è attaccato direttamente ad una attività ma ai bordi della pool significa che il messaggio parte da quel “party”, oppure analogamente arriva in quel “party”.
• Se attacco il messaggio direttamente ad una attività/evento dentro la pool, quella allora sarà l’attività/evento che invia/riceve il messaggio.

L’attività mittente invierà il messaggio quando l’attività sarà completata mentre l’attività destinataria 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