From current reality to future capability

Operating model language is often used loosely.

• Sometimes it means an organisation chart.
• Sometimes it means a process model.
• Sometimes it means a technology platform.
• Sometimes it means a consultant’s target-state deck.
• Sometimes it is just a respectable phrase for restructuring.

That is not enough.

In this body of work, an Operating Model has a specific meaning.

It is the working configuration through which an organisation turns purpose and strategy into capability, work, decisions, information, accountability, learning, and consequences.

It is how the organisation is wired to act.

The operating model is not the architecture

Business Architecture and Operating Model are closely related, but they are not the same thing.

Business Architecture helps the organisation understand itself.

It describes what the organisation must be able to do, how value is created, what information matters, how workflows, who the stakeholders are, and how the parts relate.

It provides the map.

The Operating Model describes how the organisation is configured to make that map work.

It connects capabilities, processes, data, roles, decisions, systems, governance, measures, costs, and partners into a practical arrangement.

It provides the wiring.

The distinction matters.

• A Business Capability Model may show what the organisation must be able to do.
• A Value Stream may show how value moves.
• A Process Model may show how workflows.
• A Common Data Model may clarify meaning.

But the operating model asks:

How are these elements actually configured so that people can do the work, make decisions, use knowledge, govern risk, learn from consequence, and adapt?

COM: where we are

The Current Operating Model (COM) is where the organisation is now.

• Not where the PowerPoint says it is.
• Not where the transformation roadmap says it should be.
• Not where the policy manual says it is.
• Where it actually is.

The COM includes formal structures, systems, processes, roles, data, governance, measures, and decision rights.

Assumptions in COM and TOM

Every operating model rests on assumptions.

In the Current Operating Model, many assumptions are already embedded in the way the organisation works. Some are visible. Many are not.

The COM may assume that:

•  Particular people will continue to carry tacit knowledge.

• Informal networks will continue to solve problems.
• Local workarounds, including spreadsheets, will continue to absorb design weaknesses.
• Middle managers will continue to translate unclear intent.
• Teams will continue to tolerate role ambiguity.
• Customers will continue to accept friction.
• Data redundancy and ambiguity will remain manageable.
• Trust will continue to hold the system together.
• Exceptions will be handled by experienced people.
• Governance gaps will be patched through personal judgement.

These assumptions often remain hidden because the organisation is still functioning.

But functioning is not the same as being well designed.

The COM may be held together by effort, loyalty, memory, trust, workaround, and tacit judgement rather than by a coherent operating model.

The brilliant people trap

A Current Operating Model can appear stable because brilliant people patch the holes and keep rescuing it.

• They remember what the process forgot.
• They know who to call.
• They maintain the spreadsheets.
• They translate the policy.
• They patch the system gap.
• They calm the customer.
• They interpret the data.
• They know which rule cannot be followed literally.
• They know where the real decision is made.
• They know what will break if the official model is actually used.

This is capability, but it is also risks.

Quick tacit knowledge quiz: Do you know who your brilliant people are — and which holes each of them patches?

The organisation may believe its operating model works.

In reality, it may be surviving because experienced people are absorbing design failure through tacit knowledge, judgement, relationships, and personal effort.

As one organisation’s Legal Counsel once put it to me:

“This organisation is a set of f…..d processes that only work because of brilliant people.”

That is not a compliment to the operating model.

It is a warning.

A COM like this can continue for years — until the brilliant people leave, withdraw, burn out, stop caring, or are removed in the next transformation.

Then the organisation discovers that what it thought was a process was actually memory.

What it thought was governance was actually judgement.

What it thought was resilience was actually exhaustion.

A Target Operating Model option introduces a different set of assumptions.

It may assume that:

• People will trust the change.
• Leaders will make timely decisions.
• Data will be trusted and reliable.
• Systems will integrate.
• Roles will be understood.
• Governance will be followed.
• Capability will be available.
• AI outputs will be checked.
• Customers will behave as expected.
• Regulators will accept the design.
• Staff will adapt quickly.
• Knowledge will transfer.
• Informal networks will survive.
• Middle managers will absorb the transition load.
• Productivity will recover after disruption.

Both COM and TOM assumptions must be surfaced.

The COM exposes the assumptions already holding the organisation together.

TOM options reveal the assumptions underlying potential future designs.

The design task is not simply to move from COM to TOM.

It is to understand what the COM is really doing, to imagine TOM options, to test those options against scenarios, and to keep watching the assumptions as reality changes.

COM reveals the assumptions the organisation is already living on. TOM options reveal the assumptions the organisation is proposing to bet on.

But it also includes the lived reality:

• workarounds
• duplicated effort
• informal networks
• unclear accountability
• slow decisions
• hidden dependencies
• local interpretations
• data ambiguity
• process bypasses
• role confusion
• operational friction
• trust gaps
• tacit knowledge held by particular people
• differences between official design and actual practice

This is why the Current Operating Model must be understood at Gemba.

The COM cannot be fully known from PowerPoint decks, diagrams, workshops, role descriptions, dashboards, or governance packs.

It has to be observed where work happens.

