Target Operating Model (TOM) - Getting the Basics Right

Over the years, I’ve been part of several Finance Transformation programmes and there’s one topic that consistently comes up and often causes more confusion than clarity:

👉 “What actually is a Target Operating Model… and what does it cover?”

Surprisingly, even very experienced people sometimes struggle with this. And that’s completely understandable. When organisations dive into technology transformation (especially EPM programmes) before defining their operating model, the fundamentals get lost.

Let’s break down the TOM simply and practically - no jargon, no consulting fluff - just the basics that most organisations wish they had clarified earlier.

🔵 Why TOM Confuses So Many People

From my experience, confusion happens because:

1️⃣ People assume TOM = org chart

2️⃣ Teams jump into systems and design workshops without understanding who will do what in the future

3️⃣ Different business areas use different languages for the same processes

4️⃣ Everyone is clear on strategy… but unclear on how the organisation needs to work to deliver it

I’ve now seen multiple public‑sector organisations struggle because they jumped into EPM implementation without a defined TOM and the symptoms are almost identical (more on this later).

🔵 So… What Is a Target Operating Model?

✅ A Target Operating Model is a blueprint of how the organisation will operate in the future — across people, processes, technology, data, governance and capabilities.

It is the bridge between:

🔵 The 7 Components of a TOM

Here’s the framework I’ve repeatedly seen work: 

Each component answers practical questions like:

• What does the organisation need to look like?

• How should work flow across teams?

• What capabilities do we need?

• What technology is required to run the future processes?

• Who owns which decisions?

• What data is required for insights?

• How do we ensure consistent service delivery?

  
  

🔵 What Happens If You Build EPM Without a TOM?

In several public sector discussions I’ve had recently, a consistent pattern is emerging:

✅ Organisations start EPM build too early

✅ They configure modules without defining roles, responsibilities or governance

✅ They try to solve operating model gaps with system features

✅ They end up reworking the design multiple times

Here’s what typically goes wrong without a TOM in place:

❌ 1. Reporting becomes fragmented

Different teams define metrics differently — “forecast”, “FTE”, “demand”, “vacancy”, “strength” — all meaning different things.

EPM cannot fix inconsistent business language.

❌ 2. No clarity on who owns what

Who approves?

Who inputs?

Who runs scenarios?

Who signs off?

Who maintains master data?

Without clear ownership, EPM becomes a shared spreadsheet in the cloud.

❌ 3. Processes aren’t standardised

Teams continue to work in their old ways and the system becomes an overlay, not a transformation.

❌ 4. Technology gets blamed for operating model issues

I see this often —“It’s an EPM problem”…when actually it’s a process or governance gap.

❌ 5. Scenarios & modelling fall apart

If roles, workflows and planning levels are unclear, scenario planning becomes inconsistent and difficult to approve.

❌ 6. Data becomes inconsistent

If upstream systems, structures and hierarchies aren’t aligned, EPM becomes a patchwork of manual workarounds.

❌ 7. Rework → delays → cost escalations

Because eventually, the organisation realises they need a TOM after the build has started — which means redesigning foundations already built in the system.

🔵 What TOM Is Not

A TOM is:

❌ Not just an HR restructure

❌ Not a technology design document

❌ Not a cost‑cutting exercise

❌ Not a one-off PPT artefact

It is a living blueprint that evolves with the organisation.

🔵 How to Get TOM Basics Right (Lessons From Experience)

Here are five principles I always recommend:

✅ 1. Define the TOM before the technology

Technology should enable the operating model — not define it.

✅ 2. Keep it simple and visual

If people can’t explain it in under a minute, it won’t work.

✅ 3. Co-design with Finance, HR, Operations & IT

Cross‑functional alignment is the difference between redesign and adoption.

✅ 4. Be clear on decision-making and ownership

90% of TOM confusion is caused by unclear accountability.

✅ 5. Design the transition state, not just the end‑state

Most organisations need interim operating models before reaching the target.

🔵 Final Thoughts

A Target Operating Model removes ambiguity and aligns everyone around a single view of how the organisation will operate.But more importantly:

✅ It prevents rework, delays, and confusion during transformations

✅ It ensures EPM is implemented once — not multiple times

✅ It gives clarity and confidence to the teams who will run the future processes

The organisations I’ve spoken to who are struggling today with their EPM rollout all share the same root issue:

They jumped into technology before defining their operating model.

Get the TOM right and the rest of the transformation becomes dramatically smoother.