Building a Target Operating Model
A Target Operating Model — usually shortened to ToM — is one of those Business Analysis concepts that can sound considerably more mysterious than it really is. The term appears regularly in transformation programmes, consulting assignments and professional training, but explanations often jump very quickly from the idea of a "future state" to diagrams containing capabilities, processes, people, technology and data. The result is that somebody encountering a ToM for the first time may understand roughly what one contains without understanding what it is actually for.
At its simplest, a Target Operating Model describes how an organisation, or part of an organisation, needs to operate in the future in order to achieve its objectives. It takes strategic intent — what the organisation wants to become or achieve — and begins turning it into an operating reality.
That makes a ToM particularly important during significant organisational change. A strategy might say that an organisation intends to become more customer-centred, reduce costs, standardise services, exploit digital technology or make better use of its data. Those are useful directions, but they do not yet tell us how the organisation will actually work differently. Somebody eventually has to answer questions about processes, responsibilities, technology, information, governance and the experience of the people who use the service.
A Target Operating Model is the bridge between strategic intent and an organisation that can actually operate differently.
Start With the Problem, Not the Model
The worst place to begin a Target Operating Model is with a ToM template. Before drawing boxes, defining capabilities or debating which headings should appear in the document, establish why change is necessary. What is wrong with the current operating model? What must improve? What does the organisation expect to be different in two or three years' time?
Imagine a university experiencing a fragmented student journey. Different faculties have developed their own administrative processes, several legacy systems contain overlapping student information, services are duplicated and students encounter different ways of working depending upon which part of the university they are dealing with. At the same time, costs are rising and expectations of digital service are increasing.
That gives us a reason to develop a Target Operating Model. We are not producing one because transformation programmes are supposed to have ToMs. We are trying to describe an organisation capable of addressing identifiable problems and achieving identifiable outcomes.
If you cannot state clearly what needs to change and why, you are not ready to design the Target Operating Model.
Do Not Jump Straight Into Detail
Once the need for change is understood, there is a powerful temptation to begin modelling the future in detail. People start discussing systems, drawing organisation charts, redesigning processes and allocating responsibilities. Those conversations feel productive because tangible decisions are being made.
They may also be premature. Before deciding precisely how the future organisation will work, its overall direction needs to be understood and agreed. This is why it is useful to distinguish between two levels of Target Operating Model: a Business-level ToM and a Delivery-level ToM.
They are not competing definitions of a Target Operating Model, nor are they necessarily two completely separate documents. They represent different levels of thinking. The Business-level ToM describes the future organisation sufficiently clearly for senior stakeholders to understand and agree the direction. The Delivery-level ToM takes that agreed direction and develops it into something sufficiently detailed to implement.
First agree what the future organisation should look like. Only then work out exactly how to build it.
The Business-Level Target Operating Model
The Business-level ToM is strategic. Its audience is likely to include senior executives, business leaders and the people responsible for major organisational domains. They need clarity about direction, outcomes and the important choices being made. They do not need a detailed catalogue of processes, interfaces and system components.
A useful Business-level ToM normally explains the strategic context for the change, the future operating concept, the principles that will guide design decisions, the major business domains involved, the principal changes from the current state, the expected benefits and the broad transition required to get there.
For our university, that might mean explaining how the future student lifecycle will work across recruitment, admission, enrolment, teaching, assessment and graduation; whether services will be centralised or remain within faculties; the intended digital and data direction; and how governance will balance institutional consistency with legitimate academic autonomy.
At this stage, the objective is not to answer every implementation question. It is to make the future sufficiently clear that senior stakeholders can understand what they are being asked to support.
Start With the Value Streams
A useful way to structure the Business-level ToM is around the organisation's principal value streams: the end-to-end sequences through which something valuable is created for a customer, user or stakeholder.
In a university, for example, one major value stream might follow the student lifecycle:
Recruit → Admit → Enrol → Teach → Assess → Graduate
Others might describe the research lifecycle or the university's engagement with external partners. Starting with these end-to-end flows helps prevent the ToM from simply reproducing the organisation chart. A student does not experience the university as a collection of departments; they experience a journey that crosses departmental boundaries.
That distinction matters in many organisations. Customers, patients, citizens, suppliers and employees experience services end to end even when the organisation responsible for delivering them is divided into specialist functions.
Establish the Design Principles
The Business-level ToM should also establish a small number of design principles. These are not decorative statements about being innovative or customer-focused. They are rules that help resolve later design decisions.
Our university might decide, for example, that administrative processes should be standardised across faculties wherever there is no genuine reason for difference; that student interactions should be digital-first; that data should be entered once and reused wherever possible; and that academic autonomy should be preserved where it creates genuine academic value.
Those principles become useful precisely when stakeholders disagree. A faculty may later request its own version of an administrative process. The question is no longer simply whether somebody wants it. The proposal can be tested against the agreed principle: is there a genuine reason why this process needs to differ?
Good design principles settle arguments later. If everything remains negotiable, they are not design principles.
Describe the Future at the Right Level
The Business-level ToM now needs to describe the future across the major areas that determine how the organisation operates. The precise headings will vary, but they commonly include organisation, processes or value streams, technology, data, channels and experience, and governance.
For organisation, the important question may be which services should be central and which should remain devolved. For technology, it may be whether the organisation is moving towards a smaller number of strategic platforms rather than a fragmented collection of local systems. For data, it may be whether important information will have an agreed institutional owner and authoritative source. For experience, it may concern how consistent the service should feel across digital and physical channels.
The discipline at this stage is knowing when to stop. The Business-level ToM should answer the significant questions about the future without drifting into implementation detail. If the discussion has reached individual APIs, detailed process steps or field-level data definitions, it has probably moved into the delivery model too soon.
The One-Page Test
One of the most useful tests of a Business-level ToM is whether its essential idea can be shown on a single page. That does not mean the entire ToM consists of one page. Supporting explanation will almost certainly be required. But there should be a view that allows somebody to grasp the shape of the future organisation without reading twenty pages first.
The one-page view might show the principal value streams, the organisational model, the digital backbone, the major data concepts, the channels through which services are delivered and the governance that holds the whole arrangement together.
Producing that view is difficult, and that is precisely why it is valuable. If the team cannot explain the proposed operating model clearly enough to represent it simply, there is a reasonable chance that the model itself is not yet sufficiently understood.
If you cannot explain the essence of the Target Operating Model on one page, you probably do not understand it well enough yet.
Make the Change Explicit: From → To
A Target Operating Model becomes much easier to understand when it makes the difference between the current and future states explicit. Simple From → To statements can be remarkably effective.
For example:
-
From: faculty-specific admissions processes
To: a standard institutional admissions service -
From: multiple overlapping student records
To: a single authoritative institutional student record -
From: fragmented local systems
To: an integrated digital ecosystem -
From: data repeatedly entered by different departments
To: data captured once and reused appropriately
These statements force precision. Phrases such as "digital transformation" or "improved student experience" are easy to agree with because they can mean almost anything. A From → To statement exposes the actual change being proposed and therefore gives stakeholders something meaningful to support, challenge or refine.
Validate Before You Elaborate
Before developing the detailed Delivery-level ToM, the Business-level model needs to be tested with the people whose support will be necessary. In our university example that would include senior leadership, academic representatives and the leaders of professional services.
The purpose is not to ask whether every detail is perfect. At this point there should not be that much detail. Instead, ask whether stakeholders understand the proposed model, whether they agree with its broad direction and whether the areas for which they are responsible can see how they fit into it.
Disagreement at this stage is useful. If senior stakeholders fundamentally disagree about whether services should be centralised, whether data should be institutionally governed or whether processes should be standardised, discovering that before detailed design begins is far cheaper than discovering it during implementation.
Do not use detailed design to conceal a strategic disagreement. Resolve the disagreement before investing in the detail.
Now Build the Delivery-Level ToM
Once the broad future model has been understood and accepted, the emphasis changes. The Delivery-level ToM translates strategic intent into something buildable, testable and traceable. This is where the broad statements made in the Business-level ToM are decomposed into the processes, responsibilities, systems, data, rules, controls and work packages needed to make the future state real.
This is also where Business Analysis becomes particularly important. The Business-level model may say that the organisation will provide a standard end-to-end enrolment service. The Delivery-level model must investigate what enrolment actually involves, who performs the work, what information is required, which systems support it, which policies constrain it, where the present problems lie and what must change.
The two levels should therefore remain connected. The Delivery ToM is not an opportunity to start designing a different future. Its job is to work out how the agreed future can operate.
Compare Current and Target States
The Delivery-level ToM should make the gap between current and target operation visible. For each important domain, describe how things work today, how they need to work in the future and what must change to move between the two.
This is where uncomfortable realities emerge. A proposed standard process may conflict with an existing policy. A target system architecture may depend upon technology that is not yet available. A new end-to-end service may require accountability that does not exist in the current organisation. Data that the future model assumes can be shared may have unclear ownership or serious quality problems.
Those discoveries do not mean the ToM has failed. Finding them is one of the reasons for building it.
The gap between current and target states is not an inconvenience. It is where much of the real transformation work is found.
Decompose the Value Streams
The high-level value streams identified earlier can now be decomposed into operational components. Take enrolment, for example. What triggers it? What information enters the process? Which activities occur? Who performs them? Which systems are used? What outputs are produced? Where are the delays, duplications and errors?
The objective is not to create process models for their own sake. The level of detail should be sufficient to support design, requirements, implementation and training. A process may therefore need an owner, trigger, outcome, key activities and performance measures without requiring an enormous modelling exercise describing every possible exception.
This is an important discipline throughout a ToM: model to the level necessary to make the next decision. More detail is not automatically more useful.
Define the Organisation and Accountability
The Delivery-level ToM must also explain who will operate the future model. That includes teams, responsibilities, reporting relationships and, crucially, ownership.
Questions such as "Who owns enrolment end to end?", "Who is accountable for student data quality?" and "Who has authority to change this process?" can expose problems that an organisation chart alone will never reveal.
The distinction between a job title and an accountability is important. Several departments may participate in a process, but somebody still needs sufficient ownership to ensure that the end-to-end service works. Without that clarity, the new operating model can inherit exactly the same fragmentation that the transformation was intended to remove.
Define the Technology Landscape
At Business level, the technology direction may have been expressed in broad terms: consolidate platforms, improve integration or replace legacy systems. The Delivery ToM must now make the implications explicit.
Which systems remain? Which will be replaced? What new systems are required? Where will integration be necessary? Which capabilities are provided by which platforms? Are there significant buy-versus-build decisions? Where does middleware or an integration platform fit?
These decisions need to remain connected to the business model. Technology should enable the target operation rather than quietly becoming the Target Operating Model itself. A diagram of future systems is an architecture view; it is not, on its own, a ToM.
Do Not Treat Data as an Afterthought
Data is one of the easiest areas to describe vaguely at Business level and one of the most expensive areas to leave vague during delivery. A statement such as "single source of truth" sounds attractive, but implementation requires much harder questions.
What exactly constitutes the student record? Where is each important item of data created? Which system is authoritative for it? Who owns its meaning and quality? How does it move between systems? What happens when two systems disagree? Which users are permitted to change it?
These questions lead naturally into conceptual data modelling, data governance and data flows. They also expose dependencies between process and technology that may otherwise remain hidden until implementation.
"Single source of truth" is an ambition, not a data design. The Delivery ToM has to establish what that statement actually means.
Business Rules Are Part of the Operating Model
A process tells us how work flows, but it does not necessarily tell us the rules governing the decisions made within it. In the university example, admissions criteria, enrolment eligibility, assessment regulations and progression rules may all determine what the organisation is permitted or required to do.
Those rules matter because the future systems and processes will need to implement them. If they remain buried in policy documents or in the heads of experienced staff, the Delivery ToM may describe a process that cannot actually be configured or operated correctly.
This is another area in which the BA can connect apparently separate concerns: policy, business rules, processes, data and system requirements are different views of the same future operation.
Controls, Compliance and Governance
The target organisation must also operate within its regulatory, legal and governance environment. Relevant controls may concern data protection, financial authority, audit, regulatory obligations, approvals or segregation of duties.
These should not be added after the operating model has been designed. If an approval is legally or operationally necessary, it affects the process. If particular data requires special protection, that affects systems, access and responsibilities. If a regulator requires evidence of a decision, that affects what the organisation records and retains.
Governance therefore belongs inside the operating model rather than around its edges.
Look at the Experience End to End
The Delivery ToM should return to the people who experience the organisation's services. For our university this could mean the student journey, the academic staff journey and the experience of professional-services staff.
Mapping those journeys helps expose what organisational decomposition can hide. A student may move from recruitment to admissions to enrolment without caring that three different departments and four systems are involved. If they are repeatedly asked for the same information, encounter inconsistent terminology or have to understand the university's internal structure simply to obtain help, the operating model is making its own complexity the customer's problem.
A successful target model should therefore be tested not only from the perspective of organisational efficiency, but also from the perspective of the people who must live with it.
A Target Model Still Needs a Route From Here to There
A beautifully described future state has limited value if there is no credible route from the present organisation to the target. The Delivery ToM therefore needs to inform transition design.
That means identifying work packages, dependencies, sequencing, milestones and releases. Data migration may have to precede the retirement of a legacy system. Governance may need to be established before process ownership can operate effectively. A new platform may need to be implemented before several local applications can be removed.
The roadmap should expose those relationships. Simply labelling work as Phase 1, Phase 2 and Phase 3 does not explain why that sequence is necessary.
Traceability Keeps the Transformation Honest
One of the most important features of a Delivery-level ToM is also one of the easiest to lose as a programme becomes larger: traceability. The programme should be able to connect what it is delivering back through the operating model to the reason the transformation exists.
Strategy → Target Operating Model → Capability → Process → System → Delivery Item
Suppose a programme proposes replacing a particular system. Why? Which capability of the Target Operating Model requires that change? Which process depends upon the capability? Which strategic objective does it ultimately support? If those connections cannot be explained, the programme may be delivering activity that has become detached from its original purpose.
Traceability also works in the other direction. When a strategic objective changes, the organisation can identify which capabilities, processes, systems and delivery items may need to be reconsidered.
Strategy → ToM → Capability → Process → System → Delivery. Without the connections, a long transformation programme can gradually drift away from the reason it began.
What a Target Operating Model Is Not
Because ToMs bring together many different views of an organisation, they are easily confused with the artefacts used to describe those views. A ToM is not an organisation chart, although organisational structure may form part of it. It is not a process model, although processes are important. It is not an application architecture, a data model, a customer journey or a transformation roadmap, although all of those may contribute to its definition.
Nor is a ToM simply a large document containing one example of each. The value comes from the relationships between them. The organisation structure needs to support the processes; the technology needs to enable them; the data needs to flow through them; the rules and controls need to govern them; and the whole arrangement needs to support the strategic outcomes that justified the transformation.
A collection of future-state diagrams is not automatically a Target Operating Model. The model lies in the coherent operating system they describe together.
Common Mistakes
A common mistake is to begin with detail before the strategic model has been agreed. Process maps and technology decisions then create an illusion of progress while senior stakeholders may still have fundamentally different ideas about the organisation they are trying to create.
Another is to confuse the ToM with technology architecture. Major transformations often involve substantial system change, so technology naturally occupies a great deal of attention. But implementing a new platform without changing processes, responsibilities, data ownership or governance may simply automate the existing operating model.
A third mistake is excessive detail. A Business-level ToM that grows into hundreds of pages has probably ceased to perform its primary communication function. Conversely, a Delivery-level ToM that remains at the level of slogans such as "digital first" and "customer centred" does not provide enough substance to support implementation.
Other common problems include ignoring data until late in the programme, leaving end-to-end accountability unclear, treating governance as an afterthought and failing to maintain traceability between strategy and delivery.
Where Does the Business Analyst Fit?
Target Operating Model work sits naturally within Business Analysis because it requires the BA to move repeatedly between different levels of abstraction. At one moment the discussion may concern strategic objectives and business outcomes; at another it may concern a process, business rule, data concept or requirement.
The BA can help discover the problems with the current model, identify stakeholders, analyse value streams, facilitate agreement on design principles, model current and target states, expose gaps and dependencies, define processes and information needs, and maintain traceability as the model moves towards implementation.
Perhaps most importantly, the BA can keep asking whether the detail still supports the intent. A perfectly designed process is of little value if it belongs to the wrong future. A technically elegant system is not useful merely because it is modern. A new organisational structure does not constitute transformation if responsibilities remain confused.
The BA therefore helps maintain the line of sight between why the organisation is changing and what people eventually build and operate.
A Practical Sequence for Building a ToM
Although every organisation and transformation will differ, the overall sequence can be kept surprisingly straightforward:
- Establish the problem and desired outcomes. Understand why the existing operating model needs to change.
- Identify the major value streams. Understand how value flows through the organisation end to end.
- Agree the design principles. Establish the rules that will guide future design decisions.
- Describe the future at Business level. Cover organisation, value streams, technology, data, experience and governance without disappearing into implementation detail.
- Create the one-page view. Make the essence of the future operating model understandable.
- Express the important From → To changes. Make the transformation explicit.
- Validate the direction with stakeholders. Resolve strategic disagreement before detailed design.
- Develop the Delivery-level ToM. Define processes, responsibilities, systems, data, rules, controls and journeys to a usable level.
- Analyse the gaps and dependencies. Establish what must change and what constrains the transition.
- Build the transition roadmap. Turn the gaps into sequenced, deliverable change.
- Maintain traceability. Keep every significant delivery decision connected to the operating model and ultimately to strategy.
The sequence matters because each level provides the context for the next. Strategy informs the Business ToM. The Business ToM provides direction for the Delivery ToM. The Delivery ToM identifies the changes that the roadmap must deliver. Requirements and implementation then have a clear reason for existing.
What Should the Business Analyst Take Away?
A Target Operating Model does not need to be mysterious. It is a structured description of how an organisation needs to operate in the future in order to achieve its objectives. The difficulty comes not from the definition, but from maintaining coherence as broad strategic intentions are translated into increasingly detailed organisational decisions.
The distinction between Business and Delivery levels helps enormously. At Business level, the task is to make the future understandable: value streams, design principles, major operating choices, intended outcomes and the significant changes from today. At Delivery level, the task is to make that future implementable: processes, responsibilities, technology, data, business rules, controls, journeys, dependencies and transition.
Most importantly, the two must remain connected. The purpose of the Delivery ToM is not to create detail for its own sake. It is to preserve the strategic intent while making that intent real.
When reviewing a Target Operating Model, do not simply ask whether all the expected diagrams and sections are present.
Ask:
Can we see a clear line from why the organisation needs to change, through how it intends to operate differently, to what we will actually have to deliver?