Soccer team in a huddle

Operational Process Monitoring e Process Mining: prime lezioni dall’esperienza sul campo

4, Novembre, 2016 di Andrea Pagliari

In questo terzo contributo approfondiamo i primi insegnamenti che abbiamo appreso sul campo negli ultimi mesi di intensa attività e che ci aiuteranno ad affrontare in modo ancora più efficace ed efficiente le future avventure. Non potremo essere esaustivi: il viaggio è in corso!

Un’ulteriore avvertenza: diamo per scontato che chi ci legge abbia lunga esperienza di progetti di disegno e realizzazione di soluzioni informatiche a supporto dei processi aziendali e dunque sarà in grado di collocare ogni spunto nel corretto quadro metodologico: dall’impostazione dell’architettura alla definizione dell’ambito, dalla costruzione del piano di progetto alla realizzazione e all’esercizio.

Partiamo dunque con le prime lezioni, a volte quasi scontate, altre molto meno, che abbiamo maturato in questi mesi.

pagliari_2

Lezione #1. Documentazione esistente: fidarsi è bene…. Per monitorare un processo operativo bisogna sapere esattamente come il sistema viene utilizzato. E in questo caso “esattamente” non è solo un avverbio di modo ma è una necessità imprescindibile. Per poter collegare la generazione di un “evento” ad un accadimento all’interno del sistema è fondamentale sapere con esattezza come l’utente utilizza il sistema. Ad esempio, se non è obbligatorio salvare i dati al termine della compilazione della “Service Request”, l’evento “Service Request completata” a volte sarà tracciato e a volte no. E dunque è del tutto inutilizzabile ai fini di una soluzione di “Operational Process Monitoring”. Sembra un dettaglio eccessivo, ma in realtà quando si disegnano con i key user gli eventi da tenere sotto controllo di un processo, la verifica dell’effettiva obbligatorietà di un certo passaggio è fondamentale per essere sicuri della possibilità di realizzare una certa milestone di misurazione del processo. Tutti i nodi vengono al pettine: i gradi di libertà che in fase di implementazione dell’ERP hanno permesso di non generare eccessiva opposizione all’utilizzo di un sistema troppo strutturato, oggi possono rendere di fatto non misurabili alcune fasi critiche. E quindi? Non è certo sempre possibile modificare il sistema ERP. E dunque non possiamo dare per scontato che sia possibile misurare tutti gli eventi che vorremmo. C’è di peggio: la “verifica di misurabilità” è solo in parte fattibile prima di partire con il progetto. La documentazione, quando esiste, è tipicamente molto più generica di quanto servirebbe e non è detto che i nostri interlocutori conoscano sempre le reali modalità di utilizzo del sistema. Una contromisura utile è quella di prevedere un momento di verifica del “sistema utente”, ovvero di osservazione di come le transazioni vengono effettivamente usate. E soprattutto tenere conto della lezione successiva.

Lezione #2. In produzione il prima possibile. Anche prima. E’ opportuno testare che il raising degli eventi funzioni tecnicamente in modo corretto. E basta. Per quanto abbiamo detto al punto precedente, il vero test di tutti i casi possibili di uso quotidiano della soluzione ERP può avvenire solo nell’ambiente di produzione, quello effettivamente usato tutti i giorni. E per una volta “andare in produzione” il prima possibile non è un’eresia ma una prassi da consigliare. Perché? Perché da un lato la soluzione di operational process monitoring non è mission critical e non può modificare l’ambiente di produzione. Inoltre la soluzione non crea un patrimonio dati che presenta un valore particolare rispetto alle sue serie storiche. Se andiamo in produzione e in un mese ci accorgiamo che devono essere eliminati due eventi e che è necessario inserirne tre nuovi, realizziamo le opportune modifiche e non succede nulla di grave. I dati di monitoraggio delle istanze iniziate vivranno fino alla conclusione degli eventi in corso e le nuove istanze di processo verranno monitorate da un insieme di eventi più coerenti e misurabili. Tutto qui. L’unico impatto negativo è, nel caso descritto, l’impossibilità di confrontare tutte le prestazioni intermedie delle istanze prima e dopo le modifiche. Nella nostra esperienza questo è un punto di rilevanza molto bassa, a patto di essere rapidi, sia ad andare in produzione, sia a comprendere e realizzare gli interventi di modifica necessari. Il perché lo abbiamo capito con la prossima lezione.

