How to Implement ERP/MRPII Systems Successfully

MML's approach to implementing an ERP/MRPII system is set out diagrammatically below.

In supporting ERP and MRPII implementations and re-implementations over many years, MML has developed an approach that delivers superior results, quickly and cost effectively. We believe two factors in particular have contributed to this success:

• real world experience of systems implementation as planning, inventory and materials managers across a range of different manufacturing sectors;
• a focus on business processes and the way people use the information in their daily tasks.

MML's consultants approach the implementation of ERP and MRPII systems as IT literate and highly experienced users. Although many of the elements of our methodology may appear to be similar to those used by the high quality systems providers, there are several key differences.

Firstly, we start from the premise that: if the implementation is to be successful, it must deliver tangible, measurable benefit to the business and the users, i.e. the staff. These days, even mid-range systems cost substantial sums to purchase, or licence, and install. Why spend the money if it will not deliver a return?

Moreover, we believe that if the system is to deliver this benefit, it must be seen as something the users own and want to use. The IT function still has a very important role, but it is as a service provider, managing the hardware and software and supporting the users.

Of course this puts the onus on the users, and they will have to find the time to get involved in the project, which can be difficult in these days of “lean and mean”. But the upside is that it can be done much more quickly and with a much greater probability of success. We have not had a single implementation fail to deliver benefit, although some have taken longer than others.

Secondly, we have developed this approach to address problems we encounter all too often. There are two commonly adopted routes to implementation that companies believe are potentially easier. One involves taking the “standard configuration” as offered by the vendor and, supposedly, as implemented by other users. The other takes the view that, by modifying the software to match existing business processes, the impact of the change can be minimised.

We have found both the approaches have serious drawbacks and frequently lead to implementations that do not fulfil expectations. The first route makes two fairly large assumptions:

• that the new business processes can be developed around a standard configuration that will meet all of the business requirements. In our experience this oversimplifies the extent to which all business have important, unique elements in the way they need to do business;
• that the vendor's consultants will know enough about how the client's business works to be able to set the system up to support it. Software implementation consultants usually have considerable depth of knowledge about the package, but often have a mainly technical background and lack the detailed knowledge of how the business works.

The second makes rather different assumptions, which can be even more unrealistic:

• that it is possible to make the software replicate existing processes. We know of companies that have spent large sums of money modifying the software, only to find that it cannot exactly match what they do now. More worryingly, once modified they face the ongoing cost of maintaining all of the modifications or falling off the upgrade path and being left with an unsupported version of the package;
• that the change to the way people work will be minor. We find that, even where the modifications can be made, introducing a new information system means staff have to learn how to do things in a new and very unfamiliar way.

Most worryingly, both these approaches lose sight of the fact that some things will have to change and miss the opportunity to make real improvements. And, of course, if things will have to change, the business will only get what it wants out of that change if it takes control. Leaving it to the software vendor means that you will get what they think you need - and that may not be what you are looking for.

For this reason we believe that an essential first step to implementation consists of getting the business to define what it wants. Developing a high level "design specification", whether you are contemplating minor or radical change, is the starting point for ultimate success.

We recognise that this is rather different from the traditional approach, where the project often has a predominantly technical focus, and where technical staff are responsible for a substantial part of the work. But, according to recent research, the traditional approach has less than a 20% success rate and we believe a primary reason is that it lets the users off the hook. A technically led project allows the users blame IT for giving them a system that does not do what they want, which is hardly fair on IT.

Who ever heard of anyone developing a new car by starting with a detailed design for the engine? Of course we all know that before anyone builds a new model there is an awful lot of conceptual work that has to be done first, simply to determine what the car looks like and what is will be able to do.

It is exactly the same with the business processes and the information system that will support them. Whatever the degree of change envisaged, unless there is a well defined and well understood specification, something that explains quite clearly what the business wants the system to do, the result may simply be a system that delivers what somebody else thought the business wanted. If ultimately the software provider decides, how well it works depends on how much he knew about how you run your business, and what's important to your suppliers, customers and staff.

Building a design specification for the business process defines the functionality, information and performance you need from the system in order to run the business in the way you want. Surprisingly, it not a very time consuming thing to do. Generally, it takes the board or senior management team about two or three days, although the days can be quite hard work.

