Implementing ERP systems What to do and what to avoid

Enterprise Resources Planning (ERP) Implementation

This article, aimed at ERP implementations / Enterprise Resource Planning systems implementation, describes the do's and don'ts of selecting, implementing and operating computer software systems in general but specifically E.R.P. type systems. The article highlights project management, business, and IT issues. It has been reproduced (Entitled "After the Millennium bug has been Eliminated") by the Institute of Operations Management in its original form in their magazine "Control".

Links to other best practices and training at bottom of page.

The replacement of an old system with a new system has it's own special problems. When you originally implemented your first stock control, accounting system or MRP system, the original process was manual, and was replaced with a computer system. It had limited connections to other parts of the business, such as purchasing or design. Nowadays you are replacing a computer-based process with a computer-based process. In theory that should be easier. Then why do so many companies getting into difficulties?

There are always pressures on implementation deadlines and shortcuts, not all of which are feasible or desirable. I have now been involved in a number of situations where, not only have the original lessons been forgotten, but also new lessons have been hard learned. Although this is not intended to be a comprehensive checklist here are some of the most common issues I have encountered:

The Forgotten Lessons

Project Management

The project needs an executive champion. It is not an IT project.
The project needs managing with proper ownership of tasks, planning and control.
Not all data is dynamic but some is. In a staged implementation process this needs to be taken into account.
Parallel running the new and old system with dynamic data is extremely difficult.
Parallel running reveals as many problems in the old system as in the new system.
Software problems are a useful excuse for project delays, but they are rarely on the critical path of delivering business benefit.

Business Issues

Identify the data owners. (See "Previous Best Practice of the Week 001: Ownership"). Operational responsibilities for the data including executive ownership need to be defined and agreed.
Computer salesmen do not provide solutions. You do!
Software suppliers (and their agents) do not necessarily know anything about business in general, or your business in particular. They are not generally good, best practice, practitioners.
Work is redistributed as a result of implementation.
Design the process taking advantage of the software. (See Organisational Redesign)
You need to change the way you work, not change the software to do it the old way. The new system is not a carbon copy of the old system and you should assume that you will need to change not perpetuate the old malpractices.
GIGO (Garbage In Garbage Out). Parameters need to be maintained, with procedures defined and agreed.
Set up measures for the data accuracy and control it.
Educate the people not just how to use the software but also in best practice techniques, so that they understand the implications of their actions.
Run a conference room pilot to simulate the running of your business, before you go live. This needs the creation of a test script, which deals with all the routine and abnormal things that you need the computer system to handle. The running of the script must involve the stakeholders.
Set up disaster recovery procedures. (See "25 questions to ask your IT specialist") You need a way of operating the factory or warehouse for a short while if the system is down. This is not an IT contingency plan alone. It could be any risk to the operation, and it does not mean spare computers, it means, for example, being able to ship without a computer system.
You did not design your original business process. You implemented the software. In some cases you superimposed the new computer system on top of the old manual system, so you increased the workload and manning, and you still could not keep the data correct.
Complex computer functions (particularly modelling) require skilled operators and continuity of skilled operators.
Skilled computer technicians do not necessarily know anything about running businesses and are not necessarily good, best practice, practitioners.
Complex software has lots of bells and whistles that need to be "configured". Configuring wrongly has dire implications!
Comprehensiveness (complexity) hides problems, lays mantraps, and requires management.
Businesses are uncertain places, not lending themselves naturally to mathematical techniques. (See "Previous Best Practices of the Week 009: Visibility of problems through simple and clear processes")

IT issues requiring business management attention

Software modifications shorten the life of the software.
There needs to be a method of running the reports and housekeeping and still provide an on-line service especially in the evenings and weekends.
All software has bugs (some more than others, and some more serious than others).
Many software packages do not discriminate between read and write responsibilities. I may allow many people to look at a selling price, but I will not allow many to update it!
In the event of a serious system failure or corruption, there needs to be the facility to recreate the transactions from the last backup, even if you have "RAID", or other forms of "mirroring".
The worst kind of problem is a faulty recovery from a system problem.
Programme and configuration change management is a significant, necessary, but unpopular process where the IT guys are seen to be holding up the implementation because they want to do things such as testing, version control, configuration management, documentation etc.
You need a test system for programmers use to test programs, new releases, bug fixes etc. with it's own set of programmes and databases. You need a training system with identical programmes and parameters to the production system (except when retraining after changes) but separate databases for users to use which is set up to run the conference room pilot and can be re-run at will. There needs to be sufficient computer resources to routinely operate these three environments, and a change management process to move from one stage to the next.
You need a totally secure computer live, production environment including prevention of unauthorised access (accidental or deliberate), virus protection, fire, theft, malicious actions of current or former employees, collusion in fraudulent activity etc.

