Redesigning the operating model starts with how value actually flows through the company. If you get the value streams and core processes right, organization, technology, and metrics have something solid to sit on. If you skip this step, everything else becomes an argument about boxes, titles, and systems with no real anchor.
This chapter is about practical, executive-level process design: clear enough to drive decisions, not so detailed that you disappear into BPM bureaucracy.
We will cover:
- How deep to go in process detail.
- How to define end-to-end value streams and assign real owners.
- How to decide what should be standardized globally and what can flex locally.
- How to use a few robust tools (swimlanes, SIPOC, E2E blueprints) without turning them into an industry.
5.1 Choosing the Right Level of Process Detail
Most TOM programs fail one of two ways on process:
- They stay so high-level (“we have a sales process, an onboarding process…”) that nothing operational changes.
- Or they drown in detail: hundreds of pages of BPMN no one reads or uses.
You are looking for the “right altitude”: detailed enough to shape roles, technology, and performance targets; high-level enough that executives can understand and debate it.
A simple three-level lens helps:
- Level 0 – Value stream
- Names the major end-to-end flows (e.g., “Lead to Cash”, “Order to Delivery”, “Incident to Resolution”).
- This is your backbone.
- Level 1 – Major stages
- 8–15 boxes from start to finish for each value stream (e.g., “Qualify lead”, “Prepare proposal”, “Negotiate and close”, “Set up account”).
- Clear handovers and responsibilities.
- Level 2 – Key sub-steps and decision points
- For critical stages, break down into key activities and decisions, especially where risk, cost, or customer friction are concentrated.
For TOM design, most of your effort should be at Levels 0 and 1, with selective Level 2 detail where it matters. Full-blown Level 3+ mapping (every variant, exception, and field) is usually an implementation task, not a design task.
A few practical rules:
- If an executive cannot follow the map in a few minutes, you are too detailed for TOM design.
- If you cannot use the map to answer questions like “Who owns this step?” or “Which systems are involved here?”, you are too high-level.
- If your team is arguing about the 5th variant of a rare case, you are in the weeds.
When you feel pressure to go deeper, ask:
“Will additional detail change a design decision?”
If not, stop there and move on.
5.2 Defining End-to-End Value Streams and Journey Owners
A value stream (or customer journey) is the sequence of activities that delivers a specific outcome for a customer or stakeholder, from trigger to completion. In TOM design, value streams are your primary building blocks.
Common examples:
- “Lead to Cash”
- “Order to Delivery”
- “Onboard Customer”
- “Issue to Resolution”
- “Concept to Product Launch”
You are not trying to capture everything. You want a manageable set of 3–7 priority value streams that:
- Are central to your strategy and differentiation.
- Drive a large share of revenue, cost, and/or risk.
- Involve multiple functions and handovers.
Once you name them, the critical move is this:
Every priority value stream gets a single, clearly accountable owner.
That owner’s job is not to “own everything” in a hierarchy sense, but to be accountable for:
- End-to-end performance: cycle times, cost, quality, experience.
- Cross-functional alignment of process, policies, and improvements.
- Prioritizing changes and investments that affect the stream.
Choosing value stream owners is a design decision with political implications, so be deliberate.
Common patterns:
- Business or P&L leader as owner
- Works when the value stream is closely tied to a specific segment or BU (e.g., “SME onboarding” owned by the SME BU head).
- Pros: Strong commercial focus and clout.
- Risks: May bias decisions toward “their” P&L at the expense of group or other segments.
- Cross-functional “journey owner” role
- A senior leader whose formal role is to own the end-to-end journey across functions and locations.
- Pros: Clear focus on journey performance; can be replicated across streams.
- Risks: Needs real authority and sponsorship; can become “journey owner in name only.”
- Platform/product owner
- Where the operating model is strongly platform- or product-based (e.g., a digital platform through which the whole journey runs), a platform or product owner can own both the process and the enabling stack.
- Pros: Strong link between process and technology changes.
- Risks: May underweight human, organizational, or local nuances.
Whichever pattern you choose, spell out the responsibilities of a value stream owner:
- Set and track end-to-end KPIs.
- Convene cross-functional forums to fix issues and redesign steps.
- Escalate and resolve conflicts between functions and regions.
- Shape the change roadmap and investment priorities for that stream.
Then clarify the interface with functions:
- Functions (e.g., Sales, Operations, Risk, Finance) retain people management, professional standards, and capability building.
- Value stream owners orchestrate how those capabilities combine to deliver the journey.
A simple litmus test:
- For each priority value stream, can you name one person who would say “I am accountable for how this works from end to end”?
- If that person does not exist or has no real authority, your TOM still has a silo backbone, not an end-to-end backbone.
5.3 Standardization vs. Localization: A Practical Approach
One of the most contentious TOM topics is: “What should be the same everywhere, and what can vary?”
If you centralize and standardize everything, you risk being slow, irrelevant to local needs, and blind to differences in customers and regulation. If you localize everything, you lose scale, create complexity, and make any change ten times harder.
You need a structured way to decide.
A practical approach is to segment processes and decisions into three buckets:
- Global core: must be the same everywhere.
- Configurable framework: common backbone, with controlled parameters.
- Local specific: genuinely local processes or practices.
Apply this lens across a few dimensions:
- Process steps and sequence.
- Business rules and policies.
- Data definitions and master data.
- Systems and tools.
- Roles and decision rights.
Global core
These are elements that should be designed once and reused everywhere. They are usually driven by:
- Regulation and risk (e.g., anti-money-laundering checks, capital reporting logic).
- Brand and customer promise (e.g., basic refund or complaint-handling principles).
- Scale and efficiency (e.g., how invoices are generated and posted).
- Data integrity (e.g., definitions for “customer”, “product”, “active account”).
Signs something should be global core:
- Differences across units create no real customer or regulatory benefit, only complexity.
- Fragmentation causes real problems (e.g., reporting errors, inconsistent experiences).
- It relies on major shared platforms or data sources.
For global core items, you should be explicit:
- Who owns the standard.
- How changes to the standard are proposed, evaluated, and approved.
- How compliance is checked and enforced.
Configurable framework
Here, you design a single framework but allow controlled variation via parameters, templates, or options. Examples:
- A global pricing framework with local parameter ranges (e.g., floors and ceilings).
- A common onboarding workflow with optional steps that can be toggled for certain products or risk levels.
- A shared customer segmentation logic with some local micro-segmentation allowed.
This is often the sweet spot: enough consistency to be manageable, enough flexibility to reflect different markets and segments.
The discipline is to define:
- Which elements are fixed.
- Which are configurable, within what ranges.
- Who can change parameters, and under what governance.
Local specific
Some elements genuinely need to be local:
- Local legal forms and documentation.
- Local regulatory reports and authority interactions.
- Channel or partner-specific ways of working that reflect unique ecosystems.
- Customer behaviors that are structurally different in certain markets.
Even here, you can often reuse patterns. But you acknowledge that these processes or sub-processes will be designed and managed locally, with interfaces clearly defined to the global core.
To make this practical, you can ask three questions for each major process element:
- Does variation here create real value (revenue, satisfaction, risk reduction), or is it just history and preference?
- Does fragmentation here cause material cost, complexity, or risk?
- Is the environment (regulatory, market, customer) structurally different enough to justify local design?
If the answer to 1 is “no”, 2 is “yes”, and 3 is “no”, that element belongs in the global core. If 1 is “yes” and 3 is “yes”, you are likely in configurable or local-specific territory.
The key is to decide consciously. In many organizations, standardization vs. localization is the result of who shouted loudest, not of a deliberate TOM choice.
5.4 Process Design Tools: Swimlanes, SIPOC, and E2E Blueprints
You do not need exotic notation to design a robust TOM. A few simple tools, used well, are enough:
- Swimlane diagrams
- SIPOC summaries
- End-to-end (E2E) blueprints
The point is not the diagrams themselves; it is the conversations they structure.
Swimlane diagrams
Swimlanes are straightforward: you map the steps of a process horizontally over time, with vertical “lanes” for roles, teams, or systems.
They are especially useful for:
- Making handovers visible.
- Exposing duplication (“everyone checks the same thing”).
- Seeing where work bounces between functions.
For TOM design, keep swimlanes:
- At Level 1 or selective Level 2 detail.
- Focused on priority value streams and pain points.
- Clearly annotated with:
- Handover points.
- Manual vs. automated steps.
- Approvals and controls.
You can use color or simple icons to mark:
- Where the biggest delays occur.
- Where errors are frequent.
- Where there is high risk or regulatory scrutiny.
Run short, focused sessions:
- Start from a strawman swimlane based on your current-state mapping.
- Have cross-functional teams walk through “a day in the life” of a typical case.
- Capture pain points and ideas for simplification or automation directly on the diagram.
The output is not “the final process model” but a design input that informs your target-state blueprint.
SIPOC summaries
SIPOC (Suppliers, Inputs, Process, Outputs, Customers) is a compact way to describe a process at a high level.
For each priority value stream or major process:
- Suppliers: who provides inputs (internal or external).
- Inputs: what is needed to start or continue the process.
- Process: a short summary of key steps (not a detailed map).
- Outputs: what is produced, in what form.
- Customers: who receives and cares about the outputs.
SIPOCs are useful to:
- Align stakeholders quickly on scope and boundaries.
- Spot misalignments: inputs that are unreliable, outputs nobody uses, missing or unclear customers.
- Identify where upstream changes could dramatically improve the downstream experience.
They are particularly handy when you involve people from different levels of the organization; not everyone is comfortable reading process diagrams, but almost everyone can reason through SIPOC.
End-to-end blueprints
An E2E blueprint is the target-state one-pager for a value stream. It is one of the most powerful TOM artifacts you can create.
A good blueprint pulls together:
- High-level process stages (boxes across the page).
- For each stage:
- Main activities and decisions.
- Primary roles or teams involved.
- Main systems or tools used.
- Key controls or checks.
- 2–3 critical KPIs (e.g., lead time, error rate, conversion).
You can think of it as a “process, org, tech, metrics” overlay on a single page.
Typical steps to create E2E blueprints:
Start from your current-state maps and SIPOCs for the value stream.
- Re-apply your design principles and customer promises from Chapters 3 and 4:
- Where do we want to remove handovers?
- Where should we move decisions closer to the front line?
- Where should we standardize or automate?
- Sketch the target sequence of stages:
- Use 6–12 boxes for the full end-to-end journey.
- Label each with clear, action-oriented names (“Capture order”, “Validate and price”, “Schedule and allocate”, “Deliver and confirm”).
- For each stage, add the key overlays:
- Main role accountable (not every role involved).
- Systems that should be primary in the future (not every system that exists today).
- Critical controls: what must go right here to stay safe and compliant.
- 1–3 KPIs that will define success.
- Test and refine in cross-functional workshops:
- “Walk a real case” through the target blueprint.
- Ask: How would this work in Region A? In Product B?
- Check consistency with your standardization vs. localization choices.
The result should be something an executive can look at and say:
- “I see how value will flow.”
- “I see who is accountable at each stage.”
- “I see which systems matter.”
- “I see how we will measure performance.”
That blueprint then becomes the anchor for:
- Detailed process design where needed.
- Organization and role design.
- Technology and data roadmap.
- Performance management and incentive changes.
If you find yourself with 25-page blueprints per journey, you have lost the plot. Better to have one excellent page and a few annexes than a small library no one uses.
