Skip to content
Ashish Kumar AgnihotriOperating Partner

03Service

Process Transformation & Lean Six Sigma

Lean and Six Sigma applied as engineering, not as a programme to be rolled out.

Process transformation is the work of rebuilding how value moves through your business — and proving, with data, that the new way is genuinely better. Lean and Six Sigma are the tools I use to do it, but they are tools, not the point. Used well, they remove waste and variation; used badly, they become a training programme and a wall of certificates while the actual flow stays exactly as slow as it was.

I treat a process the way an engineer treats a system: measure it as it really runs, find where time and quality are lost, redesign the flow, and prove the gain against a control. That discipline is how a billing approval cycle I worked on was compressed from roughly two months to fifteen days across 75 entities and more than 2,000 employees — not by working harder, but by removing the steps that existed only to compensate for an earlier failure.

The aim is always capability you keep. I would rather leave your team able to run the next transformation themselves than leave behind a dependency. Standard work, the right measurement, and a team that understands why the flow is shaped the way it is — that is what makes the gain hold.

01The problem

Processes accrete. They are designed once for a smaller company and then patched, never re-engineered, until the work carries years of accumulated handoffs, approvals and rework nobody can quite justify. Transformation initiatives often make this worse — a wave of training, a certificate count, and a methodology imposed on top of the mess rather than used to remove it. The flow never actually changes.

02Signs you need this

When this is the right call.

  • 01

    Cycle times have crept up and nobody can say exactly why

  • 02

    The process carries approvals and checks no one can justify

  • 03

    A previous transformation produced certificates but no measurable change

  • 04

    Rework is treated as normal rather than as a defect to be designed out

  • 05

    You are about to automate a process you have never actually re-engineered

  • 06

    Improvements are claimed but never proven against a baseline

03The method

How the work goes.

  1. 01

    Measure the real process

    Map the work as it is genuinely done — including the workarounds — and put numbers on it: cycle time, rework rate, where value is added and where it only waits.

  2. 02

    Engineer the flow

    Remove the steps that exist only to compensate for an earlier failure. Re-sequence, automate where it pays, and design the handoffs so quality is built in rather than inspected afterwards.

  3. 03

    Prove it with data

    Run the change as an experiment with a control and a measured result. Lean Six Sigma is the discipline here — used to prove the gain is real and not seasonal noise.

  4. 04

    Standardise and sustain

    Lock the improved process into standard work, with the measurement that signals drift before it becomes regression.

04In depth

What this work really involves.

Measure the process as it is, not as the SOP says

The single most common mistake in transformation is to redesign the documented process rather than the real one. The documented process is tidy; the real one is full of workarounds people invented to get the job done despite the design. Until you map the work as it is genuinely performed — the shadow approvals, the re-keying, the waiting — you are optimising a fiction. I start every transformation by measuring the actual flow: cycle time, rework rate, and the difference between time spent adding value and time spent merely waiting.

Remove the steps that only exist to fix an earlier failure

A surprising share of any mature process is compensation: an extra check, a reconciliation, a sign-off that exists only because something upstream cannot be trusted. Cut the upstream defect and the downstream compensation becomes pure waste you can delete. This is where the largest gains usually hide — not in speeding up the steps, but in deleting whole steps that should never have been necessary. It is also why simply "automating the process" often cements the waste in place instead of removing it.

Lean Six Sigma as proof, not theatre

The reason to run a change with a control group and a measured result is not methodological vanity; it is to know whether the gain is real or just this quarter’s good luck. Six Sigma’s contribution is rigour about variation and evidence — distinguishing a genuine improvement from noise, and a sustainable one from a temporary push. I use the methodology to prove the result to a sceptical CFO, not to count belts. If the data does not support the claim, the claim does not get made.

Standard work is what makes the gain permanent

Processes regress. The improved flow you install will quietly decay back toward the old one unless it is locked into standard work and watched by a metric that signals drift early. The last stage of every transformation is therefore the least glamorous and the most important: documenting the new standard, training to it, and wiring in the measurement that catches regression while it is still small. A gain you cannot hold is not a gain; it is a story you tell about last year.

Why automation without re-engineering fails

The most expensive mistake in transformation is to automate a broken process. Automation is faithful — it will reproduce the waste, the unnecessary approvals and the rework at higher speed and lower cost, cementing the bad design into software that is now hard to change. The order matters: re-engineer the flow first, prove the simpler version works, and only then automate what remains. Done in that sequence, automation pays for itself because it is mechanising a process that genuinely needs to exist. Done in the reverse order, it locks in the very steps a transformation was supposed to remove, and the business spends the next three years maintaining its own mess in code.

