Four Ways to Botch Your ERP Implementation Process

  • Written By:
  • Published:


Originally published – February 13th, 2008

In the process of implementing an enterprise application suite like enterprise resource planning (ERP) or enterprise asset management (EAM), an almost infinite number of things can go wrong. A successful implementation depends not only on selection of the correct application, but on the quality of the communication between you and your application vendor or implementation consultant.

Some of the more disastrous ERP implementations that you read about in the news—the ones that public companies blame for their poor financial performance, going well over budget, and taking years to complete—might be blamed on the complexity of the product being implemented or the perceived unresponsiveness of the implementation consultants.

But the success of the implementation often depends on the customer organization and the project management ability of its implementation team. Those on the receiving end of an implementation are in a very challenging position because in many cases, none of the team members have been through an implementation before. Ostensibly, the team representing an application vendor or implementation consultant should be experienced and professional, but miscues on its part are not unheard of either.

In white papers, there is no shortage of advice about what best practices can lead to success. But equally important is a thorough understanding of the worst practices to be avoided during an implementation. Problems during implementation are never deliberate. Following is a review of four practices that should be avoided, unless an organization wants to go out of its way to cause its implementation to tank.

1. Underestimate the strategic importance of the implementation process.

This is a very broad topic, but failure to understand the various ways an enterprise application implementation is strategically critical to your business can cause a number of problems. But perhaps the most common result of this cognitive failure is reflected in the type of people a company assigns to an implementation team, and the problems that naturally ensue.

Some companies are understandably reluctantt to devote their most valuable human assets to a months-long implementation process, and instead, assign more junior people to the team. This tends to create problems of vision, as younger, less experienced employees of a company, or those in staff-level positions, tend to have an excellent grasp of their own jobs, but a lack of understanding when it comes to the company’s strategic goals or company operations as a whole. These employees may be more likely than their more experienced peers to be interested only in making their own jobs easier, perhaps even at the expense of others in the organization, and skew project resources accordingly.

Another common error is to heavily load the team with C-level executives. These senior players have an excellent grasp of where the company is today and where it needs to go tomorrow, so their buy-in is vital to the project. However, senior executives often lack an understanding of the specific processes and activities that are used within the company. A hands-off manager will be at a loss when it comes to discussing precisely how things are done within the company today, and how, on a granular level, it is reasonable and desirable for business processes to be executed in the new software.

So who belongs on the implementation team? Choose middle managers who are key users of the software and who have extensive knowledge of both company strategy and detailed processes. They must be empowered to make decisions regarding the implementation, necessitating C-level buy-in and support, as they will be responsible for determining how the application is used and dictating the business’s process flows for a long time.

Another way that failure to appreciate the strategic importance of the implementation manifests itself is to assign what might be the right team, but to then give them no time to work on the implementation. Once the members of the team are chosen, it is vital to make sure their regular jobs are backfilled so they have time to concentrate on the implementation. In too many circumstances, I have seen situations where someone is assigned to an implementation team but is told he or she still needs to do his or her job, and has to implement this ERP package on the side. This is not a viable situation, as the implementation will be starved for resources. It will either grind to a halt, or it will be forced to move ahead with inadequate information, resulting in multiple problems at the go-live stage.

2. Bite off more than you can chew.

There are two ways to try to do too much too fast with an ERP implementation. One is to try to implement too much with regard to geography or sites all at one time. Some ERP vendors and implementation providers advocate the “big bang” approach, encouraging companies with multiple locations to take their entire organization live all at once. But often, this proves to be too much for an organization to handle.

In many cases, it is better to implement an enterprise application at one or two sites at a time. This allows a company and its implementation consultants to work kinks out of the business models and process flows that were decided upon by the implementation team.

Another way to bite off more than you can chew is to make too many dramatic changes in your organizational culture, all in one fell swoop. When you buy packaged software, you are not only buying technology—you are buying a way of doing business that can improve the efficiency of your organization.

In many cases, elements of an application’s functionality may represent business practices that you currently do not engage in, either because they have not been a part of your corporate culture, or because they are not supported by your legacy system. These process improvements and best practices are likely good opportunities to move your business forward, but trying to implement all of this functionality at the same time may prove to be too much for a business’s management structure and employee base to absorb. Consider that vitamin C is a very good thing to ingest, but taking too much of it at one time can upset your stomach!

In order to avoid disruption that can result from change that comes too quickly, it often makes sense to take a more gradual approach. At the initial implementation, reach out to your functional leaders to see whether or not adding various elements of new functionality creates too great a burden. Sometimes it’s better to go live with functionality you currently have in your legacy system, and to schedule add-ons later, when you are genuinely ready for them after an initial stabilization period.

3. Replicate your legacy system on the new software.

