By this point you have all the building blocks: mandate, strategy link, current state, value streams, org design, people, tech, sourcing, performance, and risk. The hard part now is turning these into one coherent target operating model, rather than a stack of disconnected workstream outputs.
This chapter gives you a practical, end-to-end design method you can actually run:
- A clear TOM design cycle, from principles to blueprints
- How to iterate across dimensions without local optimization
- How to stress-test the design before you lock it in
How to capture the answer on one page that the executive team can live with and use
12.1 The TOM Design Cycle: From Principles to Blueprints
Think of TOM design as a structured, iterative cycle, not a linear Gantt chart. You will loop a few times, but you should always know which loop you’re in.
A simple, workable cycle:
- Frame and confirm the brief
Even if you’ve done this earlier, start the design phase with a short reset:- Reconfirm scope, objectives, value targets, and design principles.
- Revisit the “as-is” fact pack: key pain points and constraints.
- Clarify who is on the core design team, who is on the review body, and who is advisory.
- You want everyone to be solving the same problem, with the same constraints and success criteria.
- Draft the high-level TOM “spine”
Before deep workstreams spin up, sketch a first TOM spine with a small group (typically 4–8 people including business, operations, tech, finance, and risk). At this stage you answer at a high level:- What are the 3–7 priority value streams?
- What is the macro-structure (e.g., segment-led with global platforms, or product-led with shared operations)?
- Where will major shared services and CoEs sit?
- What are the big calls on tech (e.g., single CRM, two core platforms, workflow layer)?
- This is not the final answer, but it gives everyone a concrete picture to react to.
- Run first-pass design by dimension
Now you let each design dimension do a first pass, always anchored in the TOM spine:- Processes and value streams: target E2E blueprints.
- Organization and governance: refined macro-structure, key roles, governance forums.
- People and culture: critical roles, capability families, culture shifts.
- Tech and data: target capabilities, core platforms, data domains.
- Sourcing and footprint: what moves to shared services, what is outsourced, where hubs sit.
- Performance and risk: target KPI tree, risk ownership, embedded controls.
- Each workstream produces a strawman (first version) that fits on a small number of pages, not a full design.
- Integrate and resolve contradictions
Reconvene a cross-functional design group to look horizontally across outputs. Ask:- Where are we contradicting our own principles?
- Where does one dimension’s proposal break another’s (e.g., org design assuming products that tech can’t support in time)?
- Where are we still vague on ownership?
- Adjust the TOM spine and send clear guidance back to each dimension for second-pass design.
- Deep-dive critical value streams and “hotspots”
You don’t need Level 3 detail everywhere. You do need a deeper design for:- The handful of value streams that carry most of the value and risk.
- Any hotspots with heavy pain points, regulatory scrutiny, or high complexity.
- For these, you refine:
- Detailed E2E blueprints.
- Role-level org design across the journey.
- Required system changes and integrations.
- Concrete metrics and control design.
- This is where the TOM becomes operationally credible, not just conceptual.
- Consolidate into the TOM blueprint and business case
Once you’ve iterated a couple of times:- Freeze a TOM blueprint: the integrated view of processes, org, tech, sourcing, people, performance, and risk.
- Quantify impact: cost, revenue, risk, and experience, tied to specific TOM changes.
- Size investments: tech spend, restructuring, capability building.
- You don’t need single-euro precision, but ranges and orders of magnitude must be defensible.
- Translate into a migration roadmap
Design is only half the job. You now shape:- Waves of implementation (pilots, early moves, big releases).
- Dependencies (what must happen before what).
- Key risks and mitigations.
- This flows directly into your transformation governance and program design (later chapters).
A common trap is to keep redesigning the TOM in endless loops. To avoid that:
- Time-box each iteration (e.g., 2–3 weeks per pass).
- Define approval milestones: “We will freeze macro-structure by this date, value streams by that date,” etc.
- Accept that some details will be fixed later in implementation, not in the initial design.
12.2 Iterating Across Dimensions: Avoiding Local Optimization
Most TOM failures are not because any single design workstream was incompetent. They fail because each dimension is optimized for itself.
Examples you see everywhere:
- Processes optimized for simplicity that ignore real regulatory checks.
- Organization structures that centralize everything while tech and data remain hopelessly local.
- Tech architectures planned as if people and skills were infinitely flexible.
- Sourcing decisions that cut cost but destroy insight and customer experience.
You need a deliberate cross-dimension iteration to avoid this.
Useful practices:
- Design around value streams, not functions
Anchor everything in value streams and journeys (Chapter 5). For each major design choice, ask:- “What does this do to the end-to-end journey?”
- “Does this make it easier or harder for the journey owner to deliver their KPIs?”
- This discourages functional sub-optimization (e.g., Ops optimizing for its own cost while killing NPS).
- Use design principles as a “tie-breaker”
When workstreams clash:- Central vs local: go back to your principles on standardization vs flexibility.
- Automation vs judgment: go back to your principles on risk appetite and customer experience.
- Platform vs bespoke: go back to your principles on tech reuse and time-to-market.
- If the principle is no longer right, change the principle—but do it explicitly, not by stealth.
- Run regular integrated design reviews
Do not let each dimension disappear for months. Instead:- Hold fortnightly design reviews where each workstream shows how their latest thinking impacts 2–3 priority value streams.
- Use a standard “cross-impact” slide:
- What we propose in our dimension
- Implications for processes, org, tech, people, sourcing, performance, risk
- Open interdependencies we need others to resolve
- The aim is early detection of collisions, not late-stage firefighting.
- Maintain a single TOM “canvas”
Keep one living artifact that shows, on one or two pages:- Value streams
- Macro-structure
- Major platforms and hubs
- Shared services and CoEs
- Key performance and risk elements
- Update this canvas every time a major design choice changes. This becomes the integration anchor: if someone’s new idea doesn’t fit or forces unnatural workarounds, you see it instantly.
- Protect “good enough” and lock decisions
Perfectionism is another form of local optimization. To keep moving:- Decide which aspects must be designed to 80–90% now (e.g., org structure, value streams).
- Decide which can be designed to 60–70% and refined in pilots (e.g., some process details, some local variants).
- Once a decision is “locked,” require explicit senior sign-off to reopen it.
- Otherwise, every new insight becomes a reason to redo weeks of integrated work.
- Use conflicts as design signals
When functions consistently argue about a topic, it usually means:- The scope or ownership is unclear.
- The design principle is ambiguous.
- The underlying constraint (tech, regulation, economics) hasn’t been made visible.
- Treat these conflicts as inputs: clarify ownership, sharpen principles, and surface constraints rather than papering over disagreements.
If you do this, iteration becomes disciplined integration—not endless rework.
12.3 Stress-Testing the Design: Scenarios and “Day in the Life”
A TOM that looks good on paper can still break instantly when exposed to reality. Before you lock in, you should stress-test it.
There are two very practical tools:
- Scenario tests
- “Day in the life” simulations
Both are workshop-friendly and do not require huge models.
Scenario testing
Pick a handful of realistic yet demanding scenarios. Examples:
- A 30–50% spike in volume on a core journey (e.g., peak season, marketing campaign success).
- Launch of a major new product or proposition on an aggressive timeline.
- A serious incident: core system outage, cyber breach, major operational failure.
- A regulatory shock: new requirement that affects onboarding, reporting, or risk limits.
- A material cost-pressure situation: you must remove X% cost from a function without destroying service.
For each scenario:
- Describe the situation in concrete operational terms
- What triggers it?
- What numbers change (volumes, rates, timelines)?
- What constraints remain firm (risk appetite, customer promises, regulatory rules)?
- Walk through the scenario using the target TOM
- Who sees the issue or opportunity first?
- Who decides what to do, and in which governance forum?
- How do value streams adapt: where does work get routed, re-prioritized, or paused?
- How do platforms, shared services, and partners respond?
- Where does risk and compliance plug in?
- Capture stress points and design gaps
Common issues that surface:- Decision-making still too slow or unclear.
- Over-concentration on one hub, location, or vendor.
- Controls that are too rigid to allow timely response.
- Missing roles (e.g., no clear crisis or incident owner for a journey).
- Tech that cannot scale or flex as assumed.
- Adjust the TOM blueprint
Do not just write down “risks.” Make explicit design changes where warranted:- Clarify or move decision rights.
- Introduce or strengthen specific roles or forums.
- Add redundancy in locations or vendors.
- Refine capacity assumptions and automation plans.
“Day in the life” simulations
This is a simple but powerful way to test internal coherence and usability. You simulate a typical day for key roles in the new TOM:
- A journey owner
- A country manager or segment lead
- A front-line team leader in a key process
- A platform or product owner
- A risk or compliance lead for a critical domain
For each role:
- Describe their mandate and KPIs in the target TOM
- What they own.
- What they are measured on.
- What forums they sit in.
- Walk hour by hour (or block by block) through a realistic day or week
- What decisions they take.
- Which reports they look at or dashboards they use.
- Which teams and roles they interact with.
- Which systems or tools they use for core tasks.
- How issues are escalated, and to whom.
- Ask three questions
- Is this doable? Or is the role overloaded, fragmented, or underpowered?
- Is this motivating? Does it feel like a real job someone would want, with clear levers?
- Is this aligned? Does it reinforce the TOM principles and end-to-end accountability?
Typical insights:
- Some roles are defined as “hero roles” that absorb every unresolved problem.
- Spans and layers do not match the actual intensity of interactions.
- Governance and KPIs pull people in conflicting directions.
- Front-line leaders are drowning in reporting and admin, with little time left to lead.
Use these insights to refine role design, governance, and metrics before you publish the TOM.
Stress-testing should not be a one-time event. Run a few focused sessions during design and again during early implementation waves.
12.4 The One-Page Target Operating Model Summary (Template)
Senior teams and boards will not carry around a 60-page deck. They will carry a single page (or something very close to it) that captures the essence of the TOM.
That page becomes:
- The reference in every strategic and investment discussion
- The orientation tool for new leaders
- The anchor for communication to the broader organization
You can adapt this to your style, but a robust one-page TOM summary usually has the following elements.
1. Strategy and value link (top strip)
A short header that reminds everyone why the TOM exists:
- 1–2 lines on strategic direction and positioning.
- 3–5 bullet value targets (growth, cost, risk, customer, people) with indicative ranges.
This ensures the TOM is always seen as a means to an end, not an end in itself.
2. Design principles (small panel)
List your 5–10 design principles in condensed form. This reminds people:
- How you will lean when trade-offs arise.
- Why certain unpopular choices (e.g., standardization, consolidation) were made.
3. Value streams and ownership (central backbone)
At the heart of the page:
- List the 3–7 priority value streams (e.g., “Lead to Cash – SME”, “Order to Delivery – Retail”, “Incident to Resolution – All segments”).
- Indicate the journey owner or accountable role for each (name of role, not individual).
- Optionally, show 1–2 key KPIs per stream (e.g., lead time, NPS, cost-to-serve).
This visually encodes that the operating model is built around value streams, not functions.
4. Macro-structure and key roles (left or right panel)
A simplified org sketch:
- Major business units or segments.
- Shared services and CoEs.
- Platform / tech organizations.
- Key governance forums (e.g., ExCo, Journey Council, Risk Committee).
- List of critical roles (journey owners, platform owners, heads of shared services).
Not every box and line—just enough to show who runs what.
5. Technology and data architecture (small schematic)
A simple box diagram, at the level of:
- Core systems of record (e.g., ERP, core platform A, core platform B).
- Major engagement layers (e.g., digital channels, CRM, contact center).
- Integration / workflow layer.
- Data and analytics platform.
The purpose is to show:
- Where standardization and reuse are expected.
- How major value streams are supported by common capabilities.
6. Sourcing and footprint (small map or list)
Summarize:
- Which major processes are in shared services, which in BUs, which outsourced.
- Key hubs (operations, tech, analytics) and their primary roles.
- Any important partnerships that are integral to the TOM.
This helps leaders understand where work will actually get done, and by whom.
7. Performance and risk anchors (bottom or side strip)
A compact view of:
- The main enterprise KPIs the TOM is designed to move.
- A small set of journey-level metrics.
- A few risk and control indicators linked to the TOM (e.g., major incident rates, key control failures, critical limit breaches).
This makes it clear that the TOM is tied to how success will be measured and safeguarded.
8. Change and roadmap snapshot (small timeline or box)
Finally, a brief view of how you’ll get there:
- 3–5 major waves or phases with time bands.
- Key milestones (e.g., “Shared service X live”, “Platform Y cutover for BU A”, “Journey Z redesign completed”).
- Any significant dependencies or risk points called out.
This reassures stakeholders that the TOM is implementable, not just aspirational.
