In the previous article, we looked at how Business Models and Target Operating Models can help people align around the big picture:

👉 Where are we going?
👉 How should the organization operate?
👉 What needs to change?

That is extremely useful at the start of a major transformation.

But then comes the next question:

Where exactly should we intervene first? 🤔

Because knowing that the organization needs to change is one thing.

Knowing which capabilities need strengthening, which processes are creating bottlenecks, and where investment will create the most value is something else entirely.

This is where Capability Maps and Process Maps — and, more broadly, Enterprise Architecture — can become very powerful strategy implementation tools.

And you don't necessarily need an army of Enterprise Architects to start using them.

 

🧩 Capability vs. Process: what is the difference?

Let's start with a distinction that can sometimes become unnecessarily complicated.

I like to keep it simple.

A Capability describes WHAT the organization needs to be able to do.

For example:

• Manage customer orders
• Develop products
• Plan production
• Procure materials
• Manage talent
• Bill customers
• Manage regulatory compliance

Capabilities are relatively stable over time.

The way you execute them may change dramatically, but the organization still needs the underlying capability.

This makes capability maps particularly useful when discussing strategy.

A Process describes HOW the organization actually does it.

Processes describe the sequence of activities required to deliver an outcome.

And this is where things become much more operational.

Once you start looking at:

👉 handovers
👉 approval loops
👉 waiting time
👉 rework
👉 unclear responsibilities
👉 duplicated activities
👉 systems that don't talk to each other

…you start uncovering the real bottlenecks.

So, in simple terms:

Capability = WHAT we need to be good at.
Process = HOW we make it happen.

Both are useful.

Just at different levels.

 

🎯 Strategy → Capabilities

Capabilities represent the main things an organization must be able to do to execute its business model.

There isn't necessarily one universal way of describing them.

And that's fine.

What matters more is that people across the organization can look at the capability map and say:

"Yes. I recognize our business in this."

Once you have that common picture, something interesting happens.

You can start comparing:

What we are capable of today

versus

What our strategy requires us to become capable of tomorrow.

And suddenly strategy becomes much more concrete.

 

🔍 Where are the capability gaps?

Imagine your strategy requires:

• more digital sales,
• subscription-based offerings,
• faster product innovation,
• predictive maintenance,
• stronger regulatory compliance,
• or a much better customer experience.

The next question becomes:

Do we actually have the capabilities required to deliver that strategy?

And if not:

Where are the gaps?

You can then map supporting elements such as:

• Data
• Applications
• Technology
• Organization
• Skills

against those capabilities.

This allows you to identify not just business gaps, but also issues such as:

⚠️ Missing application coverage
⚠️ Obsolete technology
⚠️ Fragmented data
⚠️ Capability duplication
⚠️ Missing skills
⚠️ Organizational weaknesses

And that is where architecture starts becoming very useful for initiative prioritization.

 

💡 A real example

I experienced this while managing a Quote-to-Cash Process Reengineering initiative at SWIFT.

Deloitte had developed a capability and architecture view of the organization.

That helped highlight areas where existing systems no longer adequately supported the capabilities the business needed.

For example, we identified the need to renew applications supporting areas such as:

• Order Management
• Subscription Management
• Traffic-usage-based Billing

Instead of starting with:

"Which application should we replace?"

we could start from a much more useful question:

"Which business capabilities need strengthening to support the future business?"

Technology investments then become a consequence of the strategy.

Not the strategy itself.

That distinction matters.

 

⚙️ Capabilities tell you WHERE. Processes tell you WHAT TO FIX.

Once an initiative has been prioritized, the level of detail changes.

Now we need to understand how work really gets done.

This is where process mapping becomes powerful.

And particularly when we take an end-to-end perspective.

 

🔗 Look across the value chain — not only within departments

Many processes are surprisingly similar across industries.

Think about:

Finance

• Accounts Payable
• Accounts Receivable
• Record-to-Report / Close-the-Books

Procurement

• Source-to-Contract
• Purchase-to-Pay

Sales

• Lead-to-Order
• Order-to-Cash

HR

• Hire-to-Retire

So you don't always need to start with a blank sheet.

Generic process frameworks can provide a very good starting point.

But that doesn't mean every industry operates the same way.

Far from it.

 

🧪 Some processes can make or break the business

Industry context matters enormously.

Take pharmaceuticals.

Before certain products reach the market, companies must comply with stringent regulatory requirements from authorities such as the FDA in the US or relevant European authorities.

In chemicals, regulatory frameworks such as REACH impose requirements related to environmental and health risks.

These aren't just administrative side processes.

They can be business-critical capabilities and processes.

Fail badly enough during an official audit and the consequences can be enormous.

