In the previous articles, we established three foundational ideas.

First, successful automation depends on scaffolding - both technical and human - not just better prompts or models.

Second, evaluation metrics must reflect the real subjectivity in your process.

Third, momentum comes from winnowing - separating straightforward cases from judgment-heavy ones so you can ship safely and learn quickly. This increases automation momentum — and equally important, it creates visbility for the policy teams to resolve the ambiguities that volume had previously hidden.

Once these foundations are in place, as you winnow more, a new question emerges:

How consistent are your automated decisions?

Especially in a Gen-AI powered system which almost always gives different responses for the same questions.

Needless to mention, in the world of operations - consistency is what turns isolated success into dependable execution.Inconsistent automated decisions aren’t just a technical nuisance. They carry a real business cost - they’re a compliance and repricing liability.

Measuring consistency

A useful way to think about consistency is through an analogy familiar to many operations leaders: Gauge R&R studies

In those studies, the same measurement is repeated multiple times under identical conditions to test repeatability. If the same part produces different measurements each time, the measurement system cannot be trusted—no matter how sophisticated the tool.

GenAI systems require the same discipline.

The principle is simple:

Given the same inputs, how often does your system produce the same decision?

Let us return to the running example from the previous articles - “identifying industry codes from business names”

To measure consistency, we ran the same few hundred businesses through the system multiple times, often 30 or more iterations, with identical inputs.

We then categorized the outcomes:

- Cases that produced the same code every time

- Cases that alternated between two plausible codes

- Cases that fluctuated across three or more codes

That alone provides useful insight. But operationally, it is still incomplete.

The real question is:

Does this variation actually matter?

So we went one step further. What counts as material variation is not universal - it is defined entirely by your downstream decision engine.

We traced the downstream impact of these variations. In particular:

- How many fluctuating codes led to different pricing outcomes?

- When pricing changed, how large was the impact?

- Did the variation create material risk, or just harmless noise?

This step is often overlooked. It should not be.

Because improving consistency always comes at a cost. It could be more prompts, more validation logic, more tokens, more latency. Before investing in tighter consistency, you must first determine whether the variation reduction is economically meaningful within the bounds of your system.

Consistency improvement is not merely a technical exercise. It is an ROI decision.

Understanding the sources of variation

Once variation is measured, the next task is to understand why it exists.

GenAI systems, at their core, are probabilistic engines. Even with identical inputs, slight shifts in interpretation can lead to different outputs. But in practice, most variation is not random. It usually traces back to identifiable causes. In fact, the largest driver of variation was not the model, but disagreement between reference sources that humans had silently worked around for years. The list boils down to the usual suspects - conflicting signals in inputs, broad prompts, inconsistent reference material, genuine business ambiguity and some inherent randomness attributable to LLMs.

Let us understand it better with an example. In the example of business code determination,

• There could be multiple businesses with the same name, especially with the common names

• Your reference manual to classify the business could be inconsistent or overlapping

• The business could claim to do multiple things - which doesn’t neatly fit into a classification code

Improving consistency - knowing the trade-offs

Once sources of variation are understood, the next step is choosing interventions. Each intervention improves consistency - but at a cost. Operational leaders must choose deliberately.

Some of the ways that worked for us,

Strengthen input gating

Many inconsistent outcomes originate from ambiguous inputs. By tightening input acceptance criteria—an idea introduced earlier in the winnowing discussion—you prevent problematic cases from entering automated paths.

Trade-off: Reduced coverage.

You improve stability, but fewer cases qualify for automation. In one of our implementations, we could only process 2/3rd of the eligible volume due to the strict gating criteria. Needless to mention, as we bring more clarity on the rules, we will be able to increase this number by winnowing more.

Break problems into atomic steps

Complex decisions are often better handled as sequences of smaller, explicit judgments rather than a single large prompt.

Best practices include:

- Using structured prompts

- Providing clear examples

- Encouraging the system to abstain when uncertain

Trade-off:Increased latency and token usage

You gain clarity and control but consume more compute. In our case, each additional call to a reasoning LLM costed us more tokens and significantly more time (about 30 seconds per reasoning call)

Stabilize reference material

If your decision depends on external knowledge, the reference layer must be reliable.

If reliance on model memory introduces ambiguity, consider using curated reference systems such as retrieval-based architectures(RAG)

Trade-off: Latency and infrastructure cost

But the gain in determinism is often substantial. But it costs more. Even with a semantic search, this increased our token consumption by 3x.

Introduce corroboration logic

When ambiguity cannot be avoided, narrow the set of possible outcomes and use additional evidence to confirm the final decision. This mimics how experienced operators behave—cross-checking before committing.

Trade-off: Latency and system complexity. This requires you access to the web or database or other details of the application making the system more complex.

Use consensus mechanisms

In high-risk decisions, multiple models or evaluators can be used to reach consensus.

Agreement across independent evaluations increases reliability.

Trade-off: Token consumption and processing time

This approach should be reserved for decisions where the cost of error is significant.

To sum it up, all of our endeavors in improving consistency from the initial implementation increased the cost by 3X token and latency by 6X. But it was a deliberate and conscious choice as the automation formed the bedrock of all the decisions that follow.

It was a deliberate choice to get the foundation right, but not a permanent one. We are actively working on optimizing the system now that the consistency baseline is established.

The sequence matters: stabilize first, then optimize. Doing it the other way around is how you end up optimizing for the wrong thing.

Consistency is not a one-time certification

Many teams treat consistency testing as a milestone. That is a mistake.

Consistency drifts over time.

Inputs evolve. Policies change. Reference data shifts. Models are upgraded.

Without periodic testing, drift goes unnoticed until failures surface in production.

Two practices are essential:

- Repeatability testing at defined intervals

- Continuous monitoring for decision drift

Golden datasets—introduced in earlier discussions on evaluation—remain valuable here. They provide a stable reference point for tracking change across system versions.

The real lesson

Consistency improvement is not free.

Every additional layer of determinism consumes time, tokens, infrastructure, or coverage.

Before tightening your system, ask:

• Does the variation materially affect outcomes?

• Does it introduce operational risk?

• Does reducing it produce measurable value?

If the answer is yes, invest deliberately.

If not, accept bounded variation and move forward.

Operational excellence is rarely about perfection.

It is about controlled reliability.

The wise old elf was right — variation is the spoiler that forces you to choose what actually matters. You can’t fight all of it. Pick your battles deliberately.

Where this leads next

At this stage in the journey, most organizations have:

• Defined realistic evaluation metrics

• Built momentum through winnowing

• Stabilized decision consistency

What remains is the final challenge - in the ‘think big, start small and scale fast’ triad.

How do you scale the automation, measure the impact and govern these systems at scale. That’s where we go next.

