Il Process mining fornisce ai team DMAIC i registri degli eventi per esaminare i percorsi di processo e le attività ripetute. Lo studio Process Mining for Six Sigma, pubblicato nel volume del 2021 della rivista, ha sviluppato una linea guida che allinea queste tecniche con la fase DMAIC. Prima di estrarre un log, il team deve identificare la decisione di miglioramento che tali registri andranno a supportare.
Definire i confini del DMAIC prima di estrarre gli eventi
La prassi del DMAIC colloca l'ambito del progetto e i requisiti del cliente nella fase Define. Un SIPOC aiuta il team ad accordarsi sull'unità di analisi e sui relativi confini. Il project charter definisce quindi un caso e il suo punto di partenza per la misurazione. Specifica inoltre il risultato che corrisponde al completamento con successo.
I tempi trascorsi eccessivi e gli output difettosi che richiedono correzioni necessitano di definizioni operative separate all'interno della definizione del problema del progetto. La revisione della fase Define con lo sponsor deve stabilire quale requisito del cliente abbia la priorità, identificando inoltre la misura di qualità che deve essere tutelata quando il team apporta modifiche al processo.
Measure: stabilire cosa può rappresentare l'event log
Un event log convenzionale collega ogni attività a un caso e registra quando si è verificata. Le informazioni sulle risorse sono opzionali, come descritto nello studio PMSS. Il piano di misurazione del DMAIC richiede una definizione per ciascun campo prima che il team calcoli le prestazioni:
- Identificatore del caso: l'istanza di processo seguita attraverso il confine del SIPOC concordato.
- Attività: la fase aziendale rappresentata da ciascun evento registrato.
- Marca temporale: il punto temporale registrato dal sistema, come l'inizio o il completamento di un'attività.
- Attributi aggiuntivi: le caratteristiche delle risorse o dei casi necessarie per le comparazioni pianificate.
La revisione della fase Measure deve anche stabilire quanto lavoro viene catturato dal registro. In uno studio del 2024 pubblicato su Data & Knowledge Engineering, i ricercatori hanno osservato sei dipendenti di una società di servizi professionali. Hanno riscontrato che un registro estratto dal sistema di trasformazione principale rappresenterebbe solo circa il 69% del tempo osservato di trasformazione e validazione dei dati. La copertura è scesa al 32.5% se valutata rispetto a tutto il lavoro relativo al cliente. Tali percentuali si applicano all'azienda analizzata nello studio.
Per un team Lean Six Sigma, tale divario di copertura solleva una decisione sullo scopo: il log proposto acquisisce il lavoro indicato nel charter? Un Gemba walk affiancato alla revisione dell'estrazione aiuta a identificare il lavoro mancante dai registri di sistema. Il deliverable della fase Measure deve citare tali attività omesse e spiegare in che modo la loro assenza limiti l'analisi.
L'analisi dei colli di bottiglia richiede più di un semplice intervallo prolungato
Un lungo intervallo tra le marche temporali richiede una spiegazione prima che il team della fase Analyze lo tratti come un problema di capacità. Uno studio del 2024 pubblicato su Information Systems scompone l'attesa tra le attività in cinque cause: raggruppamento in lotti, saturazione delle risorse, attribuzione delle priorità, indisponibilità delle risorse e fattori esterni. I ricercatori hanno valutato il loro approccio con registri sintetici e lo hanno dimostrato su un processo reale. Queste categorie forniscono ai team Lean Six Sigma cause specifiche da indagare prima di proporre capacità aggiuntiva.
Il piano d'analisi DMAIC deve distinguere il tempo trascorso tra gli eventi registrati dall'attesa prima che un'attività possa iniziare. Tale distinzione dipende da ciò che le marche temporali registrano e da come l'analisi gestisce i calendari lavorativi. Una volta confermate le categorie di ritardo, un Pareto le ordina in base al tempo accumulato all'interno del confine del progetto.
Le spiegazioni concorrenti vanno inserite in un diagramma di Ishikawa. Se il team sospetta un fenomeno di raggruppamento in lotti (batching), la revisione della fase Analyze necessita di prove che colleghino le regole di rilascio ai ritardi osservati. Un progetto pilota che modifica tali regole verificherà una causa diversa rispetto a un pilota che modifica la disponibilità delle risorse.
Classificare il ri-lavoro prima di conteggiare i difetti
La dimostrazione sulla fatturazione contenuta nello studio PMSS confronta i casi che contengono ripetizioni di attività con altri casi, esaminando i relativi percorsi e tempi di elaborazione. Questo confronto identifica i casi da analizzare. Conteggiare le ripetizioni come difetti richiede una regola aziendale, approvata dal Process Owner, che distingua il lavoro correttivo dalla ripetizione consentita.
Per la DMAIC, una misura proposta è la proporzione di casi idonei contenenti almeno una ripetizione correttiva confermata. Un conteggio separato delle ripetizioni aggiuntive rileva il carico di lavoro di correzione. La misura del difetto a livello di caso ha quindi una regola definita su cui l'analisi dei 5 Whys può effettuare dei test rispetto ai singoli casi.
Migliorare tramite un pilot legato alla causa sospettata
La valutazione della soluzione appartiene alla fase Improve. La proposta pilota dovrebbe collegare la modifica selezionata a un risultato ottenuto nella fase Analyze. Mantenere la definizione del caso baseline offre al team una base di confronto coerente; un risultato di accettazione stabilito fissa il test per la modifica. In un progetto relativo ai ripristini, il pilota dovrebbe testare una proposta di Poka-Yoke rispetto alla categoria di correzione confermata prima di una diffusione più ampia.
Durante la revisione della fase Improve, chiederei come si confrontano il gruppo del pilot e quello della baseline, incluse eventuali differenze nel carico di lavoro o nel mix dei casi. Lo sponsor deve inoltre visualizzare la misura di qualità tutelata insieme al tempo di attraversamento. Un intervallo più breve sul cruscotto di process mining non è una prova sufficiente per l'accettazione se il mix dei casi è cambiato o se i difetti sono aumentati.
I piani di controllo devono includere la pipeline dei dati degli eventi
La fase Control include la misurazione a lungo termine e i piani di reazione. Il piano di controllo dovrebbe anche nominare il responsabile delle definizioni delle attività relative all'estrazione degli eventi e stabilire chi approva le modifiche di mappatura. I record mancanti richiedono un trattamento documentato. I ripristini ricorrenti e il deterioramento della copertura dei log richiedono ciascuno una risposta assegnata.
Le definizioni di misurazione documentate devono essere trasferite nei carte di controllo. Se una modifica di sistema altera ciò che viene registrato da una marca temporale, il Process Owner necessita di una revisione della misurazione prima di interpretare il successivo segnale di prestazione.
Fonti
- Business & Information Systems Engineering (2021), Process Mining for Six Sigma: https://link.springer.com/article/10.1007/s12599-020-00649-w
- Data & Knowledge Engineering (2024), Capturing and Analysing Employee Behaviour: An Honest Day’s Work Record: https://research-portal.uu.nl/ws/portalfiles/portal/239370240/1-s2.0-S0169023X24000740-main.pdf
