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.
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.
SOURCE :http://www.technologyevaluation.com/research/articles/erp-and-scm-implementations-part-one-doing-too-much-too-soon-17235/
No comments:
Post a Comment