A more detailed description of how to go about developing a design specification can be found in out “How To Develop A Specification for Designing a New Process”. In summary the design spec consists of three things:

• a high level, one page, process diagram. Using the metaphor of designing a car, this is equivalent to the artists impression;
• a set of business objectives. These need to be realistic and measurable. They are the equivalent to the car's performance targets. If you want to improve customers service or reduce costs, it's as well to work out what you want before trying to change things in the hope that, somehow, it will deliver what you want;
• policies that spell out how the company will behave, in terms of managing the day-to-day and periodic business activities. These are the equivalent to the content of the car. It spells out the items that are to be designed but leaves the detail and technical design still to be done.

Just as an engineering drawing provides an easy to understand description of what a component or assembly looks like, so that it can be made, process maps provide a simple, easy-to-understand means of describing business processes in a way that means they can then be built. If a suitable notation is used, process maps can give a very clear picture of even quite complex processes. This is something we find that cannot be done at all well with narrative or traditional flow charts.

This point is important simply because most business processes are relatively complex. There are two main reasons for this:

• in the majority of companies business processes have evolved, in response to growth and other market or business drivers. Very often, each time something changes a few additional tasks are added;
• exceptions. If everything happened right first time processes would be much simpler. In real life things go wrong, all businesses suffer from quality failures, invoices that don't match, late deliveries, customers that change their mind, etc. Processes and systems must be able to handle these exceptions or the business will be brought to a standstill the first time one occurs.

Within the implementation project, mapping processes has two roles to play. A small amount of time spent mapping existing processes can reveal gaps and inefficiencies. These provide the starting point for improvement. They also help to identify those unique elements of the current processes that are essential features of the way the business is managed, particularly in areas that are customer facing. Identifying these is important to ensure that essential process elements are retained in the new or modified processes.

Mapping is also a reliable way of building high levels of confidence into any changes that are being made to the process. The ability to use the map to challenge, test and ensure the revised process integrates fully with other stages, , increases the chances that it will work well in practice. They allow all the staff affected by the change to understand how changes will impact their work and this builds enrolment. Most importantly, if the business is seeking improvements, the designers of the process should be able to explain, with reference to the maps, how those benefits will be delivered. If they can't, they probably don't know themselves and the benefits are unlikely to materialise.

The development of the “To Be” process maps also gives the users the opportunity to find out about and explore the functionality of the selected system. During this step they should evaluate possible alternative configurations and ways that the system parameters can be used, to find the likely best fit. Such involvement gives the key users a more detailed understanding of how the software works and minimises the company's dependence on vendor support following implementation.

A fuller explanation of this methodology is available in the paper on “How To Produce Usable Business Process Maps”

If the process maps are the equivalent of the engineering drawings, the conference room pilot is the equivalent to building and testing the prototype. Indeed, it is sometimes called prototyping.

The purpose is to ensure that the process that has been designed works and delivers the expected results in all foreseeable situations, including exceptions. It is also the step during which the final configuration is decided, since alternatives can be tested and compared.

It is done by building a model of the system in an off-line test environment. The model is used to test and evaluate the business process that has been designed. It allows problems to be identified before go-live, when they might have an adverse impact on the business. It also allows the process to be tested in something approaching a real situation. If it is done thoroughly it can ensure there are no nasty surprises in store.

Because its purpose is to test the process, it is essential that both system-based and non-system based tasks are done. In practice, this means following a series of routes through the complete business process, as a sequence of activities. It is not a set of independent tests of the different functional elements of the software, although if it is done properly such tests occur as an integral part of the process.

It is important that it is done in a structured and fairly formal way. Scripts should be written for each test. The start points recorded as well as before and after records of each step. This approach ensures errors or unexpected results can be tracked and allows tests to be repeated if required. To simplify the task it is usually sub-divided into three separate stages, each with increasing:

• complexity in the model, in terms of products, customers, suppliers etc;
• exception conditions that are included in the business process routes followed;
• volumes of transactions processed.

Where, as the result of prototyping, it is found necessary to alter the process design, the maps should be updated as a normal part of the change control mechanism. This helps to avoid specification creep at a critical stage in the project.

