For help, support, training and consultancy
ERP and our experience
Following extensive experience of assisting manufacturing companies to improve operational performance, many of the assignments undertaken by our associates are directly focussed on supporting the implementation of ERP (though the term used in many companies is 'Supply Chain' systems) but more are simply focused on general operational improvement.
Whilst this often involves changing the physical layout of manufacturing, the organisation structure, employee grading schemes, supplier management, quality initiatives and so on, a central issue is very often that of business systems. Planning and control of manufacturing is in a significant number of cases the single biggest contributor to poor business performance. All too often the company's ability to supply its products on a satisfactory lead time or even meet the unsatisfactory commitments it has made is fundamentally compromised by its poor use of a reputable, proven ERP package.
We address the reasons behind so many poor implementations and draw upon these to provide a number of steps which must be taken to enable the new system to be viewed as an investment which is paying benefits, rather than a millstone around the organisation's neck.
Time and again we hear of the implementation of new business systems failing to deliver benefits which justify the expenditure. Indeed, we often hear of system changes which not only fail to deliver business improvement but result in major problems and considerable degradation in performance to customers. It is not the intention of this paper to list the statistics for such matters, but whilst some of the apocryphal tales abounding are undoubtedly exaggerated, there is evidence from credible sources that ERP is not the roaring success that we would all like it to be.
I actually read fairly recently of some organisations giving up on ERP in order to concentrate on the new panacea for all ills - e Commerce. This no doubt sounds attractive when first contemplated by harassed executives who have been battling for some time with the poor planning information presented by the all-embracing business system covering planning and control of manufacturing operations, whether this glories in the title of ERP, or has been labelled the company's Supply Chain solution.
However, let's consider the implications. eCommerce opens up our business and our plans more than ever before to our customers. The information used to plan our operations will, if the new approaches are used fully, automatically allocate delivery dates to our customers' orders and give them the potential to monitor progress. What will this mean if our plans are not valid and correctly managed? Quite simply, we will give promises we have no hope of meeting and this fact will be visible to all. Our credibility will plummet and, with it, our hopes of retaining our market.
So, to hear of companies having failed to address the fundamental issues of planning and control starting to talk of the progress they are making in B2B or collaborative commerce has to cause doubts. Isn't it rather like a student swimmer who has failed to manage a width in the shallow end deciding to skip this bit and go on to trying a full length starting at the end where drowning is the only conceivable outcome?
In order to make these new approaches realistic we must address the issues that have held us down for so long. We need to do the fundamentals well in order to be able to give realistic plans and have the courage to open our books to our customers. This is not the time when we can say 'oh well, ERP didn't work, let's do B2B instead'. We need to say 'we are going to trade collaboratively, embracing the new ways of working, and in order to do so we need to sort out the fundamentals, the building blocks, in our business'.
One of these fundamentals is, for better or worse, our planning and control system. Central to business performance is doing well all those things at which ERP systems are most targeted. These systems all offer integrated facilities covering everything from sales forecasting through customer orders, purchasing, manufacturing, despatch, invoicing and all forms of financial analysis, but the key to getting a return on our investment remains making the right things, in the right quantities, at the right time and at the right cost. The systems all work, so why do so many companies end up with the wrong results?
How We Got Where We Are Today
Why are these all singing, all-dancing pieces of computer software burdened with such a long-winded name as Enterprise Resource Planning?
Quite simply, because the engine room of the packages, the programs which take the demand (be it in the form of customer orders or forecast) and 'explode' it through 'bills of material' to identify requirements at the component and raw material level having allowed for existing stocks and work in progress, and calculated dates to reflect lead times, was given the term Material Requirements Planning in the early nineteen-seventies.
MRP was the flavour of the month for a relatively short time, after which people realised that the basic number crunching, while a valuable tool in improving performance, was not in itself the answer to our prayers. If we loaded a top level plan which had too much demand MRP would happily explode this into unachievable plans at all levels, stocks would rise out of control and customer service would disappear as planning went out of the window and fire-fighting became the order of the day.
The instigators of MRP came back to defend their creation by telling us all that we needed to manage our businesses better. We needed to formalise our planning processes, with particular emphasis on the development of our master production schedule. MRPII appeared as two things - a management philosophy surrounding our planning and control systems and a series of additional features built into the computer packages which allowed us to close the loop of plan, validate, monitor and re-plan.
The packages were given modules which managed our production activities, reporting capacity requirements, generating shop paperwork and providing the facility to track orders, operation by operation. Purchasing modules became linked to MRP and stock, and financial packages were driven directly by the operational aspects. For several years new facilities continued to appear - as finished goods stock planning in multiple warehousing became a key focus the terms DRP and then DRPII were added to our vocabulary. Package vendors realised that they were no longer supplying simply 'materials' or even 'manufacturing' systems. Their software now addressed all aspects of the 'enterprise' and ERP was born.
Over the now-considerable lifespan of ERP systems many features have been added. The more sophisticated offerings now provide facilities for all elements of running a business. Where shop floor control modules introduced records of individual operators to enable tracking of who did what on each works order, these records grew into full HR modules capable of managing the training and career development paths of all employees. The integration of the systems enables the employee's expenses to be entered once to a package which covers the authorisation process, the accumulation of work in progress costs and all forms of financial analysis.
These systems are heavily promoted as being 'fully integrated.' We no longer need to capture the same information several times. This is put forward as an opportunity to significantly reduce costs, while at the same time offering the potential for vastly improved control. We are told we can have facilities which allow us to drill down into every customer's order to find its exact status and hence identify when it will be shipped. We can easily spot where things are going wrong and take steps to put everything right.
What Is Different? 21st Century `Tier One' v earlier solutions
The package vendors also explain that they are now able to design their systems around business processes, that they have learned from many years of introducing change to client organisations. Their implementations are often undertaken as exercises in Business Process Reengineering - no opportunity to jump onto the latest bandwagon is neglected - with heavily structured methodologies designed to ensure that good practice is introduced on the back of the software.
The packages have also grown from being targeted at particular companies and types of company, to offering the facilities to operate in a number of different ways. Indeed the number of different parameters available in the major players has grown immeasurably in recent years. Each of these systems can happily address the management of businesses selling standard products from warehouses around the world, whilst being equally at home in a ship-builders handling one unique major product after another.
Why Do Implementations Go Wrong?
As with all areas where we struggle to succeed with what might seem an excellent idea, the reasons behind such oft-repeated difficulties are many and varied. However, from personal experience and from the various research projects which appear from time to time, some common threads become apparent.
One thing which usually becomes very apparent in companies in which we are invited to investigate the poor performance being encountered following the implementation of a major integrated business system, is that the implementation was seen as exactly that - the introduction of a computer system. It is rarely seen in such companies as an exercise in changing the way the company goes about its business. There are a number of implications of such an approach, which clearly were not foreseen at the outset.
One indication that this has been the case is the selection of a project manager and team. Where the project manager is an IT person, the inference is that the skills needed in this role are likely to be centred on the computer area. Many companies now recognise the difference between 'IT' and 'IS' activities - 'IS' covers 'systems' in the broadest sense where the technology is only one part; the business processes, the definition of responsibilities and supporting disciplines are all just as important. Sadly, in others 'IS' has become the term in use in the same way that 'IT' replaced 'DP' - or, in another sphere Quality Control departments became Quality Assurance even though nothing was changed to introduce steps which would assure product quality.
Other reasons for failure can be seen in the objectives established for the project and the performance measurements introduced as part of the management process. When the overall goals are badly defined it is not uncommon to find that the concepts and techniques inherent in the software have been introduced to the organisation with far too little thought given to how the organisation will cope with them. Finally, the systems themselves can play a part in bringing about trouble due to their very richness of features.
There are several damaging effects of the project being managed as a system introduction. First among these is that the project team often appear to see their role as being one of making sure the business utilises some of the clever tools and techniques inherent in the package.
Managed As An IT Project
Such an approach often leads to these features being used without justification. The tools become almost an end in themselves rather than a means of achieving a business goal. BPR, when it appeared in the early nineteen-nineties, met some resistance but it served to remind us that we should always be looking to optimise the totality of our business rather than some specific sub-element. It gave us some valuable tips for introducing systems to manage our process and we should not forget these.
Many package vendors, and the specialist companies who have sprung up to provide specific support to these packages, all claim business processes to be a central part of their work. In some cases this is undoubtedly true, but we have seen much evidence that in many cases the package 'experts' are indeed expert in the way the system hangs together but could by no means be considered experts in good practice when it comes to helping management decide how the business should go about processing demands on it.
Perhaps the most damaging implication of a project being viewed as a systems activity is the amount of direction given by senior management. As well as indicating that the key players in the business are playing only a small part in defining the way business will henceforth be undertaken, this often explains why the rest of the business give insufficient attention to the system until they are asked to use it on a daily basis - by which time it is too late. Senior management must remember that people take their lead from their leaders.
How are project teams put together for system implementations? It is rare these days to find an implementation which did not involve functional, line personnel in key roles, but the selection often reflects the relative precedence given to the project. Introducing a major new piece of plant, or a complete physical reorganisation of the shop floor, is handed to a hard-bitten, experienced professional while 'that computer project' is allocated to somebody who can be spared, or somebody who has an interest in systems. Again, this does not help to ensure that the rest of the business takes the exercise seriously.
Finally, this leads to an area of failing which is frankly puzzling. There is enough material around these days for everybody to have learnt the lesson about piloting any new approach. In the very early days of MRPII all the educators and all the textbooks explained what a pilot was - it was an exercise is simulating the day to day running of the business using the new system.
Several types of pilot were fully understood by implementers of such systems during the nineteen-eighties - from the project team pilots which checked out different possible approaches to the final Conference Room Pilot in which other key players in the business sat down and checked that the system and all the supporting paperwork and disciplines met the company's needs. Indeed, a proper pilot included the post-pilot assessment when the fundamental question 'and does this improve the way we do things? ' was asked.
As time went on we learned that even holding the pilot in a 'Conference Room' should be avoided. We spotted the danger that the person at one stage of the process was picking up information as a result of sitting next to the person covering the previous stage. A classic example might be a planner generating shop paperwork to machine a housing because 'I know the casting has arrived. I just saw Bill booking it in. ' How would the planner know this back in the real world? Have we introduced an element in our process to trigger this step? If we had run the pilot with Bill working at a terminal in one office and the planner located next door behind a solid wall and a closed door then this gap, if gap there were, would have been apparent.
So, how is it that now we hear of companies going live with new systems and then finding that the process no longer hangs together? Wouldn't the pilot have shown this? Wouldn't the going live have been deferred until the issues had been addressed? One reason, of course, is that no pilot will ever highlight every single problem which may crop up and we can never be 100% sure that we will not encounter difficulties. However, some of the horror stories defy belief. How can this be?
Well, we often hear of system testing being the step in which the system as finally set up is checked out. We hear the term 'integration testing' used to describe the process by which the project team confirm that setting up the sales order processing module with a certain setting of a range of parameters doesn't lead to MRP failing to see the demand, or the invoicing software neglecting to pick up a despatch record and present the customer with a bill.
While the argument that 'don't bother, the system is live in 50,000 companies and it works!' may be dangerous, allowing too great a focus on the software can lead to the other function of the pilot being neglected. The objective is to confirm that the new ways of working really work. If the project team are too wrapped up in the software, and if the external specialists supporting the company are really systems people, as opposed to business experts, then the danger is that the other elements essential to successful cut-over are neglected.
Whilst very few business set out with any objectives for a system implementation other than 'reduce costs, improve customer service, increase production, reduce lead times, reduce inventory' - indeed how many of us could get the investment sanctioned by the powers that be without such benefits being clarified and quantified? - there is often evidence that these goals tend to fade into the distance during the lifetime of the project.
Badly Defined Objectives
When the objective is simply to achieve cut-over by a particular date:
One reason has been touched on earlier in that if the project is seen as one in Information Systems then the people involved will tend to have their own perception of what is required of them. Their interest will be in getting the new system live, and ideally using some very clever-looking features. Whilst it may be unfair to think of these features as 'gimmicks' there is some evidence of companies looking to utilise the latest buzzwords for their own sake rather than for what they can contribute to business performance.
Another major reason is the old maxim that badly-managed implementation will take three times as long and cost four times as much as originally perceived, whereas a well-managed project will only take twice as long and cost twice as much!
Very often the original timescales are simply wildly optimistic, showing a glaring inability to comprehend all the steps required to change the way the business operates. This leads to steps being rushed - in particular that of getting enough of the key players together for enough time to really set out the processes for doing business differently. Once this has happened the business is engaged in an exercise in sub-optimisation.
Simply allowing more time doesn't address the problem. If the people throughout the organisation don't understand what is required then setting a cut-over date way into the future simply causes complacency and woefully-insufficient attention being allocated to the project. This then leads to corners being cut towards the back-end, when successive delays have led to project fatigue. There is often evidence of the goal being to simply get the system into live running and release the project team for other duties.
This can be made worse in large organisations where there are always the stories abounding of other sites having achieved their go-live date in far less time. Again, the pressure builds to forget the business objectives and the steps needed to ensure that these are realised.
As noted earlier planning and control systems remain at the centre of ERP. They also remain central to achieving the goals of good business performance. Furthermore, as technology has enabled ever greater processing power to be brought to bear on the creation and maintenance of production plans, the resultant systems have become ever more complex. MRP is now capable of far more that the simple batching and safety rules which accompanied the early versions of IBM's Communications Oriented Production Information Control System (COPICS). This, of course, was in the days when the first glimpse of an MRPII system the original purchasers received was the delivery of a number of black books describing the principles.
First step is often project team training
Beyond MRP, the systems offer combined material and capacity planning under the new umbrella banner of Advanced Planning and Scheduling. Sales orders can be automatically slotted into our plans based on the system's current knowledge of material and capacity availability. All sorts of algorithms can be used to calculate dates and when it comes to the number of ways we can configure sales order processing to handle part and multiple shipments, well, the mind boggles.
So, how do we learn about these tools? We can train our people in how our particular package's MRP module can be made to work. We can show them the umpteen parameters, what each one does and how they all interact with each other. However, should this be the first step?
Hopefully, the answer most people would give on reflection is a resounding 'no!' Would we install a new piece of modern, highly-complex production equipment by giving the task of deciding how to use it to someone having their first experience of the basic techniques available? Of course not. We would ensure that before we let people loose on the different facilities available with this particular piece of plant that they were fully up to speed on the basic processes and opportunities offered.
Yet, time and again we hear of people configuring the planning elements of an ERP system having no previous education in the fundamental approaches of master scheduling, MRP or capacity management. Some companies even appear to have gone about the implementation of one of the major packages with a conscious decision to get the system live and then put people through some sort of formal programme, such as CPIM.
Clearly this is a recipe for nothing more than disaster. The people who are setting up the system are defining the way the business is going to operate for the foreseeable future. Changing processes after putting in a sophisticated, all-embracing integrated system is very difficult indeed and fundamental changes are often impossible. Even where the system configuration can be changed on the fly, introducing new processes piece by piece can cause a complete breakdown.
The alternative? Some companies openly admit to having allowed the package specialists to define the system set-up? As well as being a complete abrogation of responsibility by management, how can this be justified? Software consultants are just that. They are not experts in our business, our products, our market, our production processes. They do not know our organisation or the capabilities of the people within it. They don't know whether our sales office staff can suddenly become fully-competent contract managers capable of setting out plans for the fulfilment of our customers' requirements, but the decisions needed during the system configuration phase are based upon precisely this knowledge.
So, then, clearly any failure to deliver significant benefits does not rest with the software? Aren't the packages full of excellent features delivered with sophistication? Well, life is not that simple. Whilst the latter is undoubtedly true, we have to remember one fact not often pushed, and never by the people selling the systems, is that sophistication and complexity may be viewed as simply two sides of the same coin.
In Eliyahu Goldratt's excellent 'Necessary But Not Sufficient' - an assessment of life in the business systems world in these days of all-singing, all-dancing packages - he describes the implications of this sophistication from both sides. The system supplier struggles to introduce new releases because of the interaction of all the different configuration options which make comprehensive testing a near impossibility. The customer battles to achieve benefits from the systems because the processes introduced are so complex. So much effort is expended on making the system hang together that insufficient thought can be given to really thinking through, and establishing the optimum approach, to all processes.
Another frightening thought is that the interaction of all the clever approaches adopted in the system means that people often fail to identify when the information presented is completely wrong - quantities do not meet requirements, dates are incorrectly calculated. In some cases the answer presented may in fact be correct, but people don't understand how it was reached, and therefore don't trust it.
The next step is that some users of the system begin to 'fiddle' things. One of many causes of potential problems may be that a storeman can't issue some component to a works order within the system because of an incorrect setting in the 'issue location' field. He can't work out why on earth he is getting this problem. The system experts are busy addressing many other similar problems elsewhere so he downdates the stock using an adjustment transaction. He doesn't realise that this leaves the requirement still live in the system and will lead to a buyer or material planner being presented with a requisition for some stock which isn't, in fact, needed. When the buyers get too many of these, some of which they know to be invalid, they begin to ignore system recommendations and wait for people to shout.
Modern systems are very sophisticated / complex
We then began to hear of the alternative approach being viewed on research trips to Japan. The early visitors came back as campaigners for something called 'Just in Time' which didn't need clever computer systems. We shouldn't go through all this complex master scheduling nonsense; we shouldn't use this massive and incomprehensible MRP with all its calculation of batch sizes and safety stocks; we shouldn't try and integrate all this to stock and shop floor control. All we should do is make or buy exactly the quantity we need of every single component, at exactly the time we need it - and we should so it using things called kanbans.
Now, of course, we all had to learn more, and learn more we did. We learned that kanbans on their own weren't the answer. We realised that Just in Time was far more than the introduction of containers which held a fixed quantity of an item and had the part number written on the card attached to the side of the container. We learned that all of this worked only when we had stabilised demand. We had to establish a consistent usage pattern by attacking quality issues and think about defect rates in parts per million rather than percentages. We had to attack variation by rationalising our products. We had to organise our production facilities around a flow, so that when the container with this part number on the yellow card arrived at a piece of plant, the operator didn't look at it and shrug, thinking 'they'll be lucky, I've got two weeks' work backed up here and I don't think I've got any material for that job in any case.'
However, we started to apply the lessons of JIT. We moved away from quality control in favour of assuring quality through design and through improved production processes. We rationalised product design to minimise variability. We attacked set-up times to enable lower batch sizes. We addressed the supply issues with our vendors by giving them visibility of our forward order projections and we helped them by showing them what we had been doing to organise and improve our own shop floor. We moved plant around to create a visible flow and we introduced communications between production areas that were simpler than big cumbersome reports produced by big cumbersome computer systems.
However, we also learned that we needed planning and control systems. We still needed something like MRP to translate our long term production forecasts into detail component requirements. The kanbans were fine for managing the execution phase of manufacturing, but if we didn't fill our supply chain based on our forecasts they simply wouldn't work for all but the simplest and most common of components.
Thus we came to define our ideal - using integrated systems but keeping things as simple as possible. Since then, we seem to have forgotten all these lessons - to the point when we have even computerised the kanbans. I wonder if this is the final proof that I am getting old. I've been through all this once, and I resent being dragged back over the same ground again.
So, then, is it possible to make a success of fully integrated systems, the sort of integration that means when one person in our organisation catches a metaphorical cold, everybody else is in danger of pneumonia?
The answer is undoubtedly a resounding yes, but it requires that a few basic ground rules be followed.
The first of these is to apply the most mis-named entity in the sphere of human activity. If common sense really were common we would have fewer motorway pile-ups in foggy weather, far less teenagers ignoring the evidence of cancer wards by getting hooked on cigarettes and fewer business systems being implemented to automate existing over-complex ways of working that stand little chance of success.
Step one of any successful implementation has to be to ignore the hype and mystique around anybody's guaranteed, 100% foolproof methodology which introduces a whole load of buzzwords and jargon. These approaches now abound and we have to remember why. They are designed either to help sell the computer system, or to sell the services of those who are looking to secure contracts to support the implementation. It remains a sad fact of life that buzzwords and jargon are often successful selling tools.
If we avoid the jargon we can set about step two, which is remembering what we are trying to do. We are trying to change the way we manage our business in order to bring about improvement. This is our one chance to establish long-term fundamental change so we need to make sure that we fully think through what our business is about, and how we should conduct it.
How Do We Get Success?
A standard methodology?
Of primary importance is launching the project with the right terms of reference. It is a business improvement exercise with specific business objectives - or at least it should be! Since we have these objectives we should be able to define measurement techniques which quantify current performance and provide an indication of progress.
We then need to pick the right people for the project. It is hard to be too specific as each organisation is a mixture of people and these are the most complex, most variable and most downright awkward of all the tools at our disposal. Key points, of course, are that we have to pick good people - progressive people who will look to move forward rather than hold onto the past. At the same time they have to be realistic, with a healthy element of cynicism which they will need to resist some of the gimmickry they will undoubtedly encounter.
We then need to ensure that the team have a full understanding of all the tools, techniques and concepts on offer to them. Their knowledge of MRP should not be constrained to the workings of the any particular package but should be build on an understanding of the basic building blocks of the approach - including learning from the practical experience of all those companies who have used the approach with varying degrees of success over several decades. The same applies to all elements of scheduling, of order processing, or purchasing management - in short, of all the areas of the business which the system will help manage.
As well as looking at the 'system' approaches the team will also need to consider where 'non-system' may be the answer. Some of the JIT ideas may be considered to be diametrically opposed to those inherent in computer systems - for example, shop floor control systems which rely heavily on operation booking with barcode readers and other forms of technology cut across the ideas of cellular manufacturing in which the only people who need to know the exact status of each order in a cell are the people in the cell. As long as they make sure that due dates are met, and give early warning when a date may be missed, why do we need to spend money on hardware and software, and time on the booking processes?
The education should also cover the tools which will be needed to introduce change. Basic problem-solving techniques, flowcharting, fishbone diagrams and the like can all play their part, as can the lessons of BPR - predominant among which in my experience are three basic principles. We should always keep things simple, we should look to manage by exception rather than trying to monitor everything and we should try to carry out as much of a process at one step as possible.
This last point may be considered 'JIT in the Office. ' We learned in the early days of JIT that components which were made in a series of operations on a number of pieces of plant were difficult to manage. They involved several set-up times and needed movement - and all the control mechanisms associated with this movement. The same things apply in the office. A sales order entered in a series of steps by different people covering product selection and specification, credit checking, delivery dating and documentation involves a series of hand-offs and a series of in-baskets. All of this brings delay and the potential for error.
The future then needs to be set out in broad terms - high level flowcharts and descriptions of the major tasks. The importance of this phase cannot be over-stated, and the time it takes must not be under-estimated. The team cannot work in isolation so will need a lot of access to other people in the organisation, including senior management. If the rest of the business has insufficient input to this process then the solution will not be right and, crucially, it will not be 'owned' by the organisation at large.
One excellent technique for the definition of the future is to hold a series of individual meetings with managers and key players throughout the organisation, looking at current problems and exploring potential alternatives, and then put these to a series of multi-disciplinary workshops. These workshops must cover processes rather than functions and hence need participation from all areas involved in a particular process.
For example, a business designing and making to order may wish to define the process for product specification and configuration. This process generates the output in terms of bills of material and component specifications used throughout the business so all the 'customers' who will use this output need to play a part, as do the commercial people winning and logging the order and the technical staff who carry out the engineering work.
To support these workshops often requires that the participants go through much of the education work that the project team have undertaken, in order that the workshops can run smoothly based on a common understanding of the techniques available and the opportunities which these techniques offer. Alternatively, the workshops may be structured around a combination of education and development of the future vision.
Having defined the future processes the next step should be to go out and select the package which meets the needs of this future process, but in many companies these days that responsibility is taken out of the hands of company management. Often the task is one of implementing the chosen corporate solution, so we will move onto the implementation phase.
Fully armed with education in the management concepts behind the system, the project team now need to learn about the particular package. Ideally, this should be handled in such a way that they only cover the functionality likely to be used in the future processes but this is not always possible. The training available on the software may be provided only in standard courses and, in any case, the trainers themselves may not be sufficiently au fait with the management concepts to adequately select and focus the sessions. In this case the team need to be quick to spot where the training is going down a different path than the business wishes to follow and ensure that this bit is skipped to avoid time-wasting.
Having learned about the system the team can then set about its configuration. A key point to remember is that the final solution is an integrated system so the team members must work together ensuring that nothing falls down the cracks between, say, sales order entry and master production scheduling or sales despatch and invoice processing. During this phase there will be need for a series of what some refer to as 'project team pilots' when the team members check that their proposed approaches hang together to make true process improvement, rather than the sub-optimisation of better individual procedures in different areas of the business.
Given the complexity of the systems this can take some time, and mistakes will be made. However, when the 'final' answer is arrived at the acid test is in proper piloting.
The first pilots confirm that the different areas of the system work in their own functional areas and move on to proving that the different areas hang together to provide a true integrated solution to business processes. The final pilots are about proving that the business will hang together with the new way of working - not just that the system works. All the supporting paperwork, the disciplines, the job functions and descriptions, have to be proven at the same time.
Key points then include making sure that the transactions are processed by users who have been trained in the system. These users will ask questions that the project team may have missed in all the detail of setting up the different modules of the package and, undoubtedly, they will trip the project team up. This is nothing to worry about - indeed, the most worrying circumstance of all is when they find no problems to highlight. This simply shows that they haven't given the exercise anything like the commitment it needs.
So, after the pilot, what next? Quite simply, consider the problems which arose and set about fixing them. This may mean changes to the set-up of the system, the provision of some bespoke reports or possibly changes to supporting activities. You may decide that the proposed way of working, which didn't quite hang together given the current allocation of responsibilities within the organisation, was almost a major step forward and rather than change the proposal you'd prefer to change the organisation to take advantage of running the system in this way.
Obviously the extent of changes made will then have to be considered. Are they sufficient to necessitate another pilot? The temptation will always be to avoid further delay and press ahead with actually being seen to have achieved something, but remember - the goal is to introduce a system and new ways of working which improve the business. We are not looking to say 'well, the system has completely blown our chances of shipping things on time and controlling the level of our inventory, but at least we got it in on time.'
At the point of completing a successful pilot we can, for the very first time, set a cut-over date with anything like total confidence. We now have a solution which works and all the steps from here can be given timescales with the expectation of accuracy. (Until now the major task was finding a new set of processes to improve the business. Who in their right minds could really say how long that would take?)
So, finalise the data conversion - which would have started much earlier but cannot be completed until all the decisions are taken. Are we going to use the 'ship complete' marker on sales orders? Are we going to use the dynamic safety stock calculation in the new package or do we need to bring the existing figure from the legacy? Are we going to continue with the current method of overhead recovery or should we use that clever new feature offered by this new system? Data conversion should also include all the steps which have been taking place for some time to clean up the data in the current system - and possibly a major stock-taking immediately prior to going live.
Training is something which could not have started earlier, other than for the project team and, later, the people involved in the pilots. There are companies out there who undertook mass training of users early in the project and lived to regret it because of its impact. These complex ERP packages can be run in a monstrous variety of different ways and to train people throughout our organisation in all the possibilities will do little other than confuse and frighten. Sending the bulk of our organisation to sessions where they are told 'we could run this way, or perhaps like this, or maybe like this' is not a good move. We are not looking to train people in the system per se but in the new ways of working. By definition, this cannot happen until those ways of working have been finalised.
As it is covering ways of working, the training must be supported by simple documentation in these new approaches - by all means use the terms appearing on the screens in the system, and include screen dumps as much as possible, but where these terms are not immediately apparent, explain them. One well-known system offers the MRP exception message 'Plan process according to schedule' which can cause some concern. Our documentation needs to say that this means 'the system's suggested due date is based on the item's standard lead time and is later than the actual required date, so try to get the item earlier.'
The one thing to avoid is system jargon referring to tables, field names and the types of programming or data extraction techniques. To the computer-literate (and we all have lots of these, even in non-technical areas of the business) such points may be of interest - but there an many to whom such terminology will simply add to a sense of foreboding and fear. This in turn leads to confusion and errors.
Ideally, we should run a major pilot with the converted data. How else are we going to find that somebody had the wrong idea of what a particular field was used for and how it would work? Finding that the system is giving wrong dates on all sales orders entered for a particular product family in a pilot is, to say the least, annoying. However, getting our first glimpse of such a problem while trying to run live is positively disastrous.
Then, having completed the training and the pilots using converted data, we are ready for the major step. Depending on the nature of the old and new systems the conversion can take some time and while every effort should be made to reduce this time, it is very likely that the actual content is not variable. We can and should minimise the elapsed time by utilising IT resources for the conversion routines but must remember that people working twelve-hour shifts on complex tasks are not the ideal recipe for success. Parallel processing of data input routines which can lead to locked and possibly corrupt records may also contribute to something other than data accuracy.
One point which has been not been mentioned since quite early in the presentation is that of senior management involvement. Hopefully, each senior executive would have maintained input to the exercise thinking 'this team are defining the future ways of working for my people and I want to lead them to get things right. ' At the very least they would all be thinking 'I'm going to keep an eye on this lot so they don't land me with an unworkable piece of nonsense. ' Sadly, there are too many case studies out there for any of us to believe that this is always going to happen.
To avoid this we recommend that from the outset, every manager in the organisation knows that ownership of the final approach, and of the decision to adopt this approach, rests with them. It may be that there are some in all companies who live under the misapprehension that if the element of the business process which comes under their wing falls apart when the system goes live, then they can blame somebody else. This has to be challenged up front by explaining to them all from the very beginning that when the time comes to go live, they will be asked to confirm that they take full responsibility for all that is about to happen.
This can, not surprisingly, cause great consternation as people realise that they can't ignore what is going on. They can't say 'oh, I'm to busy to get involved in that computer project' since if 'that computer project' results in their functional area falling apart then the buck stops with them. They need to understand what is being proposed and why, and they need to be able to argue from a position of strength over issues that will have a major bearing on their performance.
Each senior manager to sign acceptance certificate:
However, if these people are the senior management team, then surely they are the experts? The only reason they are not the project team is that we can't spare them from the business of running the business? The project team are spending time exploring the detail of all the system features and how they hang together but they should be doing all of this under the guidance of, and working to the objectives of, their seniors.
If all these lessons are followed ERP can provide a good framework for the management of information in the business. It does not address all the opportunities for improvement that are available to us these days but it allows a good basis of valid plans, properly controlled, which are the foundations of good practice.
The certificates may be a gimmick, and may never actually be signed, but everybody has to grasp the idea that the key point remains - senior management own the processes, will take the plaudits for any glory resulting from the ERP system and must accept the consequences for any failure. This is a business project and must be managed as such.
Three simple steps:
PHS Management Training - Copyright © 2019
For help, support, training and