Lean Six Sigma
Process Improvement and Digital Transformation
Automating a broken process gives you a broken process that runs faster and costs more to change.
This is the most expensive mistake in digital transformation, and it is common because automation is easier to sell than the unglamorous work of establishing what the process actually is. A tool gets bought, configured around the existing mess, and the mess is now encoded in software.
My background is mechanical engineering and Lean Six Sigma before it was AI, which means the default sequence here is to understand and fix the process first, then decide what deserves to be automated. Often that is less than the business expected, and the saving is larger.
DMAIC, applied honestly
Define, Measure, Analyse, Improve, Control. The framework is old and unfashionable and it still works, provided the measure step is done properly rather than assumed.
Define the problem in terms of what it costs, not what it feels like. Measure the current process as it actually runs, which nearly always contradicts the documentation. Analyse where time and errors concentrate, rather than where people believe they concentrate. Improve the process itself before adding technology. Control so the improvement holds after attention moves on.
The measure step is where most exercises fail. People estimate rather than observe, the estimate is wrong in a predictable direction, and the improvement targets the wrong step.
What measurement usually reveals
Two findings recur across almost every process I have measured.
The first is that most elapsed time is waiting, not working. A task that takes forty minutes of effort takes four days to complete, because it sits in three queues. Automating the forty minutes barely moves the four days. Removing a queue does.
The second is that the exception path is the real process. The documented flow covers seventy percent of cases and the remaining thirty consume most of the effort. Any automation built against the documented flow fails on contact with reality.
Where this connects to the AI work
This is the front half of every AI engagement I run, and clients sometimes find it a strange answer to an AI question.
The order is: map the process, measure it, remove the waste that does not need technology, and only then look at what remains and ask whether a model helps. By that point the candidate list is shorter, better specified, and much more likely to survive contact with production.
It is also how you avoid paying for automation of a step that should simply have been deleted.
Control, and why improvements disappear
The step that gets dropped is control, and dropping it is why so many improvement projects show a gain that quietly evaporates over the following year.
The process improves while attention is on it. Then the person who championed it moves on, the new starter is trained by someone who learned the old way, an exception gets handled with a workaround, and within twelve months the process has drifted back with nobody having decided to reverse anything.
Control means the measure keeps being taken, someone owns it by name, and there is a defined response when it moves outside its expected range. That is deliberately unexciting and it is what separates an improvement from a project.
What this looks like for a small team
The framework was built for manufacturing and it scales down further than people expect, as long as the formality scales with it.
For a team of ten, measurement might be one person timing a process for a fortnight and recording where things wait. Analysis might be an afternoon with the people who do the work. The improvement might be removing an approval step that no longer serves a purpose. Control might be one number reviewed monthly by a named person.
None of that requires a certification or a documentation pack. It requires observing before changing, which is the part that actually distinguishes the method.
Where to point this first
Choose the process that people complain about most, not the one that looks most automatable. Complaints are a reliable signal of where time is actually leaking.
Then, before any engagement, try measuring one instance of it end to end: when it started, when it finished, and how much of that gap was waiting rather than working. That single number usually reframes the problem, and it is the fastest way to know whether this work is worth commissioning.
What the engagement includes
- A measured process map. The workflow as it actually runs, with observed timings, queue times and error rates rather than estimates.
- Waste and constraint analysis. Where time and money genuinely leak, including the waiting time that estimates always miss and the exception path that documentation ignores.
- Process fixes before technology. The improvements that need no software, implemented first, because they are cheaper and they change what automation is worth building.
- An automation shortlist. What remains after the process is fixed, scored on value and feasibility, including what should not be built.
- Control measures. How the improvement is held after the engagement ends, with the measures and owners defined.
How the work runs
- Define in cost terms. State the problem as what it costs, so the improvement can be judged against it.
- Measure by observation. Watch the process run. Estimates are wrong in a predictable direction.
- Analyse where it concentrates. Time, errors and rework, including queues and the exception path.
- Improve the process first. Fix what needs no technology before considering what does.
- Control. Define the measures and owners that hold the gain after attention moves on.
Proof
This sequence runs in front of every AI consulting engagement, and the DMAIC applied to search post shows the same method on a different problem.
Related
Talk about your situation
The first conversation is short and mostly questions. Get in touch and tell me what you are trying to fix. Or see how this is priced.
Frequently Asked Questions (FAQs)
What is Lean Six Sigma?
Two disciplines used together. Lean removes waste and waiting from a process. Six Sigma reduces variation and defects. Combined, they give a structured way to find where a process leaks time and money and to hold the improvement afterwards. DMAIC is the sequence most commonly used to apply them.
Should we fix the process or automate it?
Fix first, then automate what remains. Automating a broken process encodes the problem in software and makes it more expensive to change. Measuring first also usually shortens the automation list, because some steps turn out to be unnecessary rather than slow.
How do you measure a process we have never measured?
By observation rather than estimate. Timing the steps as they actually run, recording queue time separately from work time, and tracking how often the exception path is taken. Estimates consistently understate waiting and understate exceptions, which is why they mislead.
Does this apply to a small business?
Yes, and often with a faster payback, because a small business has fewer people between the problem and the decision. The formality scales down: the same sequence, less documentation, and improvements that can be implemented the week they are agreed.
How do you get people to cooperate with being measured?
By being clear that the process is being measured and not the person, and by showing the results back to the people who do the work first. Measurement framed as performance assessment produces careful behaviour that hides the real process, which makes the data useless. The people doing the job usually know exactly where the waste is and will say so once they trust the exercise.
Do we need someone certified in Six Sigma on our side?
No. The method matters, the certificate does not. What helps is one person who knows how the work actually gets done and has enough authority to change it. Formal training is useful if you intend to run improvement cycles yourselves afterwards, and that is worth deciding separately.