L’architettura di una soluzione Bpm è piuttosto intuitiva. Gli accadimenti quotidiani dell’azienda sono filtrati da un livello intermedio (che li normalizza) e, successivamente, processati dal motore delle regole (che li confronta con condizioni “stand …
L’architettura di una soluzione Bpm è piuttosto intuitiva. Gli accadimenti quotidiani dell’azienda sono filtrati da un livello intermedio (che li normalizza) e, successivamente, processati dal motore delle regole (che li confronta con condizioni “standard”). Tali eventi sono tradotti in azioni e diffusi attraverso display o allarmi, in modo che possano essere compresi facilmente dagli utenti. Chi intenda implementare un’architettura Bpm di successo dovrà, anzitutto, creare un livello intermedio di normalizzazione. Questo raccoglie gli eventi e li predispone per le successive analisi (ad esempio attraverso un motore di regole, che definisce e applica le norme che permettono di riconoscere gli accadimenti). Gli eventi provenienti da qualsiasi fonte dovranno, quindi, essere uniformati (ricondotti a un formato univoco) prima del processing. Il layer analitico dei sistemi Bpm è molto spesso difficile da implementare. Si tratta di un sistema che deve essere in grado di processare migliaia di eventi al secondo, proprio perché si presuppone che debba lavorare in tempo reale. Sono le regole stabilite a generare il tipo di analisi: regole semplici presuppongono l’ottenimento di valori statici (come l’indisponibilità di un codice legato a una certa transazione), ma ci sono regole che richiedono anche un maggior grado di sofisticazione. L’output di un sistema Bpm è, di fatto, un allarme o una notifica, che potrà essere inviata a una persona o linkata ad altri processi. In un contesto che richieda di tener conto di una prospettiva storica degli eventi, il Bpm richiede anche la dotazione di un data waraehouse, per mantenere un repository di dati e di risposte, correlate a specifici eventi, utile a facilitare le analisi contestuali.