While trying to change too quickly is one way to hobble your enterprise application implementation process, trying to avoid change altogether can be just as damaging.

Some people just don’t like change, and the idea of abandoning the way they have done things in the past upsets them. These people, if they are part of an implementation team, come into the project with their own paradigms and their own ideas of how things should work, which are often based on the old system. Oftentimes, it does make sense to go live first on just enough functionality to replace the legacy system, but resistance to change of this nature can bring an implementation to a halt.

A fervent desire to replicate an existing environment can be very granular, and team members may even have a specific idea of what screens they should see, what reports they should get, and what buttons they should click. People who are reluctant to move away from their legacy system focus on the functions of the software rather than on the business requirements behind those functions, and they often request numerous modifications to the new environment, which cause cost to spiral without real business benefit.

It is important for an implementation consultant to understand the current processes and how the legacy system is being used. That is why a consultant will ask not only what processes are currently being followed, but what the underlying reasons are for each of these processes. Sometimes these questions are asked to make sure that each process is necessary, but this line of questioning can also determine the business need that process is fulfilling.

An implementation consultant or applications vendor should understand that anything the customer does in its current process is likely for a good reason, and it is the consultant’s or vendor’s job to find what that reason is, and then to find the best way to satisfy that underlying need in the new software. The goal should not be to replicate the way things are done in the legacy system. Indeed, most times, an implementation may bring a slightly different process flow, different screens, and different reports. People assigned to a company’s implementation team have to be able to think outside the box and realize that their business requirements are being met even if the screens and buttons are not exactly the same.

There is a relationship between the ability to successfully navigate this process and the degree to which the right people were assigned to be a part of the implementation team. It is crucial that the implementation team be able to look beyond the superficial elements of the legacy system, and see past the screens and reports to which they have become accustomed. They need to envision how the new application will be made to meet their underlying business requirements.

Implementation team members must be comfortable opting for a slightly different approach or a slightly different process in order to meet the strategic goals a new enterprise application is meant to achieve. In some cases, team members should even be empowered and unafraid to suggest organizational changes outside the application that will better accommodate a new process flow and make for a smoother implementation. Perhaps certain departments should be merged, or people who had worked on opposite sides of a building should be moved closer together to better facilitate the new way things are to be done. With too great an attachment to the past, it is hard to realize a more productive and streamlined future.

4. Reinvent the wheel.

A fourth and final way to foul up an enterprise applications implementation process is to reinvent the wheel by disregarding established implementation methods. Regardless of the implementation provider or the enterprise software product you choose, your implementation team will come in with an implementation method consisting of specific steps to go through in order to ensure success. This implementation method is proven, and has been developed over long experience at dozens, hundreds, or even thousands of companies.

Implementation consultants and application vendors follow this method because it suits their approach and the software in question. While methods of different implementation providers may vary, a viable method will generally include four distinct steps:

  • Mapping
    At this stage of the project, a consultant will identify the business processes you will implement, and determine how, at a business process level, they will be handled by the software. IFS, for instance, uses its own IFS Business Modeler software for documentation of all process levels, automating the process of finding functional gaps and working them through to a solution.
  • Implementation-Definition
    During the implementation-definition phase, the consultant and implementation team will take the process maps and work through the details. There might be several rounds of work routine documentation, modeling data migration to make sure processes are well documented and that they will work.
  • Testing
    During the testing phase, the consultant and implementation team will tie all of the processes together and test them to make sure they will work. One way to do this is to run several days of the company’s transactions through the system, end to end, in a controlled business simulation environment.
  • Rollout
    After mapping, implementation-definition, and testing are completed, it is time to roll the application out to users in the organization. This step involves training the users and ensuring that the IT infrastructure is in place to run the application prior to going live.
  • All of these steps are absolutely necessary. But sometimes, in a budget crunch or on a tight timeline, there is the temptation to cut out some testing or some mapping. Even if you are not trying to reinvent the wheel in its entirety, it is not advisable to simply remove a few spokes to see how it holds up under load! Skimping on any of these steps comes with a degree of risk that needs to be recognized. Straying from the established implementation method creates the opportunity for things to go wrong at a critical time—during go-live week or after go live, as poor preparation comes home to roost. Typically, problems that result from diverging from proven methods cost more to fix than a more thorough and systematic implementation would have cost to begin with.

    About the Author

    Jeff Kugler is a solutions consultant with the Milwaukee, Wisconsin (US) office of IFS North America. Before entering the software industry, Kugler worked in manufacturing and operations. He has managed implementations both as a customer and as a consultant, and is active in lean manufacturing advocacy both inside and outside of IFS. He holds a BA in computer science from Lakeland College in Sheboygan, Wisconsin.

    For more information and to start your own custom solution comparison, please visit TEC’s Discrete Enterprise Resource Planning Evaluation Center.

comments powered by Disqus