Lessons on ERP testing and scheduling
By Jonathan Gross
By Jonathan Gross
Imagine waking up one day to find out that your company’s supply chain has grinded to a halt, making it impossible to fulfill $100 million worth of orders. This is what happened to Hershey’s confectionary manufacturing and distribution operations in 1999.
When it cutover to its $112-million IT systems, Hershey’s worst-case scenarios became reality. Business process and systems issues caused operational paralysis, leading to a 19-percent drop in quarterly profits and an eight-percent decline in stock price. In the analysis that follows, I use the Hershey’s case to offer advice on how effective ERP system testing and scheduling can mitigate a company’s exposure to failure risks and related damages.
Here are the relevant facts: In 1996, Hershey’s set out to upgrade its patchwork of legacy IT systems into an integrated ERP environment. It chose SAP’s R/3 ERP software, Manugistic’s supply chain management (SCM) software and Seibel’s customer relationship management (CRM) software. Despite a recommended implementation time of 48 months, Hershey’s demanded a 30-month turnaround so that it could roll out the systems before Y2K. Based on these scheduling demands, cutover was planned for July of 1999. This go-live scheduling coincided with Hershey’s busiest periods – the time during which it would receive the bulk of its Halloween and Christmas orders. To meet the aggressive scheduling demands, Hershey’s implementation team had to cut corners on critical systems testing phases. When the systems went live in July of 1999, unforeseen issues prevented orders from flowing through the systems. As a result, Hershey’s was incapable of processing $100 million worth of Kiss and Jolly Rancher orders, even though it had most of the inventory in stock.
This is not one of those "hindsight is 20-20" cases. A reasonably prudent implementer in Hershey’s position would never have permitted cutover under those circumstances. The risks of failure and exposure to damages were simply too great. Unfortunately, too few companies have learned from Hershey’s mistakes. For our firm, it feels like Groundhog Day every time we are retained to rescue a failed or failing ERP project. In an effort to help companies implement ERP correctly – the first time – I have decided to rehash this old Hershey’s case. The two key lessons I describe below relate to systems testing and project scheduling.
Hershey’s implementation team made the cardinal mistake of sacrificing systems testing for the sake of expediency. As a result, critical data, process and systems integration issues may have remained undetected until it was too late.
Testing phases are safety nets that should never be compromised. If testing sets back the launch date, so be it. The potential consequences of skimping on testing outweigh the benefits of keeping to a predetermined schedule. In terms of appropriate testing, our firm advocates a methodical process that increasingly simulates realistic operating conditions. The more realistic the testing scenarios, the more likely it is that critical issues will be discovered before cutover.
For our clients, we generally perform three distinct rounds of testing, each building to a more realistic simulation of the client’s operating environment. Successful test completion is a prerequisite to moving onto to the next testing phase. In the first testing phase – the Conference Room Pilot Phase – the key users test the most frequently used business scenarios, one functional department at a time. The purpose of this phase is to validate the key business processes in the ERP system. In the second testing phase – the Departmental Pilot Phase – a new team of users tests the ERP system under incrementally more realistic conditions. This testing phase consists of full piloting, which includes testing of the most frequently used and the least frequently used business scenarios. This testing is also conducted on a department-by-department basis. The third and final testing phase – the Integrated Pilot Phase – is the most realistic of the tests. In this "day-in-the-life" piloting phase, the users test the system to make sure that all of the various modules work together as intended.
With respect to the Hershey’s case, many authors have criticized the company’s decision to roll out all three systems concurrently, using a "big bang" implementation approach. In my view, Hershey’s implementation would have failed regardless of the approach. Failure was rooted in shortcuts relating to systems testing, data migration and/or training, and not in the implementation approach. Had Hershey’s put the systems through appropriate testing, it could have mitigated a significant failure risk.
Hershey’s project timing decisions are textbook examples of how not to schedule ERP projects. The first lesson: do not force an ERP implementation project into an unreasonable timeline. Over-squeezing implementation schedules is a sure-fire way to overlook critical issues.
The second lesson: never schedule cutover during busy seasons. Even in a best-case implementation scenario, companies should still expect steep learning curves and operational performance dips. By timing cutover during slow business periods, the company gives itself more slack time to iron out systems kinks. It also gives employees more time to learn the new business processes and systems. In many cases, it is even advisable to reduce orders in and around the cutover period. This tactic is aimed at minimizing exposure to damages caused by potentially undetected errors and less-than-perfectly-trained users.
In closing, any company implementing or planning to implement ERP can take away valuable lessons from the Hershey’s case. Two of the most important lessons are: test the business processes and systems using a methodology designed to simulate realistic operating scenarios; and pay close attention to ERP scheduling. By following these bits of advice, your company will lessen its exposure to ERP implementation failure risks and related damages.
Jonathan Gross is vice-president of Pemeco, Inc., a consulting firm specializing in ERP implementation. He can be reached at firstname.lastname@example.org.