Implementing ERP systems What to do and what to avoid

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 UK Institute of Operations Management in its original form in their magazine "Control".

Links to related training and further reading on left

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 B001: 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. This almost certainly means that resources need to be redistributed too!
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 Previous 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 business 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 can have 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 B009: Visibility of problems through simple and clear processes")

IT issues requiring business management attention

(See 25 questions to ask your IT specialist)

Software modifications shorten the life of the software. There needs to be a method of running the reports and IT 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 "transaction 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 at least:
1. a training system with identical programmes and parameters to
2. the production system (except when retraining after changes)
3. 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? This is a great opportunity to have a clear out!
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 technical guys need time for this.
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 2-3 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 any 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 evaluating 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 of today'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 (interface) 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 strategic or 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.

___________________________________________________________________

Bookmarks for this topic above:

Our full range of training

Relevant Training / Workshops

Expert Systems / Tools

Relevant Further Reading

Top

To discuss your consulting or training needs with one of our independent consultants or trainers please Contact Us

Whilst great care has been taken to provide relevant, accurate, practical, advice based on our considerable process design and development experience, this will almost certainly require interpretation into the context of your unique business. Please be careful in doing so and if in doubt seek expert advice. We would welcome your feedback!

SM Thacker & Associates

Independent Best Practice Training & Consultancy

Highlights of our full range of training courses / Workshops:

Bookmarks for this topic below:

Relevant Training Course / In-house Workshop Highlights:

Expert Systems / Tools:

Relevant Further Reading: The following further articles were mentioned in this paper:

Enterprise Resources Planning (ERP) Implementation

The Forgotten Lessons

Project Management

Business Issues

IT issues requiring business management attention

The New Lessons

Project Management

Business Issues

IT issues requiring business management attention

Bookmarks for this topic above: