Not so long ago, tech leaders were looking forward to a future where a global IT architecture on scalable cloud infrastructures would provide their companies with a full array of technology services efficiently, at scale, and at low cost.
What a difference a few years make, with a set of fragmentation forces rendering the prospect of a single, hyperproductive IT system unworkable. Local regulations (China alone has passed 21 data and tech laws), disruptions to supply chains driven by geopolitical and trade issues as well as the COVID-19 pandemic, and marked regional differences in customer behaviors, such as the contrasting preferences for WeChat in Asia and texting in Africa, have combined to undermine the prospect of a globally harmonized IT architecture.
Most tech leaders are all too aware of issues like these, yet the solutions they turn to can sometimes end up making things worse. One large pharma company, for example, developed—and supported—three different full-scale financial systems to meet local needs. In another case, an electronics manufacturer operates two parallel production processes with dedicated factories equipped with different 5G technologies to comply with the security laws of the products’ final markets. Compromise solutions may not work either; some businesses have found that using a single centralized system while making local adjustments leads to undue complexity and maintenance costs.
Technical architecture solutions, such as microservices, can help companies balance the level of local solution tailoring with the need to harness scale efficiencies. While not new, these solutions are more widely accepted and can be more easily realized in modern cloud platforms. These developments are enabling leading companies to evolve their operating models by building standardized, modular, and configurable solutions that maximize business flexibility and efficiency while making data management more transparent (Exhibit 1).
Ensuring that these new architectures and solutions work effectively, however, requires companies to embrace new forms of IT governance that include stakeholders from the business side and delegate decision authority to teams that are closer to the customer.
Identify strategic trade-offs, and build on the capabilities that serve them
The most successful governance model balancing global efficiency with local needs is often a federated model, with a central core of standard IT components and local layers that allow for selective deployment of capabilities in individual markets or business units (Exhibit 2). To build the model, businesses work through an iterative process that involves identifying strategic trade-offs between global standardization and local differentiation, reorganizing IT architecture around capabilities, and building a global IT architecture and operating model around modules that can be flexibly adapted to local requirements.
What makes such a model distinctive is that it isn’t a force-fit compromise between standardization and differentiation. Instead, it makes choices conscious and transparent and puts in place a repeatable process to continuously adjust the balance as external conditions or business needs change.
1. Identify global and local trade-offs for business and IT
Before sketching out the new model, IT and business need to develop a shared understanding of their company’s strategic business priorities and constraints and identify likely trade-offs between standardization and differentiation. The drivers for global standardization include:
- Scale effects and cost efficiencies. Digital natives have shown how businesses based on a single global platform can be scaled at minimal marginal cost.
- Simplification. Standardization helps organizations simplify and integrate processes, products, and operations across regions. This, in turn, allows operational staff to be shared—via call centers and centers of excellence, for example—and reduces hiring and training costs.
- Consistency. Providing a consistent experience across countries can add value for customers. Online shopping is much easier when a consumer who moves abroad, for example, doesn’t have to create a new account or adjust to a different user interface. Multinational corporations also welcome a consistent customer experience offering a consolidated view of their business across regions.
Would you like to learn more about McKinsey Digital?
On the other hand, the drivers for local differentiation include:
- Regulation. Businesses in highly regulated industries such as insurance and banking must adhere to national or regional regulations and ensure that regulators’ systems can connect with their own. Data privacy and security laws, such as the European Union’s General Data Protection Regulation (GDPR) and China’s Data Security Law, apply to all industries and may include requirements affecting local infrastructure, such as cloud providers, and mechanisms to control data flows, such as isolated access controls.1
- Customer expectations and behaviors. The user experience may need to be tailored to reflect local payment or communication preferences (such as AliPay or WeChat), or the need for integration with local ecosystems (such as Singapore’s Grab or Indonesia’s Gojek) or the systems of third-party service providers and suppliers.
- Risk. Global operating models can be vulnerable to large-scale disruption through single points of failure. Measures that expand the supplier base, increase local and regional sourcing, redesign networks, review inventory targets, and increase safety stocks can all help increase resilience and mitigate risk.2 At times of geopolitical instability, keeping systems and processes separate in vulnerable countries can allow business units to be carved out without too much difficulty, should the need arise.
- Differences in market size and maturity. Global systems and processes may not be the most economic choice for companies operating in a highly disparate set of markets. Smaller and less mature markets may be better served through local alternatives. For instance, an insurer with a sales force several hundred strong in its main market may need a sophisticated performance-management system to steer it, but deploying the same system to manage a local sales force with just half a dozen people wouldn’t make sense.
Weighing the pros and cons of standardization and differentiation is challenging, not least because people’s views are often shaped by their function. Risk managers often favor centralized controls, for example, while country leaders push for local autonomy. Managing these conflicts requires hard facts, such as the cost implications of a specific decision, and sometimes the willingness of a senior leader, even the CEO, to step in and settle the matter.
Balancing customization and efficiency at a manufacturing company
When a manufacturing company assessed the case for standardization versus differentiation in key business domains (exhibit), it decided to centralize some functions because of the clear benefits: procurement to increase its bargaining power, improve financial transparency, and drive efficiency across regions; and talent management, with a focus on making remote working the norm for most key staff. This made it an attractive employer for digital nomads and gave it access to new hires anywhere in the world.
On the other hand, innovation management was managed separately by each of the company’s two subdivisions, reflecting their very different product portfolios and customers, which would not have been well served by a single unified system. Meanwhile, customer management was harmonized at the regional level to allow the sales force to approach customers consistently across business units, but not at the global level, as there were no global customers.
Finally, warehouse management was organized regionally within each subdivision. Minimum requirements were set to allow integration with global supply chain systems and processes, but local operating models ensured the efficient management of a heterogeneous network of small suppliers and transport companies.
The goal will be to enable most products, components, and processes to be shared across countries. The advantages claimed for market-specific products and processes must always be carefully weighed against the disadvantages of increased complexity and limitations on scaling (see sidebar, “Balancing customization and efficiency at a manufacturing company”).
2. Reorganize the IT model around capabilities to reflect agreed strategic trade-offs
Discussions on how far to standardize and how far to differentiate can easily get lost in the weeds or become oversimplified. To avoid these traps, companies can draw up a capability map such as the one illustrated in Exhibit 3 for a European P&C insurer. Its purpose is to provide an abstract overview of individual business domains that use similar business capabilities. Properly done, such a map helps leaders visualize the business dimensions and related IT services of a given capability and determine what level of customization or harmonization is needed for their target system architecture and operating model.
The capability map shown in Exhibit 3 includes all the top-level capabilities required for the company to operate, make strategic decisions, and design the underlying IT architecture. For instance, “output management” comprises all the processes needed to create, store, and deliver outbound communications and the IT services needed to support them. For a more granular view, each capability is broken down into sub-capabilities, typically functionalities developed and maintained centrally by a cross-functional team with members from IT and the business. “Operational reporting” can, for example, be broken down into “sales performance” and “call center” reporting, each with its own team.
Wanting its business to be “as global as possible and as local as necessary,” the insurer used the capability map to help it make trade-offs as it shaped its system design and operating model. For example, the online “web and mobile” sales customer journey was developed as a single global set of microservices by a central agile team so that it could be harmonized across countries, with parameters customized only when necessary. Similarly, underwriting and pricing are managed via a shared global system, but local experts can reconfigure elements using a low-code/no-code rule engine and a standard software component.
Some of the insurer’s top-level capabilities required a more differentiated approach. Managing multiple local insurance aggregators, each with its own integration requirements, is done at the local level, as shown in teal in Exhibit 3. Similarly, capabilities that have a regulatory dimension, such as vehicle registration for car insurance, need to be deployed at the country level, as do address registers, car model search, local printing services, and repair shop networks.
The ERP platform play: Cheaper, faster, better
3. Use the capability map to build an IT architecture and operating model
A flexible global platform architecture consists of three components:
- A client journey platform, which covers an end-to-end customer experience, such as opening an account or checking out with a basket of goods. The platform is made up of products with functionalities that can be easily combined according to the specific customer needs in a particular region or segment.
- A business capability platform, which offers business functionalities that support customer journeys, such as order or payment management. This platform is made up of modular components that can meet the needs of individual countries, regions, or business units, as identified during the discussions on the capability map.
- A standardized, scalable cloud-based “IT for IT” platform, which uses state-of-the-art technology to provide IT capabilities to enable client journeys or business capabilities “as a service.” A central IT team manages this platform, while architecture and engineering teams assist client and business platforms to support the building of consistent solutions. This enables releases to be quickly deployed across the business and individual IT components to be consumed and reused independently across lines of business and capabilities.
Through these components, IT can allow local teams to tailor their technology needs either through configuration, where IT develops all the components for a given capability that local teams can configure, or extension, where locally developed components are linked to the global platform through centrally developed standard interfaces.
Configuration may be appropriate for capabilities that require only limited local differentiation, or those where differentiation is required by business logic and local configuration can be readily achieved. For instance, at the insurer described above, an open-source process-automation solution enables business leaders to configure underwriting rules locally without having to rewrite any code. Localization through extension is an approach often adopted by consumer companies to handle payments and last-mile logistics, with all their country-specific challenges. Country-specific capabilities are typically developed and maintained by local cross-functional BizDevOps teams and integrated with the global platform via APIs.
However useful these localization capabilities are, they will not work as needed unless local teams have sufficient autonomy (at some companies, local teams in China, for example, clear decisions through central headquarters, which is a major roadblock for pace and innovation). The best companies provide local teams with specific decision rights within guidelines and support them by providing necessary capabilities, such as IT talent embedded with local market teams to get customer feedback early.
Balancing these localization capabilities is a central organization, which safeguards standards and provides clearly defined services and APIs for local use. This balance helps reduce complicating adjustments and overlapping or conflicting implementations and enables the management of an effective global services architecture. We have mapped how this approach might work for automotive OEMs operating in China to find the optimal local/global balance across key functional areas (Exhibit 4).
Avoid key missteps in developing this new IT model
As a company builds out a new global architecture and operating model, it will need to avoid common issues that doom these kinds of programs. Following are some critical items to bear in mind:
- Provide local teams with clear decision rights. Leaders and the board need to refer to the capability map when making decisions, provide local teams with a clear mandate and the autonomy to make decisions, and establish a two-way communication between headquarters, countries, and business units.
- Think beyond one year for a long-term strategy. The flexibility of modern IT architectures allows companies to make extensive changes in a short time frame. However, some fundamental decisions, especially those on the data model and the organization of domains, should stay stable for three to five years. This reality may pose a challenge for managers focused on the next budget cycle.
- Create a capability map that breaks historic constraints. If the capability map is to act as a solid basis for identifying critical trade-offs and shaping the new IT model, it shouldn’t be defined by historic decisions or existing functional boundaries and constraints.
- Balance strong standards with sufficient flexibility. Standardization isn’t all or nothing; the trick is to make each decision at an appropriate level of granularity. In sales reporting, for instance, a company could mandate the use of a single IT solution across regions, limit standardization to a shared technical definition of what constitutes a sale, or choose a middle path, such as creating a shared interface with customization via local layers.
One European bank found this balance after one unit struggled to integrate the solutions that the main IT team was developing because of an array of issues, including poor documentation and IT solutions that were worse than those the local team could create. The bank launched an initiative to address this issue and developed a series of best practices, including people rotations between the local and main teams and adopting better sharing mechanisms.
In the past few years, the drawbacks of central globalized IT systems have become ever more apparent, while the advantages gained by running multiple national systems are often outweighed by complexity and costs. For a few early adopters, federated models like those described in this article are providing a better solution. Other multinationals may want to take note and follow suit.