In the previous articles, we discussed why context alone isn’t enough and how to set evaluation metrics that reflect reality. Once you have a statistically sound way to measure success, the next challenge is momentum.

The biggest killer of GenAI pilots is the “all-or-nothing” fallacy: the belief that if a model cannot handle the solid majority of cases, it is not ready for production. This perfection trap stalls teams indefinitely. The practical way out is the art of winnowing separating the straightforward cases from the messy ones, so you can ship, learn, and iterate without breaking the business.

A fair objection here is: aren’t we just optimizing for what’s easy, not what’s valuable? Sometimes the messy cases do carry most of the risk or economic impact. That is true. Winnowing is not a value strategy; it is a delivery strategy. It buys you learning velocity, operational trust, and stable foundations so you can tackle the high-impact complexity deliberately instead of betting everything on a brittle big bang.

---

The Three-Step Framework

To winnow effectively, you must identify process forks—the points where a case stops being straightforward and requires judgment, policy interpretation, or human context. These forks typically appear in three places.

Step 1: Input Gating

Analyze the segments of your input. Identify which ones are “clean” and which require nuanced treatment. If the data entering the system is ambiguous, downstream automation will almost certainly fail.

Step 2: In-Process Logic

Once the input is accepted, identify where rules blur during execution. These are the places in your SOPs that say, “It works this way for most, but it depends for the rest.”

Step 3: Output Resolution

Finally, look at the decision stage. Nuance often creeps in at the time of the final choice. If the AI cannot reach a high-confidence conclusion based on defined rules, the process must fork to a human.

A simple example: Industry code identification

Consider a common task: identifying industry codes for a firm. At a high level, it sounds simple. In practice, the forks look like this:

- Input Forks: What if the business has no website? What if three firms have nearly identical names?

Winnowing action: Automate only firms with a verifiable, unique digital footprint.

- In-Process Forks: What if the business claims to do multiple things? Which source do you trust if the website contradicts a registry?

Winnowing action: Automate firms with a single dominant activity; flag multi-activity firms for review.

- Output Forks: What if a business qualifies for two codes with equal validity? How do you separate high-confidence from lukewarm matches?

Winnowing action: Automate cases where the confidence delta clears a defined threshold; route the rest.

Fixing the running train

Scaling AI in workflow automation is never a zero-to-one move. You are fixing a running train. Business continuity matters as much as transformation(if not more).

By prioritizing the straightforward subset, you keep evaluation honest and production stable. This provides the air cover needed to iterate on the messy cases that usually carry the most learning and, often, the most value. Over time, the boundary should move.

A note of warning: Stay close to the Gemba

Winnowing carries a real risk: false segmentation. Your segments must be carved along the natural fissures of the work itself, not along what is convenient for data access or system boundaries. If you segment by region because the data is easy, but complexity is actually driven by product type, you will hit the same walls again.

Finally, be honest about the optics. Winnowing can make metrics look good if you forget to report coverage. Always pair performance with the percentage of volume automated.

Well begun is half done. Now, let’s get it done.

How are you evaluating your AI automation of operational workflows?

This is the second article in a multipart series on AI-driven workflow automation. If you have not read the previous article on scaffolding, I recommend starting there, as this piece builds directly on it.

---

The problem with evaluation metrics

Many pilot programs, including ones I have personally worked on, begin with a simplistic and idealistic view of evaluation:

“Replicate humans. Period.”

By how much?

“Let’s say 99 percent.”

That sounds ambitious. Too ambitious?

“Fine, let’s start with 90 percent.”

Nice round numbers. Comforting. Familiar.

They are chosen much like p-values in statistics and machine learning. Rarely questioned. And even when they are, the discussion is usually framed using analogies to surveys or industry benchmarks.

What is missing is a customized, objective view grounded in the reality of the specific process being automated.

An arbitrary evaluation criterion can do real damage.

• Set it too low, and you build weak guardrails that create downstream risk.

• Set it too high, and the pilot never scales because the targets are unnaturally steep.

• Choose the wrong metric, and you gain false confidence.

So how should this be done?

Yes, the intent is often to replicate human decision-making.

But it needs to be done in a deeper and more honest way.

Step 1: Understand the subjectivity of the metric you are trying to compare

Think of any operational decision as lying on a spectrum.

At one extreme, it is completely objective.

For example, counting the number of cheque bounces in a bank statement.

At the other extreme, it is highly subjective.

For example, deciding whether a slightly blurry bank statement is acceptable.

A simple rule of thumb helps here:

Given the same input, is it possible that two competent operators arrive at different outcomes?

If the answer is no, the decision is straightforward and strict matching may be appropriate.

Most of the time, however, the answer is yes.

One important caveat:

If subjectivity stems from an ambiguous policy no evaluation metric will stabilize automation. Those issues must be addressed first.

Step 2: Identify the sources of subjectivity

Once you acknowledge subjectivity, the next step is to understand where it comes from.

Consider a common step in lending workflows: identifying the industry of a business based on its name and description.

Different analysts may arrive at different classifications for several reasons:

1. The business may operate across multiple activities that do not map cleanly to a single industry code.

2. The business description may vary across sources such as the website, directories, and registrations.

3. The bank statement may reveal a revenue pattern that conflicts with the stated business activity.

4. Analysts may prioritize different sources or interpret the same information differently based on experience.

These are not edge cases. They are the norm.

The best way to uncover these nuances is by combining process intelligence, such as process mining and task mining, with Gemba. Observing operators in action builds intuition about both the causes and the extent of variation in your evaluation metric.

Step 3: Choose an evaluation criterion that reflects reality

With this understanding, you can now choose an evaluation approach that mirrors how the process actually works.

In the industry classification example, is a strict one-to-one match the right metric?

It can be measured. But it may not be the right gating criterion.

Alternatives such as top-k matches or common-intersection matches between humans and AI often better represent alignment with human reasoning.

If your downstream system insists on a single auditable value, you can still enforce deterministic resolution rules, while using top-k or intersection-based alignment as the evaluation gate.

There is no universally correct answer here.

The right metric is the one that best reflects your process reality, risk tolerance, and decision context.

Step 4: Build a statistically sound golden dataset

Once the metric is defined, select a statistically significant golden batch.

This is not new territory. Use standard sampling principles to ensure the dataset is representative of real volume, variability, and complexity.

Also remember that golden datasets have an expiry date. They remain golden only as long as they continue to represent the process. As policies, volumes, and behaviors drift, evaluation datasets must be refreshed.

Step 5: Measure human-to-human variation

Have multiple operators, with varying levels of expertise, independently execute the process on the golden batch in a blind manner.

Compare their outcomes.

This exercise gives you a clear picture of the natural variation that already exists among humans. This variation defines feasibility bounds and highlights where judgment, ambiguity, or inconsistency lives.

