Implementing Manufacturing and Supply Chain Systems

To Save Time and Money, Get Back to Basics



Ian Batey of IDMB Advisory gives ten tips for success when choosing and implementing new IT systems.


When I first started implementing manufacturing systems in the mid 1980s, life was simpler. The systems (ERP, MRP II, etc.) did what they were supposed to do, and opportunity for tweaking was limited.  The journey from idea to implementation was rarely more than 18 months.  Implementation itself took less than a year and cost between £200K and £400K for a typical medium-sized manufacturer.  Today the same business will take two years and spend 10 to 20 times as much for a new system implementation. Yet surveys don’t show an equivalent increase in either performance or satisfaction.  Even accounting for inflation – and increases in capability and expectations - this is scarcely a change for the better.   However, it’s not really the products that are to blame, though they all have their quirks. By and large they work. And they can be made to work well.

Trial by Tick-Box

So, what has gone wrong? Firstly, we got what we deserved.  Year by year, increasingly pernickety users moved towards a tick-box approach, choosing systems on the number of boxes ticked. By way of response, software vendors added more and more functions and features in a process that added little of real value while seriously complicating the overall solution. 


In addition, the pace of development and the need for flexibility led to architectures characterised by separate modules. It is true that the modular approach can help ‘future-proof’ the system by letting you replace or upgrade one module at a time, as with hi-fi. But the problem is that in many cases the modules require expert integration - by highly skilled and expensive IT professionals – to work together effectively.  The net result is difficulty in seeing what the end-solution will look like. There are also serious challenges for those tasked with making the solution fit your business, and almost certainly much confusion for end-users.  It’s an environment that leads to long design cycles, protracted blueprinting, little opportunity for trial and error - and an almost inevitable, ‘that’s not what I specified’ at user acceptance stage. 

My Ten Tips for Success

Although implementing these systems can be complex, with multiple interwoven issues, there are steps you can take to make life simpler, increase the quality of the outcome and speed up the whole process.  This starts long before you even choose a solution! 


Tip 1: Have an executive level sponsor who dedicates sufficient time.

This has been said before but it’s emphatically worth saying again!  Ensure you have executive level sponsorship – and ongoing involvement - from someone able and willing to devote serious time to the project.   And make sure you use your best people on the project. After all, you will be a hostage to their decisions for years to come. You will also have to give them fast access to senior decision makers.

Tip 2: Make project progress an executive agenda item.

It is also vital to make progress-tracking a part of your executive agenda. To keep things in control, formalise your project disciplines with rigorous processes that cover scope, risk, issue, budget, plan, quality and time management.  Hold weekly project meetings and (at least) monthly executive steering group meetings. 

Tip 3: Focus on fundamentals to define your requirements, not on tick-boxes

It is important to avoid tick-boxes, wish-lists and personal agendas when defining your business requirements.  Don’t get hypnotised by ‘features’ – the many bells and whistles available in modern systems, most of which you will use rarely or never.  The tick-box approach invariably leads to over-engineered solutions which virtually guarantee a real struggle to make the system fit your business.  Despite the internal noise and posturing, experience suggests that most businesses have a core which is absolutely common with everyone else’s.  The trick is to focus on the handful of things which are truly unique and provide the process differentiation for your business.  This ‘back to basics’ agenda should be the thread by which you navigate through the whole of the implementation cycle. 

So, what are the questions you really need to answer?

  • Which business processes are fundamental to driving my competitive position?

  • Which package will give me a real edge in these areas?

  • Is the package competent in supporting the other, less core, aspects of my business?

Tip 4: Navigate the selection maze by focusing on the critical issues

The key thing is to insist that potential vendors describe how their system will handle your critical processes.  (Remember how an exam question which needed an essay response was harder but demonstrated much deeper understanding than a multiple-choice exam?) And during the demonstrations force the vendor to show you how your critical requirements will be met.   You will almost certainly need two suppliers - the software vendor and the configuration partner (the company tasked with ensuring that the software is properly mapped to your business). Are you satisfied you can work with them?  Will they commit to delivering the benefits and sharing the risks? What is their track record? 

You must evaluate the vendors - not just the package.  Can they effectively make the link between what you need and how that would be delivered in their package?  You may find you need to employ an independent expert (apart from the software vendor and the configuration partner) to translate the IT jargon into plain English and to ensure that ‘user assurance’ is built into the project.


Tip 5:  Prototype before you purchase

