This rather dramatic statement (that was wholly justified now in my opinion) came from a manager responsible for an operating division thrown into an ERP software project at the last moment. It is an extreme but great example of ignoring key change management principles in a mid-market ERP software implementation project.
The story
It was the mid-1990s when I was the account manager and part-time financial consultant on a manufacturing project. There were two operating divisions in the customer’s business operations. The first was a “make to stock” manufacturing division where all items produced were based on standard bills of material without any customization or configuration. Let’s call that division “Alpha.” The second division, “Beta,” manufactured all of their items based on specific customer orders and rarely stocked any finished goods.
The company started off with excellent intentions. Alpha was selected as the first division to be implemented and went through a rigorous requirements analysis and proof of concept. All identified gaps were reviewed and accommodated or parked. All Alpha key stakeholders were involved in the project and appeared to be onside with the change. Then one key event happened and all of that excellent foundation went out the window.
For a number of business and practical reasons (of which cash flow was probably one) the company decided to include both divisions in the initial roll-out of the ERP manufacturing solution. None of Beta’s key stakeholders, except a few key executives, had been involved in the initial requirements and proof of concept activities. Besides this very fundamental problem in not involving the future Beta users, the difference in manufacturing processes was glossed over. The management of the shop floor and replenishment was completely different, which lead to a host of problems.
One day while I was onsite during the project I had a discussion with one of the Beta operations managers, which is where the quote came from. I was able to get around the problem because of strong executive support, but the project was severely compromised by ignoring these few key issues. At the time, I simply did not know enough about manufacturing, or even change management, to understand what was happening, although it seems obvious now. While the software went in, both the process and end result were challenged and may have been a key factor in the company fading into obscurity as they lost out to their competition.
The lesson
The sad thing is with some forethought, the project could easily have been saved early on, although at an incremental cost in consulting services. When the decision to involve the second group was made, the Beta stakeholders should have been included in a supplementary requirements review with representatives from Alpha to determine what the differences would be. A revised project plan, assuming the product was a fit for “make to order,” could have been drawn up to allow both divisions to go live in the first phase. The Beta users would have felt heard and key issues would have been dealt with upfront.
The message
The bottom line of this example is to make sure you always involve the key stakeholders necessary for the scope to be implemented in your new ERP software project. If you find a mismatch, take a step back and resolve the issue. Your users and organization will thank you.
For more information and advice on managing mid-market ERP software projects, whether manufacturing is involved or not, please contact us here.
*How time flies! 2020 has arrived and we’re working on some exciting new additions. Read our recent blog here to learn more about how our ODT family of Dynamics 365 Business Central extensions on Microsoft’s AppSource will grow significantly in 2020.
