Keys to a Successful Enterprise Resource Planning (ERP) Systems Implementation — Are you installing a new ERP system? Read our top ten (well, actually eleven) keys to a successful Enterprise Resource Planning Implementation project.


1.    Establish Clear Business Objectives.

A large-scale systems implementation affects the entire business.  It is a very expensive undertaking that should ultimately pay off with reduced costs, new capabilities to meet market requirements and / or the creation of new revenue opportunities.  But this usually occurs with considerable business disruption – most people don’t react well to change.

A successful implementation will minimize business disruption.  This is accomplished when every manager understands the goals of this new system and understands his responsibility to meet these goals. This can only occur with clear measurable and achievable business objectives that are established at the start of the project.

Large-scale projects that are linked to technical objectives – (for example, replacement of an old system with a new one because the vendor went out of business) typically are troubled if middle management does not truly see the benefit of the new system.

2.    Gain the Commitment of Senior Management.

A project that changes the entire culture of a business cannot succeed without the 100% backing of senior management.  Middle management and supervisors are most affected by a new system – therefore their buy in to the new system is critical.  But they don’t buy in if they do not feel that senior management is solidly behind the project.  Projects of this sort extend over a long period of time.  Commitment from senior management must be visible and continual.

3.    Staff Properly

Large projects need dedicated personnel with the appropriate skill sets.  The people on the project team must be relieved of their regular day to day duties.

A common mistake is to expect programmers to do the work of system or business analysts.  That’s like having your carpenter design a skyscraper.

4.    Don’t Underestimate the Data Conversion Effort

ERP projects are often replacing aged systems.  Part of the systems replacement justification is to improve the quality and integrity of the data.  Data conversion is divided into two parts: current (open orders, receivables, payables, etc.) and historical data.  Data in the older system must be mapped to the new system.  This takes planning, software development and often cleanup of inconsistent data.

This part of the project is very often ignored in project planning or the complexity of the effort is grossly underestimated.

5.    Provide Proper Tools for the Project Team

Don’t forget the little things to make a project team work effectively.  A proper work environment, telephones, voice mail, email will allow the team to communicate well and be productive.  But don’t treat the project team significantly differently than the rest of the employees – or there will be a “we” vs. “them” in the company.

6.    Communicate.  And then Communicate Again

Generate excitement.  Tell people what is happening and when it is happening.  And then tell them again.

If the project runs into problems, let people know what the problem is and what actions are being taken to get back on track.  The worst thing for an organization is to have rumors running the project.

7.    Start at the Top

Focus on the top of the information chain first – the financial data.  This data pervades every activity of the enterprise.  Assuming a new General Ledger and Financial Reporting system is part of the project, a new chart of accounts should be one of the first activities to be addressed.

8.    Big Bang? Or the Modular Approach?

An ERP implementation is usually comprised of several integrated modules.  A major decision to be made very early is how these modules are going to be implemented, one at a time, in a few groups or all at once – “Big Bang”.

The Big Bang approach has the advantage of reducing the number of interfaces that have to be written to existing systems.  But it comes at a high cost and significantly increases project risk.  When multiple modules are implemented all at once, there is simply more opportunity for things to go wrong.  It takes thorough planning and testing.  More resources are required, therefore more sophisticated project management is also required.

If the project can be separated into a modular approach without seriously affecting the rollout schedule, give it high consideration.

9.    Don’t Delay Critical Reporting

Many projects bump up against deadlines.  As they do, projects tasks are prioritized and some are determined to be unnecessary for day 1.  Frequently, the delayed task is a report – the common logic is: “It’s a monthly report.  We can get it done during the first month.”

Don’t fall into this trap.  Other problems always occur during the first month of operation, and then the key reports are put off further.  Now you have a real problem.

If critical reports or other key project components are not ready, delay the implementation.

10. Train – then Train Again

Training is one of the critical components of the implementation.  Get key users involved early.  Establish a train the trainer program.  Spend a little extra on a good technical writer and / or professional trainer.  The dividends are tremendous.

Standardized training offered by the software vendor may not be enough.  The software vendor’s training focuses on mechanics.  The more important training is related to the process changes that have occurred as a result of the new software.

Do training of users shortly before the implementation.  Establish post-implementation training sessions as well.  This will reinforce the training – and also highlight problem areas early.

11. Test – Then Test Again

Don’t assume that your vendor has tested the software, therefore you don’t have to.  You must make sure that the software supports all the types of transactions you process.  Testing is time consuming and requires a clear understanding of all the business processes.  Testing scenarios should be written and exercised with a clear test plan.  You must make sure that not only does the software function, but is it doing what you want it to do.


This entry was posted in IT Strategy/Planning. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s