You need to know the rules in order to break them successfully

Implementing ERP systems

Enterprise Resource Planning (ERP) systems are the transactional engine of medium and large organisations.  The software is clever because it integrates systems that in the not too distant past were separate and had to be stitched together.  ERP systems work seamlessly.  Why is that so good?  Because before ERP systems came along, there were always quirks that had to have some sort of IT hack or clerical intervention to make the system work, often in the form of printing something out of one system and keying it in again to another, or writing a programme to do the same electronically.  They worked, but not seamlessly.

It’s not too much of an exaggeration to say that ERP systems have been a significant source of white-collar productivity over the last two decades.  But they are a devil to implement.  Get the implementation of an ERP system wrong and you could easily be looking for a new job.  Get it right and you could be looking at promotion.

You’ll have heard horror stories about systems being very late or massively over budget or, worse, so poorly implemented that the company loses control of its data.  They’ll all be true, but sadly most of the reasons will have been avoidable.  The key, above all else, is for the users to take ownership of the project.  And I mean genuine ownership.  This is not a Friday afternoon project.  This is a hand-picked team of your best people away from their normal jobs for 12 months project.  Do not delegate project leadership to your IT people or you’ll get the implementation you deserve.

This tutorial is prepared from a user, rather than a techie, perspective.  It seeks to answer some of the basic questions people have prior to implementation, but also considers some of the practical problems that will make or break the implementation.  First, those questions:

Which is the best software?

Every industry specialist and user will have their judgement on this question based on their own experience.  Often however this experience is tainted because it might have been with an out-of-date version of the software or poorly constructed data architecture, which are not the fault of the software.  The table below lists the market share of the top three software vendors.  Having worked with the software of each company since the early nineties I’d say these market shares are a reasonably accurate reflection of the relative strengths of each.  SAP basically invented the ERP category and has remained the market leader.  Oracle and, much later, Microsoft are in the process of catching up, often through acquisition rather than organic programming development.


How much will it cost?

To prepare a business case for implementing this software, you need to know how much it will cost and, just as important, what savings you can expect.  The answers depend on your choice of software, the complexity of your organisation, how much of your own staff v consultants are used to resource the project and, of course, how extensively you want to integrate your corporate systems.  The table below suggests a broad ranges that will help sketch the first draft of the business case.


How Long will it Take?

The figure below provides an illustrative implementation programme for a typical mid-market implementation.  From having made the tender selection and received authorisation of the business case, it suggests 12 months is a reasonable implementation programme.  As many companies like to take a long time preparing the technical brief and want their staff to see presentations and visit reference sites during the tender process, it can take anything from 6 – 12 months to travel from first draft business case to the start of implementation.


Pitfalls of implementation

Passivity; implementing a new computer system should not be something that is done to you by the IT department or consultants.  Grab control of the project and make sure you do it to yourself.  You have to make sure the IT department and consultants know that they work for you.  The quid pro quo of this is that you have to put in the necessary effort that is required to lead the project properly.  Sometimes this is not as easy as it sounds.  If you are part of a large corporate roll-out, you might find a completely unknown implementation team descends on you as part of a plan to implement and then move on to the next organisation/country in your group.  Even in this circumstance, make sure you and your team are intimately involved in the project work itself and in control of the go live decision.

Resisting changing the way you work; it’s a classic of systems development that users can’t see passed what they have now.  I’ve seen computer reports that were configured is a nonsensical fashion but the user insisted they have a computer-prepared report that looked exactly as their previous manually-prepared report.  Don’t laugh.  It happens all the time.  After several decades of programming, if the ERP software can’t do what you want it to do, the chances are high that you shouldn’t be doing it that way in the first place.  But even if you are the exception that proves the rule, still I recommend you change to fit the software rather than the other way around.  The software works.  You might break it if you fiddle around.  It’s like buying a new car and then stripping out the engine and making your own modifications.  Sure that’s ok for a few enthusiasts, but no normal person does this.

Relying on ‘Soft’ savings to make the business case work; I’ve seen 90% of the benefits in a business case for a new ERP system rely on procurement savings.  There certainly will be such savings but they are notoriously ephemeral.  You must instead ensure the business case works only with ‘hard’ cost savings.  This means fewer people.  Difficult though it is, you need to be single-minded about following through on this.  Otherwise, you can have the best implementation but the project will still fail if you have no genuine savings to show for it.

