Designing the Target Operating Model

3.1 Defining the Target Operating Model and Its Core Design Choices

A target operating model describes how an organization will organize resources, accountabilities, decision rights, processes, and management mechanisms to deliver its strategy. In an integration context, its purpose is to answer the fundamental question: how should the combined business work once the most important transaction-related changes have been implemented?

The target model should not be confused with the Day 1 organization. Day 1 may preserve temporary reporting lines, duplicate capabilities, transitional services, or separate systems because the business cannot safely move immediately to the final configuration. The target operating model describes the intended destination. An interim operating model may be required between the two, particularly when technology migrations, regulatory approvals, labor processes, customer commitments, or capability-building efforts constrain the pace of change.

A useful operating model normally resolves choices across five dimensions. First, it defines the primary organizational units through which the enterprise will be managed, such as business units, product groups, customer segments, regions, sites, or legal entities. Second, it defines the role of the corporate center and the degree of autonomy granted to operating units. Third, it establishes where functional capabilities will reside. Fourth, it defines the most important decision rights and process ownership. Fifth, it determines the governance and management mechanisms used to coordinate activity across organizational boundaries.

These dimensions are interdependent. A company cannot sensibly decide that procurement will be centralized without also defining the authority of business units over suppliers, budgets, and local purchasing. A regional structure cannot be designed without deciding whether regions own profit and loss performance or simply coordinate execution. A matrix organization cannot work unless decision rights clarify what happens when product, functional, and geographic priorities conflict.

The design process should therefore begin with a short list of enterprise-level questions rather than detailed organization charts. Typical questions include:

• What is the primary unit of accountability for financial and operating performance?
• Which decisions should be made once for the enterprise and which should remain within operating units?
• Which capabilities require global scale, specialist depth, or standardization?
• Which activities require proximity to customers, regulators, sites, or local markets?
• Where must the organization preserve differentiated capabilities from one of the legacy businesses?
• Which processes require end-to-end ownership across several functions?
• What degree of management complexity can the combined business realistically support?

Executives should develop a small number of plausible operating model options rather than attempting to design the final model immediately. Options should represent genuinely different ways of running the business. For example, one model may grant significant autonomy to product business units, while another may place stronger control in global functions. A third may organize primarily by geography. Comparing meaningful alternatives forces leadership to confront trade-offs that can otherwise remain hidden.

Each option should be tested against the transaction rationale, design principles, customer requirements, economic targets, regulatory constraints, and current-state capabilities established in earlier chapters. The evaluation should also consider implementation feasibility. A theoretically attractive model may require systems, data, management capabilities, or talent that will not exist for several years. In that case, leadership must decide whether to build those enablers or select a model that the organization can operate successfully sooner.

Joint ventures require additional choices about organizational sovereignty. Management should specify which responsibilities belong to the venture itself, which are exercised by its board, which remain reserved to shareholders, and which capabilities are supplied by the parents. A venture designed to operate independently may need its own finance, human resources, technology, procurement, and commercial capabilities. Another may deliberately remain dependent on parent-company services. Neither model is inherently superior, but ambiguity between them is dangerous.

The output of this stage should be an agreed description of the target model at sufficient resolution to guide organization design. It should explain the principal organizational axis, unit accountabilities, role of the center, functional placement, decision philosophy, and major coordination mechanisms. It should not yet attempt to specify every position or reporting line. Those choices become much easier once the underlying operating logic is clear.

3.2 Determining the Role of the Corporate Center, Business Units, Regions, and Functions

One of the most consequential operating model choices is how responsibility is divided among the corporate center, business units, regions, and functions. Poorly defined roles create duplication, excessive escalation, competing authorities, and organizational cost. A strong model gives each layer a clear purpose and minimizes situations in which several groups believe they own the same decision.

The corporate center exists to perform activities that create greater value when managed for the enterprise as a whole. Typical responsibilities include enterprise strategy, portfolio management, capital allocation, investor relations, governance, risk oversight, leadership succession, financial control, and establishment of selected policies and standards. The center may also house shared capabilities where scale or specialist expertise produces clear advantages.

The size and authority of the center should follow the business model. A diversified holding company may need a relatively small center focused on portfolio ownership, capital allocation, and governance because operating businesses are intentionally autonomous. A highly integrated company with common customers, technologies, brands, or supply networks may require a stronger center to coordinate resources and establish enterprise-wide priorities.

Integration teams often make one of two mistakes. The first is assuming that the acquiring company’s existing center should automatically absorb the corresponding activities of the acquired business. The second is treating centralization as synonymous with good governance. Both can produce unnecessary bureaucracy. The design question is not which legacy center survives; it is which responsibilities must be exercised once at enterprise level for the future business to perform effectively.

