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.
Summary
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 Olin@ProcessERP.com.
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.