Incomplete data; it can’t be stressed enough, the most difficult part of the project will be your own data!  These modern ERP systems are thoroughbreds, powerful best-in-class software for all areas of your business.  The technical part of the project doesn’t involve any hard-core programming, that’s already been done.  Mostly it’s a case of switching off all the powerful features in the software to reconfigure the thoroughbred into a workhorse for your particular business.  There will however be a lot of work in locating the sources of your existing data, identifying gaps in the data available compared with the data the system needs to get all its integration gears moving, tracking down this missing data, correcting errors in your existing data, confirming validity etc.  I could go on, but I’m sure you get the picture:  this is a big task.  It’s not one that you can get away with being 99% correct.  It needs to be 100% correct and getting it into that condition is not easy.  I’m afraid it is deeply unglamorous, frustrating, thankless work.  If you don’t give it a high priority, your project will fail.

Interfaces; as integrated as ERP software is, it’s unlikely to cover every system and process in the company, especially if you are a large organisation with some sophisticated, bespoke software.  In addition there will sometimes be a miscellaneous little systems that are simply too small to justify purchasing a module of super-charged, super-expensive ERP software, and these need to be hooked up to your main ERP systems through a specially-written interface.  This is very similar to the data-cleansing activity described above.  It is hard, important work but, unlike data preparation, most of the work falls on programmers.  As users however, it becomes vitally important to put as much emphasis on testing the interfaces work correctly as with testing the main ERP software itself.

Testing;  having said there’s not much that can go wrong with the software, the word ‘testing’ seems a little out of place, and indeed it is.  With the exception of any specialised customisation you’ve made or interfaces you’ve had written, testing is not so much about testing the software as testing whether your organisation is ready to go live.  It’s like an intense training session for super-users.  This is probably the stage where the project is under greatest time pressure and yet is the most important that you take your time, going as slowly as you need to, to test every square inch of the system, with the most difficult, troublesome scenarios – the things that always go wrong in the current systems.  The most common error is for users to adopt a superficial approach to testing: not put enough people on it, not put people of the right calibre on it, not take as methodical an approach as is needed, and testing only the easy parts of the system – the scenarios that always go smoothly – and not testing data take-on routines or interfaces with a sufficient ‘Total Quality’ approach.

Training; at this point almost your entire company should be mobilised.  There should be almost no one that is untouched by your training effort.  Ideally, your super-users that did the testing should do the training.  You do see implementations where trainers are brought in but it never seems good value for money to me, and often leaves the users unsatisfied or, worse, lacking confidence in the implementation.

Words of Warning

It makes me shiver to think how amateurish our approach to implementing new computer systems used to be in the old days before ERP systems came along.   We used to spend ages building our own systems, believing our way was the only way.  The software would be glitch-prone.  Systems would never talk to each other.  Users asked programmers to code up existing paper processes rather than think from first principles about different ways of working.  So little confidence did we have in our implementation we used to run systems in parallel, sometimes for months!  This meant clerical work being repeated twice.  It was the polar-opposite of concepts such as right first time.  To be fair, it seemed that computers only moved out of a ‘data processing department’ (I am old enough to have seen one of these) and on to the desks during the mid eighties, so we were pretty green.  Only we’re still repeating these mistakes today.  In 2011 I witnessed a large scale ERP implementation that was managed so badly that one of the companies that implemented the new software reversed their decision a year later and went back to their previous software, thus unwinding 5 years of planning, work and angst.

Quite often in business you can apply the 80-20 rule, proceeding with incomplete information because the ‘best is the enemy of the good’, etc.  Not with computer systems.  For these you need to pull on your ‘attention-to-detail’ trousers.

As I write, President Obama’s second term is at risk because of a cack-handed implementation of the IT systems necessary for the healthcare insurance market created by ‘Obamacare’.  I have no insight as to the reasons why the implementation went wrong but I can be pretty sure the pressure to implement come hell or high water before the 01 November 2013 deadline was pretty strong.  Would you stand up to the President of the United States of America if you didn’t think the system was ready to go live?  Well, you must.  Pity anyone implementing an IT system in the public sector.  In politics there is a weird ‘the minister says it must be so, so it is’ type of mentality that bully’s public servants into making poor judgements.  All that happens is that it goes wrong anyway and rather than being criticised for a delay the minister is criticised for a delay and being incompetent.  Resist at all costs the pressure to implement computer systems that are not ready.  If it can damage a presidency, it can damage your company.


ERP is powerful, world-class software.  You need to match it with powerful, world-class implementation skills.

View all blog articles