header

I processi BPM

Automatizzare al massimo i processi lavorativi all'interno di un'azienda è diventato oggigiorno un aspetto primario e fondamentale per rendere efficiente ed efficace il business dell'impresa, aumentando di conseguenza la soddisfazione del cliente e riducendo costi e time-to-market.

Il BPM (Business Process Management), tramite la catalogazione dei processi, delle applicazioni aziendali e tutte le attività necessarie al mapping tra utenti, processi e applicativi, permette di creare un macro processo orientato ad aumentare l'efficienza, la crescita e la competenza aziendale.

Il nuovo standard per la modellazione dei processi aziendali e processi informatici che si propone come leva fondamentale di una nuova iniziativa nel mondo Enterprise Architecture è il BPMN (Business Process Modelling Notation) che punta a definire una notazione grafica comune che permette la modellazione dei processi lavorativi attraverso modalità standard per facilitarne la comprensione e l'adattabilità da parte dei responsabili dell'organizzazione e degli analisti di business, la comunicazione alle strutture tecniche che ne devono realizzare l'automazione ed ai manager che devono monitorarne l'efficienza.

I processi BPMN sono simili a flow chart e quindi sono costituiti da building block immersi in un control flow. La visione a flow chart è familiare ai progettisti e consente di attribuire dei significati precisi agli elementi del processo. Gli elementi operativi di livello più basso sono i task che possono rappresentare chiamate di servizi, send o receive di messaggi, attività svolte da utenti con o senza supporto informatico, script per l'esecuzione automatica oppure regole di business.

I task possono essere raggruppati in sotto-processi che possono anche assumere caratteristiche particolari, cioè transazionali, compensative, ad hoc. Il control flow è molto articolato e consente di gestire situazioni fuori dell'ordinario, come errori, escalation, timeout e compensazioni. Il campo di applicazione principale è costituito dai processi di business ripetitivi a cui partecipano utenti con vari ruoli. La suddivisione dei processi in corsie (swimlane) consente di raggruppare gli user task per ruolo o per unità organizzativa.

Case study di un processo ottimale

Un processo case-handler gestisce il ciclo di vita di un tipo di dato, ad esempio una polizza assicurativa o una richiesta di risarcimento (insurance claim); il tipo di dato gestito è detto il caso del processo.

Per esaminare il livello di complessità del control flow è necessario analizzare i processi inerenti alla gestione delle polizze, alla gestione dei sinistri e alla fascicolazione in qualità di processi case handler con casi strutturati.

Il processo di gestione polizze inizia con l'immissione di una proposta di polizza che viene poi sottoposta ad un ciclo autorizzativo; nel caso favorevole si passa all'emissione della polizza, all'incasso del premio e alla verifica dei documenti e dei pagamenti.

Nel ciclo autorizzativo può succedere che l'operatore non abbia i requisiti necessari ad approvare le condizioni contrattuali allegate alla proposta di polizza. Serve quindi una deroga che l'operatore deve chiedere al livello superiore. La proposta è quindi passata ad un operatore di livello superiore che può risolvere il caso o passarlo a sua volta. Infatti la struttura organizzativa può essere generalmente rappresentata da un albero che inizia dalla direzione, si ramifica in vari livelli e termina nei nodi che rappresentano gli intermediari. Il numero dei livelli non è stabilito a priori ma dipende dal contesto. I casi in deroga comportano l'escalation ad un livello superiore e quindi la determinazione dell'operatore destinatario dipende dalla struttura organizzativa e anche dalle caratteristiche del caso in esame. La soluzione generale è di tipo ricorsivo e si basa su eventi di escalation e su regole di business.

Mediante un evento di escalation l'operatore può passare la richiesta al livello superiore. Le regole di business consentono di esprimere nel processo la logica di scelta del destinatario e pertanto la rendono trasparente e più facile da modificare. La verifica dei documenti e dei pagamenti comporta l'introduzione di un control flow complesso a causa delle azioni correttive che devono essere compiute in base a vincoli temporali; in questi casi risulta utile il meccanismo di compensazione attuato mediante sotto-processi.

I meccanismi di control flow offerti da BPMN (tra cui escalation e compensazione) risultano adeguati al trattamento della complessità evidenziata nell'analisi dei processi indicati, mentre l'uso di regole di business consente di separare la logica di controllo dalle attività esecutive. Le componenti principali di un BPMS sono: l'ambiente di sviluppo dei processi (chiamato ambiente autore), il motore di esecuzione (process engine), il gestore delle work list e il modulo di BAM (Business Activity Monitoring).

L'ambiente autore consente la scrittura di processi consapevoli delle business operation. L'ambiente autore ideale è quello che durante la stesura di un processo consente di scegliere le business operation da un catalogo e ottenere i building block BPMN corredati dei dati necessari; anche le variabili di processo devono poter essere importate da un catalogo in quanto ciò facilita lo scambio dei dati con le business operation. Va sottolineato che questa modalità guidata rende accessibile la scrittura dei processi, o comunque ne facilita notevolmente la comprensione, ai business analyst, togliendo quindi la definizione dei processi dall'ambito esclusivo degli specialisti software.

Un'altra caratteristica importante è il supporto alla scrittura di regole di business esplicite. L'integrazione delle regole di business nei processi sta assumendo un'importanza crescente perché, se si evita che le regole siano inserite in modo hard-wired nell'implementazione delle business operation o nel control flow dei processi, si può ottenere una flessibilità maggiore.

Le regole di business possono essere descritte in vari modi – nella forma if-then-else, con tabelle decisionali, in linguaggio naturale strutturato come SBVR (Semantics of Business Vocabulary and Rules) – ma comunque presuppongono un ambiente di supporto chiamato rule management system (RMS) il cui componente principale è il motore di esecuzione delle regole (rule engine). Un RMS specifica sia il formato delle regole sia il formato dei dati ai quali sono applicate le regole: lo standard SBVR chiama fatti i dati e tipi dei fatti le strutture dei dati.

La possibilità di usare nei processi un rule engine per scrivere regole di business integrate con la struttura informativa è una caratteristica molto rilevante, in quanto dà all'azienda un vantaggio competitivo attraverso la possibilità di poter variare i processi predefiniti con poco sforzo, idealmente senza programmazione.

Il gestore delle work list è anch'esso parte fondamentale di un BPMS evoluto. Per avere un'utilità reale e non solo teorica dovrebbe essere in grado di fornire una varietà di ricerche e di ordinamenti sulle richieste (di attività) pendenti. Le richieste devono poter essere ordinate in base all'area funzionale del processo o in base a proprietà di business rilevanti come il numero di polizza o il nome del cliente. Inoltre è auspicabile che le informazioni presenti nelle work list possano essere arricchite di elementi tratti dalle proprietà delle entità di business associate alle richieste.

Il modulo di BAM riveste un ruolo fondamentale nel monitoraggio dell'andamento dei processi e nella ricerca dell'efficienza e quindi della riduzione dei costi di gestione del processo stesso con conseguente miglioramento di qualità e tempi dei servizi erogati.

Per ulteriori approfondimenti vai al sito http://www.rgi.it

Source: RGI