Quick Links

IBIS

Model Expert

Winshuttle

Avenue Portal

Web Monocle

Consulting

Training

Contact Us

Find us on:
Facebook Twitter Google+

Bookmark and Share

Keys to a Successful ERP Implementation

There are many different ways that an Enterprise Resource Planning (ERP) project can go wrong. ComputerPlus, Inc. has developed an inventory of prerequisite key components to ensure your ERP implementation project succeeds. In addition, implementation of a successful ERP needs to be delivered on-time and within budget.

This inventory of key components can also be applied to any type of large computer software project in a business environment. Each component is equally important; failing to follow even one can lead to delays, budget overruns, and even complete failure of a project.

1. Business Commitment
Many implementations fail because the top executives are not visibly supportive, or departments do not want to support the message that top executives are pushing because both they and the users are complacent and resistant to change.

All organizational levels of business, from top executives to end users, have to be supportive of the ERP system implementation. The message starts with the top executives stating their support of the project and their belief that this will move the company forward. Department managers need to emulate this message and make sure their departments believe it as well.

2. Timely Decision Making
The importance of timely decisions should never be underestimated. Time wasted is money wasted. If you take an example where you have twenty important decision steps to make on a project and each one takes one week to work out, you have already consumed five months worth of project time just on decision making. Efficient decisions result in faster implementations. Making prompt decisions are not just the responsibility of the project team, steering committee, or some other group involved in the project. Every member of the project team and, in many cases, the business users outside of the core team need to have degrees of involvement. Issues must be presented quickly and explained thoroughly, and supporting business data must be made available to help drive a decision.

3. User Involvement
Business commitment means that users need to have commitment to the project. User involvement means that users must have input and be a part of the project team. Too often in the past user input was overlooked and the project was left to IT to implement. This resulted in systems that were based on how things should theoretically work, not how the business actually operated.

It is essential to have the best available users involved, from all areas of the business affected by the project. Quite often these users are also highly valued by the business and they will be reluctant to give them up, so some negotiation may be required and it may not always be possible to get what the project team may consider the best user. Emphasizing the new skills and knowledge the user will deliver to their department will help.

User points to consider for the project team:

4. Management Involvement
In addition to their role as part of the business commitment, managers at all levels must also take an active part in the project. They need to stay informed of project status, help make key decisions and resolve conflicts, and take part in tollgates to approve requirements, design, testing, and final approval to start using the system.

5. Goals and Requirements Definition
If you do not approach a project with a clear idea of what is to be delivered, how can you determine if the project is a success? Projects without clearly defined goals and requirements will always be over budget and behind schedule.

The project should be started with a high-level definition of what is to be achieved. For example, are you trying to streamline the sales process, simplify your pricing calculations, ease your data maintenance burdens, and improve reporting? These goals can then be recorded so that they can be assessed at the end of the project. Defined goals should be measurable and clear-cut. For example, a goal of “improving the customer experience” cannot easily be measured and is also vague. A goal of “reducing the amount of time customers spend on each phone call” can easily be measured and clearly states the objective.

Once everyone has a clear understanding of the goals, the requirements can be accurately recorded.

Goal requirements should primarily fulfill the needs of the business, but also fulfill the system goals. If a requirement is not critical, it does not fulfill the system goals, and it is not in current business use, it should almost certainly be discarded.

6. Change Process
No matter how carefully the system requirements are defined, there will be times when changes are necessary. Change can come about for many reasons, including overlooking a requirement, misunderstanding of a requirements intent, or simply a change in the business environment. When changes are required, it is important to have a clearly defined process for dealing with them. A change needs to be requested, reviewed, and either approved or denied, all in a short time.

There are several things that should be decided long before the change process is required:

Typically the steering team will review these requests. Decisions to approve or deny a request are based on the information provided in the request along with any additional critical information. A common practice is to place all denied requests that merit future implementation into a lockbox that will be developed as part of a subsequent project.

7. Measurability of Progress
While it is important to measure your results against the expectations, it is also important to measure your progress. Are tasks ahead of schedule, on schedule, or do steps need to be taken to catch up?

No method of measuring progress is going to be perfect. You can have task leads update the time remaining for each of their tasks on a weekly basis. You can calculate the time remaining based on listing the number of subtasks and calculating the number complete versus the total number of tasks. There are many different ways you could choose to estimate the remaining time, but no matter what method you choose, the important point is not that you should have a perfect representation of how many hours are left, but that the estimate of time remaining should be approximately correct.

Another key point is to limit the burden on the project team. For example, if project team members need to spend five hours a week determining the remaining time for their tasks, then you are adding an extra week on to the project for every eight weeks of project working time.

8. Data
With everything else going on, data conversion often does not get the attention it deserves. Often this by itself can cause delays in even the best implementations. Business organizations can struggle to deal with correcting data and converting to a new format, and often adding new pieces of information that did not previously exist or were not mandatory in the legacy system.

Data conversion needs to be tracked just like any other project task. It should have requirements, milestones, deliverables, and tollgates. Data must be clean by the time you start integration testing, or users may simply manipulate the data to make their tests work in the belief that it is the data that is wrong, not the design.

9. Business Process Redesign
Implementing a new ERP system should not require you to completely redesign the way your company does business, but neither should you be insistent upon using all the same business processes you do now. Often these processes were designed to work with your legacy system and implementing a new system may involve simple changes or outright redesign of some of your business processes.

People are naturally resistant to change because this takes us out of our comfort zone. Despite this, it is always best to question each and every process rather than blindly mapping processes into the new system.

10. Testing
A common method of catching up on projects that are behind schedule is to reduce testing time. While this may allow you to implement your system a little bit faster, it also may cause unwanted disruptions in your business due to improperly tested functionality. While it may take longer to do the proper testing up front, in the long run it will usually save you both time and money. Performing proper testing not only means ensuring that testing time is not cut, it also means that all testing phases are performed adequately and that none of these phases are completed until the testing objectives have been met.

Bookmark and Share