The first ERP implementation I got to see up close was a mess. The company (let’s call them Acme) received some bad advice from their implementation partner, and they tried to do several things all at once with a “big bang” launch:
- Switch their approach from “make to stock” to “make to order”
- Switch from weekly to daily schedules
- Implement a new ERP System for their entire product offering
The conference room pilot went okay. However, it was focused on a limited number of products and an artificially simplistic flow of information. There was no way to test the system at scale with this approach, and in the end Acme suffered for that. Their overly simplified pilot convinced the team that they were on the right path and ready to go live.
The big day arrived, the switch was flipped and the Acme team was immediately inundated with paperwork. Thousands of pages of paper were printed out. Orders were flowing to the plant floor without requisite pre-work. Component part orders were missing or out of sequence. Inventory counts did not match reality. Any existing control over the manufacturing process was quickly lost.
In a matter of days, Acme was in a total meltdown. There was no way to go back, and the only thing they could do was jump in and dig out of the mess they had made.
What happened?
A Good ERP Implementation Requires Good Data
One of the first mistakes Acme made was that they never used their own data in the selection and implementation process. During the system selection phase, they saw many demonstrations, but all were performed with source data on a disk drive from a fictional manufacturing company.
Acme manufactured beautiful, well-crafted furniture from raw materials; the fictional demo company was basically an assembler of materials sourced elsewhere. Sixty-two percent of the product Acme produced was “special,” meaning that it was customized in some way (and often many ways) from the base product in the catalog. The demo company manufactured products exactly like the product in their catalog, and their whole approach was based upon uniformity.
So, even though Acme and the demo company’s data were from the same industry, the businesses were actually very different. Unfortunately, understanding how the system would work with highly crafted or “custom” products was not a focus of either the ERP selection process or the implementation for Acme.
Know Your Workflows to Avoid Hassles During Your ERP Launch
To compound the data issue, Acme had invested years of effort into highly tuned processes that fit their business. Again, there was no focus on understanding how those processes would work within the new system. It was just assumed that things would flow as easily as they had before once the bugs were worked out of the implementation. Further compounding these issues was the switch to daily scheduling and “make to order” as an approach to their manufacturing, because those processes had never been established or tested prior to launching the new ERP system.
Things continued to spiral out of control. Orders were lost, customers were upset, and profits were nose-diving. Acme Management decided they needed a measurement that would help them understand how bad things were, and to use as an indicator of improvement as they worked to improve things, and they decided on one simple measure that they called the “misery index.” The index was calculated by multiplying each order line by the number of days its orders were late and taking the sum of those results across their business.
The misery index quickly skyrocketed into the high hundreds of thousands.
Over time, Acme made improvements, cut down on the paperwork and regained control of their manufacturing process again, but it took almost eighteen months until they were able to drive the misery index into the low thousands, where it should have been. In the meantime, profits were low (sometimes non-existent) and business suffered, as did their reputation.
Don’t Fall Into Common ERP Implementation Traps
How could all these issues (and their consequences) have been avoided? The most obvious path would have been not to try to change the manufacturing process so drastically while a new ERP system was being implemented at the same time. So many big changes all at once are too much for most organizations.
A more realistic approach would have been to pick one thing to change, make that change, work out the kinks and then move to the next. Tackling so much at once was a recipe for disaster. Workflows became confusing, the root cause of any particular issue became harder to identify and employees were overwhelmed.
Improve Alignment Between Your Steering Committee and Project Team
Another possibility would have been to go ahead with the entire change package as described, but only for one product line instead of all products. Admittedly, this approach would take longer and would have required a higher up-front investment than only focusing on one change at a time. However, identifying and fixing major issues on a small subset of products and processes is much less expensive and disruptive in the long run, as Acme discovered.
A less obvious path could have been utilized very early in the process: Acme should have requested a demo of the system with their products, data and processes included. Trying to evaluate which ERP system was the best fit based upon an entirely different product and business model just doesn’t work. In the end, there were too many unknowns, too many surprises and not enough planning.
Get the Most Out of Enterprise Software Demonstrations
At Vervint, we meet clients wherever they are in their ERP journey rather than asking them to meet us where we are. Doing so helps our team align closely to client needs when we help them to select ERP systems (or any enterprise software system). Our approach, in every project, is to coordinate a set of demonstrations using our client’s products, data and processes. We call this exercise a “Day in the Life.”
It takes a lot of effort to analyze, build and document everything for the software vendor(s) to set up tailored demonstrations. But selection teams gain a much deeper and accurate understanding of how different systems will work in their business’ day-to-day instead of relying on an artificial world created only for quick and superficial demonstration purposes. Sometimes, software vendors are resistant to this approach because it requires more work for them than canned demos. However, we have a great deal of experience helping vendors understand the value of this work for our clients and the opportunity it presents.
We also use research, data and scripting created in the “Day in the Life” to build aligned, standardized scorecards for evaluating potential enterprise systems. This allows the software selection team to focus on the most important features and functionality necessary for their operations during the demonstration. This approach also puts a microscope on how each platform can fulfill (or exceed) the company’s requirements rather than letting the vendor’s sales team steer the conversation in different directions.
Looking for ERP Selection Consultants? Vervint Can Help!
If your team is considering new enterprise software systems (or you’re struggling with the after-effects of a recent change), our experts can help. To get started, contact Vervint today! We look forward to hearing from you!
