Miglioramento dei processi Lean: guida basata sui dati

Il miglioramento dei processi Lean consente di individuare in modo strutturato dove il lavoro perde tempo o qualità e di verificare le modifiche sulla base dei dati. Questa guida illustra come Lean Six Sigma e DMAIC possono supportare il miglioramento, quali dati servono in ogni fase e come applicare il ciclo a un processo dall’ordine all’incasso. L’obiettivo è definire una base di riferimento verificabile, mettere alla prova le ipotesi con l’analisi e introdurre controlli che aiutino a mantenere i risultati nel tempo.

Il miglioramento dei processi Lean non consiste semplicemente nell’utilizzare una serie di strumenti. DMAIC offre una struttura pratica per analizzare un processo e decidere cosa modificare.

Che cos’è Lean Six Sigma e che cosa non è

Lean, Six Sigma e Lean Six Sigma sono approcci correlati, ma affrontano problemi diversi.

Lean punta a eliminare le attività che non aggiungono valore, come le attese, i passaggi di consegne non necessari e le rilavorazioni. Six Sigma mira a ridurre la variabilità e i difetti. Lean Six Sigma integra questi obiettivi in un percorso di miglioramento strutturato.

La mappatura Lean, compresa la Value Stream Mapping, aiuta a rappresentare il flusso di lavoro previsto. I dati di processo mostrano invece come si muovono davvero i casi nei sistemi. Insieme, la mappa e i dati offrono al team una base concreta per discutere le differenze tra il processo reale e quello atteso.

È inoltre utile chiarire che cosa non è il Lean Six Sigma:

• Non è un programma di certificazione. Le cinture sono un formato di formazione. Una certificazione non sostituisce una base di riferimento misurata né un vero progetto di miglioramento.
• Non sostituisce la conoscenza del processo. DMAIC struttura l’indagine, ma il team deve comunque conoscere il lavoro e i vincoli che lo caratterizzano.
• Non è un progetto una tantum. La fase Controllo consente di monitorare il processo anche dopo che il team di progetto ha concluso il proprio lavoro.
• Non si applica solo alla produzione. Anche nei processi d’ufficio si verificano attese, rilavorazioni, passaggi di consegne e attività superflue.

Perché DMAIC ha bisogno di dati, non di opinioni

DMAIC include una fase di misurazione perché, prima di stabilire se un processo è migliorato, occorre disporre di una base di riferimento. Senza di essa, l’analisi può trasformarsi in una discussione su quale ricordo sia più attendibile.

L’osservazione manuale e il campionamento possono aiutare a comprendere un processo, ma coprono solo i casi e le fasi osservati. Nei processi d’ufficio, il lavoro può coinvolgere un ERP, un CRM, un sistema di ticketing e fogli di calcolo. Nessun osservatore riesce a seguire ogni caso dall’inizio alla fine.

Quando i sistemi registrano un riferimento del caso, un’attività e una marca temporale, è possibile usare questi dati degli eventi per ricostruire il percorso dei casi nel processo. Invece di raccogliere manualmente ogni osservazione, il lavoro consiste nel verificare i dati e interpretare i risultati. Il Process Mining offre un metodo per analizzare questi dati lungo l’intero processo.

Il confronto tra il lavoro documentato e quello effettivo può far emergere due tipi di discrepanze:

• Fasi indicate nel diagramma ma assenti nella pratica. Un controllo potrebbe non essere più eseguito oppure un’approvazione potrebbe non essere più necessaria.
• Fasi svolte nella pratica ma assenti nel diagramma. Una soluzione alternativa potrebbe essere diventata una prassi, senza un responsabile chiaro né una revisione.

Le cinque fasi DMAIC per il miglioramento dei processi Lean

DMAIC si articola in cinque fasi standard: definizione, misurazione, analisi, miglioramento e controllo. Ognuna risponde a una domanda diversa e produce un risultato specifico. Queste fasi del miglioramento dei processi Lean aiutano a passare da un problema definito a un cambiamento monitorato.

Definizione: stabilire il problema, l’ambito e i CTQ

Quali dati sostituisce: le supposizioni sui casi e sulle attività da includere nell’ambito.

Definisca il problema da risolvere, i confini del processo e le misure critiche per la qualità (CTQ) che contano per il cliente o per l’azienda. Per prima cosa, concordate che cosa costituisce un caso: potrebbe trattarsi di un ordine, un ticket, una fattura o un reclamo. Questa scelta determina quali eventi vengono raggruppati e influisce su tutte le misure successive.

Usi i dati di processo per verificare se la prima valutazione del team corrisponde al modo in cui si svolge oggi il lavoro. L’analisi può mettere in luce variazioni o misure non emerse durante un workshop. Documenti l’ambito in una mappa di processo o in un diagramma BPMN, così che il team possa fare riferimento alla stessa rappresentazione.

Un risultato utile: un ambito di cui un team possa assumersi la responsabilità, una definizione di caso chiara per tutti e CTQ misurabili con i dati disponibili.