To be clear, this is not an argument to institutionalize human variation in automated systems. The goal is to minimize it. However, once you choose the metric you want to hold your AI system to, you need a well-rounded understanding of current human performance in the system.

Why this matters

By following these five steps, you achieve three outcomes.

First, you define an evaluation metric that is fair, defensible, and grounded in your specific process.

Second, you quantify existing human variation, which allows you to set realistic and meaningful targets for your GenAI pilot.

Third, you give decision makers confidence that automated performance is comparable to or better than current operations.

Closing thoughts

Replicating humans is not the ultimate goal of automation. Consistency, risk reduction, and scalability often matter more. But human performance remains a reasonable and practical starting reference.

Workflow automation using GenAI is often a deeply reflective exercise. It forces organizations to confront their own process maturity, policy clarity, and decision consistency. Done systematically and objectively, this approach provides the confidence needed to move beyond pilots and into scaled deployment.

With evaluation clarity in place, we can now move forward to assessing AI performance against meaningful metrics and strengthening workflows through scaffolding.

Well begun is half done.

PS: Following are links to some of the arXiv papers I found useful on evaluation methodologies. The measurement system analysis in Six Sigma also deals elaborately with quantification of variation in the measurement system.

https://arxiv.org/abs/2307.03109 - A survey on evaluation of large language models

https://arxiv.org/abs/2309.16349 - Human feedback is not gold standard

The same models that can solve extremely difficult exams, write code, reason about physics, and summarize dense legal texts often struggle to replace a junior operations analyst following your process.

Your first instinct might be to say, “Ah, the model is missing context.” But that explanation is too convenient, and more importantly, it does not actually solve the puzzle.

So what is the missing ingredient that turns GenAI brilliance into real automation?

The answer lies in scaffolding, and not just technical scaffolding that shapes the system. Equally important is non-technical scaffolding that shapes human behavior around the system.

Let me explain.

Anyone who has spent time in real operations knows that actual processes are far messier than what appears in your process maps or SOPs. They are full of exceptions, shortcuts, unwritten rules, judgment calls, and “this is how we do it here” habits that rarely make it into documentation.

GenAI experts do not usually come in to fix this mess. In fact, their biggest contribution is often to reveal it.

How? By building a GenAI proof of concept based strictly on your documented process, only to find that it matches human decisions for a surprisingly small fraction of real cases. Suddenly, what looked clean on paper looks chaotic in production.

The instinctive reaction at this point is predictable:
“See? It doesn’t work. Maybe the next version of ChatGPT will be smarter. Let’s move on to another POC.”

Except that this misses the real insight.

What the low match rate is actually telling you is that your process map was incomplete. The nuances, exceptions, and tacit knowledge never surfaced in the one-hour demo where an analyst walked the GenAI team through a few happy paths and a couple of edge cases.

At this stage, many organizations jump to a neat-sounding solution.

“Let’s fix the process first. Make it consistent. Document everything from L1 to L5. Then feed that context to GenAI. Problem solved.”

That sounds reasonable until you try doing it.

Anyone who has seriously worked on process improvement knows this can take months, years, or sometimes forever. Many “process gaps” are actually policy gaps in disguise. Others are pragmatic exceptions that keep the business moving under time pressure or incomplete information. Cleaning all of this up before touching GenAI is rarely realistic.

So what is a more practical way forward?

Instead of treating GenAI automation as an all-or-nothing, end-to-end transformation, think in salami slices.

A workable playbook looks like this:

1. Observe the real work, not just the process map.
   Use process analytics, but also do Gemba. Sit with analysts, watch how they actually make decisions, and listen to why they do what they do. This surfaces the “rules of the jungle.”

2. Understand what today’s GenAI models are actually good at.
   More often than not, current models are capable enough to handle a meaningful portion of what humans already do, just not everything.

3. Pick the cleanest segments first.
   Identify parts of the process where decisions are relatively consistent and rules are clear. Automate those first. Your match rates here will be high because these are genuinely straightforward cases.

4. Adjust policy and process to support partial automation.
   Do not wait for perfect process. Improve it incrementally around what you automate.

5. Repeat.

In practice, what has worked for us is a simple but powerful “cheat code.” Separate the straightforward cases from the messy ones. Let GenAI handle what is already consistent and high-agreement. Let humans continue managing the judgment-heavy, ambiguous cases, but make those cases visible and learn from them over time.

One slice at a time, before the next iteration - process gets cleaner, the automation gets broader, and the overall system becomes more reliable.

In my next article, I will describe the scaffolding patterns, both technical and non-technical, that have made this approach work in practice.

Interested? Read on.

TLDR: Most Gen AI projects in operations do not fail because of weak models. They fail because the process they are meant to augment is only half understood. The real unlock comes from layering process intelligence end to end: the intended design, the execution patterns, and the human reality uncovered only through Gemba. A simple example from industry classification shows how each layer reveals hidden nuances that completely change how AI should be evaluated. If you want meaningful lifts in operational AI, start by understanding how the work is truly done.

WHY ENTERPRISE AI STALLS?

Enterprise AI adoption is nowhere near expectations.

The stock market calls it a bubble. McKinsey in its state of AI report notes that over 67% percent of projects have not taken off. Illiya Sutskever recently remarked that the ‘economic impact is dramatically behind’.

From my experience in operational AI, the missing ingredient in many cases is the lack of process intelligence.

Not model tuning.

Not larger context windows.

Not more GPUs.

Just a weak understanding of the process the model is meant to support.

MISSING LAYER – FULL STACK PROCESS INTELLIGENCE

Process intelligence is not one concept. It is a stack.

It has three layers:

* The intended design that sits in the process repository

* The execution patterns observed through process mining and task mining

* The human reality that drives how work is actually done

Most teams capture the first two. Very few understand and acknowledge the third.

Focus groups and demos cannot give you the tacit knowledge. They capture only the dominant and palatable version of the process. The exceptions, the shortcuts, the edge cases and the tribal knowledge emerge only through Gemba. That is, by observing operators in action, repeatedly and without filters.

HOW DOES THIS SHAPE GEN AI IMPLEMENTATION?

Let me illustrate this with an underwriting example.

Classifying a business into the right industry code is a foundational task. If you get this wrong, every downstream decision suffers. On the surface, the task is simple. Read the description. Compare it to a taxonomy. Pick the closest SIC or NAICS code. Prompt it. Evaluate it on a golden batch.

Done? Not really.

Here is how the understanding evolved.

STAGE 1: The Big Picture View

From the process repository and a few demos, the task looks straightforward.

You classify the business and match it to the code.

You think a simple prompt should work.

Evaluation should align with human choices. 95% of the times.

Except, it does not.

Why?

STAGE 2: The Process Mining View

Process mining shows that the average handling time is X minutes, but the distribution is bimodal. Some cases are very quick. Some take disproportionately long.

