Process mining gives DMAIC teams event records for examining process paths and repeated activities. The Process Mining for Six Sigma study, published in the 2021 journal volume, developed a guideline aligning these techniques with DMAIC. Before extracting a log, the team needs to identify the improvement decision those records will support.
Define the DMAIC boundary before extracting events
ASQ’s DMAIC guidance places project scope and customer requirements in Define. A SIPOC helps the team agree on the unit of analysis and its boundaries. The project charter then defines a case and its measurement start point. It also specifies the outcome that counts as successful completion.
Excessive elapsed time and defective output requiring correction need separate operational definitions in the project’s problem statement. The sponsor’s Define review should settle which customer requirement takes priority. It should also identify the quality measure that must be protected when the team changes the process.
Measure: establish what the event log can represent
A conventional event log links each activity to a case and records when it occurred. Resource information is optional, as described in the PMSS paper. The DMAIC measurement plan needs a definition for each field before the team calculates performance:
- Case identifier: the process instance followed through the agreed SIPOC boundary.
- Activity: the business step represented by each recorded event.
- Timestamp: the point recorded by the system, such as activity start or completion.
- Additional attributes: the resource or case characteristics needed for planned comparisons.
The Measure review also needs to establish how much work the log captures. In a 2024 study in Data & Knowledge Engineering, researchers observed six employees at a professional services firm. They found that a log from the principal transformation system would represent about 69% of observed data transformation and validation time. Coverage fell to 32.5% when assessed against all relevant client-related work. Those percentages apply to the firm studied.
For a Lean Six Sigma team, that coverage gap raises a scope decision: does the proposed log capture the work named in the charter? A gemba walk alongside the extraction review helps identify work missing from the system records. The Measure deliverable should name those omitted activities and explain how their absence limits the analysis.
A bottleneck investigation needs more than a long interval
A long interval between timestamps needs an explanation before the Analyze team treats it as a capacity problem. A 2024 Information Systems study decomposes waiting between activities into five causes: batching, resource contention, prioritization, resource unavailability, and extraneous factors. The researchers evaluated their approach with synthetic logs and demonstrated it on a real-life process. These categories give Lean Six Sigma teams specific causes to investigate before proposing additional capacity.
The DMAIC analysis plan should distinguish elapsed time between recorded events from waiting before an activity can start. That distinction depends on what the timestamps record and how the analysis handles working calendars. Once delay categories are confirmed, a Pareto chart ranks them by accumulated time within the project boundary.
Competing explanations belong in an Ishikawa diagram. If the team suspects batching, the Analyze review needs evidence linking release rules to the observed delays. A pilot that changes those rules tests a different cause from a pilot that changes resource availability.
Classifying rework before counting defects
The PMSS paper’s invoicing demonstration compares cases containing activity repetitions with other cases, examining their paths and processing times. That comparison identifies cases for investigation. Counting repetitions as defects requires a business rule, approved by the process owner, that distinguishes corrective work from permitted repetition.
For DMAIC, a proposed measure is the proportion of eligible cases containing at least one confirmed corrective repetition. A separate count of extra repetitions captures the correction workload. The case-level defect measure then has a defined rule that the 5 Whys investigation can test against individual cases.
Improve through a pilot tied to the suspected cause
ASQ places solution evaluation in Improve. The pilot proposal should connect the selected change to an Analyze finding. Retaining the baseline’s case definition gives the team a consistent basis for comparison; a stated acceptance outcome sets the test for the change. In a rework project, the pilot should test a poka-yoke proposal against the confirmed correction category before broader deployment.
At the Improve review, I would ask how the pilot and baseline case groups compare, including any differences in workload or case mix. The sponsor also needs to see the protected quality measure alongside elapsed time. A shorter interval on the process-mining dashboard is insufficient evidence for acceptance if the case mix has changed or defects have increased.
Control plans must include the event-data pipeline
ASQ’s Control phase includes long-term measurement and reaction plans. The control plan should also name the owner of the event extraction’s activity definitions and establish who approves mapping changes. Missing records need a documented treatment. Recurring rework and deteriorating log coverage each need an assigned response.
Documented measurement definitions must carry through to the control charts. If a system change alters what a timestamp records, the process owner needs a measurement review before interpreting the next performance signal.
Sources
- 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
