A process can be full of good people, compliant teams, strong SLAs, and well-written SOPs—and still deliver a terrible customer experience. The problem is often not the people. It is the flow.

Introduction

I used to think that if you understood Lean Six Sigma well enough, you could fix almost any process.

I was wrong.

Not because Lean Six Sigma doesn't work.

It works extremely well.

The problem is that many GCC processes don't fail because an individual step is poorly executed.

They fail because the system surrounding the process is fragmented.

Seven teams may touch the same transaction.

Four different systems may be involved.

Three approvals may be required.

Information may be entered multiple times.

Different teams may own different pieces of the workflow.

And nobody may actually own the outcome from beginning to end.

Every team can therefore be performing its responsibility correctly while the overall process is still broken.

That's one of the most important lessons Lean Six Sigma can teach a GCC:

Don't optimize the department. Optimize the flow.

---

The GCC Process Paradox

GCCs are designed to create scale.

A process that once existed in one business unit can be centralized, standardized, digitized, automated, and eventually delivered across multiple geographies.

On paper, that sounds efficient.

But scale introduces complexity.

A simple process can become something like:

Business Request
      ↓
Service Desk
      ↓
Operations Team
      ↓
Compliance
      ↓
Finance
      ↓
Technology
      ↓
Regional Approval
      ↓
Shared Services
      ↓
Business Outcome

Every team may have its own:

• SLA
• SOP
• dashboard
• queue
• manager
• system
• approval rules
• escalation mechanism
• definition of priority

And yet the customer doesn't experience nine departments.

The customer experiences one process.

That's where the problem begins.

---

Everyone Can Be Right While the Process Is Wrong

Imagine a customer submits a request.

The service desk responds within four hours.

The operations team processes it within eight hours.

Compliance completes its review within one business day.

Finance approves it within six hours.

Technology completes its part within four hours.

Every team meets its SLA.

Every manager reports green.

Every dashboard looks healthy.

But the customer receives the final outcome three days later.

Who failed?

Possibly nobody.

And that's precisely the problem.

The organization is measuring local efficiency while the customer is experiencing system-level inefficiency.

This is one of the most common traps in complex enterprise environments.

A department optimizes its own performance.

Another department does the same.

Then another.

The result can be a collection of optimized departments connected by a badly optimized process.

---

Local Optimization vs. End-to-End Optimization

This distinction is critical.

Local optimization

A team asks:

How can we make our part of the process faster?

That may result in:

• fewer processing minutes
• better utilization
• higher SLA compliance
• lower team-level backlog
• improved productivity

All useful metrics.

But they don't necessarily tell you whether the customer journey improved.

End-to-end optimization

The better question is:

How quickly and reliably can the entire process move from request to outcome?

Now the measurement changes.

You start looking at:

• total lead time
• process cycle time
• waiting time
• queue time
• number of handoffs
• rework
• first-pass yield
• defects
• approval layers
• duplicate data entry
• exception rates
• customer effort

The difference can be dramatic.

A team may spend only 30 minutes actually processing a request.

But the request may take three days to complete.

That means the majority of the elapsed time isn't work.

It is waiting.

And waiting is often where the real opportunity lives.

---

This Is Where Value Stream Mapping Becomes Powerful

One of the most useful Lean Six Sigma tools for GCC transformation is Value Stream Mapping (VSM).

The objective isn't simply to document what people are supposed to do.

It is to understand what actually happens.

That distinction matters.

A process document might say:

Request → Review → Approval → Processing → Completion

The real process might look like:

Request
  ↓
Queue
  ↓
Manual Validation
  ↓
Email
  ↓
Wait
  ↓
Excel Update
  ↓
Queue
  ↓
Approval
  ↓
Rework
  ↓
Second Approval
  ↓
System Entry
  ↓
Exception
  ↓
Email
  ↓
Processing
  ↓
Completion

The second process is where the waste is hiding.

---

What Should You Look for in a GCC Process?

When I walk into a process review, I don't start with:

"What's the problem?"

I start by asking better questions.

1. Where does the work actually wait?

Not:

How long should this step take?

But:

How long does the work actually sit before somebody touches it?

That difference exposes queue time.

---

2. Where is information re-entered?