Why the split?

STAGE 3: The Task Mining View

Task mining shows that in long cases, operators do not rely only on the business website. They jump between many sources. Aggregators. Filings. News. Prior data. And sometimes pure intuition built over experience.

This is not randomness. It is accumulated judgment.

Why do they do this?

STAGE 4: Gemba Walk (or) watch

Only when you sit with operators, or better, do the task yourself, do the real insights emerge.

Questions start surfacing.

What if a business claims to do multiple things?

What if the business has almost no online presence?

When different sources list different services, which one do you trust?

What quirks in the classification system require compensating logic?

Should success really be measured by exact alignment?

**That last question flips the entire evaluation strategy.**

Many Gen AI projects fail not because the model or prompts are inadequate, but because the evaluation criteria are disconnected from operational reality.

FULL-STACK PROCESS INTELLIGENCE SHAPES AI SUCCESS

The real work is not linear. It is iterative. You slice through each layer of process intelligence, and you adjust your AI evaluation framework accordingly.

You start asking better questions. Process intelligence helps you with those questions.

This is the boring superpower. The unglamorous part that does not make headlines. Yet it determines whether AI initiative succeeds or stalls.

FINAL THOUGHTS

In Gen AI implementation, the model is rarely the problem.

The real unlock comes from the overlooked layers of process intelligence, especially the human reality you uncover only through Gemba.

Next time you want a next lift in your operational AI program? Plan a Gemba walk, or better, try becoming the operator.

PRO TIP

We were fortunate to accelerate this learning with a seasoned veteran like Steve guiding the process. Someone who has seen enough operations to know where the real constraints and real signals lie. Try finding your Steve.

For most of us, work happens through fragmented processes across legacy systems. In such setups, even the best process mining tools hit a ceiling. So what’s the way out? One answer is task mining. When combined with AI, task mining helps you recover lost process intelligence, piece by piece.

The Problem: Invisible Work Between the Systems

Not all processes move at the same speed. Take SME lending as an example. Collections and legal recoveries stretch for months, but credit analysis happens in minutes. Hundreds of checks and judgments get compressed into a short burst.

Much of this work lives outside transactional systems, in spreadsheets, browsers, emails, documents and ad-hoc shortcuts. It doesn’t follow a strict sequence either. Seasoned analysts optimize for efficiency, similar to how an experienced trauma physician moves faster than a junior one.

The result is clear

Process mining sees only part of the truth.

Time and motion studies cannot scale.

Transformation priorities often get decided by anecdotes instead of data.

The Bridge: Task Mining Meets AI

Task mining captures user-level logs such as applications opened, sites visited, and shortcuts used, while protecting sensitive data through anonymization. It is like putting a microscope on digital work.

But scaling this comes with noise. Chat windows, re-checks, and partial retries pollute the data. Without filtering that noise, the insights remain shallow.

This is where large language models come in. By combining pattern-recognition algorithms with language-model reasoning, we can identify and exclude irrelevant activity, segment meaningful sequences, and assign precise start and end times to each work block.

Feed that cleaned data into process mining, and suddenly you have visibility into fragmented human workflows, the missing layer between systems.

The Payoff: From ROI to RO-AI

Even if your core systems are not perfect, task mining gives you a way to make data-driven transformation decisions. You will know which activities consume time, where variability hides, and what training or policy refinements move the needle. It is not perfect, but gives you a good return on investment(ROI) and eventually, the multifold return on AI(ROAI).

Sure, there is no AI without PI. But with task mining and LLMs, AI can also create better PI, completing the circle of operational life.

Just like individuals, organizations face a similar conundrum. There is a subtle fear of missing out and a constant urge to adopt the latest technology that promises to boost productivity. This is largely positive since technology often brings the biggest efficiency gains. From ERPs and CRMs to automation, Generative AI, Agentic AI, and now the latest ‘Operator’—each of these technologies has successfully reduced grunt work in processes, allowing operators to focus on tasks they truly enjoy or, more broadly, those that machines cannot replicate.

The boundaries of automation continue to expand. As a result, digital transformation has become an ongoing journey—organizations exist in a state of perpetual beta. But what can supercharge these efforts? A deep understanding of process variation. Let’s explore why addressing variation is critical to digital transformation.

Well begun is half done. The first step is to understand and attribute process variation.

Attributing variation in a process to the right cause helps us determine the most effective solution. Let’s examine three common sources of variation—policy, process sequence, and people—to understand their impact and how they can be addressed during transformation.

1. Policy-Induced Variation

Organizations must constantly assess policies to determine whether they have outlived their purpose or are too complex to implement relative to their benefits. Some policy variations may have been introduced to address legitimate needs but, when left unchecked, can lead to inefficiencies—akin to the proverbial case of “tying a cat to a tree.”

Fortunately, policy variations are the easiest to address—by rationalizing, simplifying, or, in many cases, eliminating them. Through objective quantification, their impact can be measured, leading to informed decisions. In my experience, removing redundant policies before transformation delivers the highest returns with minimal effort.

2. Process Sequence Variations

Even when policies remain unchanged, the same set of activities might occur in different sequences. While this may seem counterintuitive, it is common in complex or organically evolved processes.

Studying the major variants in process sequences can reveal why these variations occur. They may arise due to practical execution preferences, tacit tribal knowledge within teams, or simply a lack of standardization.

To address this, organizations should apply simplification and standardization—the same approach used for policy variations. Additionally, augmented intelligence solutions (with humans in the loop) can help determine the optimal sequence based on real-time inputs. An intelligent assistant can further optimize execution by dynamically adapting to specific case requirements.

3. People Variation

After accounting for policy and process sequence variations, what remains is human variation. This stems from differences in knowledge and skill levels between operators (reproducibility) and variability in the same person’s performance over time (repeatability).

While traditional solutions involve training and incentives, augmented intelligence can significantly mitigate these variations. Conducting a Gemba study (observing frontline operators) can uncover best practices and key performance drivers. Incorporating these insights into product design can enhance team-wide performance, ensuring that processes continually evolve to meet operational needs.

Optimizing Transformation Spend with Variation Analysis

Understanding process variations allows organizations to optimize transformation costs in two key ways:

Lean Spending: Eliminating or rationalizing unnecessary variations before transformation reduces complexity and ensures a more focused investment.

High-Impact Prioritization: Not all transformation efforts yield the same ROI. By identifying and prioritizing the process areas with the highest potential, organizations can allocate resources more effectively.

Ensuring Long-Term Process Control

Beyond cost optimization, a deep understanding of process variations grants greater control over transformed processes. Organizations need to establish clear expectation norms and use available technology to detect deviations. Continuous monitoring enables proactive identification of new sources of variation, ensuring consistent and efficient outcomes.

Final Thoughts

