What Must Be Standardized—and What Should Stay Local?

A company acquires several businesses and now operates thirty facilities across different regions. The executive team wants one operating system. Corporate functions see duplicated processes, inconsistent metrics, multiple technology stacks, uneven quality controls, and several ways of solving the same problem. The case for standardization appears obvious.

The sites see something else. Customer requirements vary. Labor markets are different. Some facilities are highly automated while others depend on manual flow. Buildings have different layouts and equipment. Regulatory requirements change by jurisdiction. Supplier ecosystems are local. A process that works well in one facility may be unnecessarily expensive—or simply ineffective—in another.

Both sides can be right. A network with too little standardization fragments into separate businesses that cannot learn, compare, buy, plan, or invest as one enterprise. A network with too much standardization can force local operations to comply with a centrally designed model even when the local economics, risks, and constraints are materially different.

The executive decision is therefore not whether to centralize or decentralize. It is more precise: what must be common for the enterprise to perform as one system, and what must remain adaptable for each operation to perform in its own context?

The Tension Is Older Than the Modern Operating Network

A useful foundation comes from international strategy. C. K. Prahalad and Yves Doz developed the integration–responsiveness framework to describe the competing pressures multinational organizations face. Some forces push the enterprise toward integration: scale economies, common investments, global competition, coordination, and cost efficiency. Other forces push toward local responsiveness: differences in regulation, customer needs, market structures, culture, and local operating conditions.

Christopher Bartlett and Sumantra Ghoshal later extended this logic in their work on the transnational organization. The underlying management problem remains highly relevant beyond multinational strategy. A distributed operating network—whether composed of plants, fulfillment centers, service locations, branches, or business units—faces the same tension between enterprise integration and local fit.

The framework is valuable because it rejects the idea that one organizational philosophy is universally correct. High integration may be economically essential in one part of the operating model and counterproductive in another. Likewise, local autonomy can be a source of competitive advantage or an expensive form of fragmentation.

The practical implication is important: the enterprise does not need to occupy a single position on the framework. Different design elements can require different levels of integration and responsiveness. Financial controls may need near-total consistency. Safety-critical requirements may be nonnegotiable. Data definitions may need enterprise-wide standardization. Staffing models, work sequencing, supplier routines, or customer-response mechanisms may need considerably more local discretion.

What Standardization Actually Buys

Executives often describe standardization as a control mechanism, but its economic value is broader. Common processes and definitions allow performance to be compared across sites. Common technology platforms reduce duplication and support shared data. Common specifications increase purchasing leverage. Common operating language accelerates training and the transfer of practices. Common controls can reduce compliance, quality, safety, and cybersecurity risk.

Standardization also creates an enterprise learning system. If every location measures defects differently, defines downtime differently, or manages process changes through incompatible methods, the organization cannot reliably distinguish a better practice from a different one. The enterprise accumulates experience but cannot convert it into reusable knowledge.

McKinsey's 2026 work on distributed operations highlights this advantage. Successful network transformations establish common performance objectives, governance, metrics, and an enterprise architecture while allowing sites to translate those expectations into locally grounded plans. The purpose of the common core is not administrative neatness. It is to make learning, accountability, and scale possible across the network.

But standardization carries its own cost. Every enterprise standard assumes that the benefit of sameness exceeds the cost of forcing different operating environments into the same design. That assumption should be tested rather than treated as self-evident.

Where Local Responsiveness Creates Value

Local variation is economically justified when operating context changes what good performance requires. A facility facing severe seasonal labor scarcity may need a different workforce model than a site in a stable labor market. A plant serving highly customized customers may need different production sequencing than a high-volume site producing a narrow product range. A distribution operation in a dense urban market may need a fundamentally different transportation model than one covering a broad rural geography.

Regulation can make adaptation mandatory. So can differences in equipment, building design, utility reliability, supplier capability, language, and customer commitments. Even within one country, two sites can face materially different constraints. The closer a decision sits to those conditions—and the faster those conditions change—the more valuable local judgment can become.

This is where central organizations frequently make a category error. They interpret local variation as evidence of weak discipline when the variation may actually be a rational response to different constraints. The opposite error occurs at the sites, where historical preference is defended as necessary adaptation. "We are different" can be a legitimate operating fact or a convenient defense of legacy practice.

Neither claim should be accepted without evidence.

Standardize the Architecture, Not Every Method

The strongest distributed operating models tend to be explicit about what the enterprise owns and what the site owns. The corporate center should define the elements that must remain common because variation creates risk, destroys comparability, prevents scale, or weakens enterprise control. Local leaders should own adaptation where the method must respond to conditions the center cannot efficiently specify in advance.

That usually means greater enterprise control over definitions, critical controls, data architecture, technology standards, financial governance, escalation thresholds, strategic objectives, and the interfaces between sites and functions. These are areas where inconsistency makes it difficult for the organization to behave as one enterprise.

Local discretion is more defensible in the detailed method of execution: staffing patterns, sequencing choices, local supplier coordination, physical workflow, community relationships, and other practices shaped by real operating context. The boundary will differ by company, risk profile, technology, and strategy. The point is not to create a universal list. It is to make the boundary deliberate.

Jay Galbraith's Star Model provides a useful supporting lens because the decision is not only about process. If the enterprise changes the degree of centralization, it also changes structure, decision flows, rewards, and capability requirements. A company cannot tell sites to behave like empowered businesses while requiring every meaningful decision to be approved centrally. Nor can it demand enterprise optimization while rewarding leaders only for local performance.