You will need to validate the preferred choice with a prototyping ‘pilot’ exercise before purchase.  This is a hands-on session carried out in a conference room which uses realistic data and real-life challenges, situations and issues to show your team just what is involved - and what the solution is expected to do.  Use this as your first test of the capability of the package and your relationship with your suppliers.  This will cost money but pay dividends.  You should be looking hard at the vendors (i.e. the software vendor and the configuration partner) and at your own team.  Done correctly, this stage will test both the package and also that your own team understands how the final solution will behave when built.

Tip 6:  Keep saying ‘show me’ throughout blueprinting

Having done a prototype, the blueprint process should be much easier and consist of fleshing out the prototype to agree the detail of the eventual solution.  At this stage the tendency of the vendor will be to ask for signature of a paper document stuffed with incomprehensible information about system settings.  I defy anyone to understand exactly what they are signing off at this stage.  To minimise the risk of signing up for something you didn’t intend, ensure that the vendor/configurer walks you through a ‘mock-up’ of the solution using a combination of real software, screen-shots and PowerPoint explanations to describe the blueprint in ‘how the business will use the software in its day-to-day operations’, rather than technical settings.  
If you’ve got someone acting in the translator role, then get them to guide the ‘show-me’ events and give them responsibility for user assurance. It is their job to ensure that the relevant events are done, but not to ensure the solution passes the test… that rests with the configuration partner.  Make this the first step in your development of user training materials. 


Tip 7:  Ensure that the test scenarios cover your requirements.   

At this point, the technical team will be working on the innards of the software and will need less support from the business users, other than occasional business clarification.  At this stage, you should be worrying about all of the myriad tasks needed for you to get ready for the solution:  user acceptance test (UAT) scripts and acceptance criteria, data sourcing and cleaning, communications and change, super-users and help desks, etc.  Whilst there will be a tension with their ‘build’ workload, you must ensure that you get sufficient knowledge transfer from your configuration partner at this stage to allow your inexperienced users to specify tests efficiently.  Your team will know what they asked for, but at this stage, only the configurers will know exactly how the solution will work. Thus, you will need skills of both parties to script the tests properly.  Your User Assurance person should ensure that the test scenarios cover all your requirements.  


Tip 8: Take charge of data conversion 

Though not strictly the province of the end-user, it can be enlightening to witness key integration tests where the software has been knitted together.  It can save repeating tests at UAT and highlight areas UAT needs to pay particular attention to. 

Assuming you are converting data from an old environment to the new one, then you should absolutely get involved in validating that the data conversion and trial cut-over tests produce the correct information in its new form. 

Tip 9: Make sure what you get is what you signed for. 

‘User Acceptance Testing’ is the last chance you have of making sure that the solution is what you signed up for.  You should make sure that you have a very structured (and scripted) approach to this process.  The test here is ‘does the system meet the requirements as defined earlier?’ and not ‘do I like the solution?’ 

There will be a tendency for users to want to change things at this stage. You should resist this vigorously!  In most cases, changes here reflect badly on your user team rather than the configuration partner.  It means either that users were not precise enough in their definition of requirements or that they didn’t pay enough attention during blueprinting.

Delays now will be very damaging to the project timelines so a pragmatic approach involving a risk review of any emerging issues will allow you to make progress while still holding the line on critical items.

Tip 10: Plan for an intense learning period post-go live.  

Assuming you have properly conducted the UAT and trial cut-overs, the main issues here will be around training, user access/roles/permissions and the general change management issues everyone faces.  You should plan for an intense ‘learning period’ and ensure you have a strong set of ‘super-users’ who have been intimately involved in the UAT (and training).  These will need to deal with the myriad of ‘how do I?’  queries which emanate from even the best trained users.  

Technical resource should be made available for ‘hyper-care’ to ensure that any technical issues or questions can be resolved quickly. And of course you will need an accessible and searchable list of FAQs to encourage a cost-effective, self-help approach to smooth running. 

Success Won’t Happen by Chance

Success in manufacturing or supply chain systems is not a matter for chance; it is about implementing rigorous controls consistently throughout the life-cycle of the implementation.  Forcing the description of the solution to be in ‘business speak’, rather than technical jargon will improve communication and reduce misunderstanding.  Making your configuration partner conduct regular knowledge transfer sessions will ensure that when the solution is built, you will be ready to use it.  Finally, remember that successful and unsuccessful implementations can and do still happen.  But follow my tips, remember my ‘back to basics’ message, and you will boost your prospects of success and remove a great deal of risk. Good luck! 

Ian Batey


Ian Batey has spent over 40 years in various line roles in manufacturing, IT and management consulting.  He has advised at both management and board level  across the globe and been responsible for dozens of successful operational improvement and IT implementations.

View my profile on LinkedIn