Business units generally exist to create clear accountability for a market-facing or economically meaningful part of the enterprise. They may be organized by product, customer segment, brand, technology, or industry. Where business units own profit and loss performance, the model must give their leaders sufficient authority over the resources and decisions required to deliver that performance. Holding executives accountable for results while central functions control every material operating decision creates nominal rather than real accountability.

At the same time, business-unit autonomy should not justify unnecessary duplication. Each unit does not automatically need its own treasury, payroll, cybersecurity operations, procurement infrastructure, or legal administration. The question is which capabilities directly shape competitive performance and which can be provided more efficiently or consistently at enterprise level.

Regions play several possible roles, and integration teams should define which role is intended. A region may own financial performance, coordinate multiple businesses within a market, provide shared infrastructure, represent the company to regulators, manage local talent, or simply execute global product strategies. Problems arise when regional leaders carry senior titles but their authority is not clear relative to global business and functional leaders.

Where regional structures are retained, management should specify what decisions regions own rather than describing them as generic coordination layers. Examples might include local pricing within defined parameters, regulatory relationships, country-level legal accountability, market-entry execution, or regional capacity decisions. A regional role without distinctive decision authority often adds another management layer without resolving any operating requirement.

Functions provide expertise, standards, processes, talent development, and execution capacity across the enterprise. Functional leaders may operate through fully centralized teams, embedded resources within businesses, or a combination. The design must distinguish between functional authority over professional standards and operating accountability for business outcomes. A chief human resources officer may own enterprise talent standards while business-unit leaders remain accountable for the quality of their leadership teams.

Matrix structures emerge when more than one dimension is important enough to influence resource allocation and decision making. For example, a global product business may need strong geographic leadership because customer requirements and regulation vary significantly by country. Matrices are not inherently ineffective, but they impose a coordination cost. The organization should use them only where the value of representing multiple dimensions exceeds that cost.

When a matrix is necessary, leaders should avoid relying on phrases such as “shared accountability.” Shared contribution may be appropriate; shared final accountability is usually not. For important decisions, the model should identify who decides, who provides input, who can establish constraints, and how unresolved conflicts escalate.

Joint ventures add another organizational layer: the shareholders. The venture board may perform functions that resemble a corporate center, including strategy approval, capital allocation, senior appointments, and risk oversight. Parent companies may also retain technical, commercial, or functional influence through contractual rights. The venture operating model should distinguish these governance rights from management responsibilities so that shareholder involvement does not become day-to-day operational interference.

A practical role map should summarize the purpose of each organizational layer and identify the principal decisions owned there. If management cannot explain why the corporate center, each business unit, each region, and each major function exists, the structure is likely more complicated than necessary.

3.3 Deciding What to Centralize, Share, Federate, or Keep Local

Centralization decisions are among the most visible and politically sensitive aspects of integration. They affect executive authority, headcount, locations, service levels, and synergy realization. They should therefore be made through an explicit framework rather than by assuming that larger scale automatically justifies centralization.

Four broad delivery models are useful. A centralized activity is controlled and typically performed by one enterprise organization. A shared activity is delivered as a common service to multiple operating units, often through a shared-services organization. A federated activity combines enterprise standards or leadership with resources embedded in business units or regions. A local activity is substantially owned and performed within an operating unit.

These models can be applied separately to different components of the same function. Finance, for example, might centralize treasury and external reporting, provide accounts payable through shared services, federate financial planning through business-facing teams, and retain local statutory expertise in selected countries. Thinking at the activity level produces better decisions than treating entire functions as indivisible.

Activities are strong candidates for centralization when scale improves economics, consistency, control, bargaining power, specialist depth, or enterprise coordination. Treasury, cybersecurity operations, enterprise architecture, tax policy, insurance, executive compensation, and certain procurement categories often exhibit these characteristics. Centralization is particularly attractive when fragmented execution creates material risk or prevents the enterprise from using its combined scale.

Shared services are most suitable for high-volume, repeatable activities that can be standardized and delivered through common processes and technology. Payroll administration, accounts payable, employee-data administration, basic procurement operations, and certain customer-support activities can fit this model. A shared-service decision should consider transaction volume, process maturity, service requirements, technology compatibility, language needs, local regulation, and transition cost.

Federated models are appropriate when the organization needs both enterprise consistency and close business partnership. Human resources, finance, legal, data, marketing, and technology frequently use this structure. A central functional leader may own standards, professional capability, technology, and career development, while embedded teams support individual business units. The principal design challenge is avoiding confusion over who sets priorities and evaluates performance.