If the same customer information is entered into:

• an email
• Excel
• CRM
• ERP
• ticketing system
• compliance system

then the organization isn't just spending time.

It is creating additional opportunities for errors.

---

3. How many handoffs happen?

Every handoff introduces potential friction.

A handoff may require:

• communication
• context transfer
• validation
• prioritization
• queueing
• ownership clarification

More handoffs don't automatically mean a bad process.

But unexplained handoffs deserve investigation.

---

4. Which steps actually create value?

This is where Lean thinking becomes uncomfortable.

Some activities exist because they create value.

Others exist because they reduce risk.

Others exist because regulation requires them.

And some exist simply because:

"That's how we've always done it."

Those categories should not be treated the same way.

---

5. Who owns the outcome end-to-end?

This might be the most important question.

You can have:

• an operations owner
• a technology owner
• a compliance owner
• a finance owner
• a regional owner

But who owns the customer outcome?

If the answer is unclear, the process probably has an ownership problem.

---

The Hidden Waste Inside GCC Processes

Lean Six Sigma gives us a language for identifying waste.

But in GCC environments, waste often hides behind corporate complexity.

1. Waiting

The work is ready.

The person is available.

The system works.

But nothing happens.

The request is simply waiting.

This is often the biggest source of lead-time reduction.

---

2. Overprocessing

The same information is:

• reviewed twice
• validated twice
• approved twice
• entered twice
• reported twice

Sometimes this is required.

Often, it isn't.

---

3. Rework

A request moves forward and then comes backward.

Missing information.

Incorrect data.

Wrong approval.

System mismatch.

Unclear requirement.

The process effectively performs the same work more than once.

---

4. Handoffs

A request moves between teams without a clear owner.

Every handoff creates a potential queue.

And every queue creates potential delay.

---

5. Duplicate Data Entry

This is particularly common in enterprise environments.

A system exists.

But someone still asks:

"Can you send me the Excel file?"

Then another person copies the data into another system.

Then someone exports it into another report.

The organization has built an ecosystem around moving information instead of moving value.

---

6. Excessive Approvals

Approval is often treated as synonymous with control.

It isn't.

A good approval mechanism reduces risk.

A poorly designed approval chain simply increases lead time.

The question shouldn't be:

"Can we remove this approval?"

It should be:

"What risk does this approval mitigate, and is there a better control mechanism?"

That's a much more useful conversation.

---

Why SOPs Don't Automatically Fix the Process

A well-written SOP is valuable.

But an SOP describes how a process is supposed to operate.

It doesn't necessarily reveal how the process behaves under real-world conditions.

Consider a process with ten documented steps.

The SOP says:

Step 1 → Step 2 → Step 3 → Step 4 → Step 5

But the actual process is:

Step 1
  ↓
Wait
  ↓
Step 2
  ↓
Exception
  ↓
Email
  ↓
Step 3
  ↓
Manual correction
  ↓
Wait
  ↓
Step 4

The SOP may be perfectly accurate.

The process may still be terrible.

That's why process observation matters.

Go to the work.

Follow the transaction.

Talk to the people performing it.

Measure the waiting.

Track the handoffs.

Observe the exceptions.

The process tells you what the documentation often cannot.

---

The 99% SLA Problem

One of the most dangerous things in operational reporting is a metric that looks excellent but measures the wrong outcome.

Imagine:

SLA compliance: 99%

That sounds fantastic.

Now ask:

What exactly does the SLA measure?

Maybe the SLA measures how quickly Team A responds after receiving a request.

But the customer doesn't care about Team A's response time.

They care about:

When will my problem be resolved?

There is a fundamental difference.

Activity metric

"Ticket acknowledged within four hours."

Outcome metric

"Customer issue resolved within 24 hours."

The first may be green while the second is red.

That's why process transformation requires more than dashboards.

It requires asking whether the organization is measuring the right thing.

---

Don't Automate Waste

This is where Lean Six Sigma becomes especially relevant to today's AI and automation discussions.

Organizations are investing heavily in:

• AI agents
• workflow automation
• RPA
• copilots
• orchestration platforms
• intelligent document processing
• predictive analytics

All of these can create tremendous value.

But there is a dangerous assumption:

If we automate the existing process, the process becomes better.