Misurazione: definire una base di riferimento per tempo di ciclo, costi e rilavorazioni

Quali dati sostituisce: stime e piccoli campioni usati come approssimazione delle prestazioni attuali.

Misuri il processo rispetto ai CTQ concordati nella fase di definizione. In base ai dati disponibili e all’ambito del progetto, una base di riferimento utile può includere il tempo di ciclo, i costi e le rilavorazioni per caso.

Se il processo coinvolge più sistemi, verifichi come collegarne i dati. Unire i log usando un identificativo del caso concordato può aiutare a seguire il percorso nei diversi sistemi. Prima di basarsi sui risultati, convalidi l’unione e le marche temporali sottostanti: un collegamento parziale o errato può far apparire la base di riferimento più affidabile di quanto sia.

Usi la base di riferimento per descrivere le prestazioni attuali prima di fissare un obiettivo. Colleghi le misure al problema descritto, invece di scegliere indicatori solo perché sono facili da estrarre.

Un risultato utile: una base di riferimento che il responsabile del processo possa rivedere, corredata dalle ipotesi e dai limiti dei dati su cui si fonda.

Scopra come definire una base di riferimento a partire dai dati reali del processo.

Analisi: individuare colli di bottiglia, varianti e discrepanze di conformità

Quali dati sostituisce: ipotesi emerse nei workshop e non verificate rispetto al comportamento effettivo del processo.

Analizzi le evidenze per capire perché le prestazioni variano. Individui dove si accumulano i ritardi, quali varianti di processo si verificano, quale volume segue percorsi meno comuni e dove i casi si discostano dal processo previsto.

Una variante di processo è uno dei percorsi che i casi possono seguire. Confrontare le varianti aiuta a capire se un ritardo è diffuso o concentrato su un percorso specifico. L’analisi di conformità confronta il comportamento effettivo con il processo previsto e permette di individuare le differenze.

Ordini le possibili cause in base al loro impatto e verifichi le ipotesi confrontandole con i dati. Un’analisi approfondita può confermare l’ipotesi iniziale del team, ma può anche rivelare che il vincolo principale si trova altrove. Per una guida pratica, consulti come analizzare un processo e individuare i colli di bottiglia.

Un risultato utile: un elenco prioritizzato di possibili cause profonde, supportate da evidenze e aperte a verifica.

Migliora: dare priorità ai cambiamenti e testarli prima dell’implementazione

Quali dati sostituisce: la scelta di un cambiamento perché è familiare o facile da annunciare.

Usi i risultati dell’analisi per individuare cambiamenti che intervengano sulle cause emerse. Confronti l’impatto atteso con l’impegno e i rischi necessari. Se possibile, modelli il processo proposto e simuli diversi scenari prima dell’implementazione. In questo modo può valutare i possibili effetti del cambiamento senza considerare la simulazione una garanzia del risultato.

Documenti il processo obiettivo, affinché chi svolge il lavoro possa comprendere il nuovo flusso. Dopo l’implementazione, misuri gli stessi indicatori usati per la base di riferimento. Il confronto aiuta a valutare se il cambiamento ha migliorato le prestazioni o ha introdotto un nuovo vincolo in un’altra fase.

Un risultato utile: un cambiamento testato rispetto alla base di riferimento, con un piano per verificare le prestazioni effettive dopo l’implementazione.

Controllo: monitorare prestazioni, Dashboard e responsabilità

Quali dati sostituisce: il ricorso a verifiche occasionali o alla memoria per accorgersi dei cambiamenti nelle prestazioni.

La fase Controllo aiuta a mantenere i miglioramenti nel tempo. Scelga le misure da monitorare, definisca soglie che richiedano una revisione e indichi chi è responsabile di intervenire. Una Dashboard consente al responsabile del processo di vedere se le prestazioni stanno cambiando e dove approfondire.

Concordi la frequenza delle revisioni e le azioni da intraprendere quando una misura esce dall’intervallo previsto. Al variare dei volumi o della composizione dei casi, verifichi che il processo e i relativi obiettivi siano ancora adeguati.

Un risultato utile: un responsabile identificato, aspettative chiare per la revisione e misure che aiutano a rilevare eventuali regressioni e a decidere come procedere. Per approfondire il monitoraggio continuo, legga come monitorare costantemente il processo.

Un esempio pratico: dal ricevimento dell’ordine all’incasso

Ecco come si potrebbero applicare le cinque fasi a un processo che va dal ricevimento dell’ordine all’incasso. I dati riportati di seguito illustrano un esempio e non costituiscono un risultato garantito.

Definizione. Il progetto riguarda il processo dal ricevimento dell’ordine all’incasso per una famiglia di prodotti. Il caso inizia quando l’ordine viene accettato e termina quando la fattura viene pagata. I CTQ sono la correttezza della fattura e il tempo necessario per incassare. Poiché il problema riguarda i ritardi nell’incasso, il pagamento è un punto di arrivo più pertinente della spedizione.

