Process mining biedt DMAIC teams gebeurtenissenlogs om procespaden en herhaalde activiteiten te onderzoeken. De studie Process Mining voor Six Sigma, gepubliceerd in de tijdschriftjaargang van 2021, ontwikkelde een richtlijn die deze technieken afstemt op DMAIC. Voordat de loggegevens worden geëxtraheerd, moet het team het verbeterbesluit identificeren dat door die gegevens wordt ondersteund.
Definieer de DMAIC-grens voordat u gebeurtenissen extraheert
De DMAIC-richtlijnen van de ASQ plaatsen de projectomvang en de klanteisen in de Define-fase. Een SIPOC helpt het team overeenstemming te bereiken over de analyse-eenheid en de grenzen ervan. Het projectcharter definieert vervolgens een case en het startpunt van de meting. Het specificeert ook het resultaat dat als een succesvolle afronding geldt.
Overmatige doorlooptijd en defecte output die gecorrigeerd moet worden, vereisen afzonderlijke operationele definities in de probleemstellingvan het project. De Define-review van de sponsor moet bepalen welke klanteis prioriteit krijgt. Er moet ook in worden vastgelegd welke kwaliteitsmaatstaf moet worden beschermd wanneer het team het proces wijzigt.
Measure: stel vast wat de gebeurtenissenlog kan vertegenwoordigen
Een conventionele gebeurtenissenlog koppelt elke activiteit aan een case en legt vast wanneer deze heeft plaatsgevonden. Informatie over middelen is optioneel, zoals beschreven in het PMSS-artikel. Het DMAIC-meetplan heeft een definitie nodig voor elk veld voordat het team de prestaties berekent:
- Case-ID: de procesinstantie die gevolgd wordt binnen de overeengekomen SIPOC grens.
- Activiteit: de zakelijke stap die door elke vastgelegde gebeurtenis wordt vertegenwoordigd.
- Tijdstempel: het punt dat door het systeem is geregistreerd, zoals de start of afronding van een activiteit.
- Aanvullende attributen: de kenmerken van middelen of cases die nodig zijn voor geplande vergelijkingen.
De Measure-review moet ook vaststellen hoeveel werk de log omvat. In een studie uit 2024 in Data & Knowledge Engineering observeerden onderzoekers zes werknemers bij een zakelijke dienstverlener. Ze stelden vast dat een logboek uit het primaire transformatiesysteem ongeveer 69% van de geobserveerde datatransformatie- en validatietijd zou vertegenwoordigen. De dekking daalde tot 32.5% wanneer deze werd beoordeeld ten opzichte van al het relevante klantgerelateerde werk. Die percentages zijn van toepassing op het onderzochte bedrijf.
Voor een Lean Six Sigma-team roept dat dekkingsgat een vraag over de projectomvang op: omvat de voorgestelde log het werk dat in het charter is genoemd? Een Gemba walk naast de extractiereview helpt bij het identificeren van werk dat ontbreekt in de systeemgegevens. De Measure-oplevering moet die weggelaten activiteiten benoemen en uitleggen hoe hun afwezigheid de analyse beperkt.
Een onderzoek naar knelpunten vereist meer dan een lang tijdsinterval
Een lang tijdsinterval tussen tijdstempels heeft een verklaring nodig voordat het Analyze-team het als een capaciteitsprobleem behandelt. Een studie uit 2024 in Information Systems verdeelt de wachttijd tussen activiteiten in vijf oorzaken: batching, concurrentie om middelen, prioritering, onbeschikbaarheid van middelen en externe factoren. De onderzoekers evalueerden hun aanpak met synthetische logs en demonstreerden deze op een praktijkproces. Deze categorieën geven Lean Six Sigma-teams specifieke oorzaken om te onderzoeken voordat ze extra capaciteit voorstellen.
Het DMAIC-analyseplan moet een onderscheid maken tussen de verstreken tijd tussen geregistreerde gebeurtenissen en het wachten voordat een activiteit kan starten. Dat onderscheid hangt af van wat de tijdstempels registreren en hoe de analyse omgaat met werkroosters. Zodra de vertragingscategorieën zijn bevestigd, rangschikt een Pareto-analyse ze op opgelopen tijd binnen de projectgrens.
Concurrerende verklaringen horen thuis in een Ishikawa-diagram. Als het team batching vermoedt, heeft de Analyze-review bewijs nodig dat vrijgaveregels koppelt aan de geobserveerde vertragingen. Een pilot die die regels wijzigt, test een andere oorzaak dan een pilot die de beschikbaarheid van middelen wijzigt.
Classificeer herstelwerkzaamheden voordat u defecten telt
De facturatiedemonstratie in het PMSS-artikel vergelijkt cases met activiteitsherhalingen met andere cases, waarbij hun paden en verwerkingstijden worden onderzocht. Die vergelijking identificeert cases voor verdere inspectie. Het tellen van herhalingen als defecten vereist een bedrijfsregel, goedgekeurd door de Process Owner, die correctiewerk onderscheidt van toegestane herhalingen.
Voor DMAIC is een voorgestelde meting het aandeel in aanmerking komende cases dat ten minste één bevestigde correctieve herhaling bevat. Een afzonderlijke telling van extra herhalingen legt de werklast voor correcties vast. De defectmaatstaf op caseniveau heeft dan een gedefinieerde regel die het 5 Whys onderzoek kan testen aan de hand van individuele cases.
Verbeter via een pilot die gekoppeld is aan de vermoedelijke oorzaak
ASQ plaatst de evaluatie van oplossingen in Improve. Het pilotvoorstel moet de gekozen wijziging verbinden met een bevinding uit Analyze. Het behouden van de case-definitie van de nulmeting geeft het team een consistente basis voor vergelijking; een vastgesteld acceptatieresultaat vormt de test voor de wijziging. In een herstelwerkproject moet de pilot een poka-yoke -voorstel testen tegen de bevestigde correctiecategorie voor een bredere uitrol.
Bij de Improve-review zou ik vragen hoe de pilot- en de nulmetingsgroep zich tot elkaar verhouden, inclusief eventuele verschillen in werklast of casemix. De sponsor moet ook de beschermde kwaliteitsmaatstaf zien naast de verstreken tijd. Een korter interval op het process mining-dashboard is onvoldoende bewijs voor acceptatie als de casemix is veranderd of de defecten zijn toegenomen.
Control-plannen moeten de gebeurtenis-datapijplijn omvatten
De Control-fase van ASQ omvat langetermijnmetingen en reactieplannen. Het beheersplan moet ook de eigenaar van de activiteitsdefinities van de gegevensextractie noemen en vaststellen wie wijzigingen in de gegevenskoppeling goedkeurt. Ontbrekende gegevens hebben een gedocumenteerde behandeling nodig. Terugkerend herstelwerk en een verslechterende logdekking vereisen elk een toegewezen reactie.
Gedocumenteerde meetdefinities moeten worden doorgevoerd in het of. Als een systeemwijziging verandert wat een tijdstempel registreert, heeft de Process Owner een meetreview nodig voordat hij het volgende prestatiesignaal interpreteert.
Bronnen
- 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
