Strategic Context & Business Case

Linking the TOM to Corporate Strategy

A Target Operating Model does not exist in a vacuum. It is the operational expression of corporate strategy — the mechanism through which a bank's strategic ambitions are translated into concrete decisions about how the organisation operates. If the corporate strategy calls for expansion into new markets, the TOM must define how operations will scale to support those markets. If the strategy prioritises cost leadership, the TOM must identify structural efficiency opportunities. If the strategy emphasises digital client experience, the TOM must design operations around digital-first delivery.

The failure to link TOM design to strategy is one of the most common reasons operating model programmes fail to deliver lasting value. Without strategic alignment, TOM design becomes an exercise in operational optimisation — improving what exists rather than designing what is needed. The result is an incrementally better version of the current model, rather than a fundamentally different operating model that enables new strategic capabilities.

Strategic alignment is achieved through a structured process:

1. Articulate the strategic intent. What is the bank trying to achieve over the next three to five years? This should come directly from the board-approved strategy, not from the assumptions of the transformation team. Common strategic themes in banking include: geographic expansion or contraction, digital transformation, cost-to-income ratio improvement, client segment focus, product rationalisation, and regulatory compliance enhancement.

2. Derive operating model implications. For each strategic theme, identify the operating model implications. If the strategy calls for expansion into Asian markets, what does this mean for location strategy, technology platforms, regulatory compliance, and data architecture? If the strategy calls for a 20% reduction in the cost-to-income ratio, what structural changes to the operating model are required — not just headcount cuts, but process redesign, platform rationalisation, and automation?

3. Define design principles from strategic priorities. The design principles that govern TOM decisions should flow directly from strategic priorities. A strategy focused on client experience might yield a design principle of "design from the client backward." A strategy focused on regulatory excellence might yield "compliance by design, not by exception."

4. Validate continuously. As the TOM design progresses, regularly test design decisions against strategic alignment: "Does this design choice move us toward our strategic objectives, or does it merely optimise the current state?"

Defining the Vision and Design Principles

Before detailed design begins, the TOM programme must establish a clear vision statement and a set of design principles that will guide all subsequent decisions.

The vision statement for the target operating model should be concise, aspirational, and measurable. It describes what the operating model will look like when the transformation is complete. Examples from real banking programmes include:

• "A single, globally standardised operations platform supporting all asset classes, with 90% straight-through processing and real-time client reporting."
• "A digitally-enabled operating model with centralised processing in two strategic hubs, delivering best-in-class client service at a cost-to-income ratio below 45%."
• "An operationally resilient model with no single point of failure, full regulatory compliance across all jurisdictions, and the capability to onboard new products within 90 days."

Design principles translate the vision into actionable guidelines. They should be specific enough to resolve real design disputes, not so generic that they apply to any organisation. "We value efficiency" is not a useful design principle. "All processes will be designed for straight-through processing as the default, with manual intervention only at defined exception points" is a useful design principle because it gives the design team a clear rule to apply.

Typical design principles for a banking TOM include:

• Process standardisation: "A single global process for each operational function, with local variants only where mandated by regulation or market infrastructure."
• Location strategy: "Processing activities are performed in the lowest-cost location that meets regulatory, risk, and service level requirements."
• Technology consolidation: "One platform per function. Where multiple systems currently serve the same purpose, the target state will consolidate to a single platform."
• Data ownership: "Every data element has a single defined owner and a single golden source. No duplication of master data across systems."
• Automation threshold: "Any process with more than 500 daily transactions and a rule-based decision logic will be automated within 18 months."
• Governance simplicity: "Decision rights are assigned to the lowest organisational level that has the competence and authority to make the decision effectively."

Design principles must be formally approved by the TOM steering committee, documented, and communicated to all design workstreams. They serve as the constitution of the programme — when design teams disagree about an approach, the design principles provide the arbitration framework.

Building the Business Case

No TOM transformation programme proceeds without a business case. In banking, where transformation budgets can run into tens or hundreds of millions of euros, the business case must be rigorous, credible, and structured to withstand scrutiny from the CFO, the board, and potentially from regulators.

A TOM business case has three core components: costs, benefits, and financial metrics.

Costs

Transformation costs include:

• Programme management: The cost of the transformation team — programme managers, workstream leads, business analysts, change managers, and project coordinators.
• Technology investment: New platform licences, cloud infrastructure, integration development, data migration, testing, and deployment. In banking, technology is typically the largest cost category.
• People costs: Redundancy packages for roles eliminated by the new model, recruitment costs for new skills, training and reskilling programmes, and temporary contractor costs during the transition.
• Third-party costs: Management consultants, system integrators, specialist advisors, and vendor professional services.
• Operational disruption: The cost of running parallel operations during migration, reduced productivity during transition periods, and the potential for increased errors during cutover.

Benefits

Benefits fall into two categories: quantifiable and qualitative.