The organisation needs to ask:

How does the work actually get done?
Where does the official model not match reality?
Where are people compensating for weak design?
Where are decisions delayed, avoided, or escalated unnecessarily?
Where does information lose meaning?
Where does accountability break?
Where is trust holding the system together?
Where is tacit knowledge doing work the formal model does not recognise?

A COM is not just a description.

It is a diagnosis.

TOM: a hypothesis, not a destination

The Target Operating Model (TOM) is often treated as the future state.

That is dangerous.

In a complex organisation, the future is not a destination that can be designed once and rolled out.

A TOM should be treated as a hypothesis.

It says:

Under these assumptions, in these conditions, with these capabilities, this configuration may help the organisation deliver value, coordinate work, make decisions, govern risk, and adapt more effectively.

That means there should rarely be only one TOM.

There should be options.

• One TOM option may favour standardisation.
• Another may favour local responsiveness.
• Another may favour centralised governance.
• Another may favour distributed decision-making.
• Another may favour product-aligned teams.
• Another may favour capability-based platforms.
• Another may favour human-led judgement supported by AI.

Each option has consequences.

Each option rests on assumptions.

Each option will perform differently under different future conditions.

This is where TOM design connects directly to Scenario Planning.

TOM options and scenario planning

A Target Operating Model should not be selected simply because it looks tidy.

It should be tested against possible futures.

Scenario planning asks:

What different futures might this organisation have to operate within?

For each scenario, the organisation can test TOM options:

• What assumptions does this option depend on?
• What happens if demand increases suddenly?
• What happens if regulation changes?
• What happens if trust falls?
• What happens if key people leave?
• What happens if AI changes the economics of the work?
• What happens if customer expectations shift?
• What happens if data quality is weaker than assumed?
• What happens if suppliers fail?
• What happens if the organisation faces multiple shocks at once?
• What happens if the informal knowledge base is thinner than expected?

This changes the TOM conversation.

The question is no longer:

Which design do we prefer?

The question becomes:

Which operating model option remains coherent, ethical, learnable, and adaptive across the futures we may face?

That is a much stronger question.

Assumptions must be surfaced

Every operating model rests on assumptions.

• Some are explicit.
• Most are not.

A TOM may assume that:

• People will trust the change.
• Leaders will make timely decisions.
• Data will be reliable.
• Systems will integrate.
• Roles will be understood.
• Governance will be followed.
• Capability will be available.
• AI outputs will be checked.
• Customers will behave as expected.
• Regulators will accept the design.
• Staff will adapt quickly.
• Knowledge will transfer.
• Informal networks will survive.
• Middle managers will absorb the extra load.
• Productivity will recover after disruption.

These assumptions must not remain hidden.

They need to be surfaced, named, tested, monitored, and revised.

Otherwise, the TOM becomes a faith statement.

A good operating model design process should create an assumption map:

• What must be true for this operating model to work?
• How would we know if that assumption is failing?
• Where would the weak signal appear first?
• Who would notice?
• How would that signal reach decision-makers?
• What would we change if the assumption failed?

This is where the Organisational Awareness Hub becomes essential.

The Organisational Awareness Hub watches the assumptions

A TOM isn’t complete once approved; it requires ongoing observation. The Organisational Awareness Hub ensures the operating model stays aligned with reality. Its role is to continuously sense, collect, interpret, and escalate signals from the field.

Not just formal feedback.

Not just dashboard measures.

Not just project updates.

The Hub watches for changes in:

• customer behaviour
• employee confidence
• process friction
• data quality
• exception rates
• decision delays
• workload stress
• trust levels
• informal workarounds
• risk events
• compliance strain
• supplier signals
• AI failure modes
• capability gaps
• unintended consequences
• weak signals from Gemba

The Hub asks:

• Are the assumptions still holding?
• Is the operating model working as intended?
• Where is reality pushing back?
• Where are people compensating for design weakness?
• Where are consequences emerging?
• What needs to be adjusted before the model fails?

This turns operating model design into a living learning process.

Gemba tests the operating model

Gemba is the point where the operating model interacts with actual practice. While a Target Operating Model (TOM) may appear logically sound, pass governance checks, align with strategic goals, and be backed by process maps, capability models, role descriptions, and technology roadmaps, it is Gemba that truly shows whether it functions effectively.

At Gemba, people discover:

•  The role design is misaligned with the actual work.
• The process relies on information that isn’t available.
• This leads to redundant handling.
• Decision rights are not well-defined.
• Accountability is misplaced.
•  Key performance measures can influence behaviour negatively.
• AI generates outputs that appear plausible but require human judgment.
• Customers often deviate from the expected flow.
• Exceptions occur more frequently than the model predicts.
• Tacit knowledge underpins the system.
• Trust facilitates unseen coordination efforts.

This is not embarrassment. This is learning.

A living operating model must be corrected by reality.

The model goes to Gemba.

Gemba challenges the model.

Hansei reflects on what happened.

The organisation adjusts.

That is how the operating model becomes part of Adaptive Capacity.

The operating model as a consequential intervention

Changing an operating model is not a neutral design exercise.

