Source: https://vdocuments.site/avoiding-the-pitfalls-of-erp-system-implementation.html
Timestamp: 2019-04-21 10:07:44+00:00

Document:
Avoiding the Pitfalls of Erp System ImplementationTheodore Grossman a & James Walsh ba Senior lecturer of Information Technology Management at Babson College, Wellesley,Massachusetts. He can be contacted at grossman@babson.edub The managing partner of Carroll Burdick & McDonough LLP in San Francisco, California.He is a litigator and has litigated several high-technology cases, including ERP contractualdisputes. He can be contacted at jwalsh@cbmlaw.com.Published online: 21 Dec 2006.
ERP implementation is a massive undertaking fraught with risk. This article is filled with prac-tical advice for minimizing these risks. It looks at the technical, operational, and legal aspects of ensuring a satisfactory ERP deployment.
embarking on an ERP implementation. It does not discourage the journey, but cautions the traveler to be vigilant of the potential issues. The issues are broken into three categories: technical, operational, and legal.
THEODORE GROSSMAN is senior lecturer of Information Technology Management at Babson College, Wellesley, Massachusetts. He can be contacted at grossman@babson.edu.
JAMES WALSH is the managing partner of Carroll Burdick & McDonough LLP in San Francisco, California. He is a litigator and has litigated several high-technology cases, including ERP contractual disputes. He can be contacted at jwalsh@cbmlaw.com.
often, they are in the inventory control, order pricing, or manufacturing areas. These are the sacred cows that differentiate a company from the competition, and the ERP package must be adapted to these needs, not the reverse. Any successful ERP implementation must not im-pose operational philosophies on the organiza-tion.
Scheduling the InstallationEverybody wants to get the package installed as soon as possible. Feeling this pressure, the package vendor and its implementation part-ner might promise a six-month implementation period. However, be very wary of these kinds of promises. Remember the first laws of soft-ware implementations: it takes longer and costs more than originally planned.2 Regardless of what resources are thrown at the project, it just takes time to get it all done. Unexpected problems can arise in the pilot phase. This re-quires either modifications to the package or a commitment by a company to change its own processes to match the packages methods. That reconciliation takes time. Change is pain-ful and organizations resist change. Other tasks are usually minimized in the planning process but take much longer, such as testing, training, and rollout. Regardless of everyones best in-tentions, it takes a long time to successfully im-plement an ERP. Hershey Foods found that out the hard way, like many other large sophisticat-ed companies, not to mention the small com-pany implementations that litter the landscape.
easily measured, measuring improved financial management or better managerial decision making is more difficult.
Potential Problems with Third-Party Implementation PartnersAlthough there are many third-party implemen-tation partners that are very familiar with an ERP package that is being implemented, that does not always hold. Especially when a pack-age includes a new version, an implementation partner might be learning on the job. Also, many consulting companies hire a sizable num-ber of recent college graduates and use them as the worker-bees on implementations. Fre-quently this might be their first exposure to an ERP package, and they are learning on the job. More importantly, no matter how experienced the implementation partner is with an ERP package, they do not know the contracting or-ganizations business and its intricacies, which leads to the next issue.
This Is a Team SportRegardless of how many people are included to help from an ERP vendor or an implementation partner, it stills requires a major commitment from an organizations employees. Only the employees know the processes and institution-al history that makes the organization success-ful. The greater role employees play in the implementation, the higher the likelihood of a successful implementation. This ensures that undocumented knowledge is covered and pro-vides a greater buy-in from the organization. The kiss of death for a system is if the organiza-tion rejects the changes that the system requires. Conquering cultural issues is mandatory for a successful implementation.
Vendors May OverpromiseBy definition, ERP systems are both integrated and comprehensive solutions. Each of their modules has many features and options. It is impossible to vet each function and feature be-fore signing on the dotted line. Often, an ERP vendor promises a new feature in the next ver-sion of its system. Organizations should be highly skeptical of these promises because they often turn out to be worthless.6 Vapor-ware has a long history in the computer indus-try. All promises must be in writing and specifications for the promised software well understood.
t is impossible to vet each function and feature before signing on the dotted line.
The Importance of Detailed SpecificationsDetailed specifications are a requirement for several reasons. How does an organization ever know if a system performs as required if it has never defined requirements? This is the equiva-lent of asking a building contractor to build a house without detailed blueprints. Detailed specifications should be a major component of the contract that an organization has with the ERP provider and third-party implementer. De-tailed specifications should include not only in-formation about features and functions, but also requirements concerning volumes and re-sponse times. A system that has all the neces-sary functions but has a suboptimal response time can never be acceptable. How long are end users willing to sit at a computer monitor and wait for a response? Five seconds, ten sec-onds, three minutes? Response time frequently is the difference between the success and fail-ure of a systems implementation.
Infrastructure Design Must Be a Collaborative EffortInfrastructure can also make the difference be-tween success and failure. ERP vendors neither prefer to be involved in nor take any responsi-bility for the design and specification of hard-ware and network infrastructure. However, it is the ERP company that knows the most about its softwares demand on both hardware and a network. ERP software companies usually dis-claim all responsibility for hardware and network infrastructure in their license agree-ment. They assume no liability and place all re-sponsibility on the client for hardware and network sizing and configuration. This places the client in a no-win situation. The client must force the ERP company into assuming some level of ownership in the hardware and net-work configuration decision. This issue has been the source of several high-profile lawsuits in failed ERP implementations.
files do not contain the same information. One has a payment address and the other an order address. Telephone and fax numbers might be different. Data cleansing and consolidation is a necessary step in the data conversion process. A group must be assigned responsibility to eval-uate the quality and completeness of legacy da-ta.
Stress Testing Must Be Performed before Going LiveMany companies make the mistake of assuming that once an application concept is proven in the pilot phase, it can go live. That is far from the truth. The pilot phase is merely a prototyp-ing phase. Once that is complete and all the data has been loaded into the system, stress testing must be performed. What works in small volumes does not necessarily work when put under the operational loads of a live envi-ronment. There are various tools that can simu-late production volumes. Stress testing may reveal that response time degrades to unac-ceptable levels, or that the network becomes overwhelmed with volume. The system might need to add additional bandwidth or additional processors.
TrainingTraining is the stepchild of most software im-plementations. It is the one area that cannot be overlooked or underemphasized. Without ade-quate training, a system can never be used properly, nor can it ever achieve the returns that were projected. Training involves almost the entire organization. Anyone who uses the system or has some connection with the sys-tem must have some level of training. The cost of training should not be underestimated. Training is frequently as costly as the system it-self. Resolving operational and cultural issues contributes greatly to a systems success. And training is an integral part of that process.
tress testing may reveal that response time degrades to unacceptable levels, or that the network becomes overwhelmed with volume.
the organization and its third-party implemen-tation provider. Vendors often attempt to dis-claim warranties, limit their liabilities, and shy away from as much responsibility as possible. An organizations job is to negotiate not just the best price but also the most favorable terms and conditions. Contrary to popular opinion, an organization can negotiate the terms of a contract. Vendors can resist changes their its ironclad or standard contract terms, but they can be made to negotiate. There are sever-al components to a valid contract; some of the more important are discussed in the next sec-tions.
Pitfalls of Integrated ContractsAn integrated contract states that the contract is the entire understanding of the parties and supercedes all other representations, whether oral or written. The result of an integrated con-tract may be to void whatever promises the ERP vendor or implementation partner might have previously made orally or in writing, and a vendor can argue it cannot be held to such promises.8 It is best, when possible, to make all of those promises and representations a part of the contract. At a minimum, the contract should acknowledge that the parties have ex-changed other representations or promises.
Inclusion of Detailed SpecificationsWithout detailed specifications in a contract, there is no way to hold vendors responsible for their products and services.9 Those specifica-tions should include product functions, fea-tures, program specifications, listings of reports and query capabilities, and, most im-portantly, response times.
courts preclude defendants from hiding behind limitation provisions11 but limitation of liability clauses are usually upheld.
Arbitration versus LitigationMany software providers have recently put mandatory binding arbitration clauses into their contracts. This requires the two compa-nies to go before an arbitration panel consist-ing of three arbitrators. This is called alternative dispute resolution (ADR). The typical choice is the American Arbitration Association. The theo-ry is that arbitration is a cheaper and faster ven-ue for resolving disputes. However, many organizations leave the process feeling less than satisfied with the process and the resolu-tion. If an organization wants to be able to avail itself of the court system to resolve a potential dispute, then mandatory arbitration clauses must be avoided. Along with the venue of dis-pute goes the choice of law. A software compa-ny often wishes to impose the laws governing the software companys state instead of the laws of the organizations state. The issue arises regarding whether trial or arbitration proceeds in a software companys state. All of these are issues open to negotiation, and an organization should make every effort to try and tip the bal-ance in its favor; it should not be afraid to nego-tiate hard.
Payment IssuesPayment issues, like other contract terms, can in many cases be negotiated. Most ERP systems are licensed on a per-user basis for a term. Con-trary to popular belief, many ERP software companies provide flexible pricing, especially when they are prepared to execute contracts near the end of their fiscal year and they need revenue to meet investor expectations. This in-cludes even some of the largest software com-panies. Not only is the cost of the license negotiable, but so is the timing of the pay-ments. Because an organization should be wary of software vendors promising functions that are not part of the currently released ver-sion, it can negotiate payment terms that help guarantee that the required functions are pro-vided.
ecause an organization should be wary of software vendors promising functions that are not part of the currently released version, it can negotiate payment terms that help guarantee that the required functions are provided.
work when it goes live some months later. An organization should negotiate a payment plan that provides for a holdback percentage in case the software does not work properly. Just be-cause software works in prototype mode does not mean that it works properly when execut-ed under the stresses of a production environ-ment.
Who Owns Software Modifications?Under current law, although an organization paid for modifications, unless it specifies in the contract to the contrary, the software company owns the modified software. Under the work-for-hire concept, the author of the product owns the copyright to the work. An organiza-tion must specify otherwise in its contract if it hopes to own the code. Because in many cases an organization is modifying existing vendor software, the new program might well be con-sidered a derivative work under copyright law. Again, the parties should negotiate these is-sues.
sel for very good reason. They provide counsel to help avoid problems; and if an organization has a problem with the ERP system it has pur-chased, hopefully they can help get the organi-zation out of trouble. Let the buyer beware.
of Enterprise Solutions: The Directors Cut, Accenture, 2002.
4. See, e.g., USM Corp. v. Arthur D. Little Sys., Inc., 28 Mass. App. Ct. 108, 546 N.E.2d 888 (1990) (describing the importance of speed in a systems functionality).
5. In Who Says Elephants Cant Dance, Louis Gerstner discusses how he changed IBMs organization and culture to meet the needs and challenges of the new technology paradigm.
6. See, e.g., Chatlos Systems, Inc. v. National Cash Register Corp., 635 F.2d 1081 (3d Cir. 1980) (a software vendor is sued for failing to provide four of six promised functions).
7. See, e.g., Camas Colo. v. Bd. of County Commrs, 2001 Colo. App. LEXIS 667 (April 2001); Scott Co. v. MK-Ferguson Co., 832 P.2d 1000, 1002-03 (Colo. App. 1991).
8. See, e.g., L.S. Heath & Son, Inc. v. AT&T Information Systems, Inc., 9 F.3d 561 (7th Cir. 1993) (the defendant won summary judgment on lower court because the integration clause freed it from pre-contractual representations; on appeal, the integration clause was found to be insufficient); Sierra Diesel Injection Serv., Inc. v. Burroughs Corp., 890 F.2d 108 (9th Cir. 1989).
9. Hersch Co., Inc. v. Highline Village Assn, 30 P.3d 221 (Colo. 2001).
10. See Caudill Seed & Warehouse Co. v. Prophet 21 Inc., 123 F. Supp. 2d 826 (E.D. Pa. 2000) ([W]hen an exclusive remedy fails, a buyer may seek the entire range of remedies available under the UCC.); RRX Indus., Inc. v. Lab-Con, Inc., 772 F.2d 543 (9th Cir. 1985).
11. See, e.g., Shell Western E&P v. Dolores County B+d. of Commers, 948 P.2d 1002 (Colo. 1997).
Legal IssuesPitfalls of Integrated ContractsInclusion of Detailed SpecificationsLimitation of Liability ClausesArbitration versus LitigationPayment IssuesWho Owns Software Modifications?
Avoiding the pitfalls of family communication!

References: v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v.