Not necessarily.

If a process contains:

• five unnecessary approvals
• duplicate data entry
• unclear ownership
• redundant validation
• unnecessary handoffs

then automation can simply make the waste move faster.

You haven't eliminated the problem.

You've automated it.

---

The Better Sequence

A more effective transformation sequence is:

Understand
   ↓
Measure
   ↓
Simplify
   ↓
Standardize
   ↓
Automate
   ↓
Optimize

Not:

Existing Process
      ↓
Add AI
      ↓
Hope

Technology should amplify a good operating model.

It shouldn't compensate for the absence of one.

---

Where AI Can Actually Help

Once the process has been understood and simplified, AI becomes much more powerful.

For example, AI can help with:

Intelligent triage

Automatically classify incoming requests and route them to the correct queue.

Document processing

Extract information from documents instead of requiring manual entry.

Exception management

Identify transactions that don't follow the standard path.

Knowledge retrieval

Help employees find the right policy, SOP, or resolution path.

Root-cause analysis

Analyze large volumes of process data to identify recurring failure patterns.

Predictive operations

Identify where queues or backlogs are likely to develop before they become major problems.

But these applications work best when the underlying process is understood.

---

The Role of a Lean Six Sigma Black Belt in a GCC

This is where I believe the role becomes much more interesting.

A Lean Six Sigma Black Belt shouldn't simply be viewed as someone who knows:

• DMAIC
• SIPOC
• Pareto analysis
• Fishbone diagrams
• control charts
• capability analysis

Those are tools.

The real value is knowing which tool to use, when to use it, and what business problem it should solve.

In a GCC, that means being able to connect:

Process

with

People

with

Technology

with

Controls

with

Customer outcomes

That's where transformation becomes practical.

---

DMAIC Still Matters

The classic DMAIC framework remains highly relevant.

Define

Clearly define the problem.

Not:

"The process is slow."

Instead:

"The average request-to-resolution lead time is 72 hours, while actual processing time is 4 hours."

Now you have something measurable.

---

Measure

Collect actual process data.

Look at:

• lead time
• cycle time
• queues
• defects
• rework
• handoffs
• volumes
• variation
• SLA performance

Don't rely entirely on what the process owner believes is happening.

Measure what is actually happening.

---

Analyze

Find the causes.

Why is the request waiting?

Why does it get rejected?

Why is information entered twice?

Why does the approval take two days?

Why does the same exception keep appearing?

This is where root-cause analysis becomes important.

---

Improve

Redesign the flow.

Possible improvements include:

• eliminating unnecessary steps
• reducing approvals
• standardizing inputs
• changing ownership
• integrating systems
• automating repetitive work
• redesigning queues
• reducing handoffs

---

Control

Make the improvement sustainable.

This means:

• clear ownership
• meaningful KPIs
• process controls
• monitoring
• governance
• continuous improvement

Otherwise, six months later, the process can quietly return to its previous state.

---

The GCC Transformation Flywheel

A mature GCC can think about transformation as a continuous cycle:

Map the Value Stream
        ↓
Find the Waste
        ↓
Measure the Baseline
        ↓
Remove Friction
        ↓
Standardize
        ↓
Digitize
        ↓
Automate
        ↓
Measure Outcomes
        ↓
Improve Again

The important word here is again.

Process improvement isn't a one-time project.

Markets change.

Technology changes.

Volumes change.

Customers change.

Organizations restructure.

New regulations appear.

A process that was efficient two years ago may be inefficient today.

---

From Functional Metrics to Flow Metrics

This is one of the biggest mindset changes GCC leaders can make.

Instead of asking only:

Traditional Question	Better Question
Did the team meet SLA?	Did the customer get the outcome on time?
How productive is the team?	How quickly does value move through the system?
How many tickets were closed?	How many issues were actually resolved?
How many people do we need?	Why does this process require this much work?
Can we automate this step?	Should this step exist at all?
Which team owns it?	Who owns the outcome?
How fast is each department?	How fast is the end-to-end value stream?

That shift can fundamentally change transformation discussions.

---

A Simple GCC Process Review Framework

If I had to reduce the approach to a practical checklist, I'd start here.

Step 1: Define the customer outcome

