by Madeline Weiss, June Drewry

How to Overcome Resistance to Global IT Standardization

Sep 27, 20133 mins
Enterprise ArchitectureERP SystemsIT Governance

Thereu2019s inevitable tension between enforcing global IT standardization and allowing flexibility at the local level. Hereu2019s how to find the right balance.

One of the most vexing challenges for CIOs is finding the right balance between enforcing global IT standards (for efficiency) and allowing far-flung business units some flexibility to match IT to local business needs. But after an arduous journey, Nestle, the world’s largest food company, has achieved a balance that has been successful for its business, according to research by Michael Wade.

Wade, a professor at the IMD business school in Switzerland, shared Nestle’s experience with the Society for Information Management’s Advanced Practices Council. The familiar story begins with duplicated processes and costly systems that inhibited sharing of information and best practices. As one Nestle exec put it: “We had 10 definitions of ‘sugar’ in Switzerland alone. There was very little global standardization of data, systems or processes.”

To increase global efficiency, Nestle began an SAP installation–the world’s largest at the time. There were 15,000 processes to reconcile, and the project encountered lots of resistance. But Nestle’s CEO continued to push for standardization, and gradually the cost savings and benefits became clear. In two years, the percentage of Nestle business units using standardized processes jumped from 30 percent to 80 percent. Among other benefits, standardization made it easier to integrate acquired companies.

Although Nestle initially planned to standardize 95 percent of its processes and systems, it ultimately decided to allow more flexibility. Process owners can make a business case for a local (non-standardized) process.

Wade says the following practices helped Nestle and other firms achieve the right balance:

Adapt processes first. Executives often pressure CIOs to move too quickly into system-implementation mode without changing processes, hoping that new systems will force the issue with resistant business-unit heads. For example, a large shipping company lost patience with an SAP implementation and overlaid the software on top of existing processes. Seven years later, the project shows few gains and the company is considering starting over.

Pick smart pilots. The goal is to test concepts and build credibility. An ideal pilot program is medium-sized–not so large that problems are super-visible or will hurt organizational performance, but not so small that it’s considered an unrealistic test for other units.

Get top management support. According to a Nestle executive, “The CEO’s sponsorship was the number one success factor. He clearly stated that the project would be his legacy. This sponsorship provided the essential push to get the project off the ground.”

Build strong governance. Create mechanisms for figuring out which processes and systems become the global standard, how to authorize exceptions, and which processes or systems will be discontinued.

Start with back-office processes. Then move to manufacturing, operations and supply-chain functions, where the benefits of efficiency are high. Finally, tackle market-facing functions such as marketing and sales, which tend to resist standardization and support local flexibility–probably for good reason.

In a world where there’s likely to be strong resistance to any centrally led initiative, you’ll need a strong, strategic rationale behind each standardization request. Nestle’s CEO recognized that balancing local flexibility with global efficiency was pivotal to future growth and success. As chief IT strategists, CIOs play a crucial role in helping their firms create that balance.

Madeline Weiss is director of the Society for Information Management’s Advanced Practices Council (APC). June Drewry is former CIO of Chubb and an adviser to the APC.

Follow everything from on Twitter @CIOonline, Facebook, Google + and LinkedIn.