Sadly, the pitfalls from the early implementations of MRP are still being stumbled over today. Many companies introduce planning systems from reputable suppliers and the systems quickly get wholly out of control. Reasons for this are many but all too often we find that the approach to adopting the system has led to the business going live with a configuration that doesn’t meet the company’s requirements and with people who don’t really understand what they should be doing. 

So, can ERP systems deliver benefits? The MLG view is most definitely that they can, if approached in the correct way. The key aspects of this correct approach are headlined below:

  • This is a Business Project
  • One standard failing of ERP implementations is to approach the exercise as an IT project.

  • Management Must Be Committed
  • The implementation of ERP takes a long time. This commitment has to take the form of the senior team providing a steering group which genuinely steers the project.

  • The Project Team Has To Be The Team That Can Lead Change
  • The project will involve significant change to the business. Team members must be those who lead this change, rather than those who know their way around the software best.

  • The Organisation Only Has One Future . . .
  • . . . and only one set of future processes. The implementation project must be the one exercise defining the processes of the future. This is not to say the business cannot have a Business Process Reengineering or Lean project. The introduction of the new system has to be exactly that – see below.

  • Defining The Future Vision Takes Time
  • We assume that the project objective of improved business performance is a given. Reaching conclusions requires that the key players be empowered, trained as necessary, weigh up the options, establish best practice and explain this to others to ensure ownership being spread as necessary. 

  • Selecting a System Must Be Driven By The Future Vision
  • The traditional approach to system selection included the creation of a detailed Statement of Requirements (SOR) document which listed the features needed in the system. More important than that approach is to establish a clear vision of future operation of the business and to challenge the software suppliers to show how their offering supports this vision. 

  • System Configuration Must Also Be Driven By The Process Vision
  • The configuration process must begin with the product consultants understanding the future processes. This can sometimes be difficult when the major interest and knowledge of specialists is in the software product rather than the business issues. However, understanding how the business intends to work is the most crucial step in configuring the system to operate in this way. 

  • Testing The Configuration
  • There is the need to test even the most widely-used systems. The number of customisable parameters in today’s packages means that the ultimate combination may well result in a unique configuration – and, after all, all systems have ‘bugs’.

  • Piloting
  • A more complex issue than testing is that of confirming the business processes using the new software. In working though a trial run it will become apparent that some information is not available, additional detailed questions arise and members of the team will set about finding the right solutions.

  • Training
  • People often question why our outline project plan has the vital area of training so late in the overall sequence of events, but of course how could it be earlier? Training is intended to show people how to do their jobs and until the completion of all piloting, this isn’t finalised. Training of project team will be much earlier while there is a need to understand what the software can do but training the general populace in myriad options saying “you will use one of these options” will only spread confusion and fear.

  • Data Conversion
  • This can be a major element of any project but may again be constrained by the mapping / configuration process. Until the project team have decided how the system is to be used, some of the fields on key records (such as item master, customer, supplier and work centre) cannot be finalised and thus the work to set out the transfer routines cannot be completed. Some of the work can be done early in the project and there may well be some clean-up activities required in the existing (legacy) system.

  • The Project Team Role Upon Going Live
  • In the early days after going live, the project team will be running around like firefighters in the seaside town holding this years arsonists’ convention. Thereafter the role will move from problem-solving and crisis management to genuine improvement activities. No matter how well the in-house team and any external specialists have thought through the future vision they will not have identified every last ounce of streamlining or opportunity to improve information flow.

So, in summary form, this is the MLG approach to implementing a modern ERP / Supply Chain system. Running through like this it all sounds very simple – so why do so many companies struggle to achieve real benefit from such expenditure, such massive investment of people’s time and such an interference effect on the business? Well, quite simply, because no matter how logically we might set out on the path, when the bullets start to fly, life gets complicated. Unforeseen problems crop up and compromises have to be reached in order to keep moving forward. We still believe that, managed properly, an ERP implementation is the opportunity for step change improvement. The reverse side of the coin is that, managed badly, it can be a weight around the neck for many years.

There is a more comprehensive view of the MLG approach to system implementation. This is available to organisations about to undertake such a project and can be requested by clicking here.