Quantifiable benefits include:

• Headcount reduction from process automation, shared services consolidation, and elimination of duplicate functions. This is typically the largest benefit line item.
• Technology cost reduction from platform decommissioning, licence consolidation, and infrastructure rationalisation.
• Error reduction from standardised processes and automated controls, measured in reduced operational losses and lower remediation costs.
• Cycle time reduction leading to better client service and reduced operational risk.
• Regulatory cost avoidance — preventing future regulatory penalties or remediation costs by building compliance into the operating model.

Qualitative benefits include:

• Improved client experience and satisfaction
• Enhanced operational resilience
• Better regulatory relationships
• Increased organisational agility
• Reduced key-person risk

Financial Metrics

The standard financial metrics for a TOM business case are:

Net Present Value (NPV): The sum of all future benefits minus all future costs, discounted to present value. A positive NPV means the programme creates value; a negative NPV means it destroys value. Banks typically use a discount rate of 8-12% for operational transformation programmes.

Internal Rate of Return (IRR): The discount rate at which the NPV equals zero. A higher IRR indicates a more attractive investment. Banking transformation programmes typically target an IRR above the bank's cost of capital.

Payback period: The time required for cumulative benefits to exceed cumulative costs. For major TOM transformations, payback periods of 2-4 years are typical. Programmes with payback periods exceeding 5 years face significant scrutiny and may require phasing to deliver early benefits.

Cost-to-income ratio impact: The projected improvement in the bank's cost-to-income ratio resulting from the transformation. This is a key metric for banking executives and analysts, as it directly impacts return on equity.

A credible business case also includes sensitivity analysis — what happens to the NPV and payback period if costs are 20% higher than planned, or if benefits are 30% lower, or if the programme takes 12 months longer? This analysis builds confidence that the programme remains viable even under adverse scenarios.

Current State Assessment

Before you can design the target state, you must understand the current state with honesty and precision. The current state assessment is a structured diagnostic that documents how the organisation actually operates today across all five TOM dimensions.

Assessment Techniques

Stakeholder interviews. Structured interviews with operational managers, team leads, process owners, technology managers, risk managers, and front-line staff. These interviews capture the reality of daily operations — the workarounds, the pain points, the informal processes, and the areas where documented procedures diverge from actual practice. A good interviewer asks not just "What do you do?" but "What should work but doesn't? Where do you spend time on activities that should not be necessary? What would you change if you could?"

Process walkthroughs. Observing actual operations in real time — watching how a trade is booked, following a payment from initiation to settlement, tracking a client onboarding case from start to finish. Walkthroughs reveal realities that interviews miss: the four spreadsheets that sit between two systems, the email chain that substitutes for a proper workflow tool, the manual reconciliation that happens every morning before the "automated" process can run.

Data analysis. Quantitative analysis of operational data — transaction volumes, error rates, cycle times, STP rates, exception volumes, system availability metrics, and cost data. This provides an objective baseline against which the target state can be measured.

Technology landscape mapping. Documenting every system, platform, database, and tool used in operations — including shadow IT, desktop applications, and locally developed Access databases or Excel macros. Many banks discover during this exercise that their actual technology landscape is 30-50% larger than what is recorded in their official application inventory.

Regulatory and control mapping. Documenting current regulatory obligations, control frameworks, audit findings, and areas of non-compliance. This ensures the target state addresses known deficiencies rather than carrying them forward.

Common Pitfalls in Current State Assessment

Documenting the "should be" instead of the "is." The most dangerous pitfall is capturing how processes are supposed to work rather than how they actually work. Senior managers describe the designed process; front-line staff reveal the actual process. Both perspectives are needed, but the actual process must be the documented baseline.

Insufficient depth. A superficial current state assessment leads to a target state that fails to address fundamental issues. If the assessment does not identify that the reconciliation team is running 47 separate Excel spreadsheets to compensate for system limitations, the target state will not address this problem.

Scope limitations. Assessing only one dimension — typically technology — while ignoring people, process, governance, and data. Technology migration without process redesign simply automates existing inefficiencies.

Maturity Models for Operational Capability

Maturity models provide a structured framework for assessing the current capability level of each operational function and setting target maturity levels for the future state. The most widely used framework in banking operations is a five-level maturity model:

Level 1 — Initial/Ad Hoc. The process exists but is undocumented, inconsistent, and dependent on individual knowledge. There are no standardised procedures, limited management oversight, and high key-person risk. Outcomes are unpredictable.

Level 2 — Repeatable. Basic processes are documented and consistently followed within individual teams. However, there is limited standardisation across teams or business lines. Management reporting exists but is manual and inconsistent.

Level 3 — Defined. Processes are standardised across the organisation, documented in a central repository, and governed by defined ownership. Performance is measured against KPIs. There is a formal control framework, and exceptions are tracked and analysed.

