You do not redesign a target operating model in a vacuum. You are changing a living system with history, politics, workarounds, and real performance issues. Understanding today’s reality is essential—but it is also one of the easiest places to lose months in analysis that everyone already “knows” intuitively.
The goal of current-state work in a TOM effort is simple:
Get just enough fact-based insight to inform bold design choices, without turning the project into an audit of the entire company. This chapter focuses on how to do that in a disciplined, time-boxed way.
4.1 When You Need a Current-State Diagnostic—and When You Don’t
The first decision is not how to analyze the current state, but whether you need a formal diagnostic at all.
There are situations where you can move almost directly from strategy to target design, and there are situations where skipping a current-state diagnostic will lead to naïve designs, surprises, and implementation failure.
You almost certainly do need a structured current-state diagnostic when:
- The organization is large and complex, with multiple regions, BUs, or legacy acquisitions.
- There is substantial performance variability (by region, product, or channel) and no common understanding why.
- You operate in a heavily regulated or safety-critical environment where existing controls, systems, and accountabilities matter deeply.
- There is obvious organizational and process sprawl—multiple ways of doing the same thing, local workarounds, parallel systems.
- There is low trust in internal narratives (“everyone blames someone else”) and you need a shared factual baseline.
In contrast, you may not need a full traditional diagnostic if:
- You are building a greenfield operation, a carve-out, or a new digital business with minimal legacy.
- The scope is tightly confined (e.g., a single small BU or product line) and the leadership team already has a clear, shared view of the main issues, supported by hard data.
- You are in an acute crisis where the priority is to put in place a viable interim operating model fast, then refine later.
- You have very recently completed another deep piece of diagnostic work whose findings are still valid (for example, an operations benchmarking or a regulatory remediation review).
Even in these “lighter” cases, you normally still need some view of the current state, but you can keep it to a short, sharp baseline rather than a deep-dive.
A few framing questions help you decide how far to go:
- Are senior leaders aligned today on the top 5 problems in how we operate?
- Do we have at least a basic, quantified view of performance gaps (cost, service, risk, growth)?
- Are we about to interfere with critical control processes (e.g., safety, risk, regulatory reporting)?
- Are there major unknowns where the answer would materially change design choices?
If the honest answer to the first two is “no” and to the latter two is “yes,” you need a structured current-state diagnostic. If the answers are largely flipped, you can use a minimal current-state pass and spend more time on design.
The principle to keep in mind is:
The current-state diagnostic is there to de-risk and accelerate design, not to satisfy curiosity.
4.2 Rapid Current-State Mapping: Processes, Org, Tech, Metrics
Once you decide you do need a current-state view, the trick is to keep it fast, focused, and decision-oriented. A good guideline is to look at the organization through four lenses:
- Processes and value streams
- Organization and governance
- Technology and data
- Performance and metrics
You are not creating four encyclopedias. You are building a coherent, cross-linked picture that explains why performance is what it is today.
Processes and value streams
Start with the priority value streams you identified in Chapter 3. For each:
- Map the end-to-end flow at a high level (10–20 boxes, not 200).
- Mark major handovers between functions, locations, or systems.
- Identify where work splits into many variants (product variants, customer segments, local rules).
- Flag visible pain points: rework loops, manual steps, queue build-ups, duplicated checks.
The test for “good enough” process mapping at this stage:
- A senior leader can look at the map and say, “Yes, that really is how we work,” and
- A designer can use it to see where structural redesign might simplify or standardize.
Do not let teams drift into detailed level-4 process mapping at this point. That level of detail belongs in implementation or in tightly scoped deep dives, not in a baseline TOM diagnostic.
Organization and governance
Here you want to understand how accountability and decision-making really work today, not just what is written in HR systems.
Key elements:
- High-level org charts for major units and functions, with spans and layers.
- Where P&L ownership sits (by BU, region, product, or segment).
- Key governance forums (executive committee, risk committees, portfolio boards, etc.): what decisions they take, how often, and with what information.
- Informal structures: taskforces, “shadow” decision bodies, or single individuals who act as de facto bottlenecks.
You are trying to answer questions like:
- Who really owns each priority value stream?
- Where do decisions slow down?
- Where are there duplicated or ambiguous accountabilities?
Again, “just enough” is the principle. A handful of clean diagrams and decision maps will be far more useful than a 60-page org-structure appendix.
Technology and data
For technology and data, resist the instinct to inventory every system. Instead, focus on:
- The main systems involved in each priority value stream (core platforms, CRMs, ERPs, workflow tools, major spreadsheets).
- How they connect today: key interfaces, manual extracts, workarounds (e.g., CSV dumps, email approvals).
- Known tech pain points: instability, lack of integration, unsupported legacy systems, duplicated tools.
- Data issues that visibly affect operations: inconsistent master data, lack of single customer view, missing or unreliable metrics.
The goal is to answer:
- Which systems are structural constraints you must design around in the TOM timeframe?
- Where are the biggest opportunities from simplification, integration, or automation?
This view will later anchor the technology and data components of the TOM roadmap.
Performance and metrics
You also need a hard view on how well the current model is performing. That means assembling a small, targeted set of metrics that matter for the TOM scope:
- Cost and productivity measures (e.g., cost-to-serve, cost per transaction, FTE per unit of output).
- Service levels and experience (e.g., lead times, backlogs, complaint rates, NPS or equivalent).
- Quality and reliability (e.g., error rates, rework, defect rates).
- Risk and control indicators (e.g., incidents, near-misses, audit findings, mandatory training compliance).
You are not building a full performance dashboard for the whole company; you are answering:
- Where are we clearly underperforming?
- Where is performance highly variable across units?
- Where do we not have reliable measures—and is that itself a problem?
A practical pattern that works well:
- Two-week “current-state sprint”
- Week 1: interviews, document review, metric collection, quick process walks.
- Week 2: build and iterate the four-lens view; test with key leaders; refine into an “as-is fact pack” (Section 4.4).
Timeboxing the work forces pragmatism and keeps teams from disappearing into analysis.
4.3 Prioritizing Pain Points, Bottlenecks, and Failure Modes
A common failure mode is to end the diagnostic phase with long lists of issues: 127 pain points, 63 “improvement ideas,” and 40 risks. No one can design around a list like that. Your job is to compress and prioritize.
Think of this as moving from raw observations to sharp problem statements.
You gather raw input from:
- Interviews and workshops with leaders and front-line staff.
- Direct observation of work (walking the process, sitting with teams, listening to calls).
- Performance data and reports.
- Existing audits, reviews, and customer feedback.
You then synthesize them using three filters:
- Impact
- How much value is at stake if we fix this?
- Consider cost, revenue, customer impact, risk, and employee time.
- Frequency and breadth
- Is this a one-off issue or a recurring pattern?
- Does it affect a single team, or multiple regions and functions?
- Structural vs. local
- Is this primarily caused by the operating model design (process, roles, systems, decision rights)?
- Or is it mainly about local execution, skills, or leadership in one area?
You are looking for structural, high-impact patterns that the TOM must address. For example:
- “No single owner for the SME onboarding journey; Sales, Operations, and Risk optimize locally, driving 20–30% rework and long lead times.”
- “Fragmented customer data across five systems prevents a single view; this undermines both risk controls and cross-sell opportunities.”
- “Decision rights for pricing are unclear; multiple back-and-forth approvals add days to quote turnaround and create inconsistent margins.”
These problem statements are much more actionable than “onboarding is slow” or “data is bad.”
A practical way to get there:
- Cluster individual issues by value stream and by TOM dimension (process, org, tech, people, risk).
- Within each cluster, ask:
- What is the underlying structural cause?
- How would we explain this to the CEO in one sentence?
Push teams to move from symptoms (“we have too many emails”) to causes (“no single workflow tool; approvals not standardized; unclear thresholds”).
You should aim to emerge with:
- A short list (typically 8–15) of priority structural issues that the TOM must solve.
- Each framed as:
- A clear description of the problem.
- Evidence (data, examples, metrics).
- Link to value (cost, growth, risk, experience).
- Link to specific value streams.
This list becomes one of the most critical bridges between diagnostic and design work.
4.4 The “As-Is” Fact Pack (Minimal Viable Diagnostic Template)
The output of your current-state work should not be a sprawling report. It should be a compact, shared reference that:
- Aligns the leadership team on “how we really work today.”
- Clearly articulates the structural problems to be solved.
- Provides enough factual backbone to guide tough design choices.
Think of it as the “As-Is Fact Pack”—the minimal viable diagnostic.
A practical structure (which you can adapt to your context) might be 10–15 pages:
1. Purpose and scope (1 page)
- Why we did the diagnostic (link to strategy and TOM objectives).
- Scope: units, value streams, dimensions, time horizon.
- Brief description of methods: interviews, data, process walks (no need for exhaustive detail).
2. Today’s performance snapshot (1–2 pages)
- A concise view of current performance vs. ambition or benchmarks:
- Cost and productivity.
- Service and experience.
- Risk and control.
- Highlight 3–5 key facts that illustrate why change is needed (e.g., “onboarding time is 3x that of peers,” “40% of volume processed outside core systems”).
3. End-to-end value streams today (2–3 pages)
- For each priority value stream:
- One high-level process map with major steps and handovers.
- Short narrative: how it works today, what variants exist (by region, product, or segment).
- Aim for one page per major stream, not a detailed process manual.
4. Organization and governance snapshot (1–2 pages)
- Macro org picture for the in-scope areas (BUs, functions, shared services).
- Where P&L, journey, and functional ownership sit today.
- Key governance forums and who attends; example of a typical decision path for an important decision (e.g., pricing, product launch, large deal approval).
5. Technology and data landscape (1–2 pages)
- Overview diagram: main systems in scope and how they connect to each priority value stream.
- Notes on critical constraints:
- Systems that will not change in the TOM horizon.
- Major instability or obsolescence issues.
- Key data problems that materially affect operations.
6. Pain points, bottlenecks, and failure modes (2–3 pages)
- The prioritized list of 8–15 structural issues described earlier, each with:
- One-sentence headline.
- Brief evidence (numbers or concrete examples).
- Link to value streams and TOM dimensions.
- Optionally, a simple visual clustering of issues (e.g., by value stream, by TOM dimension).
7. Initial implications for the TOM design (1–2 pages)
- High-level statements that connect diagnostic findings to design directions. For example:
- “We will need clear end-to-end owners for X, Y, Z journeys.”
- “We must consolidate A, B, C processes into a shared service or platform.”
- “We cannot achieve the target cycle times without addressing legacy system X or introducing a workflow layer.”
This section does not pre-empt the full TOM design, but it makes sure that the obvious implications are captured while they are fresh, instead of being rediscovered later.
To keep the fact pack disciplined, you can use a simple internal rule:
- Any slide or page that does not directly help a design decision in the next phase gets cut.
You can always keep a separate “back pocket” of detailed diagnostic material if needed for specific deep dives, but do not let it clutter the core pack that the executive team must actually read and use.
A simple checklist before you call the current-state phase “done”:
- Does the fact pack fit comfortably into a single executive meeting (e.g., 60–90 minutes) without drowning people in detail?
- Can each leader, after that meeting, explain:
- How we currently work in the critical value streams.
- Where the biggest structural problems are.
- Why a TOM redesign is necessary, not just “more effort.”
- Are there clear, explicit links from the fact pack to the TOM design principles and objectives established earlier?
- Have the main functional, regional, and risk leaders reviewed and accepted the description of today’s state, even if they do not like it?
If you can answer “yes” to these questions, you have achieved exactly what you need from current-state mapping: a shared, fact-based platform to move into bold, integrated TOM design—without getting lost in the weeds.