In all stages it is advisable to use real data rather than synthetic. It gives a much better reflection of the real world. As the activity approaches stage three it is usually possible to use the knowledge acquired during prototyping to start developing the cut-over plan and the user training materials.

Using our analogy, this step is akin to road testing the pre-production models. The purpose is to test the final design that emerged from prototyping, for completeness and robustness.

It offers an opportunity to involve users outside of the core project team and to test the draft user instructions. It also offers the opportunity to process a sizeable volume of data as well as some of the cut-over routines.

Once again, it should be a fairly formal process with detailed records being kept of the start position, the data processed and the outcomes. Similarly, care should be taken to ensure that all infrequent and unexpected events are included, such as period and year end, discounts and price changes, rejections and reworks, late delivery etc.

In this step there are no iterations; it is a final validation of a fully configured system and fully designed process. If, during validation, an error is found or something needs to be changed:

• the process design must be altered and approved;
• the revised design must be returned to prototyping;
• once prototyped the design must be validated.

We have seen too many implementations that failed validation but went ahead anyway. Invariably, the problems encountered during validation caused major disruption to the business, post go-live.

This is the task of loading the data into the new software. It can be a time consuming and critical task and needs to be well managed if problems are to be avoided post implementation. Poor data quality is frequently a root cause of poor business performance and increased cost.

For the purposes of loading, data can be separated into two broad categories:

• static data, which changes relative infrequently. This includes things like bills of material, vendor and customer records, and so on;
• dynamic data, which changes every day. This includes stock records, purchase orders, customer orders and so on.

Static data can be loaded over a period of time, providing there is an adequate change control mechanism to ensure that any changes in the current system are reflected where the data has already been loaded to the new system. This approach eases the task of loading.

Dynamic data can only be loaded at the point of cut over. Best practice is to close down existing systems and check the figures. This may, for example, include conducting a stock check to validate stock balances. Once validated the data is transferred into the new system, checked to ensure it is complete, and then the new system switched on.

For both categories it is prudent to take the opportunity to do two things:

• housekeeping, to ensure that only up-to-date, valid and correct data is loaded into the new system;
• give responsibility for each element of data to a named individual, so that it is easy to ensure the work is done.

Cut-over planning consists of identifying exactly what data is required and then populating the new system. Here it should be noted that rarely is everything the system can accommodate actually required. Once again, the process maps can provide a very simple means to identify just what data is needed to make the process work. Loading additional fields “because they are there” simple generates additional overhead to maintain them.

Each person responsible for loading data should be tasked with:

• defining the methods they will use for data cleansing and validation;
• deciding how they will collect and load the data. This can be particularly important if, in using additional functionality, new data is required;
• agreeing the time scale and method for loading;
• validating the loaded data;
• reporting on progress, in terms of completeness and correctness.

For this to be done properly the nominated individuals need access to user query or report writing tools, so that they can “look under the covers” and see what is going on, particularly as validation may require several fields to be cross checked.

The organisation put in place to manage the project and the techniques used are another key factor in success. They will, of course, vary in complexity with the size and scope of the project, but we have concluded that there are a few essentials without which it is very hard to achieve success.

Any project of importance needs a sponsor who has sufficient seniority to champion the cause and protect the project against conflicting demands. Lack of adequate senior management support is probably the most common cause of failure.

Although a key player, the sponsor needs to be part of the senior team who steer the project. Their job is to make sure it is properly resourced, resolve conflicts of priority, produce the "design specification" and approve the final versions of the detailed process design, or process maps. After all, as the senior executives within the business, it will be their responsibility to deliver the processes, and the improvements, once the system is in place.

The project itself is usually best managed by a full time project manager along with a number of full time support staff. The number depends on the size of the project and can be supplemented by part-time members of the project team. In practice, unless there is a critical mass of full time people most projects fail to make adequate progress and are continually overtaken by pressing day-to-day demands of the business.

The role of the project team and project manager is to produce and deliver the project plan, to define and monitor the tasks involved and make sure that the task teams:

• know what they have to do;
• know how to do it;
• have a means of knowing when the task is complete and whether it has been done adequately;
• have access to the knowledge, expertise and resources they require;
• identify and resolve, or refer, any issues that arise.