Addressing process variations is not just a complementary effort—it is essential to successful digital transformation. With organizations operating in perpetual beta mode, having a hawk-like focus on process variation can deliver significant dividends by driving efficiency, consistency, and adaptability.

Do you agree? What has your experience been? What best practices do you follow to integrate variation reduction into digital transformation efforts?

A few days ago, my manager, an operations veteran, asked me to suggest a book that would help him get an overview of process engineering, especially in the services industry. I instinctively turned to the quick reference section of my bookshelf to suggest some titles. I had books on topics spanning data science, operations research, problem-solving, lean thinking, and the formidable Lean and Six Sigma Body of Knowledge (BOK). However, I couldn’t suggest a single title right away. What would give an overview of process engineering? This hesitation made me reflect: Is process engineering just the sum total of all this knowledge? Or worse, with the new fear that has been unlocked - have all these been made irrelevant in the age of large language models (LLMs) trained on process mining libraries?

The Overlapping Skill Groups

I’ll try to answer the question based on my experiences. My unconventional career path across disciplines has enabled me to collect a diverse set of skills. Over time, I’ve come to realize how these skills complement each other and help me excel in my role as a process engineer.

Let’s begin by exploring the broad skill groups essential for a process engineer in the services industry. These include interpersonal skills, structured problem-solving, data science, technical/IT skills, and management. While these skill groups often overlap, they are mentioned separately to underscore the importance of gaining deep experience in each area. This approach offers multiple benefits: not only does expertise help solve problems more efficiently, but it also enables the identification of opportunities for improvement before customers recognize a need.

As Henry Ford famously remarked, “If I had asked people what they wanted, they would have said faster horses.” Similarly, process owners or sponsors might not know what they truly need until it is presented to them. By developing expertise in these areas, process engineers—who closely observe how work gets done—are well-positioned to contribute significantly to the transformation agenda, making connections that drive meaningful change.

Interpersonal Skills: The Foundation of Collaboration

Think of processes as an invisible thread that connects and holds an organization together. This analogy highlights not only the all-encompassing nature of processes but also the fact that they often operate behind the scenes, out of direct sight. Processes are essentially a sequence of steps defined by business owners, executed by operations teams, and supported by product and IT systems developed and maintained by their respective teams. For process engineering teams to implement and sustain successful changes, they must collaborate closely with all these stakeholders. This requires building trust and mastering key interpersonal skills such as effective communication, empathy, negotiation, and conflict resolution. As one becomes more senior, these skills start getting more significant and can determine the effectiveness of the process engineering program.

Structured Problem-Solving: The Playbook for Success

Structured problem-solving is the backbone of process engineering. It involves breaking down complex issues into manageable parts, identifying root causes, and systematically developing solutions. Tools and frameworks like PDCA, Six Sigma, Lean thinking, and the Theory of Constraints are essential playbooks that help a process engineer navigate problem-solving with a sequence of what to do, when, and, importantly, what not to do. I believe that we have come past the days of DMAIC milestone reviews, but the essence of problem-solving frameworks is more relevant and valuable than ever.

Data Science: Beyond segmentation analyses

Advanced statistical data analyses and simulations have always been part of the process engineering toolkit. I remember that proficiency in Minitab was a prerequisite for passing the black belt certification exams. But stopping with that will not help us leverage the enormous potential that the data-science techniques offer.  There are machine learning methods that can be used to do segmentation and correlation analyses at speed and scale that would be impossible for humans to replicate. Think of it as an intern who can augment your decision-making by doing a lot of pre-processing and mundane chores. I have also worked on some projects where techniques like clustering and market basket analysis yielded some insightful findings during the ‘analyse phase’ of the project. More recently, at the intersection of data science and process science - ‘process mining’ has been superpowering every stage of the process improvement or transformation workflow.

Technical/IT Skills: Bridging the Gap Between Problems and Solutions

Knowledge of technical / IT skills is becoming increasingly crucial for process engineers, especially in service industries where digital transformation is a key efficiency driver. Understanding the various options available – multiple types of automation, web / mobile applications, low code software, etc., will help you choose the best tool for the job. Considering the nature of the job and the constraints one is operating with; this knowledge will help decide the proper intervention for need. In addition to this, having a basic understanding of waterfall and agile software development approaches will help you effectively partner with IT teams in ensuring that the apt solutions get designed and implemented.

Management Skills: Keeping Projects on Track

Management skills are essential for process engineers, especially when leading complex projects that involve multiple teams and stakeholders. Project management, resource allocation, risk management, and leadership are all critical components of this skill set.

Effective management ensures that projects are completed on time, within budget, and with minimal disruption to operations. It also involves clear and consistent communication with all stakeholders, informing everyone of progress and any changes that might occur. By managing risks proactively, process engineers can avoid pitfalls and ensure that projects deliver the expected benefits.

The Synergies Among the Skills

The synergies among these skills are what make process engineers exceptional problem solvers. At their core, process engineers are tasked with tackling inefficiencies, addressing bottlenecks, and finding solutions to enhance service delivery. Structured problem-solving skills provide a systematic approach and a playbook for what to do and when to do it. Data science skills enable them to identify the root cause of issues quickly. In the solution stage, technical/IT skills allow them to collaborate effectively with the right teams and choose the best technology to implement solutions. Management skills ensure that projects stay on track, risks are managed, and communication is clear and consistent. Finally, given the interdepartmental nature of problem-solving, interpersonal skills are foundational—they multiply the effectiveness of all other skills, ensuring that collaboration leads to successful outcomes.

Reflecting on my manager’s request, I realized that no single book could encompass the full breadth of what process engineering entails, especially in the service industry. The role requires a deep understanding of various disciplines and, more importantly, the ability to integrate these disciplines into a cohesive approach that drives continuous improvement. More than any methodology or tool, it is about developing a mindset that embraces change, seeks out inefficiencies, and continually looks for ways to make things better.

Do you agree with this list? What other skill groups do you think are essential for a process engineer?? I look forward to seeing them in the comments!

Image credits: medium.com/hackernoon

Imagine a detective trying to reconstruct the homicide crime sequence using the clues that she's got. She speaks to bunch of witnesses and understand the major events that unfolded during the crime day. Next, she further probes into the closed circuit camera feeds, call data records, access logs etc., Now her understanding of the day gets more granular. As the next step, if she get overlay the mobile phone's location data, she can get even more precise. All of these will enhance and provide a comprehensive understanding of events that happened during the crime day. Excuse me if the analogy sounded morbid, but this is exactly what the process mining attempts to do from the event logs.

When you use your IT systems to process something, you keep creating traces of actions. It can be something like moving the application to the next stage or approving a request or anything that changes the state of the entity that is being processed. They have the basic information of who did what and when it was done. These are called event logs. In the case of a purchase order, you will have information of when it was created, approved, fulfilled and dispatched. Process mining software reconstruct the process flow with these event logs. This initial step is also known as process discovery where, all the event logs are synthesized into one single visualization, with chronological sequence of events from start to finish. This is also known as the 'digital twin'.

