BPM Process Pattern: Incoming Process

L'Incoming Process è un pattern che interviene spesso nei processi dove è richiesta una interazione (collaboration) con il mondo esterno all'azienda.


Il suo utilizzo torna utile quando nella fase di modeling del processo ci troviamo ad affrontare il problema di dover processare un input esterno senza garanzie che questo possa essere realmente utile al nostro core process. Lo spunto per lo sketch mi viene dal blog di Anatoly Belychook, e ne riprendo il caso da lui studiato: la classica "Emissione di Carte di Credito". Rappresentiamolo inizialmente in modo semplificato:

PER I DIAGRAMMI STAVOLTA HO VOLUTO UTILIZZARE INNOVATOR FOR BUSINNES ANALYSTS DI APTERO SOLUTION NELLA PERSONAL EDITION.
INTERESSANTE L'ANIMATION DEL FLOW TRAMITE TOKEN CON LA POSSIBILITÀ DI CREARE PIÙ PATH.

Spieghiamolo un attimo: quando giunge una richiesta di emissione per una nuova carta di credito, tale domanda viene elaborata e se l'emissione viene apprata allora se ne produce una. Il richiedente ha 45gg per presentarsi allo sportello della filiale per ritirarla, altrimenti la carta verrà annullata.

A questo punto proviamo a pensare cosa può creare dei problemi al nostro modello.

Senza dubbio un primo ostacolo possono essere i volumi. Supponiamo che in media i clienti aspettino una decina di giorni e che alla filiale giungano 50 richieste al giorno: il decimo giorno dall'avvio del processo in produzione il nostro impiegato si troverà ad avere in coda 500 carte dove cercare quella da emettere. Un classico problema di stock e di capacità d'emissione per il povero impiegato.

Altro problema, non meno serio riguarda il fatto che l'impiegato non ha la possibilità di eseguire autonomamente il task, ma deve essere il cliente ad arrivare in filiale, il tutto sotto la supervisione dell'impiegato.

Ecco allora che ci vengono inizialmente in aiuto le collaboration e i messaggi (per semplicità consideriamo collassato il pool del cliente):

Non abbiamo però risolto un problema intrinseco ai messaggi in arrivo: il nostro desiderio sarebbe che tra l'utente e l'impiegato si parlasse la stessa lingua, cioè l'utente dicesse tramite ID quale carta ha richiesto. Ovviamente non è concepibile che ciò avvenga, anche perchèl'ID è un concetto puramente legato al nostro DBMS.
Per ovviare a tale serio inconveniente allora ci appelliamo all'Incoming Process Pattern, automatizzando questa fase di associazione cliente-id-carta:

In realtà qui non stiamo considerando molte cose lasciando il tutto solo un esempio (sul suo blog molti si sono lamentati non capendo che lui ha focalizzato l'attenzione sull'Incoming Process più che sulla possibilità di una delivery into production). Ad esempio il caso di un cliente che arriva troppo presto: infatti se così fosse l'impiegato non trova l'ID della carta e manda via il cliente, la carta viene comunque prodotta e passati 45gg verrà cancellata. in questa sede però non ci interessa questo ma solo evidenziare come un messaggio con il mondo esterno possa essere diretto solo se esce dal pool che ci rappresenta, altrimenti se è un messaggio entrante allora è necessario inserire un Incoming Process, cioè un task che processa tale messaggio convertendolo in un linguaggio utile a noi.

In futuro , forse , magari lo estendo un pò così da renderlo più vicino alla realtà.