Misurazione. Il team unisce i dati degli eventi provenienti dall’ERP e dal sistema di fatturazione usando il numero d’ordine. La base di riferimento indica una mediana di 34 giorni tra l’accettazione dell’ordine e il pagamento. Undici di questi giorni trascorrono tra la generazione e l’invio della fattura.

Analisi. Il ritardo si concentra su percorsi specifici. Nell’esempio, il 22% degli ordini passa attraverso un controllo manuale del credito che aggiunge nove giorni, mentre una fattura su sei viene riemessa, facendo ripartire il conteggio dei tempi di pagamento. Nessuno dei due percorsi compare nel modello di processo documentato.

Miglioramento. Il team valuta se innalzare la soglia di credito, così da riservare i controlli manuali alle eccezioni. Una simulazione basata sui dati storici suggerisce che questo potrebbe eliminare nove giorni per il 18% degli ordini, senza aumentare i crediti inesigibili nei dati analizzati. Dopo l’implementazione, il team dovrebbe comunque verificare le prestazioni effettive.

Controllo. Il team monitora la quota di ordini che segue il percorso manuale e stabilisce una soglia che richieda una revisione. Il team addetto alla gestione degli ordini è responsabile della misura e la relativa Dashboard è accessibile al gruppo che gestisce il processo.

Errori ricorrenti nel miglioramento dei processi Lean

Un progetto DMAIC può seguire correttamente tutte le fasi sulla carta e non produrre comunque cambiamenti utili. Faccia attenzione a questi schemi ricorrenti:

• Burocrazia legata alle cinture. Il team dedica tempo ai documenti di progetto prima di verificare il processo o i relativi dati. Gli statuti di progetto e le mappe degli stakeholder possono essere utili, ma da soli non dimostrano i progressi.
• Base di riferimento non difendibile. Se si salta la fase di misurazione o ci si basa solo su un sondaggio, l’analisi ha pochi elementi da verificare. Senza un punto di partenza, in seguito non sarà possibile fare un confronto attendibile.
• Ambito definito a livello di programma. Un programma ampio potrebbe non avere un unico responsabile, una definizione di caso o una misura su cui un singolo team possa intervenire. Restringa l’ambito a un processo con confini e responsabilità chiari.
• Il miglioramento viene scelto prima dell’analisi. Se il team ha già deciso che cosa automatizzare o riprogettare, potrebbe cercare solo evidenze a sostegno di quella scelta. Usi la fase di analisi per verificare la causa ipotizzata, non per giustificare una soluzione già decisa.
• Manca la fase Controllo. Se nessuno è responsabile delle misure dopo la conclusione del progetto, i cambiamenti nelle prestazioni potrebbero passare inosservati. Prima di chiudere il progetto, definisca il responsabile, le soglie e la frequenza delle revisioni.

Come ProcessMind supporta ogni fase DMAIC

ProcessMind può aiutarLa ad analizzare i dati di processo, documentare i flussi, valutare le prestazioni e simulare i cambiamenti proposti. Supporta l’indagine, mentre il team decide quali cambiamenti apportare e li implementa. Questi strumenti per il miglioramento dei processi Lean aggiungono evidenze al ciclo DMAIC, senza sostituire le competenze o le responsabilità del team.

Le fasi si basano su una definizione condivisa del processo. Se ciascuna utilizza dati diversi o una rappresentazione differente, il team potrebbe dover dedicare tempo a ricomporre le discrepanze anziché valutare il miglioramento.

Per una panoramica del flusso di lavoro di analisi, consulti come analizzare i dati di processo. Per capire come si integrano modellazione dei processi e Process Mining, legga il ruolo complementare della modellazione dei processi e del Process Mining.

Come avviare un progetto DMAIC

Segua questi passaggi per trasformare un obiettivo di miglioramento ampio in un progetto misurabile. Questo modello di miglioramento dei processi Lean mantiene il primo ciclo concentrato su un processo che il team può definire, misurare e rivedere:

1. Scelga un processo con un responsabile chiaro. Se nessuno è responsabile del processo, sarà difficile assegnare le responsabilità per la fase Controllo.
2. Concordi la definizione del caso. Indichi che cosa dà inizio e che cosa conclude un caso, poi individui i sistemi che registrano gli eventi corrispondenti.
3. Misuri prima di migliorare. Definisca una base di riferimento prima che i workshop o la riprogettazione stabiliscano il risultato atteso.
4. Mantenga il primo ciclo circoscritto. Inizi con un ambito che il team possa analizzare e rivedere, poi usi quanto appreso per decidere che cosa approfondire.

Dopo aver verificato una modifica, proceda con l’attuazione dei miglioramenti.

Come procedere

Avvii il progetto DMAIC definendo una base di riferimento misurata.

Avvii il progetto DMAIC definendo una base di riferimento misurata