Prepare your organisation for Enterprise AI with Versatile Consulting
Target Operating Model Design
We work with C-suite leaders at multinationals navigating Enterprise AI Operating Model Transformation. Whether you’re scaling AI enterprise-wide, integrating an acquisition, or coordinating operations across countries, we redesign how your organization works so transformation moves from ambition to execution.
What is a target operating model?
A target operating model is a definition of how an organization needs to work in order to deliver its strategy. It describes the future-state design of capabilities, processes, structure, governance, people, technology and performance measures — and how those elements fit together. The word target matters: it is a description of the intended future state, not of how the organization operates today.
A target operating model sits between strategy and execution. Strategy states what an organization intends to achieve and where it intends to compete. A target operating model states what the organization must become in order to make that achievable: which capabilities have to exist, who decides what, how work flows across functions, and what has to be measured. Without it, strategy stays a statement of intent and change programmes optimize parts of an organization that were never designed to work together.
What a target operating model is not
- Not an organization chart. An organization chart shows reporting lines. A target operating model shows how work, decisions and capabilities are distributed — structure is one component of it, not the whole.
- Not a strategy. A strategy chooses the destination. A target operating model designs the vehicle. Organizations that skip this step tend to restructure repeatedly without ever changing how decisions get made.
- Not a process map. Process maps describe how a specific activity is carried out today. A target operating model describes the future-state logic those processes have to serve, and usually invalidates some of them.
The components of an operating model
An operating model is not a single artefact but a set of interdependent components. Designing one means making an explicit choice in each of them and checking that those choices are consistent with each other — most operating model failures are consistency failures, not component failures.
Capabilities
Capabilities are what the organization must be able to do, expressed independently of who currently does it. A capability map is the backbone of the model because it is the only component that stays stable while structure, technology and processes change around it. Design starts here: which capabilities are differentiating, which are necessary but not differentiating, and which the organization does not need to own at all.
Structure
Structure allocates capabilities to organizational units and defines how they group, report and coordinate. The design questions are which axis leads — function, geography, customer segment, product — and how the axes that do not lead are represented. Structure is decided after capabilities, never before.
Governance and decision rights
Governance defines who decides what, with which inputs, at what speed, and who is accountable for the outcome. It is the component that most reliably determines whether a new model behaves differently from the old one, and the one most often left implicit. Explicit decision rights are what stop a redesign from becoming a relabelling exercise.
Processes and ways of working
This component defines how work actually flows across the structure: the end-to-end value streams, where handovers occur, and which rituals and cadences hold cross-functional work together. It is designed at the level of the value stream, not the individual procedure — procedure-level detail belongs to implementation.
People, roles and skills
Every capability implies roles, and every role implies skills the organization either has, can build or must acquire. This component covers role design, spans and layers, and the skills gap the target state creates. It also surfaces the leadership capacity the new model requires, which is frequently the binding constraint and a separate body of work: see leadership development and succession planning.
Technology and data
Technology and data are treated as an enabler of the designed model, not as its starting point. The design questions are which capabilities require which systems, where data must be authoritative and who owns it, and what the architecture has to support for the target state to be operable. Where AI changes the work itself rather than accelerating it, the design problem is different in kind: see AI operating model design.
Performance management and measures
Measures determine what the organization optimizes for, and they routinely undo good design. If the model asks functions to collaborate end to end while the measures reward functional output, the measures win. This component defines the metrics, the review cadence and the accountability that make the model self-correcting.
Target operating model vs. strategy vs. current operating model
These three are routinely used interchangeably, and the confusion is expensive: it produces strategies nobody can execute and reorganizations that change the boxes without changing the work.
| Strategy | Current operating model | Target operating model | |
|---|---|---|---|
| Question it answers | Where do we compete and what do we intend to achieve? | How does the organization actually work today? | How must the organization work to deliver the strategy? |
| Time horizon | Three to five years | Present state | Defined future state, with a transition path |
| Output | Choices about markets, customers and value proposition | An evidence-based description of capabilities, decisions and constraints as they are | A designed model of capabilities, structure, governance, processes, people, technology and measures |
| Owner | Executive team and board | The organization as it has evolved, rarely owned by anyone | Executive sponsor, with cross-functional design authority |
| Common failure | Ambition with no delivery logic | Never made explicit, so it is never challenged | Designed on paper and never implemented |
The current operating model is the diagnosis. The strategy is the intent. The target operating model is the design that connects them.
Functional target operating models
The same design logic applies at functional level, where the target operating model defines how a single function organizes itself to serve the rest of the business.
IT target operating model
An IT target operating model defines how technology capability is organized, governed and delivered against business demand. The recurring design questions are the split between build and run, how demand is prioritized across the business, which capabilities are retained versus sourced, and how product-oriented teams coexist with the platforms and services they depend on.
Finance target operating model
A finance target operating model defines how the function delivers control, reporting and decision support. The design centres on what sits in shared services versus business partnering versus centres of expertise, how close-and-report cycles are structured, and where finance capability needs to be embedded in the business rather than consulted by it.
Data target operating model
A data target operating model defines ownership, stewardship and delivery of data as an organizational asset. It resolves who owns which data domain, how quality is enforced, whether analytics capability is centralized, federated or embedded, and what governance is required for data to be usable in automated and AI-supported decisions.
Procurement target operating model
A procurement target operating model defines how sourcing, supplier management and buying are organized across categories and geographies. The design questions are the balance between central category strategy and local execution, which spend is managed and which is channelled, and how supplier relationships are owned beyond the contract.
Cyber security target operating model
A cyber security target operating model defines how security capability is organized relative to IT and the business. It sets accountability for risk decisions, where security is embedded into delivery rather than applied as a gate, and how detection and response capability is staffed, sourced and governed.
Technology services and ITSM target operating model
A service management target operating model defines how services are defined, owned and supported end to end. The design work is usually less about process frameworks than about service ownership: who is accountable for a service across its lifecycle, and how that accountability survives the boundary between internal teams and suppliers.
How we design a target operating model
Design is a structured sequence, not a workshop. Each phase produces an artefact that the next phase depends on, and each one is validated with the people who will have to operate the model.
1. Strategic intent and design principles
We start from the strategy and translate it into a short set of design principles — the explicit criteria every subsequent design decision must satisfy. Without them, design choices get made on precedent and personal preference, and there is no basis on which to reject an option later.
2. Current-state assessment
We make the existing operating model explicit: how work actually flows, where decisions are really made, which capabilities exist and where they duplicate. Organizations rarely have this written down, and the gap between the documented model and the operated one is usually where the diagnosis lives.
3. Capability model and design options
We build the capability map for the target state and develop viable design options against the design principles, with the trade-offs of each made explicit. Presenting a single option is a common failure: it removes the executive team’s ability to own the choice.
4. Detailed design
The chosen option is developed across all components — structure, governance and decision rights, ways of working, roles and skills, technology and data, measures — and tested for internal consistency. We use KNOM, our adaptive operating model framework to design models that stay coherent as conditions change rather than being optimized for a single set of assumptions.
5. Transition roadmap
The design is sequenced into a transition path: what changes first, what depends on what, and what has to be stood up before anything can be switched off. The roadmap is where our work on the model ends and delivery begins — see change management.
Organization design and organizational effectiveness
Organization design and organizational effectiveness are frequently sold as separate services. In practice they are two views of the same object, and we treat both inside operating model work.
Organization design is the structural component of the operating model: how capabilities are grouped into units, how those units coordinate, and how spans and layers are set. Designed on its own, it produces a chart. Designed as part of an operating model, it inherits its logic from the capability map and the decision rights, which is what makes it defensible when it is challenged.
Organizational effectiveness is the measurement side: whether the model as operated actually produces the intended outcomes — speed of decision, quality of cross-functional delivery, cost of coordination, capacity to absorb change. It is the feedback loop that tells you whether the design worked, and it is why we build measurement into the model rather than assessing it afterwards.
Workforce strategy
A target operating model defines the work; workforce strategy defines who will do it. It translates the target model into the shape of the workforce required — the roles, the volumes, the skills, the sourcing mix between employees, contingent workers and partners, and increasingly the split between work performed by people and work performed by systems.
The reason it belongs inside operating model design rather than beside it is sequencing. Workforce plans built from headcount trends extrapolate the current model. Workforce plans built from a target operating model start from the capabilities the organization has decided it needs, which is the only version that survives contact with a changing strategy.
Some of our TOM projects
Rebuilding the operating core across 63 countries
Industry: Agrochemicals · Size: €24B revenue · Impact: ~5,000 people · Footprint: 63 countries
The challenge. Market and business change had outgrown the company’s operating core. Global teams — Basis, Security, Data & Analytics — and regional teams were planning and delivering out of sync across dozens of countries, with coordination effort growing faster than output.
What we did. We designed a new coordination model and the operating model behind it, along with the scaling strategy to take it from a five-country pilot to the full footprint. The work included a new design for shared services and the internationalization of talent, so global and regional teams could synchronize planning and delivery rather than duplicate it.
The results. A 25% reduction in coordination effort during the pilot alone. Around 15% lower cost of technology tools. Approximately €150,000 per month in OPEX savings from a single process — with about 30 processes still to be redesigned. The initiative is being extended to all 63 countries.
Team: 2 external + 3 internal.
From six-month to one-week data cycles
Industry: Banking · Size: Largest bank in Austria · Impact: 250 people across Europe
The challenge. The data and analytics area was slow to deliver. The team was spread across Europe and split between the business and IT arms of the bank, which meant every new data requirement crossed an organizational boundary before it could be built.
What we did. We changed the operating model behind that collaboration — structure and processes — removing the silos and bringing both teams into a single area. During the work we identified the need for a new analytical platform, which was designed and taken to first release in under three months.
The results. Cycles to create new data fields dropped from six months to one week. Releases of new offers for specific customer segments became about 68% faster, with faster iterations on analysis and data gathering across the board.
Team: 10 external + approx. 40 internal.
HR shared services after an acquisition
Industry: IT consulting · Size: 30,000 employees · Impact: 500 people
The challenge. After acquiring a Spanish consultancy, the company wanted to integrate the acquired HR practices into its shared services. The integration surfaced a deeper problem: staff and processes had been structured incorrectly for local markets, creating friction in delivery and risk in local legal compliance.
What we did. We redesigned the operating model of HR shared services, introducing corporate, regional and country layers, and reshaped the roles within it — particularly the business partner role. Processes were optimized and rebuilt around better information flows and explicit decision-making models, and we created a portfolio process for investment decisions on new HR projects.
The results. The redesigned operating model was implemented, wait times dropped sharply, decisions on new HR investments moved faster, and employee experience improved across the shared services function.
Team: 3 external + 10 internal.
Realigning network provisioning
Industry: Telecom (network provisioning) · Impact: 650 people (75 office, rest field)
The challenge. As the rest of the organization moved to agile ways of working, the network infrastructure installation team was left out of step, and communication with other departments started to break down. The root cause was not the team itself: changes to the business and operating models of IT, HR and Finance had created a bottleneck in interdepartmental communication.
What we did. We brought the network provisioning operating model closer to the rest of the organization while preserving what its dependency on physical infrastructure demands. We created self-organizing teams around value streams, each with its own policies and WIP limits, designed a governance model specific to the department for iterative delivery, and built the information flow channels to and from central governance.
The results. Materially less rework in provisioning work orders, driven by better interdepartmental communication.
Team: 6 external + 20 internal.
About Versatile Consulting
Saket Bivalkar
Managing Partner. Meet the Versatile Consulting team.
Saket Bivalkar is the founder and Managing Partner of Versatile Consulting and leads its target operating model engagements. He has spent years designing operating models for organizations whose capability had grown by geography and acquisition rather than by design, including a technology company operating across 42 countries. He is the author of the KNOM adaptive operating model framework.
Frequently asked questions
How long does it take to design a target operating model?
Design typically runs [X to Y] weeks, depending on the size of the organization and how much of the current state is already documented. The variable that moves the timeline most is not complexity but decision speed: designs stall waiting for executive choices, not for analysis.
What is the difference between an operating model and a target operating model?
An operating model describes how an organization works. A target operating model describes how it must work in future to deliver its strategy. The distinction matters because most organizations have never made their current operating model explicit, and you cannot design a credible target state without first describing the one you have.
Who should be involved in designing a target operating model?
An executive sponsor with authority to make structural and governance decisions, a small cross-functional design group drawn from the areas the model affects, and representation from the people who will operate the model day to day. Designs produced by a narrow group tend to be technically sound and rejected in implementation.
Can a target operating model be designed without restructuring?
Yes. Structure is one component of seven, and a significant share of operating model problems are resolved by reassigning decision rights, redesigning cross-functional flows and changing measures, with the reporting lines left intact. Restructuring is an outcome of the design when the design requires it, not the starting assumption.
What happens if the current operating model has never been documented?
That is the normal starting point, and it is why current-state assessment is a phase rather than a document request. The model an organization operates is rarely the one on its intranet, and the gap between the two is usually where the diagnosis is found.
Does a mid-sized organization need a target operating model?
Size is not the trigger; change is. Organizations need one when strategy, ownership, scale, technology or regulation has shifted enough that the way they are organized no longer matches what they are trying to do. That happens at 200 people as readily as at 20,000.
How often should a target operating model be reviewed?
Annually against performance, and immediately on any material change of strategy, ownership or operating conditions. A model designed as a fixed end state ages badly; the practical alternative is a model designed to be revisited, which is the principle behind our KNOM framework.
What frameworks are used to design a target operating model?
Most published frameworks describe the same underlying components with different labels — capabilities, structure, governance, processes, people, technology and measures. The differentiator is not the framework but how consistency between components is tested and how the model is designed to adapt. We use KNOM.
Book an exploration call
If your strategy has changed and your organization has not, an exploration call is a structured conversation about where the current model is constraining delivery — and whether a redesign is the right response.