Failure of Enterprise Resource Planning(ERP) Implementation

Failure of ERP Implementation:

1. Doing it in the first place.

Even before implementation the company is dilemma whether they really require it or not. Often large ERP implementation projects fail before they even start. Companies unhappy with their current system become convinced their reporting, integration, or efficiency problems lie in the software they are using. Convinced the grass is greener on the other side of the fence, they embark on a large, risky, and expensive ERP replacement project, when a simple tune-up of their current system, or a small add-on application, such as a better reporting system or employee portal, would address the problem at a fraction of the cost. Even a reimplementation of the same software is usually less costly than switching to another software vendor.

2. No clear destination.

To be clear with the expectations. Once an organization makes the decision to implement a new ERP system, the first step is to have a clear definition of success. Often, lack of consensus on the problems being solved, the outcome desired, or the specific financial justification of the project, leads to challenges later controlling the scope and maintaining executive sponsorship. Having a clear destination means defining the important business processes, financial benefits, and deadlines up front and making certain stakeholders agree how to address them. Without a strong definition of success, the end point becomes a moving target.

3. A good plan or just a plan?

A detailed plan is very necessary for successful implementation. All projects of this size start with some kind of plan. However, more times than not, the plan are not realistic, detailed, or specific enough. Companies build a high-level plan with broad assumptions or underestimate the amount of business change involved. Despite how obvious this sounds, it remains the most common mistake companies make. To be a good plan, it needs to identify all the requirements and the people who are going to work on them. It needs to be at a level of detail where a knowledgeable person can visualize the work, usually in work blocks of a few days. It needs to have a logical sequence of tasks, like leaving time in the schedule to fix bugs found in test cycles. Until you have a good plan, you really do not know when the project will end or how much it will cost.

4. Part-time project management.

A person experienced in project management makes lot of difference. There is some debate whether project management is a skill all good managers should have or whether the field will eventually develop into its own professional discipline, just like there are registered engineers, nurses, and lawyers. Putting that debate aside, it is clear software projects of this size need their own dedicated, experienced project managers. Asking the executive sponsor or the business owner to also manage the project as a part-time adjunct to their main role means neither job will be done well. Not just a scorekeeper, the project manager needs to be an active leader pushing for accountability, transparency, and decisiveness.

5. Under-estimating resources required.

Most common blunder to happen is with resources projected. Having a solid understanding of the internal and external resources needed to complete the project is critical. For internal resources, understanding the time commitment needed from business users, typically in the Finance, Accounting, or Human Resources departments, is one of the most commonly underestimated areas. During critical phases of the project, it is often necessary to backfill the majority of transactional employees by bringing in temporary resources. This frees up the users of the new system so they have time for implementation and training. For external resources, having an agreement up-front with your consultants and contractors about the specific duration, skills, and quantity of resources needed is critical.

6. Over-reliance on the consultants.

Too much dependability on consultant can make the team more redundant. Most ERP implementation projects involve consultants, for the expertise, best-practices, and additional resources they bring. While their outside experience is definitely helpful for a project, there is a risk that the company can become over-reliant on the consultants. The company needs to maintain control over the key business decisions, hold the consultants accountable, and have an explicit plan to transfer the knowledge from the consultants to the internal employees when the project is winding down.

7. Customization.

This aspect makes it or breaks it for an ERP tool. Most companies these days understand that customizing their ERP system adds risk, time, and cost to the project. In fact, customizations, along with interfaces and data conversion, are the main areas of technical risk in ERP implementations. Perhaps more surprising is that in a recent survey, less than 20% of respondents implemented their ERP system with little or no customization. Despite the risk and expense of customizations, most companies find it enormously difficult to control the project scope by turning down customizations. Customizations always start out small, but incrementally grow to become the technical challenges that derail these projects. Few ERP implementations have zero customizations, but take a very firm line on justifying even the smallest ones and manage them tightly.

8. On the job training.

Experience makes a lot of difference. The typical lifespan an ERP system within an organization is 10 to 12 years. With that in mind, most employees in a company have been through one or two ERP implementations in their career. Just as you would not be comfortable with a surgeon as their first or second patient, the leaders of your ERP project, both internal and external, need to have experience implementing your specific chosen system several times. This is one of the major benefits to working closely with an outside consultant or directly with the software vendor.

9. Insufficient testing.

It should be treated as rectifying stage. When schedules get tight, reducing the number and depth of test cycles is one of the first areas that often get cut. The purpose of testing in an ERP project is not to see if the software works. The purpose is to see if the system meets your business needs and produces the output you need. Reducing testing may not leave defects undiscovered, but it certainly increases the risk the ERP system will be missing important functions or not be well accepted by end users.

10. Not enough user training.

The management shouldn’t hurry to start using the tool without adequate training to users. Today’s modern ERP systems are being used by more and more personnel within a company.

Beyond the Finance and Accounting departments, modern systems also cover procurement, supply chain functions, compliance, customer relationships, sales, and much more. If the system includes human resources or expense reporting, then essentially all employees use the system. Training hundreds or thousands of users, to the right depth, at just the right time, is no easy task. Leaving training to a small phase at the end of the project makes it very difficult for users to get the training they need to understand the system and have a positive first impression at the rollout.

If ERP systems are the nervous system of a company, then doing an ERP implementation is like brain surgery: only to be attempted if there is a really good reason and not to soon be repeated. Unfortunately, ERP implementation projects often fall victim to some of the same problems of any large, complex project.