Local models are appropriate when activities depend materially on customer proximity, local regulation, site knowledge, response speed, or market-specific expertise. Plant operations, country regulatory affairs, local sales, clinical operations, and field service often require substantial local ownership. Keeping work local does not prevent the enterprise from establishing common standards; it simply places execution authority closer to where performance occurs.

A disciplined evaluation should consider several criteria for each major activity:

• Scale economics: Would consolidation materially reduce cost or improve utilization?
• Consistency: Is standardization important for quality, brand, data, or control?
• Specialist depth: Is scarce expertise more effective when pooled?
• Business proximity: Does performance depend on intimate knowledge of customers, operations, or products?
• Response time: Would centralization make urgent operational decisions slower?
• Regulatory requirements: Must accountability or execution remain within a jurisdiction or legal entity?
• Strategic differentiation: Is the activity a source of competitive advantage that should remain close to the business?
• Technology dependency: Can systems and data support consolidated delivery?

The evaluation should distinguish control from execution. An activity can operate under centralized policy while execution remains local. Conversely, transactional work can be physically centralized while important decisions remain with business units. Separating these dimensions often resolves debates that appear to be simple conflicts between centralization and decentralization.

Integration timing also matters. Management may decide that an activity ultimately belongs in shared services but cannot move it there until systems are harmonized. In that case, the target operating model should record the intended destination while the implementation plan establishes an interim arrangement. Temporary duplication may be justified if it protects continuity during the transition.

Synergy targets should inform but not dictate the analysis. If the transaction model assumes significant savings from support functions, the operating model must explain how those savings will actually be produced. Eliminating positions without consolidating the underlying work simply redistributes workload. Conversely, centralizing an activity solely to support a synergy number can reduce service quality or create new coordination costs that offset the savings.

Joint ventures often rely extensively on parent-company services, creating a fifth practical option: source from a shareholder. This may be efficient during startup or where a parent possesses unique infrastructure, but the arrangement should be explicit. The venture must understand service levels, pricing, intellectual-property rights, data access, continuity provisions, and its ability to replace the service if ownership changes or the venture becomes more independent.

The final decision should be documented at the activity level, with a short rationale and any transition dependency. This produces a transparent record of why work sits where it does and prevents later organizational debates from reopening decisions without new evidence.

3.4 Designing Critical Cross-Functional Interfaces and Process Ownership

No operating model works through vertical organization structures alone. Customer outcomes, product launches, investments, supply decisions, talent moves, and risk responses routinely cross several functions and business units. The target model must therefore define how critical interfaces will operate and who owns processes that cannot be contained within a single organizational silo.

The first task is to identify the interfaces that matter most. These should be selected based on economic importance, customer impact, operational risk, and historical friction rather than by attempting to document every interaction in the company. Typical examples include sales and operations, product and engineering, commercial and finance, procurement and manufacturing, business units and technology, corporate functions and regions, or headquarters and regulated entities.

For each critical interface, the team should identify the recurring decisions and outputs that cross the boundary. Consider the interface between sales and operations. Important decisions may include demand commitments, prioritization during shortages, inventory allocation, service-level exceptions, and launch volumes. Simply stating that the functions must “collaborate” does not define how those choices will be made.

Process ownership provides a mechanism for managing work that spans organizational boundaries. An end-to-end process owner is accountable for the design and performance of a process even when execution occurs in several functions. Examples include order to cash, procure to pay, hire to retire, concept to launch, demand to supply, or incident to resolution.

The process owner should not necessarily control every employee involved. Instead, the role should carry enough authority to establish process standards, define performance measures, resolve cross-functional issues, and sponsor improvements. Functional leaders remain responsible for the quality and capacity of resources performing their portions of the process.

The integration team should avoid creating process ownership merely by adding titles. If a process owner lacks decision rights, measures, resources, or an escalation path, the role becomes another coordination layer. Before establishing one, management should specify which decisions the owner can make independently, which require functional agreement, and which escalate to enterprise governance.

Decision-rights tools can clarify particularly difficult interfaces. A simple framework may identify who recommends a course of action, who contributes required input, who makes the final decision, and who executes it. More elaborate matrices should be used only when the additional complexity genuinely helps. The objective is clarity, not classification.

Service relationships between centralized functions and business units should also be defined. Centralization often fails when corporate teams believe they have delivered efficiency while operating units experience slower service and less responsiveness. Important shared or centralized services should therefore have explicit expectations for service levels, prioritization, issue escalation, and performance measurement.