The project manager reports to the steering committee and should use a formal project management tool to monitor and report progress as well as assess the impact of change or delay. Ultimately, the project team must deliver a working system and business process, on time and to budget, that will achieve the targets set in the design specification.

The leg-work is done by the task teams. Ideally these need to be cross-functional, so that they can take a process view. Depending on the size of the project, there may need to be several of these in which case two particular management techniques become important:

• each task team should be supported by a member of the project team, not necessarily as leader. This ensures the project team support the task teams and know what is happening;
• task teams will need to be “cross fertilised” by having at least one member who belongs to another team. This ensures tha individual teams do not start to develop sub-processes in isolation that may not integrate with the whole.

Task teams will almost certainly be composed of a mixture of full-time and part-time members, and may vary in size, number and composition depending on the task in hand. An advantage of this rather flexible approach is that even infrequent members act as ambassadors for the developing system and process, discussing it with colleagues and widening the enrolment within the company.

Their job is to develop the detailed process maps; discover how to use the software, prove the design through prototyping and take individual responsibility for areas of cut over. They are also likely to produce the future power users and the resource to train other users across the different departments.

Such a structure will require some level of external support, certainly from the vendor but possibly also from business consultants. The roles of these parties are discussed in more detail in the next two sections.

The parents amongst us are probably quite happy for our children to receive sex education at school. We might not be so happy if it was sex training! This illustrates rather sharply the important difference between education and training. Education is about understanding why. In general, training teaches you how to do it. If we just have training and do not understand, it can be almost impossible to respond correctly when things go wrong. This is why pilots are educated about the laws of aerodynamics - they don't just spend time in a simulator.

Not only are these two roles different, but the providers and audience are too. In the structure described in section 6 above, everyone needs to understand what ERP/MRPII is about. Indeed, there is a view that if the business is really going to make a success of ERP/MRPII, everyone needs educating, everyone needs to know how it will affect them.

We have some clients who have, for example, rolled out aan education programme across the whole shop floor, delivered by the managers and supervisors. This was a short, two-hour session. Not everyone needs the same level of understanding.

The steering committee may need a high level strategic understanding, whilst the task team members may need to have a very thorough grasp of the detail. If they are going to work as a team and deliver something that will give the business what it needs, they need a common language, they need to be able to discuss issues from the same perspective, above all, they need to reach agreement about how it is going to work.

This can only really be achieved through education.

Training, on the other hand, is really most usefully directed at those who will be using the system in their day-to-day work. Unless you physically use the computer, it may not be necessary for you to know how to enter data of produce works orders, for example.

Systems training is usually given by the software provider. It comes as part of the package and they are the best people to give it. If they are also offering education, it may be prudent to ensure it is not simply a high level overview of their particular interpretation. If it is it might overlook some of the fundamental business issues. Taking the metaphor, you might end up understanding only how aerodynamics affect one particular aircraft.

As well as having to understand how the principles of ERP/MRPII can be used to run the business, an implementation project will involve staff in activities many of them may never have done before. Putting in new systems is probably not been a part of their normal day-to-day work.

It is not surprising, then, to find that they will need to use a different set of tools and techniques. Some of these will be required only for the implementation but others are likely to have value long after the implementation, since they can be usefully applied to other areas of the business. The difficult question is not whether they are needed, for without them the project is unlikely to be successful. The real issue is whether to build them in-house or to buy them in.

It is possible to find external resource that has the necessary skills and experience. If it is only needed for the implementation, for example, the ability to size the hardware requirements, it may not present a problem after the project is completed. It may simply not be needed. But if resource is bought in to manage the project, map the processes and test the system, when they depart so does all the knowledge they have gained about your business processes and systems. When circumstances alter and something needs changing you may have no option but to buy the resource in again.

Our approach recognises the costs and risks associated with such decisions. Working with clients to transfer skills and ability we have been able to build capability where tools and techniques have a longer-term value. Process mapping, problem solving and project management are three examples where clients have taken the skills their staff acquired during the ERP/MRPII implementation and used them to support other projects, such as continuous improvement initiatives or change management.