Standardizing on One ERP System in a Multi-division Enterprise

It Is A Strategy Question   

In an enterprise with multiple operating divisions, should the enterprise standardize on a single set of software? The "one vendor - one ERP system" idea, although highly attractive, has remained utopian until recently, partly owing to the functional inadequacy of any ERP suite to satisfy requirements enterprise-wide. Recent broadening of major ERP products' scope to include e-procurement, supply chain management (SCM) and customer relationship management (CRM), and the advent of Web-based product architecture may, however, tempt the corporations to reconsider deploying this concept. Although the enterprise can generate many benefits from standardization, they may also create other issues that often result in disruptions.

Operational Considerations   

Like many strategy issues, this reduces to a series of trade-offs. A number of areas must be considered. The first place to look is at the operational needs of the business units. If the standardization driver comes from anywhere but operational needs such as business process unification, the project will likely result in shortcomings.

For one, how homogeneous are the divisional businesses? If the two or more units are in very different businesses, then the needs of both businesses may not be addressable by the same system. For example, a company that makes a food or chemical product that also manufactures the machines used to sell or apply the product at the customer's site has two very different businesses. The operational needs of both businesses must be met.

Will the single ERP system selected supply the level of functionality required for both businesses or will one or both be restricted or hampered by an inadequate system? Further, the product breadth and subsequent complexity of a Tier 1 ERP system (e.g., SAP and Oracle) may well be overkill for a small division that may only need basic ERP functions (e.g., accounting or order management) or may need deep plant-level functionality for a specific industry, where a Tier 2 or Tier 3 vendor (e.g., QAD, SCT, Lilly Software, Navision, etc.) could be a more appropriate solution.

The integration required between two or more operating units can vary. The units may be serving the same market, using the same suppliers, doing manufacturing for each other, selling each others products or have other relationships. The level of operational integration provides a sense of how integrated the systems of the two units must be. But having some of these joint operational issues is not sufficient to say that the units need the same system. These intimate cross-unit business processes can also be achieved via a kind of business process integration (e.g., EDI, a message broker, a portal, a private trade exchange (PTX)) between disparate ERP systems. The same approaches that work for collaboration between two different companies can be applied to internal collaboration between operating units.

How the relationship is structured is also an issue. If the current interaction is that of customer and supplier, then the connection can be handled by the same methods that they work with their other customers and suppliers, which again obviates the need for the same ERP system.

Furthermore, how global is the enterprise? Globally widespread corporations may be hard pressed to find a single ERP system that meets local regulatory compliance in every country the enterprise has a presence. They may often have to resort to using an alternative locally more apt vendor for certain organizations.

If the integration requirement is not operational but financial or managerial, this does not mean that the units need the same ERP system. Nevertheless, this remains a common myth and often the wrong rationalization for ERP standardization. The financial integration needs can be met by the consolidation functions available in many financial systems or by financial integration tools provided by vendors like Hyperion. The managerial integration might be met by using a single business intelligence or data warehouse solution over the different ERP systems, taking care to eliminate contextual issues across the systems within the BI (Business Intelligence) application.

Moreover, most of the ERP systems typically do not deliver the above solutions as standard offerings. The ERP system will require implementation of some sort of separate enterprise performance management (EPM) or executive information scoreboard (EIS) module from an ERP vendor. These components should generally be able to access data from other ERP systems, which removes the need for ERP standardization.

IT Considerations   

The IT department is often a proponent of this approach because standardization means integration needs are both minimized and simplified. However, it will be rare that the integration needs will be eliminated. Another benefit might be the use of consistent data structures (e.g., item numbers) corporate-wide, which an enterprise should strive towards in any case.

The difficulty of supporting multiple systems will also be less, as a single-vendor relationship often means easier negotiation and unambiguous accountability identification. IT will not require multiple sets of experts (full-time or consulting based) and investments in services like help desk, upgrades, etc. can be leveraged across the operating units resulting in lower cost and, in most cases, a higher level of service. However, significant IT cost benefits will not be achieved if the above operational benefits are not addressed and achieved.

Impact of M&A, the corporate culture and infrastructure   

Mergers and acquisitions raise an even more difficult set of standardization questions. When a new unit is acquired, should the existing systems be replaced with the "standard system"? In addition to the considerations stated above, the cost in terms of monetary and human resources plus the cost of business disruption must be considered, particularly if it involves replacing a system that has been mastered and accepted by users.

When two units are merged into one unit, what should be done with systems? The question is a repeat of the considerations given above but with the issue being "how merged" are the two units.

If the business has a culture of frequently buying and selling businesses, tightly integrated systems may become a negative. Tightly integrating the systems across multiple units may mean that the units cannot stand-alone without a major systems investment, leading to an obstacle to selling a unit. If the philosophy is tightly integrated systems, the acquisition of a new unit may dictate large investments in replacing systems to satisfy the dictates of this philosophy.

On the other hand, the following profile of an enterprise might benefit from considering ERP standardization: A centrally managed organization with strong corporate HQ, with globally enforced rigid corporate policies, and either a single core service business or similar manufacturing environments in all plants.


Should a multi-division enterprise standardize on a single ERP system? The answer is maybe. The considerations are both complex and many.

Given many diverse business units, the decision on a single system does not have to be consistent across the enterprise. Units with tightly integrated business operations and similar needs can standardize on one solution. Units with different needs or limited operational integration can and perhaps should exist with different systems.

Given that the clear cut answer is seldom found, enterprises may benefit from pursuing a limited ERP rationalization in order to obtain best of both worlds - a reasonable number of deployed applications without imposing a 'suffocating' global standard. Some recommended practices would be:

  • Identify an ERP vendor (often a Tier 1 vendor) with strong global coverage and product capabilities, as well as support for a wide range of platforms and integration standards, solid portal and/or trade exchanges initiatives, and diverse vertical industry solutions of your interest, and negotiate a corporate-level agreement with that vendor.

  • For geographically remote and peculiar divisions, and for divisions with esoteric functional requirements, identify a limited number of appropriate Tier 2 vendors.

  • Replace all existing systems (legacy and/or third-party bolt-on solutions) that are outside the corporate core competency with the systems from the above selected vendors. Also, allow divisions to implement functional applications that should boost competitive advantage, when they demonstrate it against the corporate-level vendor's solutions.

  • When different systems are used, establish a limited set of integration standards.

  • Consider deploying highly interoperable and flexible solutions both at the corporate level and in divisions. Additionally, application service providers (ASP) delivered solutions can, in some instances, facilitate more practical rollout of the corporate-level solution to a division, particularly for administrative backbone functions and when the division is soon to be divested.

As a summary, the ERP standardization strategy can impact the ability of the enterprise to operate. Consequently, it is truly an enterprise strategy, not an IT issue.

About the Authors   

Olin Thompson is a principal of Process ERP Partners. He has over 25 years experience as an executive in the software industry with the last 17 in process industry related ERP, SCP, and e-business related segments. Olin has been called "the Father of Process ERP." He is a frequent author and an award-winning speaker on topics of gaining value from ERP, SCP, e-commerce and the impact of technology on industry.

He can be reached at

Predrag Jakovljevic is a TEC research director with a focus on the ERP market. He has over 13 years of manufacturing industry experience, including several years as a power user of IT/ERP, as well as being a consultant/implementer and market analyst. He has been certified in production and inventory management (CPIM) and in integrated resources management (CIRM) by APICS.

comments powered by Disqus