Erp Implementation Lessons Learned

This article is also available on our website: PROACTION - Generating Best Practices. It is an excerpt of a paper originally written by George Miller, Founder of PROACTION. It has been modified and updated by Paul Deis, PROACTION CEO.

INTRODUCTION

This case study describes lessons learned from the ERP implementation at a leading metal container products company. It is a $200MM, 53-year-old company, headquartered in the USA, with facilities in multiple states and in Europe. It is a leading producer for the wholesale, retail, OEM and industrial markets. The company was in the midst of a successful turnaround during the project, which was initiated primarily to deal with the Y2K problem, as a new management team provided new direction.

During the project, the company was also transitioning to focus factory management, flow manufacturing, product rationalization and reorganizing business units, all this in the midst of a major facilities consolidation. In spite of all this, the project was probably in the top 10% of ERP efforts.

There was a constant personnel shortage and competition for mindshare. Due to inevitable time and resource constraints, the phase I implementation consisted only of replacing legacy systems and the most urgent partial reengineering of at-risk processes. The company was successful in transitioning to the improved system and initiating follow-on process reengineering. Currently (mid-1999), system implementation in other North American and European sites is underway.

The founders sold the firm to the present owners in 1996, who faced a number of challenges to bring the company up to their expectations:

• Need for more emphasis on quality
• Debt load to service initially inhibited capital appropriations
• Difficult facilities consolidation project
• Aging, obsolete and unresponsive business systems, with a Y2K problem
• Product development
• Competition

In that context, the company was attempting to modernize, rightsize and streamline for the future, but nearly lost the race with time. About six years ago, the company engaged a major consulting firm to study major improvement opportunities. One of the chief recommendations was to upgrade ERP systems, but due to many other priorities, the company only started moving on the recommendations in mid-1997, with a looming Y2K deadline. Therefore, schedule and implementation priorities were somewhat mandated by the situation.

The owners brought in new management in the summer of 1998 and they began building their new team of high quality professionals, including key valued members of the existing team. Fortunately, the former management had the presence of mind to initiate the ERP project and to staff it with mostly excellent people. The new management's major initial challenges and priorities involved dealing with a difficult plant consolidation, product shortages, customer issues, and that little Y2K ERP problem also.

The unresponsive business systems weren't solely attributable to ancient software. There were also data integrity problems in inventory, purchasing and production. Practices and procedures were in need of updating. Much training was needed. Existing systems tools were not even fully implemented. There were philosophical differences between the way the business was run and how the systems were designed to work, not an atypical situation in many companies.

THE ERP PROJECT

The company had a "legacy" system, consisting of Data 3 MRPII, HFA Order Entry/Accounts Receivable, S2K (Infinium) Financials and the old ADP Payroll system. These were all pretty good products in their time, but hadn't been kept up to date, although vendors did offer newer versions, but required customization made some impractical.

For a variety of reasons, beyond the scope of this paper, the company chose a very expensive but good set of platforms, including Oracle applications and systems software, Hyperion Pillar budgeting, ADP PC-based payroll, ADP HR systems, HP hardware and HP-UX operating system and other mass storage, networking and data warehousing products.

The company set up an implementation team consisting of an executive steering committee, project manager (from Engineering!), and project leaders from middle management and 10 "Superusers," mostly high potential administrative people, to become their departments' experts in the new system. In addition, there were a number of Oracle technical and applications consultants, as well as third party contract programmers, database administrators and business consultants.

There was a fair amount of personnel "churning," until the company got the right combination of Oracle and other outside consultants. Several internal team members fell by the wayside, principally due to operational workloads or people moving on. The team leaders were especially vulnerable to their heavy departmental workloads and some were not able to devote sufficient energy and time to the project success. To a significant extent, the Superusers, outside consultants and IT personnel picked up the slack.

Progress was relatively slow in the initial months, even requiring a rededication at one point. But the company and the team never gave up and ultimately progressed to a successful and fairly smooth implementation, but not without a struggle during the preparation.

SCOPE AND OBJECTIVES

A. Due to the aforementioned issues, project scope and objectives were limited to the following:

• Y2K compliance (actually the main de facto schedule and objectives driver)
• Timely, accurate financials
• Closed loop MRPII
• Strong IT infrastructure for future growth, flexibility, integration, stability and profitability

B. Not included, but desired:

• Business Process Reengineering
• Automated Data Collection/bar coding
• Freight/Warehouse system
• Flow Manufacturing
• Full ERP
• Supply Chain Planning

C. Applications addressed were:

• Financial: General Ledger, Accounts Payable, Accounts Receivable, and Financial Planning/Budgeting
• Manufacturing: Master Production Scheduling/Material Requirements Planning, Inventory, Work-in-Process, Capacity Requirements Planning, Engineering/Bill-of-Materials, Costing
• Order Management; Order Entry, Invoicing