What does "done" actually mean?

Don't define success as completion of a departmental activity.

Define the final outcome.

---

Step 2: Map the actual process

Document what really happens.

Include:

• people
• systems
• queues
• decisions
• handoffs
• approvals
• exceptions

---

Step 3: Measure the flow

Capture:

• total lead time
• touch time
• waiting time
• rework
• defects
• handoffs

The gap between touch time and lead time is often revealing.

---

Step 4: Identify waste

Look for:

• waiting
• duplication
• unnecessary movement
• unnecessary approvals
• rework
• overprocessing
• manual data movement

---

Step 5: Clarify ownership

Ask:

Who owns the end-to-end outcome?

Not just:

Who owns each activity?

---

Step 6: Simplify before automating

Remove unnecessary work.

Then standardize.

Then digitize.

Then automate.

Then introduce AI where it creates genuine leverage.

---

Step 7: Measure the outcome

Don't stop at:

"We automated the process."

Measure:

• lead-time reduction
• cost reduction
• defect reduction
• customer experience
• employee effort
• throughput
• quality
• control effectiveness

Transformation should produce measurable outcomes.

---

The Bigger Lesson for GCC Leaders

A GCC can have world-class technology and still have mediocre operations.

It can have excellent people and still have poor flow.

It can have sophisticated dashboards and still measure the wrong outcomes.

It can have beautiful SOPs and still have broken processes.

It can have AI agents and still be automating waste.

That's why process excellence remains relevant even in an AI-first enterprise.

In fact, I would argue that it becomes more important.

The easier technology makes it to automate work, the more important it becomes to ask:

Should this work exist in the first place?

---

Technology Is Not the Transformation

This is perhaps the biggest misconception in enterprise transformation.

Buying a platform is not transformation.

Deploying AI is not transformation.

Automating a workflow is not transformation.

Transformation happens when the system produces a materially better outcome.

Technology can enable that.

But technology isn't the transformation itself.

The operating model, process design, governance, people, data, and technology all have to work together.

---

What Lean Six Sigma Taught Me About GCCs

The biggest lesson wasn't how to make teams faster.

It was how to see the system differently.

Once you start looking at the entire value stream, certain things become difficult to ignore.

The unnecessary approvals.

The duplicate checks.

The Excel files.

The "just send me an email" handoffs.

The queues nobody measures.

The work that gets done twice because nobody trusted the first output.

The dashboards that celebrate departmental performance while the customer waits.

And eventually, the conversation changes.

It stops being:

"How do we make this team faster?"

And becomes:

"Why does this work need to pass through this many hands in the first place?"

That's the conversation that creates transformation.

---

The Real Opportunity

GCC transformation isn't simply about doing more with less.

It's about designing a system where less unnecessary work needs to be done in the first place.

That means:

Fewer handoffs.

Less waiting.

Less rework.

Less duplication.

Clearer ownership.

Better data.

Better controls.

Better technology.

And ultimately:

Better flow.

A Lean Six Sigma Black Belt can create real value in a GCC not by making people work harder, but by helping the organization understand how work actually moves—and redesigning the system around that reality.

Because the goal isn't to build the fastest department.

It's to build the fastest, most reliable path to the customer outcome.

---

Final Thought

The next time a GCC process looks slow, don't immediately ask:

"Where can we add automation?"

Ask:

"Where does the work actually wait?"

Then ask:

"Why?"

That question might reveal more transformation opportunity than another technology implementation ever will.

Because sometimes the biggest opportunity in GCC transformation isn't adding more technology.

Sometimes, it's removing the waste that technology was about to automate.

---

Key Takeaways

• A process can fail even when every individual team performs well.
• Local optimization does not guarantee end-to-end optimization.
• Waiting and handoffs are often hidden sources of GCC inefficiency.
• SLA compliance can mask poor customer outcomes.
• SOPs describe processes but don't always reveal how work actually flows.
• Value Stream Mapping can expose hidden waste across functions and systems.
• Lean Six Sigma provides a structured approach to process improvement.
• Process simplification should come before automation.
• AI can amplify a good process—but can also automate bad ones.
• GCC transformation should focus on end-to-end value flow, not departmental efficiency.

Don't optimize the department. Optimize the flow.