The New Lessons

Project Management

The same rules above still apply.
Parallel running is not an option, when replacing an on-line system.

Business Issues

Your business has changed since you designed the original system. The original system was aimed at a highly functional organisation where the words "best practice" were not words on anyone's lips. The current business has a totally different product set, with different customer and supplier profiles, different organisation, (hopefully process focused). The business priorities have certainly changed with simplification in some areas and sophistication (complexity) in others. You need to redesign your processes. (See "Organisational Redesign".)
Also because the new software is different you cannot map your old processes, data, parameters, code structures, and transactions directly onto the new software. Quite often there is a completely different hierarchy of data with different prerequisites. The business processes need migration as well as the data, parameters, and code structures. Then the new business transactions can be "mapped" onto the new software.
Your original software did not reflect subsequently revised best practice. Using the old software as a checklist to buy new software misses the opportunity to exploit the new thinking using new functions.
Not all software available incorporates perceived current best practice, in fact some of it hardly any. (See "What control Systems do I need".)
Perceived best practice has changed since you designed your original system, making some of the original software functionality provided, obsolete or inadequate. It should not be replicated in the new software.
Archive the old data. Do not migrate it. Now it is easy to migrate the data using computer programmes, but do you really need all those old data for those obsolete products, based on that plant which was sold 3 years ago?
Policies, procedures, and facilities for archive and retrieval of data are essential.
The new software is different. Because it is a package it will satisfy a different but hopefully larger sub-set of the complete requirements (if you have done your software selection correctly). Do not assume all your old program changes are still necessary, the new software may simply do it a different way.
The dirty data tolerated by the new system is different and the new system may be tolerant or intolerant to different data from the old system.
The well-established technical support infrastructure you used to enjoy and undervalue ("we never had these problems with the old system"), does not exist any more and has to be re-invented.
The people still need education as well as software training. This is a great opportunity to do that, but why did you wait until now? Ideally education should be part of the induction programme for new employees or part of the change management process for system changes. It can also act as a catalyst for change in a workshop style session. One operations director said to me that he aimed to repeat education at two-year intervals to simply remind people what they were supposed to be trying to achieve.
The conference room pilot is even more important, and change-management using an updated conference room pilot scenario essential. It must also be used in testing configuration changes. The conference room pilot must also check the validity of the migration path and especially the migration programmes.

IT issues requiring business management attention

There is even more software around now from which to choose.
Some of it is even more dysfunctional, lacking in vital functions and less efficient to use than the old software. One I was using recently contained all of these faults.
It is more comprehensive (complex) than the old software.
The IT guys have to learn the new software as well as a new technical environment, at a time when implementation pressures preclude proper training.
Data migration computer programmes cause more problems than they solve.
So-called technical advances are in fact limited, non-existent or retrograde from a user point of view. Examples of this are:
- I have seen new systems where "forward recovery" from last night's backup means re-inputting all the day's transactions,
- I have seen systems where "dynamic transaction back-out" (which avoids database corruption in the event of a power cut, or transaction failure), means throwing away the current database and starting again.

I am old enough to remember that these were never allowed to become a business problem because technical facilities existed to avoid the problem. Also:

"Client / server" and "GUI" are fine until there is a problem, when they can mask it.

"GUI" is not necessarily a good way of high speed transaction processing.

WYSIWYG (what you see is what you get) is more often a myth than a reality in graphics, or report producing software.

Integration is fine provided you can undo an accounting transaction that arose out of a faulty original transaction (e.g. for a faulty goods receipt).
Integration is not simply a technical issue it is also a training and communication issue, in that the person originating the transaction must understand it's implications in other parts of the system.
Integration is an overused and abused word, often meaning that there is a loose connection between the applications, and that in some circumstances they can become out of step, or at least that for the duration of an on-line day they are not consistent until the overnight interface is run.
Reliability availability and performance of computer systems are forgotten words, replaced by the words, "the system has crashed again", "we have to take the system down at lunch-time again", and "it always takes five minutes to log on" respectively. The worst one of all I encountered recently is "the IT department's door is locked they must have gone home"!

So you have felt the pain. It is still not too late to get some business benefit out of the new system. If you changed your software for Millennium bug IT reasons alone, you are definitely missing an opportunity. Go back and check the above list and start work on it as soon as the dust has settled on the implementation. If you are in the fortunate position of starting now, you still have time to do it right first time.

___________________________________________________

The following further best practice articles were also mentioned in this paper:

Stock control

MRP

What control Systems do I need

Malpractices

Conference room pilot

25 questions to ask your IT specialist

Software selection

Organisational Redesign

Previous Best Practice of the Week 001: Ownership

Previous Best Practices of the Week 009: Visibility of problems through simple and clear processes