It is common knowledge within the manufacturing industry that errors made while selecting ERP software packages can doom projects before they even get started. Yet, not much has been written about some of the more subtle aspects of managing the ERP selection process -- many of which can make or break an
Learn the manufacturing industry jargon
There are ERP packages that support different types of manufacturing operations. For example, some vendors may state that their packages support companies that use models such as build-to-order or assemble-to-order, build-to-stock, configure-to-order or engineer-to-order. Other vendors claim their system capabilities address discrete, batch, repetitive and lean manufacturing. Adding to the confusion is the fact that many companies do a little bit of all the above. Moreover, none of these attributes are unique to the manufacturing industry and can mean different things to different people (including many ERP vendors).
Prior to choosing an ERP package, project leaders should become educated on the industry definition of these operational models and practices to prepare the company for the software evaluations that lie ahead.
Define what, not how, when selecting ERP software
When implementing a new ERP system, it is important to recognize that things will change. Even if everyone loves the old system, the new system will not look like the old one. Also, keep in mind that any new business processes that were defined prior to selecting ERP software are rarely implemented as originally envisioned.
More on SAP software selection
Learn the value of proper ERP testing
Find tips for planning ERP site visits
Read advice on managing ERP consultants
When developing a list of software requirements, focus on what the software must do, not exactly how it should do it. Remember, at this stage we are trying to select the best software tool, not implement it. Focusing too much of the "hows" can limit the flexibility of any package to address the requirements, since there is usually more than one way to efficiently accomplish a task. It can also lead to the potentially false conclusion that a particular package is not a good fit, when really the requirements are too rigid.
Avoid a software 'beauty contest' when choosing ERP
ERP software demonstrations are where the rubber meets the road. If these sessions are not managed correctly, bias and subjectivity will taint the evaluation process as vendors attempt to turn the demos into a beauty contest. Beyond a list of software requirements and process scripts for the vendor to demonstrate, the evaluation team leader must take the following additional steps:
- Create an equal forum for all vendors. The meeting place for the demos, the agenda and the delivery method -- sales team on-site or remote -- should be the same for each vendor. This is about leveling the playing field. For example, if one vendor performs a demo on-site and another does theirs remotely, which vendor do you think has the advantage?
- Request that each vendor send their A-team. If the ERP software demonstrator is not familiar with the software, he or she can make a good package appear inadequate. It is in your best interest to understand what the software can really do.
- Vendors should demonstrate the software you plan to implement. Avoid demos using software and technologies that are not representative of the actual product or a version that will be used.
- The evaluation team leader must be a referee. Vendors and clients come from different worlds and use different terminology, thus much can get lost in translation, leading to invalid software conclusions. During the software demos, make sure the vendor is demonstrating the software, not just talking about the software's capabilities.
- Educate the team on how to properly apply the package scoring system. For example, the highest possible score for a requirement is achieved only if the system fully addresses the need right out of the box, with no procedural workarounds or client modifications.
- Do reference checks beyond the marquee accounts. Remember, the objective of a reference check is to uncover issues, and most marquee accounts will not fully disclose them. While it is valuable to understand all the good things about the software, it's important to understand the bad things as well -- so ask for and check other references.
About the author:
Steven Phillips is an ERP professional with over twenty-seven years of implementation experience. He is the author of the book Control Your ERP Destiny, available at Amazon, Google Books, Barnes & Noble and through many other international booksellers.
Follow SearchManufacturingERP.com on Twitter @ManufacturingTT.
This was first published in March 2013