The operating model should also specify how conflicts are resolved. Cross-functional disagreement is normal because different units optimize different outcomes. Sales may favor customer responsiveness while operations emphasize stability and efficiency. Risk teams may seek controls that commercial teams perceive as restrictive. A strong interface does not attempt to eliminate these tensions; it establishes a mechanism for resolving them at the appropriate level.

Management forums should be created only where recurring cross-functional coordination is genuinely required. A weekly supply meeting may be essential. A permanent committee for an issue that arises twice a year probably is not. Each forum should have a clear purpose, decision authority, membership, cadence, and expected output. Meetings that merely exchange information can usually be simplified or replaced.

Metrics should reinforce the interface rather than pull participants in opposite directions. If a commercial team is rewarded exclusively for revenue while operations is rewarded exclusively for inventory reduction, conflict is predictable. Shared outcome measures can help where performance genuinely depends on joint execution, but accountability should remain sufficiently specific that poor performance can be diagnosed.

Joint ventures create several interfaces that deserve explicit design: venture management and the board, venture functions and parent-company functions, venture employees and seconded personnel, and the venture with parent-provided service organizations. These interfaces should not rely on informal goodwill. Decision rights, information access, service expectations, confidentiality, escalation routes, and conflicts of interest may all need formal treatment.

The output should be an interface map showing the most important organizational boundaries, the decisions or processes crossing each boundary, the accountable owner, the supporting governance mechanism, and the measures used to judge effectiveness. This map makes the target model operational. Without it, an organization can have clean reporting lines yet remain unable to make decisions across them.

3.5 Target Operating Model Blueprint and Design Decision Template

The final step is to consolidate the design into a target operating model blueprint that executives can understand, challenge, approve, and ultimately implement. The blueprint should be concise enough to guide management decisions but detailed enough that functional teams interpret the model consistently.

A useful blueprint begins with a one-page enterprise view. It identifies the primary organizational units, the role of the corporate center, major business or regional accountabilities, key functional structures, and the principal governance relationships. The graphic should show operating logic rather than every reporting line. Detailed organization charts belong in the next stage of design.

The blueprint should then document the major choices supporting that enterprise view. A practical structure includes five components:

1. Operating model intent: Summarize what the model is designed to enable, including the most important transaction objectives and design principles.
2. Organizational roles: Define the purpose and principal accountabilities of the corporate center, business units, regions, major functions, and, where relevant, parent companies.
3. Activity placement: Record which important activities are centralized, shared, federated, local, or externally provided.
4. Critical interfaces: Identify major cross-functional processes, decision rights, process owners, and governance mechanisms.
5. Transition implications: Distinguish the target state from Day 1 and identify major capabilities, systems, agreements, or organizational changes required to reach it.

The team should maintain a separate design decision log alongside the blueprint. The purpose of the log is to preserve the rationale behind important choices and prevent recurring debates. Each entry should state the decision, alternatives considered, decision criteria, rationale, approving authority, date, dependencies, and any conditions under which the decision should be revisited.

A short decision template can be structured as follows:

• Decision required: State the specific operating model choice.
• Business requirement: Identify the problem or objective the decision must address.
• Options: Describe the viable alternatives without creating artificial choices.
• Evaluation criteria: Link the assessment to approved design principles and transaction requirements.
• Recommendation: State the preferred option and principal rationale.
• Risks and trade-offs: Identify disadvantages and mitigation actions explicitly.
• Dependencies: Note systems, talent, legal, regulatory, contractual, or sequencing requirements.
• Approval: Record who has authority to decide and when the decision becomes effective.

The blueprint should be tested through practical scenarios before final approval. Management can ask how the model would handle a major customer issue, capital request, product launch, regulatory problem, talent decision, or supply disruption. If executives cannot determine who owns the decision and how the organization would respond, the design remains incomplete.

Joint-venture blueprints should additionally show the boundary between management, the venture board, shareholders, and parent-provided capabilities. Reserved matters, delegated authorities, service relationships, and parent interfaces should appear as integral parts of the operating model rather than being treated solely as legal provisions. The venture must be able to operate within these arrangements in practice.

The completed target operating model should give leadership a coherent answer to how the future organization will work without prematurely specifying every job. It establishes the architecture within which detailed organization design can proceed: which organizational units matter, what each is accountable for, where major activities belong, how cross-functional work is governed, and which dependencies must be resolved during implementation. With that architecture agreed, subsequent decisions about reporting lines, leadership roles, spans, layers, governance forums, and staffing can be made against a common operating logic rather than negotiated independently.