Does the 'digital twin' help you answer the process questions like speed, efficiency, cycle times etc.? If it does, then good enough. But there are times when you feel that event logs are not very granular. You might realize you need more visibility between two points in an event log because they quite long and a lot happens in-between. This is when 'task mining' comes to your rescue. These software collect the actions happening in the user desktop. You will be get insights on,

* How much time is spent on every application?

* How much time the user toggles between the spreadsheet and the email agent?

* How many items are copy - pasted?

There is wealth of information that gets captured, in an anonymized fashion, into the how work gets done. Now these insights can be consumed independently of process mining or can be converted into an event log and ingested into the digital twin that has already been constructed to get a more granular view of the process.

To appreciate the importance of this technology, you should contrast it to the way process discovery happened in the 'not so distant' past. Big conference rooms with wide walls were booked. The wall was segmented vertically to different sections, with one for each department. Each task was assigned a particular color and each sub-task had one post it note. Understandably, with multiple stakeholders, it gets noisy, chaotic and, at times, contentious. Initially, all the stakeholders have an 'assumption' of what the process is. But during the interaction, all of them agree on a 'perceived' process. This might a politically acceptable version of the process and still be a different version from the actual 'as-is' process. The process mining technology bypasses all these gaps and gives you an objective view of the process based on the data. That is a big cost and time lift to the way processes discovery and transformation was done. It also opens up a lot of other possibilities.

First it super charges business-intelligence. Which helps us get actionable insights on the past, present and the future. On the past - it helps us answer the basic questions like,

* How long did something take ?

* What was our processing capacity?

* How much was the utilization of the resources?

* What the extent of rework ?

* Where are the bottlenecks in the process?

* Did we meet the agreed delivery timelines?

and so on.

It also helps in answering more nuanced questions. For example, in an expense approval process, you might want to understand how many of them took the standard way and how many of them had to get an exception approval because of various reasons. Each of them is a variant of the process. Variants are different ways to reaching the same destination but through different routes. Not all variants are inefficient. But some of them definitely area. Process mining software helps you understand the different variants and compare the process measures across them. This will you focus on the ones need attention and also focus on standardization of the process, wherever possible.

Now lets discuss the present. Once you have this digital twin constructed and the various measures defined, you can use them to monitor your present. Once you plug in real time data into this system, at a very basic level, they can alert you if something is getting stuck in process. It can get more sophisticated than that. When a process sequence or state is encountered, they can even run some automations or take some preset action. It doesn't stop there. Plug this into a sophisticated AI system, they can mimic some of the human decision making as well. This suite of capabilities to manage the operational processes based on intelligence synthesized from the event logs is called 'execution management system'

The next logical thing is to extrapolate the past, use the present data and predict what could happen. Then prescribe certain actions based on the prediction. For example, based on the current work volume in progress and historical cycle times, can you predict the wait time for the new customer order that just landed up? Once you're able to answer that question, you can configure the system to do send a communication or reprioritize resources or any form prescriptive action, based on the prediction that was made. The possibilities are endless.

Now that you have a crystal ball, that answers the past, present and future - what prevents you from answering - 'what if? ' questions. Using simulation capabilities, the process mining software help you simulate scenarios like,

* What if a step was eliminated or automated?

* What if you work on reducing the time taken for a particular step?

* What if you deploy more resources for an activity?

* What if you change some policies?

Various such scenarios can be tested out and you can study how key process metrics change for each of them. This will help you make educated guesses about the process design and the corresponding tradeoff between various measures.

By now, you might have realized how each of these capabilities are going help in different phases of process management. Think of the impact it would have in digital transformation - where you first study the way work is getting done, then evaluate the kind of changes you're going to make, simulate multiple versions of it and compare them. Finally, make the changes and ensure that the processes are getting executed the way you wanted them to. Process mining software can add a lot of value in all these stages.

Another adjacent use case is in evaluating if things have happened according to the rules that have been laid out. Traditionally, during the process audits that happen on a periodic basis, random samples are selected. They are they evaluated if the necessary process steps were following in executing that case. Now with this capability, there is no need for a sample or periodic audits. All the entities are evaluated real time and any exception or deviation is flagged instantaneously. This will free up the auditing department to move up the audit value chains.

I hope this article helped you understand the essence of process discovery algorithms and big edifice that has been constructed on top of it. There are many vendors out there and they are approaching the market differently. You might want to read this article where I explore the evolution of process mining software over the last two decades. Rest assured, irrespective of the domain, this technology is going to have a widespread adoption across the board.

What are your thoughts?

Gen AI forms another stack or layer between the core process mining algorithms and the end user. This layer empowers the user with many possibilities that would have otherwise been complex or cumbersome. Across my reading and experimentation, I listed several of them and I was looking for a way to group and simplify the myriad use-cases. I came across McKinsey's article on the impact of GenAI on operations, which grouped the capabilities into four categories viz., concision, creative content, customer engagement and coding. In the next few paragraphs, I will start with an explain of what each category is and the process mining use-cases that it could unlock.

Concision

Concision refers to capability of Gen AI to interpret large corpuses of unstructured data to identify and summarize relevant answers in the service and analysis contexts. In other words, help you get to the crux of what's relevant and important.

The first concision use-case is about assisting the process analyst in generating knowledge models. Process knowledge is supposedly contained in the SOPs and the manuals. But in reality, much more nuances are present as tacit knowledge with the people close to the process. That is why, during process discovery, Gemba visits are super helpful. Its just a fancy Japanese term for being in "the actual place" and watching the operators and the process in action. This is helpful because it gives you an uncensored insights into workings of the process. In the services context, it could mean observing the operators and having detailed discussions and interviews. When these interviews are fed to the Gen AI systems, the BPMN or DMN model can be autogenerated. Using these generated models, we could execute multiple process mining use cases like quality control, process conformance, auditing etc.,

The next use case is about surfacing out the insights that need attention. This could translate to many possibilities like,

• Sentiment analysis could be performed on the in-flight cases and, in conjunction, with other process parameters like wait/cycle time, reworks, number of touches - corrective actions could be initiated if needed

• One could build an RAG(Retrieval augmented generation) systems and automatically surface out insights of importance based on the context. Different from a querying or prompting approach, this is a complete push model to filtering out and consuming relevant insights

• The RAG could be extended to give prescriptive insights based what could unfold and how it could impact given the context of the process? An example of this would be to alert when there could be a potential SLA miss for a customer with a penalty clause attached in contract