Reading a process the way an engineer reads a system

An engineer does not ask whether a system feels busy; they ask where the time goes and where the failures originate. The same discipline applied to a business process is unreasonably effective. Every step is interrogated: does it add value, or does it only inspect, wait, or compensate for an earlier failure? Where does variation enter, and what does it cost downstream? Which handoffs lose context? This is not abstract — it is the difference between an opinion that the process is "too slow" and a measured map showing that sixty percent of cycle time is queueing between two teams that could be merged. The map is what makes the redesign obvious rather than contentious.

Capacity you release without hiring

When a process is carrying years of accumulated rework and unnecessary steps, the people running it are spending a large share of their time on work that should not exist. Remove that work and you do not just shorten the cycle — you give those people their hours back. Re-engineering routinely releases meaningful capacity without adding a single headcount, which is the most defensible kind of efficiency: nobody is asked to work harder, and the released capacity can be pointed at growth instead of firefighting. For a CFO, this is the rare improvement that lowers cost and raises throughput at the same time, proven against a baseline rather than asserted in a slide.

05What it looks like

What an engagement looks like

  • Scoped to a specific process or value stream with a measurable target
  • Methodology used as a tool, never imposed as dogma or certificate-counting
  • Capability transfer so your team can run the next transformation
  • Works alongside an existing PMO or transformation office

Outcomes

  • Cycle times compressed — often dramatically — with the rework removed
  • Capacity released without adding headcount
  • A proven, data-backed result rather than an asserted improvement
  • Standard work your team can hold without external support
Discuss this engagementSee the results

Questions

Common questions.

No. The methodology originated in manufacturing but applies to any repeatable process — billing, onboarding, claims, content production, client delivery. Anywhere work flows through steps with cycle time and a defect rate, the same discipline of measuring, re-engineering and proving the gain works. Most of my transformation work has been in services and delivery operations, not factories.

Capability transfer is part of the work, but the engagement is a transformation, not a course. The goal is a re-engineered process with a measured result, plus a team that understands why it is shaped that way and can run the next one. I would rather your people learn by doing a real transformation with me than collect certificates.

By running the change as an experiment with a baseline and, where possible, a control — then measuring the result against it. That is the core of the Six Sigma discipline: distinguishing a genuine, sustainable gain from seasonal noise or a temporary push. The result is a number a sceptical CFO can rely on.

It works alongside them. I bring the engineering discipline to a specific process or value stream while your PMO retains governance of the portfolio. In many cases the engagement also lifts the PMO’s own toolkit, leaving it better able to run measured transformations after I have gone.

It depends on the breadth of the process and how much of the change is re-engineering versus automation, but a focused transformation of a single value stream typically runs over a few months: a measurement and mapping phase, a redesign and pilot, then standardisation. The aim is to show a proven, measured result rather than to run an open-ended programme. Larger, multi-process transformations are sequenced into discrete pieces, each with its own target, so value lands along the way instead of all at the end.

Lean is about flow and waste — removing the steps, delays and handoffs that add no value, so work moves faster and lighter. Six Sigma is about variation and defects — using data to reduce the inconsistency that produces errors. They are complementary: Lean makes the process faster, Six Sigma makes it more reliable, and together they make it both. I use whichever the problem calls for rather than applying a methodology for its own sake; the tools serve the result, not the reverse.

Some, yes — measuring the real process requires seeing how work actually flows, which usually means access to the relevant systems, timestamps and a sample of live work. The depth of access is scoped to what the analysis needs and nothing more, and it is handled with appropriate confidentiality. The better the data we can see, the more precise the diagnosis and the more defensible the proof of improvement at the end.

You are left with a re-engineered process locked into standard work, the measurement that signals drift before it becomes regression, and a team that understands why the flow is shaped the way it is. The improvement is documented and owned internally, not dependent on me. Where it is useful, I stay available for a defined period to support the transition, but the design goal is a process your own people can hold and improve without external help.

Other ways I work

01

Fractional COO

An operating partner inside the business — not a deck about it.

02

Business Excellence & Quality Audits

A clear, evidenced read on how good your operation really is — and where it will break.

04

Operations Governance & BI Systems

The measurement and decision rights that let leadership steer, not guess.