A target operating model is the organisation's blueprint for how people, processes, technology, data and governance will work in a chosen future state, not the strategy itself.
If your future organisation chart looks convincing, but nobody can explain how customer work will move through the business during the change, what have you designed? Directors need more than a picture of the destination. They need clear decisions about ownership, service standards, investment and what should stay untouched while the business keeps running.
Table of Contents
- What a Target Operating Model Actually Means
- Why Digital Evidence Makes the Model Matter
- Six Building Blocks Inside Every Target Operating Model
- Benefits and Risks of a New Operating Model
- Target Operating Models in SMEs and Regulated Firms
- How to Reach the Target Without Stopping the Business
- Choose the First Change and Leave the Rest
What a Target Operating Model Actually Means
Say an engineering SME wants to grow without allowing support problems to interrupt production. Its strategy might be to expand into new markets while maintaining dependable delivery. Its target operating model, often shortened to TOM, describes the practical arrangements needed to make that ambition workable.
Think of a building. Strategy explains why you're building it, an organisation chart shows who has a desk, and the operating model explains how people will use the space, receive services, control access and deal with failures.
Separate ambition from operating design
Leaders often combine documents that serve different purposes:
- Strategy: States the ambition, such as serving larger customers or opening additional sites.
- Current operating model: Describes how work happens today, including informal approvals, duplicated records and reliance on particular employees.
- Target operating model: Defines the future arrangements for delivering services, making decisions and managing performance.
The target isn't necessarily a new department structure. Your engineering firm might retain its existing reporting lines while introducing a standard support process, clearer supplier responsibilities and tested recovery arrangements.
The relationships between those choices matter more than the appearance of the diagram.
Start with the service people need
The Office for National Statistics described its TOM through changes to products, processes, systems and people, while its transformation programme sought a 19% real-terms reduction in core funding by 2020, supported by productivity improvements, online collection and greater use of administrative data, according to the UK Statistics Authority's transformation update.
That example connects an operating design to a measurable objective. It doesn't establish that every SME should pursue the same savings or technology choices.
For your business, the equivalent might be dependable production support rather than a funding reduction. Define the service required, then decide what employees should retain, what should become standard, and what a specialist supplier should deliver under agreed service levels.
Practical rule: Describe what customers and staff must be able to do before deciding which boxes belong on the organisation chart.
Where production continuity is central, the operational reliability insights from Forge Reliability provide a useful companion perspective on operation and maintenance. Include maintenance responsibilities and failure response in the design, not just normal working conditions.
Why Digital Evidence Makes the Model Matter
In its Digital and Technology Strategy, the ONS set ambitions to reduce contractor use to below 10% of its digital and technology workforce and place 100% of its strategic data-processing capability and virtual-server infrastructure on secure commodity computing platforms.
Those were organisational ambitions, not universal benchmarks. Their value for an SME director is the specificity: sourcing and infrastructure choices were part of the operating design, rather than purchases made separately by individual teams.
The visual gives a broader view of the workforce targets within that strategy.
Turn a technology choice into a management decision
A North West manufacturer considering cloud hosting needs more than a migration proposal. Its director should know which applications production depends on, who approves access, how employees receive support and who takes charge when connectivity fails.
Moving a server doesn't settle any of those matters. Without explicit responsibilities, the business can acquire modern infrastructure while keeping the same operational confusion.
Use a short decision record to connect the proposal to the service:
- Sourcing boundary: Identify the work employees retain and the specialist work a provider will deliver.
- Service expectation: Define acceptable availability, support response and recovery arrangements.
- Control ownership: Assign responsibility for permissions, security settings and evidence of testing.
- Business evidence: Record the current performance measure before changing the platform.
Measure the work, not the installation
A successful installation is an implementation milestone. It isn't proof that staff can resolve customer requests faster or recover an essential application reliably.
Choose measures that match the intended benefit. Support ticket cycle time can reveal workflow delays; restoration tests can expose recovery weaknesses; cost-to-serve can show whether additional platforms have introduced unnecessary administration.
An SME digital transformation roadmap can help arrange approved changes around dependencies and business priorities. Keep the distinction clear: the roadmap schedules delivery, while the operating model defines the arrangements that delivery must establish.
Technology becomes part of an operating model when managers name the roles, processes, controls and outcomes together. A subscription list alone won't tell a director whether the business can deliver its promises.
Six Building Blocks Inside Every Target Operating Model
A useful model connects the people doing the work with the systems, information and authority they need. The Government Functional Standard for Digital calls for operating models to describe delivery approaches, working practices, people and skills, and the data, technology and AI capabilities required for services.
For an SME, the following building blocks provide a practical way to organise those decisions without creating a large design exercise.
What each building block of a target operating model defines
| Building block | Design question | SME illustration | Proof it works |
|---|---|---|---|
| Processes | How does work flow and where is it repeated? | Standard joiners, support and month-end steps | Cycle time and error rate |
| Organisation | Who owns the work, decides and has the skill? | Named owner for IT, finance and suppliers | One accountable owner per capability |
| Technology | Which platforms are standard and which are excluded? | Microsoft 365, hosted desktops, backup, connectivity | Uptime, adoption and cost to serve |
| Data | Who owns, accesses and retains information? | Customer, finance and people records | Completeness and access exceptions |
| Governance | Which controls, approvals and duties apply? | Change control, Cyber Essentials, audit trail | Control pass rate |
| Performance | Which outcomes show the model is better? | Response, resolution and recovery targets | Service level and recovery time |
Clear ownership comes first because somebody must resolve disagreements and approve improvements. That person doesn't have to perform every task, but they must have enough authority to correct the process.
Standard working practices then reduce dependence on memory. If employees follow the same approved route for a new starter, the business can spot a missing permission or device before it becomes a service problem.
Technology should support that route rather than introduce a competing one. Use a business systems integration guide to examine hand-offs between applications, particularly where staff currently copy information between records.
Apply the blocks to employee access
Consider an SME whose growth depends on bringing new staff into customer-facing work securely. Its operations manager owns the employee-access capability, while line managers approve the access each role needs.
The current-state note might read: managers email different suppliers, equipment arrives separately, and nobody checks the completed access list. The future-state note might read: an approved request triggers a standard checklist, a named coordinator confirms completion, and the line manager verifies access before work begins.
Microsoft 365, identity management and endpoint configuration are dependencies. Governance defines approval and access-review rules; performance reporting records late completion and access exceptions.
Backup and recovery belong alongside this design because employees need more than permission to open files. They also need those files to remain recoverable when something goes wrong.
AI belongs within the technology and data decisions only where a defined use case, capable owner and suitable controls exist. Don't add it as a separate ambition disconnected from the service.
A complete platform inventory can still conceal an incomplete operating model. Check the hand-offs between people, not just the connections between systems.
Benefits and Risks of a New Operating Model
A new operating model can make daily management easier, but only if employees can use it under ordinary working pressure. The strongest benefit statements name a visible change in behaviour, not an abstract improvement in alignment.
Clearer ownership should mean fewer decisions passed between departments. Standard processes should allow colleagues to cover absences without reconstructing somebody else's personal method.
The comparison below captures the balance between better coordination and poorly managed change.
Pair each promise with its failure mode
| Promised gain | How it can fail | Management response |
|---|---|---|
| Faster decisions | The named owner lacks authority | Document approval boundaries and escalation |
| Consistent service | Staff bypass an impractical procedure | Test it with the people doing the work |
| Less duplicated spending | Old subscriptions remain active | Assign responsibility for retirement |
| More dependable recovery | Nobody practises restoration | Require recovery evidence before accepting delivery |
| Better investment discipline | The target is too distant to approve | Fund a bounded improvement first |
Over-standardisation can also remove useful flexibility. A production incident and a routine laptop request shouldn't follow identical approval routes merely because they both involve IT.
Likewise, a design copied from a large enterprise may assume specialist roles your business can't staff. An impressive governance diagram won't help if the same busy manager has been assigned every approval.
Use a minimum viable operating model
A minimum viable operating model is the smallest workable arrangement of roles, processes, controls and platforms that improves a selected outcome with the people and budget available. It's a controlled starting point, not permission to omit essential safeguards.
For example, a business might establish a dependable support intake and escalation process before replacing its wider application estate. That gives employees a usable service without making every improvement conditional on a major migration.
Watch for warning signs:
- No current-state description: The designers haven't established which workarounds employees rely on.
- No performance measure: Management can't distinguish improvement from disruption.
- No stop decision: The new process adds work without removing the old burden.
Keep a claimed benefit only when an owner accepts it and a numerical measure can test it.
Target Operating Models in SMEs and Regulated Firms
An engineering firm and a legal practice may use similar software while needing different operating arrangements. The manufacturer must protect production continuity; the legal practice must manage confidential matter access and professional judgement.
Start with the consequence of failure. That determines which capabilities deserve the strongest controls and which decisions the business should retain.
How a target operating model changes by organisation type
| Organisation type | Main pressure | Capabilities to design | Often provided externally |
|---|---|---|---|
| Engineering or manufacturing SME | Downtime and site resilience | Backup, disaster recovery, connectivity, production access | Managed infrastructure and recovery |
| Legal practice | Confidentiality and remote working | Identity, Microsoft 365, secure file access | Managed security and support |
| Financial firm | Regulatory evidence and data protection | Logging, backup, access control, awareness training | Managed detection and certification support |
| Growing multi-site business | Uneven local IT | Hosted desktops, standard support, voice and mobiles | Fully managed support against service levels |
For manufacturing, distinguish office infrastructure from systems that production equipment depends on. A change to remote access or connectivity may need coordination with equipment suppliers and a maintenance window, even if the office team considers it routine.
Reliable production depends on both infrastructure and people who understand its operation.
Retain judgement while buying specialist delivery
A legal practice can outsource security monitoring without outsourcing decisions about client confidentiality or appropriate matter access. Its partners still need to define who may authorise exceptions and how those decisions are recorded.
A financial firm needs usable evidence, not just installed controls. Define who reviews logs, who acts on alerts, how Microsoft 365 data is backed up and how staff demonstrate that they understand security procedures.
Cyber Essentials or Cyber Essentials Plus support may form part of that arrangement, but certification support isn't a substitute for identifying the firm's specific regulatory duties. A policy development approach helps turn those responsibilities into instructions employees and suppliers can follow.
For a multi-site business, consistency matters at the service boundary. Staff should know how to request help, report a telephone fault or obtain an approved device regardless of location, while legitimate site differences remain documented.
Keep the planning documents in their proper roles
The target operating model determines which capabilities the business needs and where accountability sits. The IT strategy and roadmap sequence the supporting platforms; managed services deliver capabilities the business chooses not to operate itself.
That external scope might include helpdesk, cloud hosting, backup, security operations or connectivity. Business leaders still retain decisions about priorities, acceptable risk and expenditure.
Where AI is being considered across departments, SourceX's AI planning for mid-market businesses offers a planning resource to consider alongside those boundaries. Apply it to an approved business use case rather than treating AI adoption as a sector requirement.
How to Reach the Target Without Stopping the Business
Defining a future arrangement is easier than changing live work. The SME Digital Adoption Taskforce's final report identified high switching and adoption costs, fragmented support, and limited confidence or expertise among smaller firms.
The answer isn't to postpone every improvement. It's to make each stage small enough to supervise and concrete enough to test.
The transition should protect ongoing operations while gradually replacing the arrangements that no longer serve the business.
Give each stage an acceptance test
Map current work around a priority capability. Follow a real request from start to finish, including spreadsheets, supplier calls and manual checks. Record the legacy system that must remain available so the change team doesn't accidentally remove a dependency.
Define the target and its minimum viable version. Separate the eventual service from what current staff can operate safely. For employee onboarding, that might mean an approved checklist before introducing automated provisioning.
Assign the owner and protect the boundaries. Name who can approve the change, identify information that must move or coexist, and document what won't change during this phase. Include a rollback route and responsibility for reconciling records.
Agree measurable acceptance before spending. Give the milestone a numerical threshold based on business need, such as a recovery-time objective or maximum cycle time. Obtain approval from the service owner and affected stakeholders rather than leaving acceptance to the installer.
Pilot with live teams before retiring the old route. Where safe, compare results against the existing process; where parallel operation would create conflicting records, use a controlled cutover and reconciliation. Remove the old step only after the owner accepts the evidence.
Release the next change based on the result. Use unresolved issues to adjust the next stage. Don't launch unrelated cloud, communications and automation projects just because their purchase orders are ready.
Respect the dependencies
Establish Microsoft 365 identity and access arrangements before broad automation. Verify backup and restoration before moving an important workload, and establish workable support service levels before extending the same arrangement to more sites.
A cloud migration planning guide can help translate those dependencies into preparation, migration and validation tasks. Include user training and support capacity in the schedule, not just technical installation work.
Use the following video as a discussion prompt for the team responsible for implementation.
Acceptance test: A stage isn't complete because the platform is live. It's complete when the responsible manager can demonstrate that the agreed service works.
Keep the evidence with the change record. Failed tests should lead to corrective work or a pause, not a revised definition of success.
Choose the First Change and Leave the Rest
When directors ask, “What is the target operating model?”, the useful answer should eventually become a decision about live work. A proposed target is better only if it improves a named outcome without introducing unacceptable cyber, regulatory or integration risk.
Before discussing suppliers, apply these exclusion rules:
- Reject ownerless tools: Somebody must accept responsibility for configuration, support, cost and retirement.
- Reject incompatible additions: A proposed tool must work with the system that needs to remain operational, or have an approved replacement route.
- Reject undefined controls: Don't proceed without clear access, recovery and incident-handling arrangements.
Make exclusion a positive decision
The Enterprise Research Centre evidence described in the government's review of barriers and enablers to advanced technology adoption indicates that combining technologies doesn't routinely improve productivity, with some combinations reducing returns, apparently because of integration complexity and inefficient internal processes.
More technology therefore needs a business case, not an assumption of progress. Leaving an application out can protect staff capacity and reduce the number of dependencies the business must support.
Your first workshop should produce a selected capability, a brief current-state and future-state description, a deliverable minimum version, an outcome measure and a written exclusion list. Record why each excluded proposal is unsuitable now and what evidence would justify reconsidering it.
If internal capacity is limited, a managed provider can deliver the approved capability. The business should retain its strategy, risk decisions and exclusion list.
This month, choose the operational problem that causes the clearest harm, appoint its owner and authorise only the change needed to test an improvement. Leave unrelated purchases unapproved until there's a reason to include them.
Blowfish Technology offers managed IT support, Microsoft 365, cloud services, backup and disaster recovery, cybersecurity, and connectivity for SMEs and regulated firms. Visit Blowfish Technology to discuss which capability to improve first, what should remain in place and how to measure a safe transition.