The final use case in concision is about using the GenAI to do root cause analysis. It essentially involves studying the impact of multiple factors on the KPIs of interest. While many vendors have implemented this feature using data science algorithms, Gen AI could bring in external data that is relevant to the context of process and augment the list of factors.

Creative content

Next comes, the capability of generating 'Creative Content'. It implies rapid tailoring of complex and structured documents to specific needs and contexts. Simply put, its about creating or helping co-create solutions relevant to the context.

To start with, a very straightforward use case, is about documentation of process, SOPs etc., from the technical specifications like BPMN, DMN and control charts.

The next use case in 'creative content' is about gen AI partnering with process designer in devising a solution. In one of the interviews Marlon Dumas, the founder of Apromore mentions that, the process improvement life cycle there is "big chasm" from identifying the bottleneck or the root cause to devising a solution and feels Gen-AI could play a vital role there. He also mentions that in the pilot implementation, the Six Sigma practitioners found that Gen AI suggested solutions that they would otherwise not have thought of.

Many at times, in an improvement or transformation journey, it is important to incorporate the domain expertise to meet the compliance norms or to prevent reinventing the wheel. While an experienced process engineer in the domain could bring in those design patterns, a Gen AI system could analyze the processes and suggest alternatives. Also in the process design, they could also help in the risk analysis of future state.

Customer engagement

This is the most popular Gen AI use case and it refers to the capability of building copilots that can guide customers through their personalized journeys in the realm of customer engagement. More popularly known as the democratization of process mining journey.

One straightforward use case, is in using a copilot for querying. Instead of writing complex SQLs / PQLs, the user can prompt their queries, which the Gen AI can convert to query language and return the results. This can be extended to creating complete dashboards with prompts. Many vendors have already implemented this features in different forms.

The next use case, is about making simulations more conversational. Once the bottlenecks are identified and addressed through solutions, the next logical step is to have a view of the future state. It could be having a view on new through throughputs, cycle times, SLAs, resourcing etc., Simulating multiple scenarios using the digital twin helps the process designer in answering those questions. Given that the nature of 'what - if' analyses is inherently conversational, having a co-pilot do that would be a great enabler.

Another interesting use case in this category is in the process story telling. To contextualize what each user needs to know from the process. Depending on the role of the user, the Gen AI could highlight aspects that they might interested in. For example, senior business user might be interested to know the broad KPIs and their trends. A department head might want to understand the KPIs, trends and causation factors in depth for her department. A process engineer might need to know the inefficiencies like long cycle times of segment, loops and reworks in the process. Like wise, someone looking for tech, automation and AI opportunities to refine the process will look for different things. Currently these requirements are partly catered by building different dashboards or views, but Gen AI can definitely do a much better job in contextualizing the content. Gen AI along with AI can be a powerful navigator.

Coding and software

The final capability of Gen AI is in 'coding and software' - the capability that enables the user to co-create new software and migrate legacy systems at scale and speed. There were not many process mining use cases in the segment - but I did come across use-cases where entire user stories and software could be generated from the BPMNs and DMNs. Well, why not? With the AGI not far-away, I think we should aspire to reach 'process autonomization'. Systems that automatically detect and act on compliance and performance gaps. And 'self-heal' too!

You might have noticed that this is not an exhaustive or a mutually exclusive set of use-cases. There are overlaps between them and I was more interested in laying of the different broad possibilities that could unfold. Undoubtedly, like in any other discipline, Gen AI would have a tremendous impact on process management. The technologies, both rapidly evolving, would complement each other and transform the way processes of tomorrow are designed, improved and maintained.

What are the ones that you find are most impactful to your industry?

It all started with this thought of Prof. Wil Van der Aalst - "What if I could reconstruct the process from its execution logs?". This is the idea he had introduced in the year 1999 in his publication "Process Design by Discovery". For almost one decade after that, we could only find it in mentions of IEEE conference proceedings and in the Prom software. In parallel, this was the era when there was massive digitization taking place across industries. From 2010s, commercial software like Celonis, Disco and others gained prominence. It was also the time when I got introduced to this concept through the famous Coursera program - "Process Mining: Data science in action". The commercial software were able to integrate themselves into the larger ecosystem of big data analytics and machine learning. Thanks to the live integrations with the source systems SAP, Salesforce these firms were able to provide an execution layer to support process management. The segment started growing leaps and bounds.

Fast forward to the present, there are over 30 process mining vendors and each of them is approaching the market in different ways. Some of the broad themes which the vendors are trying to address are,

• Discovery and analysis - This is one of the basic features in all process mining tools. It is about the ability to read process event logs and generate the process maps. Using that model, almost all vendors, provide capabilities to configure your KPIs and dashboards.

• Process Improvement - Some software vendors have tailored their capabilities to support the framework of systematic process improvements like Six Sigma. That includes capabilities like automatic detection of opportunities, benchmarking, root cause analysis and monitoring of improvements

• Comparative process mining - This refers to the capability to compare a process against some standards to compare the KPIs or execution. It could be useful in auditing for compliances against standard process or other process variants.

• Process Simulation - Using the digital twin of the process to conduct to predict the outcomes of process changes and do what-if analyses

• Automation enablement - Process mining and automation complement each other well. While process mining highlights the bottlenecks or inefficiencies, automation solves some of them. So many automation vendors have also acquired process mining capabilities to support the identification of areas for automation.

• Process Documentation - Some vendors have provided the capabilities to for end to end process management by including features to document and maintain BPMN models and compare it against the execution

• Task mining - This is an important feature that helps unpack the intelligence from the event data available in UI logs. These UI logs that are generated from the clicks, keystrokes and data entries are useful in understanding the manual effort involved in performing the tasks

• Other advanced use-cases like machine learning workbench, predictive process monitoring and prescriptive analyses are also provided by some of the vendors.

I had just detailed out the major themes; a more detailed explanations can be found in research reports like Gartner and Forrester. Complementary version of these reports can be downloaded from many of the vendor websites.

Now we enter treacherous zone of forecasting what the future evolution might look like. There are three major themes that could play out,

• Process mining tools go 'invisible' - Don't get me wrong, they would continue to exist, but like electricity, they will be an invisible layer powering things. They could connect different legacy systems be the layer that integrates process data , rules of execution, alert / action definitions etc., Some of the analysis and visualization might be taken over by the BI tools and specialized simulators, process designers, automation systems - all powered by the 'invisible layer' - could evolve.

• Gen AI unlocks new capabilities in process intelligence - This is an evolution I am near certain about. Gen AI will become another layer between the user and the core process mining engine. This will help in the realizing many gen AI use cases like - contextualization, democratization, content creation etc., . A more detailed article on this will follow.

• OCPM - Object centric approach to process mining is a novel way that overcomes the limitations of traditional process mining. It captures the interaction between systems and objects so that processes can be followed more holistically across entire business. The adaption might be steep, but I believe, will bring about a lot of value to many complex processes.

