Introduction
Enterprise
resource planning (ERP) systems are typically very complex and all-encompassing
software. Supply chain management (SCM) systems are no slouches when
it comes to complexity and scope, either. So why would a company attempt to
implement both systems at the same time? Some rationalize that their software
is in such dire straits that they need to get in front of the system's development
curve, not just keep pace. Others rely on the "rip off the bandage with one
quick pull and the pain won't be as bad" approach to software implementation.
They reason that by implementing both software systems at roughly the same time,
the business disruptions only have to be endured once but with great intensity.
While this may work with bandages and human beings, most companies cannot withstand
the shock to their organizations and personnel.
This article looks at reasons advising against this potentially foolhardy and risky approach. These reasons include lack of foundation and resources, organizational trauma, and interface construction. The article closes with a discussion of which system to implement first. While not surprised by the answer, you should understand the arguments and be prepared to address them.
This
is Part One of a two-part note.
Part
Two will address interfaces and priorities.
Lack
of Foundation and Resources
Typically,
software needs a layer of data to serve as a foundation on which programs can
function, process, and update. As software grows into systems, architectures,
and networks, systems rely on other systems to supply this data foundation.
As illustrated in figure 1, such is the case with ERP and SCM software.
ERP
software manages, validates, and updates the data for SCM software. This data
is the form of such things as ingredients or parts, formulas or bill-of-materials,
routings, resources, and orders or customer demand. Unless this data is firmly
in place, SCM software can become a different kind of software beast to wrestle
with. While trying to implement both ERP and SCM software simultaneously, the
data becomes a moving target. While you are trying to get the data right for
ERP purposes, the SCM software is using the same data for its testing. If unexpected
results are encountered during the SCM implementation, is it because the data
being fed from the ERP software is erroneous or is it a case that the setup
in the SCM software is wrong? It becomes a guessing game to find "Who Shot John?"
As
in construction, it is important that the underpinnings of the foundation are
in place and solid before attempting to erect the walls and roof. Likewise,
assurances must be made that the data in the ERP repository accurately reflects
the business rules of your company before attempting to use with the SCM software.
Typically, this requires a shakedown period under live, production usage, implying
that the SCM software should only be implemented after the ERP software is stable
and firmly in place.
Experience
indicates that the ratio of full-time equivalents (FTE's) for implementing
ERP and SCM software is about 3 to 1. This means that, for every three FTEs
needed for an ERP implementation, one FTE is needed for the implementation of
SCM software, given the same environmental constraints. Do the math! An ERP
implementation project team of ten FTE's is not unreasonable. Add to this the
three FTE's to complete an SCM implementation at the same time. Asking an organization
to dedicate thirteen FTE's to implementation projects that will take, at a minimum,
nine months and, more likely, eighteen months, is unrealistic. Who will keep
the current business running profitably or running at all? In small to medium-sized
enterprises this allocation of personnel resources is not only unrealistic,
it is impossible.
Some
might argue that, by undertaking both projects simultaneously, on an aggregate
basis you are tying up fewer personnel for a shorter period of time. However,
somehow you need to factor the uncertainties and unexpected delays created by
the floating data foundation described above.
Finally
you will be asking the same people to do many tasks. This becomes more acute
in small to medium-sized enterprises. For example, on the first shift, the person
managing production line will be asked to oversee the setup of product nomenclatures,
create the formula, define resources, and establish routings, which are all
ERP activities. On the second shift, the same person will be asked to complete
SCM tasks such as modeling the production floor, define bottlenecks, and then
resolve constraints. Something will have to give, be it incomplete data, inaccurate
planning estimates, or target dates being missed. Similar cases can be made
for other members of the members of the project teams. This does not reduce
the FTE requirement; it just makes people frustrated because they cannot complete
all of their assigned tasks.
Organizational Trauma
Obviously,
the person who coined the phrase, "variety is the spice of life," did not install
software for a living. If so, this person would surely know that, at least initially,
the last thing users want to learn is a new system. The cultural shock on personnel
having to learn and use ERP software is difficult enough. Compound this by having
to adjust to SCM software at the same time and your project life cycle just
got a lot tougher.
Organizations
converting from legacy systems face a double-edged sword. Not only are users
faced with new software, they are also faced with new technology. Depending
on the age of the legacy systems, this technology could include something as
basic as the use of a mouse or more sophisticated technology such as radio
frequency identification (RFID) for parts and ingredients. Have you ever
seen someone use a mouse for the first time? It's not a pretty sight. So, in
addition to learning how to enter orders, pick inventory, and modify production
schedules, personnel are being asked to learn how to point'n'click, operate
barcode readers, and drag'n'drop.
Would
it not make more sense to train users on new technology while keeping the new
screens and data elements that they are confronted with to an absolute minimum?
Of course it would. Following this line of reasoning, it would make more sense
to implement enterprise software packages one at a time. By the time that you
get to the second enterprise package, at least the technology curve should be
a straight line.
Now the hour of truth: go live. Rarely do packages go into production without problems. The question, that you have to ask yourself is, "How many fires can you put out at the same time?" Again, problems happen and things go "bump in the night". The fallout in terms of lost confidence and frustrations is the real damage. The recovery time to restore user confidence does not happen overnight. To limit your exposure, implementing one software package at a time may keep the fires to a manageable few. It may also give you the opportunity to establish your track record. As a personal choice, stacking the deck can't hurt.
Starting an ERP implementation with the more basic, straightforward components, say accounts payable or general ledger, can quickly build confidence and demonstrate that the software functions according to expectations. Furthermore, it can develop a friendly rivalry between project teams. If we did it, so can you. Understand that there are tricky points that must be negotiated when you split up the implementations of integrated software. However, if planned properly, the benefits can significantly outweigh the risks and created a safe harbor for the remaining components.
This
concludes Part One of a two-part note.
Part
Two will address interfaces and priorities.
About
the Author
Joseph
J. Strub has extensive experience as a manager and senior consultant
in planning and executing ERP projects for manufacturing and distribution systems
for large to medium-size companies in the retail, food and beverage, chemical,
and CPG process industries. Additionally, Strub was a consultant
and Information Systems Auditor with PricewaterhouseCoopers and an applications
development and support manager for Fortune 100 companies.
He
can be reached at JoeStrub@writecompanyplus.com.