That means some processes deserve significantly more management attention than others.

Which brings us to another important point.

 

🏆 Not every process deserves the same level of investment

I find it useful to distinguish between different types of processes.

Some are simply necessary to run the business.

Others are critical.

And others are genuinely differentiating.

A differentiating process is one of the reasons a customer chooses your company rather than your competitor.

If fast product development is central to your competitive advantage, your innovation processes matter enormously.

If exceptional service differentiates you, customer support processes deserve particular attention.

If operational excellence drives your margins, supply-chain performance becomes strategic.

The important question becomes:

Where does superior performance actually create competitive advantage?

Because trying to make every process "world class" is usually neither realistic nor economically sensible.

 

📊 Then add performance

Once the process landscape is visible, I like adding another dimension:

How well are we performing today?

Ideally, you use benchmarks where meaningful comparisons exist.

But benchmarking has to be handled carefully.

For example, inventory turnover expectations will be dramatically different between:

🥬 Fresh food and 💊 Pharmaceuticals
📦 Packaging materials and 🔧 Maintenance, Repair & Operations inventory

Even companies within the same industry can have very different operating models.

So when external benchmarks aren't meaningful, a pragmatic internal assessment can still be valuable.

For example:

🟢 Performing well
🟡 Some friction
🔴 Significant bottlenecks

You can look at:

• Lead time
• Rework
• Manual effort
• Errors
• Waiting time
• Customer complaints
• Cost
• Employee frustration

You don't need a six-month study to discover where the organization is hurting.

Sometimes the people doing the work already know very well where the problems are.

They just haven't been asked systematically.

 

🚨 Beware the departmental view

This is perhaps one of the most important benefits of process mapping.

Organizations are usually managed vertically.

Value is usually created horizontally.

Sales optimizes Sales.

Finance optimizes Finance.

Procurement optimizes Procurement.

Operations optimizes Operations.

IT optimizes IT.

And everybody may improve their own KPI…

…while the customer experience gets worse. 😅

That is why end-to-end processes such as Order-to-Cash, Purchase-to-Pay or Hire-to-Retire are so useful.

They force us to look at the handovers.

And very often, the handovers are where the gold is buried.

Or the bottlenecks. 😉

 

🗺️ How I use these concepts in practice

Personally, I don't get too religious about terminology.

On one assignment, I used a combination of:

1. The value chain — where is value created?
2. A high-level capability view — what does the organization need to be able to do?
3. A more detailed process/capability map — where are the weaknesses?
4. Performance and criticality information — where should we intervene first?

Some Enterprise Architects might call part of this a Level 2 or Level 3 Capability Map rather than a Process Map.

That's fine.

The terminology matters less to me than the decision it enables.

What I deliberately didn't do was document every individual process in detail.

Why?

Because the objective wasn't detailed process redesign.

The objective was to understand:

Where should management focus its improvement initiatives?

For a targeted initiative — drug serialization, for example — I would absolutely go much deeper into the actual process.

Different objective.

Different level of detail.

That's an important principle:

Don't model more than you need to make the decision.

 

🏗️ Do you need Enterprise Architects for this?

In large, mature organizations, Business Architects and Enterprise Architects will normally lead much of this work.

And rightly so.

But what about smaller organizations?

Or organizations where architecture maturity is still developing?

I believe experienced:

👉 Program Managers
👉 Project Managers
👉 Business Analysts
👉 Transformation Managers

can absolutely apply the same thinking at a pragmatic level.

Not necessarily to build the perfect Enterprise Architecture repository.

But to create enough structure to improve decision-making.

And sometimes that is exactly what the organization needs.

Because strategy implementation doesn't fail because your architecture diagram wasn't sophisticated enough.

It fails when the organization:

❌ invests in the wrong capabilities
❌ launches too many disconnected initiatives
❌ optimizes departments instead of value streams
❌ ignores critical bottlenecks
❌ or doesn't understand where performance actually matters

A relatively simple map can already trigger very powerful management conversations.

 

🎯 My takeaway

I see these models as different zoom levels of the same picture:

Business Model / Target Operating Model
➡️ Where are we going and how should the organization operate?

Capability Map
➡️ What must we become good at to get there?

Process Map
➡️ How does the work actually happen — and where is it breaking down?

Detailed Process Analysis
➡️ What specifically needs to change?

The trick isn't choosing the one right model.

The trick is knowing which level of detail you need for the decision you're trying to make.

And stopping there.

 

💬 How about you?

How do you use Capability Maps, Process Maps or Enterprise Architecture in your organization?

Do they genuinely help management make better strategic decisions?

Or have you sometimes seen them become an architecture exercise that was simply too detached from real business problems?