Addressed separately: Forecasting (Smart Forecast), Payroll (ADP PC version), Human Resources (ADP), Aggregate Inventory Management (IQR System), Returns and Warrantee (homegrown), Quality (Homegrown and PC packages),
OADW (Oracle Applications Data Warehouse).

LESSONS LEARNED

The company learned some important lessons during this project, some relatively painless, some didn't come so easily. To save time, only the ones deemed most important are listed below.

Major executive involvement is crucial to success.

Executives control the staff, budget, punishments and rewards. In the cases where we failed to engage executives, results usually suffered. When engaged and informed, they usually improved the situation. Notable examples:

• When it became apparent that training was seriously deficient, several VP's and the CEO took decisive steps to alleviate the problem.
• When we noticed that contingency planning was potentially deficient, the CEO made it a personal crusade and insisted upon a plan before he would approve the implementation go-live date.

The Steering Committee was the principal tool employed for executive engagement. All of the executives whose departments were most affected were on the steering committee, along with the CEO, IT Mgr. (who was also the Project Manager) and an outside business consultant. As it inevitably happens in situations where busy people have multiple priorities, it was a chore to get everyone to show up at meetings, do critical reviews and make decisions. When it was successful, which it wasn't always, several people had to get together in advance to push an agenda and line up participation. Thankfully, the new CEO, once he got on board and saw how important this project was, proved invaluable with his support when it was most needed, although we had to carefully choose our battles.

BPR (Business Process Reengineering) should be done up front.

The company elected to put the system up first and reengineer later. This was primarily attributable to budget and schedule reasons. The downside is that the system, as implemented, tends to perpetuate the status quo, although certain improvements came about just from installing it. Some minimal reengineering was done where time permitted or where the old procedures were almost totally unworkable. Now, we're going back and working on the processes with the best improvement potential, but not as fast as we'd like.

Objectives/metrics/issues should drive the project.

Budget and schedule drove this project and it showed. Metrics were developed, but, key performance reports are still being brought on-line. In the instances where the objectives were stressed, improvements were made. Examples: the CEO and Finance stressed 1)- Pricing rationalization. Margin improvements and simplified order processing have already resulted. 2)- Inventory accuracy was stressed as a prerequisite to system performance- improvements are gradually occurring.

The team did do a good job making business issues drive the project, towards the end, as their expertise developed. One of the main benefits of the project was the training of a cadre of people prepared to run a formal business system. Now they're ready to do a great job on the next implementation!

Management is driving needed improvements and forcing the system to adapt. For example, they are addressing customer service and inventory issues effectively.

Effective training is needed at all levels.

The first priority of key project people is to be familiar with the overall principles of ERP and the applications in their specific areas, so that they can demonstrate the system and train others, as well as effectively determine implementation approach (with consulting help), priorities, etc. Next, IT people need to be ready to perform technical work and ongoing support. Project leaders/middle management need to understand the big picture and how their own areas will work and interface with other areas. Executives need to understand the big picture, what systems can and can't do and what are the priorities and tradeoffs.

Finally, end users need to be as comfortable as possible with their new tools BEFORE going live. It became apparent 2 ½ months before implementation that additional training was needed for effective utilization of the system. Management was quite serious about rectifying the situation. The Human Resources Dept. managed this effort. Standards of performance for each employee were developed. The employees, trainers, supervisors, managers, and ultimately, executives, were held accountable for employee competence. Formal knowledge assessments were conducted and remedial action taken. The vast majority of employees were ready on the "go live" day, and it showed in the results.

One notable shortcoming in training/resources: nobody—company personnel, Oracle or third party person—seemed to know the entire system well enough to provide the big picture. We had to spend an inordinate amount of time and money consulting with all kinds of people to get cross-functional, cross "module" answers. We still have more work required to fully develop such people. However, the company does have a couple of excellent "generic" business systems gurus available, which has proved invaluable. We recommend spending the time and money to beg, borrow, steal or develop cross-functional experts to know your business and applications systems.

Our Superusers and Project Leaders must have really been good, because a lot of them have already been promoted/moved on to better jobs. We have realized this and are working to develop a better ongoing training/successorship approach.

Any organization needs a comprehensive generic business systems education program to ensure that people are aware of the state of the art. An APICS trainer is providing overview education for the company. Some seminars are being attended on things like forecasting, JIT, etc. A wider-reaching program is still needed.

Thorough Conference Room Pilot, testing, simulation are needed, including stress testing
When all is said and done, the team must thoroughly exercise the system In order to know and assess its strengths, weaknesses and different ways they can solve problems with it, in order to iron out bugs, procedural weaknesses, needed organizational changes, documentation and training requirements. Realistic scenarios and data are needed.

The company got real serious about this a few months before implementation, beefing up the conference room pilot activities, making them a centerpiece of the effort. This paid off in building a good implementation model, testing it and helping in documentation and training efforts.

Two highly realistic stress tests exercised the system not long before the go-live date. Minor defects, which might have caused major problems, were quickly identified and corrected. Conversion programs were also tested again and again to avoid unpleasant "Day 1" surprises.

