Operating Model Construction and Elevation: Building the Enterprise TOM Top-Down, Bottom-Up, and by Convergence
v0.4 · 19 October 2026 · First issued 1 September 2026 · Custodian: BusinessGPS · Version index and changelog
Position. An operating model canvas (OMC) or target operating model (TOM) may be initiated top-down from strategy and customer value, bottom-up from a domain or value stream, or through both directions. It becomes an enterprise OMC/TOM only when its boundary is explicit, its enterprise hypotheses are reconciled with strategy and the business model, its cross-domain interfaces are validated, and the integrated design receives the appropriate human approval.
Executive summary
The literature on operating models tends to assume one direction of travel: strategy sits at the top, and a target operating model cascades down from it. That top-down route is real and necessary — but it is not the only legitimate one, and treating it as such causes two recurring failures. Teams either wait for a perfect enterprise strategy before touching the operating model, or they let a single function quietly rename its own model “the enterprise TOM.”
In practice, a detailed functional discovery — a finance discovery, or a supply-chain discovery — produces a powerful vertical slice through the whole enterprise. It exposes how the organisation actually works: the hidden dependencies, the unofficial work, the judgement, the compensating controls. That is genuine enterprise evidence. What it is not, on its own, is the complete enterprise operating model.
This paper defines the two construction routes, argues for their convergence, and — most importantly — specifies the controls that let a domain model elevate to the enterprise level legitimately: a federated OMC/TOM architecture and five human elevation gates. It is the construction-and-integration companion to the BusinessGPS diagnostic papers: where The Five-Layer Activity Model says where enterprise work sits and TCM Discipline names the discipline that governs change, this paper says how the operating model itself is built and integrated.
1. The question behind the paper
A detailed functional discovery, such as finance, can yield a useful operating model canvas and target operating model. That raises a wider method question:
Can a detailed functional discovery provide a legitimate starting point for constructing the wider enterprise OMC/TOM?
The answer is yes — with clear scope and reconciliation conditions.
Finance and supply chain each expose enterprise-wide patterns because they cross organisational boundaries. Their models are powerful vertical slices through the enterprise. They should not, however, be assumed to represent the complete customer, strategic, or operating reality without validation from other perspectives. This paper defines the legitimate bottom-up route and its controls.
2. Two valid construction routes
The strategy-led, top-down route runs: environment and strategy → customer/beneficiary evidence → value proposition → business model canvas → enterprise OMC → domain OMCs → detailed TOM → transformation roadmap. This route is strongest for determining what the future enterprise should become. It anchors design in customer value, strategic choices, business-model economics, and target outcomes.
The domain-led, bottom-up route runs: domain evidence and lived operations → domain OMC/TOM → cross-domain interfaces and dependencies → enterprise operating-model hypotheses → reconciliation with strategy, customer value, and the business model → integrated enterprise OMC/TOM. This route is strongest for exposing how the organisation actually works, including hidden dependencies, unofficial work, judgement, information gaps, and compensating controls.
The preferred route is convergence. Use outside-in / top-down design for direction, and inside-out / bottom-up discovery for operating truth. The integrated model emerges through reconciliation of the two — not by automatically privileging either view. Top-down intent and bottom-up truth meet in the middle, and the meeting is where the real design decisions are made.
3. The correct unit of analysis
A finance discovery initially produces a finance domain OMC, a finance TOM, a finance-led enterprise operating-model discovery, or a finance vertical slice through the enterprise operating model. A supply-chain discovery initially produces the supply-chain equivalents, or a value-flow-led operating-model discovery. These may contain material enterprise evidence — but that evidence does not automatically change their formal scope.
To keep scope honest, the unit of analysis should record: the domain and organisational boundary; the value streams directly examined; the stakeholders represented; the enterprise areas directly evidenced; the areas inferred but not validated; the current, transition, and target-state content; the evidence cutoff and provenance; the decisions already authorised; and the assumptions requiring cross-domain validation.
4. Why finance is a strong enterprise discovery lens
Finance observes or participates in much of the enterprise — revenue, billing and collection; procurement, expenditure and supplier payment; inventory, assets and valuation; product, programme, customer and organisational costs; capital expenditure and transformation investment; planning, forecasting and performance reporting; treasury, tax, audit, risk and control; legal-entity and management reporting.
It can therefore reveal economic and value flows, business-unit and legal-entity structures, product and customer profitability, organisational accountabilities, enterprise information and master-data fragmentation, supplier and platform dependencies, management priorities and decision rhythms, and the manual reconciliation that compensates for operating-model fragmentation. This makes finance a strong economic, control, and management-information spine for enterprise discovery.
5. The limits of the finance mirror
Finance does not literally mirror the complete business. It primarily sees what can be transacted, classified, valued, budgeted, controlled, and reported. It may not adequately expose: customer jobs, pains, and lived experience; unmet or unrecorded demand; queues, handoffs, and failure demand; informal work and tacit judgement; engineering and technical knowledge; quality and safety mechanisms hidden by aggregated reporting; supplier collaboration outside contractual records; workforce trust, change load, and social licence; or strategically important capabilities whose value is not readily financialised.
Finance structures are also shaped by charts of accounts, cost centres, legal entities, accounting standards, and ERP configuration — which may encode the historical operating model rather than the target one. So:
Finance provides a powerful view of economic and control reality, but it is not a complete representation of customer value, lived operations, or strategic capability.
6. A finance domain OMC using POLISM
| OMC element | Finance-domain content |
|---|---|
| P — Processes / value-delivery chains | Record-to-report, procure-to-pay, order-to-cash, planning, consolidation, treasury, tax, and control processes |
| O — Organisation | Controllership, FP&A, finance business partners, shared services, centres of expertise, and decision accountabilities |
| L — Locations | Corporate, business-unit, regional, shared-service, operational-site, and outsourced locations |
| I — Information | Ledgers, plans, forecasts, management accounts, profitability, master data, reporting, and analytics |
| S — Suppliers | Banks, auditors, advisers, BPO providers, data suppliers, and platform vendors |
| M — Management System | Planning, budgeting, investment, performance, risk, control, and management-reporting governance |
This is a valid OMC/TOM at finance-domain level. Its enterprise value comes from the interfaces it exposes.
7. Finance as a vertical and a horizontal slice
Vertically, the finance domain decomposes: finance outcomes → finance value streams → the capabilities they draw on and the processes and decisions that realise them → roles and authority → information and systems → controls and suppliers → measures and improvement. That produces a detailed finance TOM.
Horizontally, finance value streams cross other domains — and it is those crossings that generate enterprise hypotheses:
| Finance flow | Cross-domain interfaces |
|---|---|
| Order-to-cash | Commercial, contracting, delivery, customer service, collections |
| Procure-to-pay | Supply chain, procurement, receiving, quality, suppliers, treasury |
| Product / programme costing | Engineering, manufacturing, programmes, supply chain |
| Planning and forecasting | Strategy, commercial, operations, workforce, investment governance |
| Capital accounting | Portfolio governance, programmes, assets, benefits management |
| Management reporting | Business units, functions, value streams, executive governance |
8. Supply chain as a bottom-up route
In a physical-product enterprise, supply chain is an equally legitimate — often more direct — view of the principal value-delivery flow: sense demand → plan → source → make → deliver → service/return → learn. It crosses customer and aftermarket demand, sales-and-operations planning, sourcing and procurement, supplier collaboration and risk, production and capacity planning, manufacturing and quality, inventory and logistics, delivery and returns, and working capital and resilience.
Its strengths are the physical and informational value flow, demand and capacity and constraints, sites and networks and external dependencies, quality and service and resilience, and working-capital and cost-to-serve drivers. Its limits: it may not fully reveal the customer proposition and channel strategy, product and service innovation decisions, financial and capital-allocation logic, non-supply-chain business models, organisational legitimacy and workforce impacts, enterprise governance beyond operational planning, or digital and aftermarket value propositions outside the physical flow. Supply chain is therefore another powerful domain model and enterprise evidence source — not automatically the complete enterprise OMC/TOM.
9. Finance and supply chain together
The two perspectives are complementary:
| Finance primarily sees | Supply chain primarily sees |
|---|---|
| Economic flow | Physical and operational flow |
| Revenue, cost, and capital | Demand, material, capacity, and service |
| Control and reporting structure | Lived execution and dependencies |
| Legal / management entities | Sites, suppliers, and operational networks |
| Financial outcomes | Operational causes of outcomes |
| Periodic measures | Events and flow behaviour |
Together they trace a single chain: customer demand → operational activity → resource consumption → product/service delivery → financial consequence → management decision. Customer, commercial, engineering, workforce, data, and risk perspectives are still required to complete the enterprise view.
10. Controlled elevation from domain to enterprise
Elevation is a sequence, not a leap:
- Declare the boundary. Make scope, evidence, omissions, current/target state, and decision authority explicit.
- Classify findings as domain-owned (designed and operated within the domain), cross-functional (shared across a boundary), or enterprise-significant (may affect enterprise strategy, business model, OMC, or governance). For example: a finance consolidation process is domain-owned; order-to-cash accountability ambiguity is cross-functional; the inability to see product profitability by segment, or a legal-entity structure that conflicts with value-stream ownership, is enterprise-significant.
- Extract enterprise hypotheses — evidence-linked, about enterprise value streams, business-unit and customer/product boundaries, capability ownership and maturity, shared/federated/local services, information domains and data ownership, decision rights and management routines, platform and supplier dependencies, and constraints and priorities. Do not convert a domain interpretation directly into an enterprise decision.
- Reconcile with strategy and the business model — test the hypotheses against mission and target outcomes, end-customer value propositions and journeys, segments and channels, revenue and cost logic, key activities and resources and partners, and engineering/manufacturing/service/workforce realities.
- Validate interfaces — run focused evidence challenges with the relevant owners. The interfaces to test depend on the enterprise. They typically include commercial and contracting; engineering or product development; operations; supply chain and procurement; quality and assurance; programme and portfolio management; service operations; people and workforce; data, technology, and cyber; and risk, audit, and executive governance. The purpose is not to repeat discovery — it is to confirm interfaces, expose contradictions, and identify missing perspectives.
- Construct and approve the enterprise OMC/TOM — elevate only validated enterprise choices into the customer-to-outcome value-delivery chains, the enterprise capability model, the organisation and decision architecture, the location/footprint model, the information and data model, the supplier/ecosystem model, the enterprise Management System, and the integrated TOM and roadmap. Retain the domain OMCs/TOMs beneath the enterprise model rather than flattening their detail into a single canvas.
11. The federated OMC/TOM architecture
The output of convergence is not one flat canvas — it is a federated architecture, and this is what this paper calls the enterprise operating model:
- At the top: strategy, customer value, and the business model canvas set direction and constraints.
- Below them, the enterprise OMC records the few enterprise-wide choices that integrate and constrain the domain designs — it is deliberately thin.
- Beneath the enterprise OMC sit the domain OMCs — finance, supply chain, engineering, and the rest — each retaining the detail required to operate its part of the model, and each with its own domain TOM.
- Binding them together is the cross-domain layer: the value streams, capabilities, data, decisions, controls, dependencies, and measures that run across the domains.
The discipline is one of restraint at the centre and detail at the edges: the enterprise OMC holds only what must be common; everything else lives in the domain models it federates. That is what makes the model both coherent and operable — a network of connected operating models, not a single unreadable diagram.
12. The five elevation gates
A domain model may inform the enterprise OMC/TOM only when it passes all five:
- Evidence integrity — scope and provenance are explicit; facts, interpretations, hypotheses, and decisions are separated; current, transition, and target states are distinguishable; material contradictions remain visible.
- Strategic reconciliation — enterprise hypotheses trace to strategy, customer value, and the business model; financial or operational optimisation does not undermine the value proposition; target outcomes and economic constraints are coherent.
- Cross-domain validation — affected owners review interfaces and dependencies; lived flow is distinguished from documented process; missing customer, engineering, workforce, supplier, and control perspectives are addressed.
- Enterprise design assurance — POLISM elements align internally; end-to-end flow, capacity, decision rights, and controls are operable; AI/human boundaries, risk, fallback, and supplier dependencies are explicit; the governing constraint is improved rather than displaced.
- Human approval — the appropriate enterprise design authority approves the elevation; dissent, conditions, and switching triggers are recorded; and acceptance of a design is not treated as authorisation to implement.
13. Anti-patterns
Avoid: renaming a finance TOM as the enterprise TOM without validation; treating the chart of accounts or ERP hierarchy as the organisation’s true value architecture; letting reporting availability determine strategic importance; optimising a domain at the expense of end-to-end customer value; flattening domain OMCs into an unreadable enterprise canvas; using AI-generated completeness as evidence of enterprise agreement; inferring customer truth from internal functional data alone; and beginning transformation initiatives before cross-domain dependencies and owners are confirmed.
14. The AI contribution — and its boundary
AI materially accelerates bottom-up discovery: extracting evidence from documents, workshops, and system artefacts; identifying entities, flows, decisions, and controls; mapping cross-domain dependencies; detecting contradictions and missing evidence; generating domain-to-enterprise hypotheses; checking traceability across the business model, OMC, and TOM objects; comparing current and target states; and drafting validation questions and scenarios.
AI must not: manufacture missing stakeholder evidence; treat financial classifications as the definitive operating model; approve elevation from domain to enterprise; decide workforce, supplier, or risk consequences; collapse dissent into apparent consensus; or approve its own model or assurance findings. The elevation gates are human gates by design — AI prepares the evidence; people own the choice.
Bounded decision models and the management layer (added 30 September 2026). A new class of model may sharpen one boundary in this section. This is a hypothesis. TypeSafe’s Jev, launched in early access in a post dated 15 September 2026 and described by its maker as a “System One Model”, returns a constrained decision with a confidence score. It is sold as a decision rule inside ordinary software. If models of this kind work as described, the first management work they reach is likely to be routing, triage and first-pass checks of status and evidence. These are the recurring coordinating decisions inside management work, whoever holds the title. On the same hypothesis, setting objectives, resolving conflicts, developing people and answering for outcomes stay with named people, however good the classifier. The consequence for the TOM is that it should record, for each recurring decision, whether a machine may take it and which named person owns that boundary. The test is to re-run the classification of an operating model’s work with and without such models available, and compare the management-layer result.
15. Where this sits in the O2O method
| O2O position | Bottom-up use |
|---|---|
| Step 1 — Business Context | Domain discovery, lived-flow evidence, current domain OMC/TOM, and enterprise hypotheses |
| Step 2 — Business Goals | Reconcile domain evidence with customer value, business-model options, economics, and target outcomes |
| Step 3 — Business Change | Integrate validated domain designs into the enterprise OMC/TOM and identify capability gaps |
| Portfolio and Execution (steps 10–18) | Sequence cross-domain initiatives by constraint, value, capacity, dependency, and risk |
| Execution: step 18 cells (18.1–18.9) | Implement through domain and cross-domain work while governing transition states |
| Operations (steps 19–27) | Measure outcomes, absorption, benefit, and operating drift; feed evidence back into design |
Transformation Capability Management governs this convergence-and-elevation process through the OMC Management System.
16. The canonical principle
An OMC/TOM may be initiated top-down from strategy and customer value, bottom-up from a domain or value stream, or through both directions. It becomes an enterprise OMC/TOM only when its boundary is explicit, enterprise hypotheses are reconciled with strategy and the business model, cross-domain interfaces are validated, and the appropriate design authority approves the integrated model.
This legitimises finance-led and supply-chain-led discovery without overstating their scope — and it gives every domain team a disciplined route from “what we found” to “what the enterprise should decide.”
Companion papers
- The Five-Layer Activity Model — where enterprise work sits (the diagnostic lens this construction method populates).
- TCM Discipline: The Missing Discipline — the discipline that governs the convergence and elevation described here.
Version index and changelog
- v0.4 (19 October 2026): capability and process kept distinct in the domain decomposition; no argument changed.
- v0.3 (19 October 2026): wording, O2O step names and references aligned with the published method; no argument changed.
- v0.2 (30 September 2026): one paragraph added to Section 14 on bounded decision models and the management layer (TypeSafe’s Jev), stated as a hypothesis. Paragraph by Apollo.
- v0.1 (1 September 2026).
From BusinessGPS source R&D.