It is a Consequential Intervention.

It changes:

• Who decides?
• Who owns the risk?
• Who carries the workload?
• Who has authority?
• Who loses influence?
• Who gains visibility?
• Who is held accountable?
• What knowledge matters?
• What work is automated?
• What relationships are strengthened or weakened?
• What do customers experience?
• What measures drive behaviour?
• What do people believe the organisation values?

This is why operating model design must be ethical.

• A TOM that improves efficiency while damaging trust may weaken Adaptive Capacity.
• A TOM that centralises control while silencing local knowledge may reduce awareness.
• A TOM that automates work while hiding accountability may increase risk.
• A TOM that removes experienced people without preserving tacit knowledge may create transformation debt.
• A TOM that looks elegant but cannot be lived at Gemba is only architectural theatre.

The test is not whether the model looks coherent.

The test is whether the organisation becomes more capable, more aware, more trustworthy, and more able to learn.

Human Capital, Social Capital, and Operating Model design

Adaptive Capacity depends on both Human Capital and Social Capital.

Human Capital includes knowledge, skill, experience, judgement, and expertise.

Social Capital includes trust, relationships, shared understanding, psychological safety, informal coordination, and willingness to contribute.

An operating model configures both.

It influences collaboration, decision-making, knowledge sharing, conflict resolution, accountability, and learning. That’s why designing an operating model extends beyond just structure, processes, and technology.

Organisations can buy Human Capital.

They can hire skills, contract expertise, and acquire technical capability.

But they cannot simply buy Social Capital.

Trust, shared history, psychological safety, informal coordination, and willingness to contribute judgement under uncertainty must be earned.

A TOM that ignores Social Capital may appear efficient but become brittle.

A TOM that strengthens Social Capital can increase Adaptive Capacity.

That is the real prize.

Operating model design in the Adaptive Capacity architecture

In the Adaptive Capacity architecture, the operating model sits within a larger learning system.

• Purpose and Ethics provide direction and boundary.
• Business Architecture provides the shared map of capability, value, information, process, stakeholders, systems, measures, and relationships.
• Current Operating Model describes how the organisation is actually configured today.
• Scenario Planning explores possible future conditions.
• Target Operating Model options propose different future configurations.
• Organisational Awareness monitors assumptions, weak signals, consequences, and changes in the field.
• Gemba tests whether the model works in lived practice.
• Hansei enables reflection on what actually happened.
• Dialogue and Sensemaking help people interpret signals and consequences together.
• Governance makes disciplined choices.
• Action tests those choices.
• Consequence
• Adaptive Capacity emerges when the organisation can keep moving through this cycle coherently.

So, the operating model is not a static design.

It is part of an adaptive loop.

Practical operating model questions

A useful operating model conversation should ask:

Purpose

• What purpose must this model serve?
• What ethical boundaries must shape it?

Capability

• What must the organisation be able to do?
• Which capabilities need to be protected, built, strengthened, or retired?

Value

• How does value move across the organisation?
• Where is value delayed, degraded, duplicated, or lost?

Work

• How does work actually happen?
• Where do official processes differ from lived practice?

Decision

• Who decides?
• Where should decisions be made?
• What evidence is required?

Information

• What information is needed?
• What shared meanings are required?
• Where does data ambiguity create risk?
• Where does data redundancy create risk?

Technology

• What systems support the work?
• What does AI change?
• Where must human judgement remain visible?

Governance

• What rules, principles, and escalation paths are needed?
• How do we prevent governance from becoming theatre?

Cost

• Where is cost incurred?
• What activities consume resources?
• What capability does the cost sustain?

Learning

• How will we know whether the model is working?
• What assumptions are we monitoring?
• What will we do when reality contradicts the model?

Closing reflection

An Operating Model is not the answer.

It is a designed configuration that must be tested, lived, challenged, and renewed.

• The Current Operating Model tells us where we are.
• Target Operating Model options help us imagine where we might go.
• Scenario Planning tests those options against possible futures.
• The Organisational Awareness Hub watches the assumptions.
• Gemba tests the model against lived reality.
• Hansei turns consequence into learning.
• Adaptive Capacity grows when the organisation can keep adjusting the way it works without losing coherence, trust, purpose, or judgement.

The operating model is not a plank over the chasm. Done properly, it is part of the bridge.

To understand more

This Source Note connects to:

• Business Architecture & Operating Model Pathway
• Business Capability Model
• Enterprise Architecture
• Common Data Model
• Business Process Management
• Activity Based Costing
• Value Streams
• Line of Sight
• Organisational Awareness
• Scenario Planning
• Gemba
• Hansei
• Consequential Intervention

For a deeper dive:

Subject Area – Enterprise Architecture & Operating Model

Explore further

This article connects to the broader framework:

• Ethical Domain — how constraints shape decisions
• Sensemaking Domain — how organisations interpret reality
• Relational Domain — how trust and coordination emerge
• Learning Domain — how knowledge is created and tested
• Action Domain — how intent becomes capability

To understand more on Purpose detailed Subject Areas, visit the Deep Dive section.