Lezione #3. Il monitoraggio operativo non è retroattivo. Mentre il process mining trova ambito di applicazione sui dati di log passati, come dicevamo nel precedente contributo, l’operational process monitoring vive nel presente. Inizia a “popolarsi” con le istanze che vengono iniziate un attimo dopo che è entrato in produzione. Dunque la ripresa dati non esiste: sarebbe molto dispendioso e poco utile ricostruire gli eventi passati. E’ opportuno iniziare a monitorare gli aereoplani che stanno atterrando e vogliono decollare ora. Le statistiche dei voli della settimana scorsa si trovano su altri sistemi, disegnati e realizzati per altre finalità. Ovviamente la realtà aziendale non è mai binaria: anche in un sistema di operational process monitoring e di datamining vengono definiti e misurati dei key performance indicators, che hanno però finalità e prospettive differenti rispetto a quelli tipicamente contenuti nei cruscotti del data warehouse aziendale.

Lezione #4. Sistemi esistenti: questi sconosciuti. Le effettive competenze sui sistemi esistenti sono scarsamente disponibili. Noi invece siamo costretti a capire in quali punti del processo di utilizzo del sistema mettere una sonda (il “raise” dell’evento) o in quali parti del modello dati , magari non standard, si trovano i log che possono servire al process mining. Senza considerare che non necessariamente tutti i sistemi di back end sono sistemi SAP. Anzi nei casi più interessanti e sofisticati i processi si snodano lungo una successione di sistemi SAP e di sistemi custom.

Come è intuibile, non esiste una ricetta per ovviare a questa criticità, se non quella di prevedere un opportuno dimensionamento delle attività e delle risorse dedicate a questo scopo, senza fare particolare affidamento sulla documentazione disponibile.

Lezione #5. La fine è solo l’inizio. Una volta in produzione, il sistema di monitoraggio operativo e di process mining deve essere gestito in modo molto preciso e puntuale rispetto alla gestione del sistema di backend. E questo deve avvenire rispetto a due aspetti. Il primo è l’operatività quotidiana. Eventuali malfunzionamenti di alcune componenti del sistema complessivo, ad esempio un blocco del CRM e successivo ripristino, devono essere valutati anche rispetto all’impatto che generano nelle informazioni relative alle istanze di processo monitorate. Non basta ripristinare il componente, è anche necessario controllare e comunicare gli impatti che si sono verificati nella piattaforma di monitoraggio. Il secondo aspetto è relativo alle modifiche di funzionamento del sistema di backend. Anche in questo caso è fondamentale che i cambiamenti introdotti a livello applicativo siano valutati e realizzati considerando gli impatti e i necessari cambiamenti che comportano nelle logiche e negli strumenti di monitoraggio. In questo ambito diventa molto importante prevedere e realizzare documentazione tecnica e manuali operativi che siano effettivamente condivisi e compresi da tutti i ruoli coinvolti all’interno e all’esterno della funzione sistemi informativi. Nelle realtà più complesse diventa necessario prevedere all’interno delle procedure di “change request management” un punto di verifica rispetto agli impatti sulle soluzioni di process mining e di operational process control.

Fin qui le evidenze più interessanti con cui abbiamo iniziato a confrontarci. Niente di particolarmente nuovo per chi si occupa di introduzione di tecnologie informatiche nelle organizzazioni da più di venti anni. Troviamo tuttavia interessante l’intensità di alcune lezioni dovute alla natura di questi progetti e delle tecnologie utilizzate.

Il viaggio è appena iniziato, in futuro cercheremo di continuare a condividere e stimolare la discussione intorno al tema dell’Operational Process Monitoring e del Process Mining che rimarrà anche in futuro parte stimolante delle nostre curiosità e dei nostri impegni professionali.

 

Andrea Pagliari
Business Senior Manager – Consulting

bottone7

Tags: , ,