If You Insist on a "Big Bang" Implementation, then do it right

The author is not in favor of this implementation approach, of putting the whole new system on-line at once. But, it had been decided to go that way long before his arrival, so we all pitched in to minimize the risk. The most important things to accomplish for that were: thorough testing, testing, testing, exhaustive conference room piloting, sound technical execution, testing, training and a good contingency plan. Did I mention testing, also? The accountants were a little more conservative, bringing up the general ledger first and running in parallel three months earlier than everyone else.

• Strong technical, systems programming/DBA (Database Administration) capabilities are needed, at least for a system as complex and flexible as Oracle.
• There are numerous tables, parameters and security to set up and maintain software versions and patches to control, for various system and database "instances." A good DBA is also a consulting resource to IT, Users and management.

Conventional wisdom says that modern software packages take most of the technical risk out of an implementation. Conventional wisdom is incorrect. Unless we tackled technical issues head-on, such as system setup, multi-site definition, library/version control, conversion, etc., it would have meant trouble. Technical factors became a non-issue precisely because we did apply the resources to deal with them.

We relied heavily upon outside resources in the beginning and gradually tapered these off as we built the skills in-house. We need to continue to broaden the skills base to ensure that multiple in-house employees can handle critical technical tasks, a common aspiration in mid-sized Information Technology departments.

The company was successful in building an effective Oracle RDBMS/UNIX/Oracle Apps, technical capability, scaled appropriately for maintaining a "vanilla" version of the system. It took more people than we would have liked.

Ensure data accuracy

Formal ERP systems are very sensitive to data accuracy. We had to make big improvements prior to implementation. Even though our outside auditor "blessed" our overall numbers prior to implementation, these still did not meet our far more rigorous internal standards. We are only now approaching world class standards in most areas, but actually slipped in one area after a reorganization, spurring a rededication to data accuracy. In the future, we will conduct rigorous quarterly internal inventory accuracy audits and look at other areas as well. We are simultaneously trying to reduce dependency on formal data accuracy by moving to more visual control approaches and quick reaction systems.

Minimize software modifications

Everyone we knew in other companies making major changes to a software package ended up spending huge amounts of money and time and often had maintenance and operational problems. We learned from their experiences, made minimal changes and had minimal problems.

Control the scope

Although there were people who wanted us to do a lot more, most of us agree that scope control helped to get the job done cheaper and faster than it would have otherwise. It would have really stretched things out and jeopardized the results if our plate had been even more full than it was.

Have Contingency Plans

After seeing and hearing about others' past disasters, we developed a contingency plan for: what to do if the implementation failed; what to do when the system crashes- for an hour, a day, a week, longer? This was addressed. There is also an alternate backup site in place. We can always improve with an ongoing readiness audit.

Have a Go/No Go decision point

We did it and are glad we did. We waved off the implementation date twice, because we wanted additional preparation. By the third time, we knew what to look for, knew what we needed, and to some extent, even knew what it was we didn't know. We made a list of the outstanding issues that had to be resolved before we would "go live" with the implementation and worked them hard, as a team. A couple of months' delay is insignificant compared to years of pain from a failed implementation. Never implement until your people are confident and ready.

Other

A few additional hints—Don't put up the latest version of the vendor's software, no matter how they praise its virtues. Major ERP packages are never perfect—ESPECIALLY major new releases. Let others debug it for you, even if it means waiting a little longer for some bells and whistles. We took the conservative route and avoided much agony. Make sure you have key management reports in place before going live. We didn't have them all and paid the price. Make sure a critical mass is trained in report writing. We didn't, but when offering training the second time around, classes were "sold out" immediately. Don't scrimp on hardware resources. You'll get punished more for bad system performance than for spending too much on hardware. Once we eliminated a few bottlenecks in testing, performance became a non-issue. Establish specific systems performance objectives, get commitments to them in writing.

Reward contributors any way you can—with praise, training, coveted team assignments, promotions, etc. Your good people are your finest asset.

EPILOGUE

The new system went live on 4 January 1999 and we never looked back. There were only two serious problems.

• Bugs in order entry slowed us down. Better testing and documentation of results would have mitigated this problem.
• In addition, an administrative problem resulted in a number of blanket vendor purchase orders not being put on the system for weeks, screwing up purchasing and inventory records for the duration.

We had our first major system crash in March, 1999. Recovery procedures took nearly a day, but restoration resulted in zero lost data, using the task level recovery features of the system.

We have lost some key trained talent and are trying to improve our successorship and training management.

The reengineering effort seems to be more of a gradual, continuous improvement approach. It needs to move faster. This will take more emphasis and rededication. There are lots more things that we can do to improve. Other important projects seem to present even better opportunities at this time.

More importantly, "the vision thing" is back and sales and profits have been great. The system is working and helping to provide a firm foundation for the new century!