A Practical Example: One Operating System Across Twenty-Five Sites

Consider an illustrative manufacturer with twenty-five facilities created through years of growth and acquisition. Corporate leadership launches a common operating system after finding wide variation in daily management, maintenance, quality routines, planning, staffing, and performance reporting. The first design is highly prescriptive. Sites receive common meeting templates, identical staffing assumptions, fixed escalation routines, detailed standard work for management, and a single set of process requirements.

The system creates immediate benefits. KPI definitions become consistent. Safety and quality escalation improve. Performance becomes easier to compare. Best practices spread faster. But problems emerge as the rollout matures. A highly automated facility spends time complying with routines designed around manual production. A site with severe labor volatility cannot use the standard staffing assumptions. A make-to-order plant is judged through metrics designed around repetitive production. Local leaders begin creating unofficial workarounds while formally reporting compliance.

The enterprise has standardized beyond the point where standardization creates value.

Leadership redesigns the model. A smaller set of enterprise requirements becomes nonnegotiable: metric definitions, safety and quality controls, financial and data standards, escalation rules, technology interfaces, and the minimum management mechanisms required to maintain control. Sites retain discretion over how they organize labor, sequence work, structure certain routines, and solve local performance constraints within those guardrails.

The center also changes its role. Instead of writing increasingly detailed instructions, it becomes responsible for architecture, comparison, capability building, knowledge transfer, and adjudicating exceptions. Sites are expected to explain why a local deviation creates value, measure the result, and share successful adaptations. A practice that repeatedly outperforms across contexts can then become the next enterprise standard.

That final step matters. Local autonomy without a mechanism for learning creates permanent variation. Standardization without a mechanism for local experimentation creates permanent rigidity. A high-performing network needs both.

The Economics of the Boundary

The boundary between enterprise standard and local discretion should ultimately be an economic decision. Standardization earns its place when it materially improves scale, quality, comparability, risk control, investment efficiency, or learning. Local adaptation earns its place when contextual differences materially change cost, service, speed, risk, or the probability of successful execution.

For any proposed standard, executives should ask several practical questions. Does variation create enterprise risk or prevent meaningful comparison? Does scale materially improve the economics? Does local context change what good performance requires? Can the interface be standardized while allowing the underlying method to vary? And if an exception is permitted, how will the enterprise determine whether it should remain local or become the new standard?

These questions move the debate away from preference. Corporate functions can no longer argue that a process should be common merely because common processes are easier to govern. Site leaders can no longer defend variation merely because the site has always operated that way. Both sides must demonstrate value.

The Counterargument: Local Autonomy Can Become Organizational Entropy

There is a legitimate reason executives gravitate toward standardization. Local freedom can deteriorate into duplication, incompatible systems, uncontrolled process changes, inconsistent customer experiences, and weak enterprise controls. Site leaders can overestimate the uniqueness of their environment. Acquired businesses can preserve legacy processes long after the original rationale has disappeared.

This is especially dangerous when local choices affect enterprise interfaces. A site may prefer its own planning method, but if that choice corrupts network data or prevents capacity from being compared, the local decision creates a system-level cost. A plant may prefer a different maintenance platform, but the resulting data fragmentation may destroy enterprise asset visibility. Autonomy is not free.

The answer is not unrestricted local choice. It is bounded autonomy: clear enterprise outcomes, controls, interfaces, and decision rights combined with freedom to adapt the method where local context genuinely matters. BCG's work on global operating models makes a similar point, arguing that organizations need to preserve local decision speed while remaining explicit about which authorities and resources are decentralized and which global platforms must remain common.

Uniformity Is Not the Goal

The executive temptation is to measure operating-system maturity by how consistently sites follow the same process. Consistency can be valuable, but sameness is not the objective. Enterprise performance is the objective.

A distributed organization should standardize what must be common for the company to behave as one system: the language of performance, the critical controls, the data, the interfaces, the strategic priorities, and the mechanisms that allow learning to travel. It should preserve local discretion where different conditions require different methods to achieve those common outcomes.

The strongest network is therefore not one in which every site works the same way. It is one in which leaders are explicit about where sameness creates value and where variation is a capability rather than a defect.

That is the real standardization decision: not how much control the center can impose, but where the enterprise becomes stronger by being the same—and where it becomes stronger by allowing itself to be different.

Selected Sources

Prahalad, C. K., and Doz, Y. L.. The Multinational Mission: Balancing Local Demands and Global Vision. 1987. Source

Bartlett, C. A., and Ghoshal, S.. Managing Across Borders: The Transnational Solution. 1989. Source

Midgley, D. F.. Integration-Responsiveness Framework. Encyclopedia of International Strategic Management, 2023. Source

Devinney, T. M., Midgley, D. F., and Venaik, S.. The Optimal Performance of the Global Firm: Formalizing and Extending the Integration-Responsiveness Framework. Organization Science, 2000. Source

McKinsey and Company. Leading from the Field: Transformation in Distributed Operations. June 2026. Source

Boston Consulting Group. If You're a Global Business, You Need a New Operating Model. June 2025. Source

Galbraith, J. R.. Designing Organizations: Strategy, Structure, and Process at the Business Unit and Enterprise Levels. 3rd ed., 2014. Source