Its a journey that's just getting started. This was meant to give a broad overview and outline without getting bogged into the details. I will follow this up with detailed articles on some of these topics. Meanwhile, please share any of the broad use-cases or trends that you find most relevant to your industry.

First, Six Sigma was sold as a panacea, a cure-it-all framework to all management problems. Not every problem needs to go through the Six-Sigma rigor.

Second, the paraphernalia of the ‘belt culture’. While it was an attempt to bring greater clarity to the overall scheme of things, trying to enforce stringent rules for project or role classification, at times, turned out be borderline farcical. The belts also gave it an elitist flavor, which further alienated people.

Finally, majority of practioners, did not embrace the technology developments in process-analysis and transformation.

In the recent years, technologies like ML/AI, automation, process-mining, cloud-computing, blockchains, etc., have all had transformational impact on the way we do things. This led to multiple transformation initiatives that were executed in parallel within the same organization - from the process team, technology team, customer experience team etc., Understandably, this led to chaos and contributed to the irrelevance of the Six Sigma to the transformation agenda. That was a lot of nitpicking!

Before we write it off, let us take a step back. In essence, what Six Sigma tries to do is to delineate and address the root-cause of variation / errors in a well-defined problem using a data-driven approach. It trains you on the tools / techniques that help you achieve this. Essentially, it makes you focus on what matters the most for the objective that you seek to attain. Everything else is built on top of this premise. Pretty commonsensical, right? Seeing it at this level, will make Six Sigma relevant to a lot of use-cases.

Let us take case of digital transformation programs. In this article [1] McKinsey points that the lack of broad and holistic understanding is one of the primary impediments. Some view it as an IT program, some see it as digital marketing or analytics program. What is often lost is the clear and tangible understanding of the impact that the digital solutions could have on the business processes and its eventual impact to ROI of the program.

Next let us understand the reasons for failure in process automation programs. A Forbes article[2] points out the primary reasons why automation programs fail is the lack of clear to-be state, lack of change management and, not surprisingly, automating the wrong processes. An incorrect understanding of the interplay between business-processes, people, and the important key process indicators (KPIs) could lead to investing effort in automating things that might not move the needle.

Finally, a few learnings from the analytics programs that I have watched from proximity. Overzealous business intelligence developers, in an attempt give a comprehensive view of what’s happening, end up creating very complex and crowded dashboards. This often leads to fatigue and inertia from the user and results in the classical case of signal getting lost in a noisy dashboard. There have also been instances where jazzy visualizations get used for the sake of it. In all these cases, adapting the Six Sigma approach could have avoided some of these pitfalls.

The big-picture orientation, having clarity on the right set of metrics, ensuring the robustness of your measurement systems, addressing the right set levers that would bring about the change and ways to sustain the change are all foundational principles of Six Sigma. Someone recently encapsulated the essence of Six Sigma as ‘scientific common sense’. I couldn’t agree more. Once you start seeing it as a philosophy, approach, and an expanding toolset to solve process-problems, things start becoming relevant. Going forward there might not be fancy belt titles or DMAIC milestone reviews, but Six Sigma would have its legacy through the commonsensical and methodical approach to problem solving.

[1] [https://www.mckinsey.com/industries/retail/our-insights/the-how-of-transformation](https://www.mckinsey.com/industries/retail/our-insights/the-how-of-transformation)

[2][https://www.forbes.com/sites/forbestechcouncil/2021/10/12/why-process-automation-initiatives-fail-and-how-yours-can-succeed/?sh=55d539683b62](https://www.forbes.com/sites/forbestechcouncil/2021/10/12/why-process-automation-initiatives-fail-and-how-yours-can-succeed/?sh=55d539683b62)

If you are wondering about these terms and their sequence, they happen the courses that I did during the last 18 years. In the next few articles, I invite you to accompany me as I recount my journey. More than my journey, it is the journey and evolution of process improvement and transformation as a discipline. Along the journey, I will take you through some interesting applications of these methods with the objective of transforming processes.

After my B.Tech in information technology, I joined TCS from the campus. I was put through a two month learning program. Lots were drawn at the end of the program, I was destined to join data warehousing. For a fortune 5 customer, who insisted that IT vendors were also Six Sigma compliant. Shh, we are not supposed to name them! That’s how I pivoted from data warehousing to Six Sigma.

Initially, Six Sigma programs in IT firms were primarily about compliances. Ensuring that you have certain number of ‘belts’. In the process of acquiring those belts, people did improvement projects. The Six Sigma teams had to enable them to execute those projects and ‘drive’ the compliance and the savings target. It was okay till it was not, more on this in the next article. After spending some time in corporate offices, consulting, I moved on to the world of hard dollar benefits. This was a different experience and I learnt more about persuasion and change management than anything else.

In parallel, the data-science was picking up momentum. There were HBR articles written touting the sexiest job of 21st century, books written and courses offered. ‘Given my inclination to anything quantitative, I enrolled for a program with IIM Bangalore. It was worth it. More than venturing into standalone analytics engagements, I was able to do process transformations much better and faster. Be it classification, regression or clustering, every method had a rightful place in the transformation arsenal.

The biggest leap to my practice came in the form of process mining. For folks who have done lean action workouts, you can imagine the process discovery days where there giant whiteboards and post-its and heated discussions on how the process is actually getting executed. All of that was gone. You had an objective, data-based view of your process. With the digital twin in place, the product firms began to offer a host of other features like conformance checking, automation, simulation, prediction etc., Its only a start and its no wonder that the market is expected to grow at 45% a year till 2030.

While all these methods helped you understand the as-is process and get a view of bottlenecks and other causes of variation, automation, data-products and Gen-AI, has helped us implement some quick fixes or band aid solutions and make the process better. From the days of excel macros for RPA, we have come a long way in the form of intelligent automation. Gen AI, though in its initial stages, has offered us tremendous potential to improve operations. We have tested out some promising use-cases in the area of agent enablement and customer servicing.

Its an exciting time to be alive. With all these tools in our arsenal, executing transformations has never been more exciting. In the next few weeks, I will share my experiences of using these tools with a dose of gyaan, that inevitably comes along with grey hairs. Stay tuned.

Subscribe now

It has been a long cherished dream to have a blog with this evergreen poem as the first post. Every line of Tagore, resonates with the values that I hold dear and I invite you to join my journey..

Where The Mind Is Without Fear

Where the mind is without fear and the head is held high
Where knowledge is free
Where the world has not been broken up into fragments
By narrow domestic walls
Where words come out from the depth of truth
Where tireless striving stretches its arms towards perfection
Where the clear stream of reason has not lost its way
Into the dreary desert sand of dead habit
Where the mind is led forward by thee
Into ever-widening thought and action
Into that heaven of freedom, my Father, let my country awake.