Redesigning a target operating model is not just a design exercise, it is a political and organizational project. The quality of your TOM will be defined as much by how you frame the effort, who owns it, and what mandate you secure, as by any process maps or org charts you produce.
If you skip this chapter in real life—if you rush into workshops and swimlanes without a clear mandate—you will pay for it later in rework, resistance, and “death by alignment meeting.” This chapter is about doing the unglamorous but essential upfront work so that the rest of the TOM journey has a solid foundation.
We will cover:
- Who is actually sponsoring and deciding
- How to define and right-size the scope
- How to clarify objectives and value targets
- How to capture all of this in a short, sharp TOM mandate and charter
2.1 Who Is the True Sponsor and Decision-Maker?
Every TOM effort has a nominal sponsor and a real sponsor. If those are not the same person (or body), you will encounter delays and reversals.
The nominal sponsor is the name on the slide: “Executive Sponsor: COO” or “Sponsor: Group CEO.” The real sponsor is the person whose decisions actually stick—whose word resolves conflict, unblocks resources, and signals priorities down the line.
Your first task as an executive leadership team is to be brutally honest about who has to own this.
For an enterprise-level TOM, the real sponsor is usually:
- The CEO, if the TOM cuts across multiple businesses and functions and will alter power, budgets, and decision rights.
- Occasionally the COO or a Group-level executive with clear authority over operations, technology, and functions—but only if the CEO will consistently back them when trade-offs get tough.
For a business-unit-level TOM, the sponsor is typically:
- The BU CEO / P&L owner, with clear alignment to the Group CEO if the TOM changes shared functions, platforms, or brand-level ways of working.
For a functional TOM (e.g., Finance, HR, Operations), the sponsor might be:
- The functional head (CFO, CHRO, etc.), as long as they have enough authority to change how other parts of the business interact with their function; otherwise, you still need a Group-level executive to co-sponsor.
A useful way to surface the true sponsor is to ask a few simple questions:
- Who can approve the final TOM design without needing someone else in the room?
- Whose support (if withdrawn) would quietly kill this initiative?
- When there are conflicts between major stakeholders (e.g., BU vs. Group, Sales vs. Operations), whose decision will be treated as final?
- Who controls the budget and people needed to implement the redesigned TOM?
If the answer is “a committee” for most of these, you have an early warning sign. Committees can advise and ratify; they rarely drive bold operating model choices.
Once you identify the true sponsor, you should:
- Confirm that they are willing to visibly own the TOM: communicate it, defend it, and stay engaged throughout design and implementation.
- Clarify their decision role: which decisions they will personally take, which they will delegate, and which require full executive team alignment.
- Align on time commitment: TOM design is not something a sponsor can “set and forget.” They will need to chair key design reviews, resolve disputes, and signal priorities repeatedly.
If you cannot secure such a sponsor, the honest conclusion may be: this is not the right moment for a full TOM redesign. You might scale the ambition to a narrower transformation that a lower-level sponsor can credibly own.
2.2 Defining Scope: Enterprise vs. Business Unit vs. Function
The second foundational choice is scope: what exactly are you redesigning? Scope decisions determine the magnitude of change, the complexity of alignment, and the time to impact.
There are three primary axes of scope:
- Organizational scope: enterprise, business unit, function, region.
- Value stream / process scope: which end-to-end flows (e.g., “Lead to Cash”, “Order to Delivery”, “Hire to Retire”).
- Thematic scope: which dimensions you touch (e.g., just organization; org + process; org + process + tech + data; etc.).
You want a scope that is big enough to matter, but small enough to manage.
Enterprise-level scope
An enterprise TOM redesign covers the majority of the company’s value streams and functions. This is warranted when:
- The strategy has fundamentally shifted (e.g., to platforms, integrated solutions, or radically different markets).
- Current fragmentation across BUs or regions is a structural blocker (e.g., too many local variants, inconsistent risk practices).
- Major tech or M&A moves require a common “backbone” across the group.
Benefits:
- Coherent, integrated design across the company.
- Clean decisions on central vs. local, shared services, platforms, and governance.
- Significant potential value (cost, speed, risk reduction).
Costs/risks:
- High coordination burden; many stakeholders to align.
- Longer design and implementation cycles.
- Risk of becoming “too abstract” if not anchored in concrete value streams.
Business-unit-level scope
A BU TOM redesign focuses on one P&L, segment, or product line. This is suitable when:
- The BU’s strategy meaningfully differs from others (e.g., digital-first vs. traditional).
- The BU has specific performance issues that others don’t share.
- The Group wants to pilot a new way of working in one BU before wider rollout.
Benefits:
- Faster decision-making; fewer stakeholders.
- Easier to pilot bold changes.
- Clear P&L ownership of outcomes.
Costs/risks:
- Potential misalignment with group functions and platforms.
- Risk of creating one more “variant” of the operating model if there is no plan to converge later.
Functional scope
Here, you redesign the operating model of a function (e.g., Finance, HR, Operations, IT, Risk). This can be appropriate when:
- The function is a critical enabler of strategy (e.g., Data & Analytics, Technology).
- The function is underperforming or overly complex.
- The enterprise TOM is already clear, but the function has not yet caught up.
Benefits:
- Tight focus; manageable stakeholder set.
- Clear link to functional metrics and capabilities.
- Often quicker impact on cost and quality within that function.
Costs/risks:
- If not integrated with business and other functions, you risk local optimization—a function that is efficient but misaligned with how the business actually works.
When defining scope, be explicit on four dimensions:
- Organizational boundary: which legal entities, BUs, regions, functions are in and out.
- Value streams / journeys: which end-to-end flows will be explicitly redesigned.
- Design dimensions: which of the eight TOM dimensions are in scope (e.g., “Org + Governance + Processes + Tech/data; we will not redesign corporate strategy or brand”).
- Time horizon: is this a 2-year TOM, a 5-year TOM, or both (with a “next 24 months” focus)?
You can use a multi-speed approach if needed: for example, an enterprise-level TOM “frame” with one or two BUs going deeper and faster as pilots.
The key is to avoid vague formulations like “we’re rethinking how we operate” without concrete boundaries. Ambiguity here will surface later as scope creep, frustration, and diluted impact.
2.3 Clarifying Objectives and Value Targets Up Front
A TOM redesign is not a philosophical exercise; it is a value delivery mechanism. Before you start drawing any diagrams, the executive team should align on:
- What problems the TOM must solve
- What outcomes you expect (in numbers, where possible)
- What trade-offs you are willing to make
Think in terms of five families of objectives:
- Financial / Efficiency
- Structural cost reduction (e.g., reduce operating expense by X%).
- Productivity improvements (e.g., revenue or output per FTE, per asset).
- Capital efficiency (e.g., working capital, asset utilization).
- Growth / Revenue Enablement
- Faster time to market for new products or features.
- Improved sales effectiveness or conversion rates.
- Ability to enter new markets or segments at lower marginal cost.
- Customer / Stakeholder Experience
- Service levels (e.g., response times, lead times, on-time delivery).
- Quality (e.g., error rates, rework).
- Experience metrics (e.g., NPS, customer effort score).
- Risk, Control, and Compliance
- Reduction in operational losses, incidents, or audit findings.
- Stronger compliance posture; fewer remediation programs.
- Improved resilience (e.g., continuity, cyber, key-person dependency).
- Organizational Health and Flexibility
- Simpler structure with fewer spans/layers.
- Greater cross-functional collaboration and clarity of decision rights.
- Better talent attraction, retention, and career paths in critical roles.
You do not need to set dozens of targets, but you should agree a small, sharp set of core goals. For example:
- Reduce structural operating cost by 10–15% over three years.
- Cut lead-times for X key journeys by 40–50%.
- Halve the number of material audit findings in core processes.
- Reduce the number of management layers from 8 to 6.
You should also agree what the TOM is not primarily about. For example, you might say:
- “This TOM is not a headcount-cutting exercise; cost savings will come mainly from simplification, automation, and consolidation.”
- Or: “This TOM is explicitly a structural cost program; experience improvements are desirable but secondary.”
This level of clarity helps downstream when you face trade-offs like:
- Should we centralize more to save cost, even if it reduces local autonomy?
- Should we invest more in data and automation now to unlock longer-term benefits, even if payback is slower?
- Should we accept some short-term service disruption during implementation?
It is useful to summarize objectives and targets in a simple value tree:
- At the top: a small set of enterprise outcomes (e.g., EBIT, growth, risk).
- Below: TOM levers (e.g., consolidation, automation, process redesign, org simplification).
- For each lever: estimated contribution range and key assumptions.
You are not building a detailed business case yet—that comes later—but you are pinning a flag: “If this TOM works, these are the kinds of benefits we expect, and in this magnitude.”
Finally, confirm alignment by asking each executive privately (or in a candid session):
- “In one sentence, what is the primary reason we are doing this TOM?”
- “What must be visibly better in 18–24 months for you to call this a success?”
If the answers vary wildly, you need more alignment work before you proceed.
2.4 Drafting the TOM Mandate and Charter (Template & Checklist)
Once you know who owns the TOM, what the scope is, and what outcomes you seek, capture it in a short, concrete mandate and charter. This becomes the reference document you come back to every time someone tries to expand scope, reopen settled questions, or reframe the purpose.
Think of the charter as a 4–6 page working document, not a glossy brochure. It should be concise enough that senior leaders will actually read it.
A practical structure:
1. Context and Rationale
- Brief summary of the strategic and operational context.
- Key pain points and opportunities that the TOM must address.
- Why now (triggers, timing constraints).
2. Objectives and Value Targets
- Primary objectives (1–3 sentences).
- Quantified targets or ranges for cost, growth, risk, experience, and organizational health (as applicable).
- Any explicitly secondary or out-of-scope objectives (to avoid confusion).
3. Scope and Boundaries
- Organizational scope: entities, BUs, regions, functions included and excluded.
- Value streams / journeys in focus.
- Design dimensions in scope (e.g., processes, org, tech, sourcing, performance, risk).
- Time horizon: target state timeframe and key interim milestones.
4.Design Principles
- 5–10 clear principles to guide design choices, such as:
- “End-to-end ownership: each value stream has a single accountable owner.”
- “Global standards where they matter; local flexibility where they create value.”
- “Automation-first for repeatable transactional work.”
- “Controls embedded in processes and systems, not added on top.”
These principles will be used later to test design options and to explain decisions.
5. Governance and Roles
- Sponsor: name and role; decision authority.
- Steering committee or design board: membership, remit, meeting cadence.
- TOM design lead and core team: roles and time commitment.
- Decision framework: which decisions are made by whom, and how conflicts are escalated.
6. Deliverables and Timeline
- Key design deliverables (e.g., one-page TOM blueprint, detailed process maps for priority journeys, org design, tech/data implications, sourcing model, business case, roadmap).
- Phasing of work (e.g., diagnostic and framing, high-level design, detailed design, business case, roadmap).
- Target dates for major gates (e.g., “High-level TOM sign-off by Month X”).
7. Constraints and Guardrails
- Non-negotiables (e.g., regulatory requirements, commitments to unions, technology decisions already made, strategic pledges to customers or employees).
- Budget envelope for design work and for near-term implementation if already known.
- Interfaces with other major programs (e.g., ERP implementation, M&A integration, restructuring).
You can treat this as a living document during the first few weeks, but lock it once you start serious design work. Any major changes after that should be explicit and sponsored, not gradual creep.
To make this practical, here is a TOM Charter Checklist you can use as a quick test:
- Have we clearly named a single accountable sponsor with decision authority?
- Have we defined the exact scope (org, journeys, dimensions, time horizon) and noted what is out of scope?
- Have we agreed and written down primary objectives and value targets, not just generic aspirations?
- Do we have 5–10 design principles that are specific enough to guide real trade-offs?
- Is the governance structure clear, including who sits on the steering group, who leads design, and how often they meet?
- Are the key deliverables and gates defined with indicative dates?
- Have we captured important constraints and interfaces to other major initiatives?
- Has the full executive leadership team explicitly endorsed this charter (not just “not objected”)?
If you can answer “yes” to all of these, you have a solid foundation. If you are missing several, you are about to launch a complex, sensitive transformation effort with a fuzzy mandate. Experience suggests that any time you “save” by skipping this work will come back as months of delay and rework.
With the sponsor, scope, objectives, and mandate now clarified, you are ready to move into the next stage: translating strategy into concrete operating requirements and design principles, and beginning to map your current state without drowning in detail. That is the focus of the next chapters.