Level 4 — Managed. Processes are actively managed using quantitative data. Performance is monitored in real time, root causes of issues are systematically identified, and continuous improvement is embedded in operational management. Automation is widely deployed, and STP rates are high.

Level 5 — Optimised. The organisation operates at industry best-practice levels. Processes are continuously refined based on data analytics, benchmarking, and emerging technologies. Innovation is systematic, and the operating model is designed for adaptability.

In a TOM programme, the maturity model is used in two ways: first, to assess current maturity levels across all operational capabilities (providing an objective view of the current state); and second, to set target maturity levels for the future state (not every capability needs to be Level 5 — the target should reflect strategic priorities and cost-benefit considerations).

Gap Analysis

Gap analysis is the bridge between current state assessment and target state design. It systematically compares the current state against the target state across all TOM dimensions and identifies the specific changes required.

For each gap, the analysis documents:

• Dimension: Which TOM dimension is affected (people, process, technology, governance, data)?
• Current state: A concise description of how things operate today.
• Target state: A concise description of the desired future state.
• Gap description: The specific change required to move from current to target.
• Complexity: An assessment of the difficulty of closing the gap (low, medium, high).
• Dependencies: Other gaps or changes that must be completed before this gap can be addressed.
• Priority: The urgency of closing the gap, based on strategic importance, regulatory pressure, and cost-benefit.

The output of gap analysis is the transformation backlog — a prioritised list of changes that forms the basis of the implementation roadmap. This backlog is managed as a living document throughout the programme, with new gaps added as they are discovered and completed gaps closed out.

Banking Example: Centralising Securities Operations

Consider a European banking group — let us call it Continental Securities Group (CSG) — with securities operations spread across three entities: a German entity focused on European equities and fixed income, a Luxembourg entity handling fund administration and custody, and a French entity serving institutional clients with derivatives and structured products.

Each entity has its own operations team, its own technology platforms, its own processes, and its own governance structure. The total annual cost of securities operations across the three entities is EUR 120 million, with 650 FTEs.

CSG's board approves a strategy to become the leading European securities services provider, with a target cost-to-income ratio of 55% (currently 68%). The CEO commissions a TOM programme to define how securities operations should be structured to deliver this strategy.

Strategic alignment: The TOM must enable geographic expansion (adding new markets), product expansion (adding new asset classes), cost reduction (achieving the 55% target), and regulatory compliance across multiple European jurisdictions.

Design principles established:

1. Single global process for each operational function
2. One platform per function (no duplicate systems)
3. Processing consolidated into a single European hub
4. Client-facing functions retained in each market
5. Automation first — manual intervention only at defined exception points

Current state assessment reveals:

• Three separate settlement platforms (one per entity), none of which communicates natively with the others
• 47 different reconciliation processes, of which only 12 are automated
• No common data model — client reference data is maintained independently in each entity
• Different KPI frameworks — there is no way to compare operational performance across entities
• 23 regulatory reporting processes with significant manual intervention

Maturity assessment:

• Settlement: Level 2 (Repeatable) in Germany, Level 2 in France, Level 1 (Ad Hoc) in Luxembourg
• Reconciliation: Level 1 across all entities
• Client reporting: Level 2 in France, Level 1 in Germany and Luxembourg
• Regulatory reporting: Level 2 across all entities

Business case construction:

The programme team builds the business case over eight weeks, incorporating:

• Costs: EUR 65 million over three years (technology platform consolidation EUR 35M, programme team EUR 12M, redundancy and relocation EUR 10M, training EUR 3M, contingency EUR 5M)
• Benefits: EUR 40 million annual run-rate savings by Year 3 (headcount reduction of 180 FTEs through consolidation and automation EUR 27M, technology cost reduction from platform decommissioning EUR 8M, error reduction and operational loss avoidance EUR 5M)
• NPV (10-year, 10% discount rate): EUR 142 million
• Payback period: 2.4 years
• Cost-to-income ratio impact: Reduction from 68% to 56%, approaching the 55% target

The business case includes sensitivity analysis showing that even with 25% cost overrun and 20% benefit shortfall, the NPV remains positive at EUR 68 million.

Gap analysis identifies 127 gaps across the five TOM dimensions, prioritised into three implementation waves:

• Wave 1 (Year 1): Organisational consolidation, process standardisation, common KPI framework
• Wave 2 (Year 2): Technology platform migration, data model harmonisation
• Wave 3 (Year 3): Advanced automation, optimisation, and continuous improvement embedding

This structured approach — from strategic alignment through current state assessment, maturity evaluation, gap analysis, and business case — provides CSG's board with the confidence to approve a EUR 65 million transformation programme, because every number is grounded in rigorous analysis and every design decision traces back to strategic intent.

In the next module, we will dive into the process architecture and capability mapping dimension of TOM design — the detailed work of defining how the bank's operations will function at every level from enterprise value chain to desktop procedure.