Last week, we cited an industry article about alternative ways of implementing ERP systems. The article gives an example of a large ERP implementation that challenged the traditional notion of going live via a “hard” cutover at go-live. Instead, the profiled organization stuck to strict deadlines, went live on time, and made changes to the system as needed going forward to address any functionality gaps that were missing at the initial go-live.
In some ways, a more iterative approach to ERP software design, development, and go-live is a refreshing change from the typical project that misses duration and budget milestones. However, there are three significant risks to this approach:
- Organizational Change Issues. First, this approach creates organizational change management issues. On the one hand, this approach helps create buy-in and ownership of the new system. However, ERP change is significant enough as it is, so going live without having worked through at least the major issues can be disruptive and demoralizing to the average employee. In addition, users become very frustrated when their system changes from week to week due to new enhancements or updates to the system
- Business Risk. The organization that was profiled was an educational institution, and the ERP focus was on financial functionality. The article notes that there were problems processing paychecks as a result of going live without hashing out all the kinks. One could argue that a few missed paychecks aren’t too big of a deal, but the consequences could be much more severe for a manufacturing or distribution company that finds it can only ship a fraction of its normal volume after go-live. If I were the CEO of a manufacturing or distribution company, there is no chance of me being comfortable with this approach given the high level of business risk and uncertainty around this style of implementation.
- Lack of Clear Requirements and Functionality. There is something to be said for drawing a line in the sand and saying that you won’t go-live with the new system until key business requirements and functions are fully developed and tested. Going live without ensuring that key business needs are met and thoroughly tested is risky and irresponsible at best.
- Difficulty Managing System Changes. The flexibility of ERP makes a more iterative approach more possible; software can constantly be changed as needed to meet evolving business requirements. However, such flexibility can create somewhat of an operational mess if not managed appropriately prior to and after go-live.
So what’s the “right” way to implement ERP, assuming there is a right way? The answer is somewhere in between the two spectrums. There’s something to be said for both approaches. The traditional “design-build” ERP implementation strategy has some structure that helps minimize risk, but it lacks some of the urgency that the alternative approach affords. The alternative approach, on the other hand, creates a sense of ownership and urgency by ensuring a broad set of employees are working out the kinks in the system, but it also neglects key functionality that should be in place prior to go-live.
The best thing is to try to get the best of both worlds. Clearly defining requirements and making sure the system meets these requirements prior to go-live is critical. At the same time, there is some value to having people start using the system before all the detailed kinks are worked out.
When we at Panorama Consulting advise our clients through ERP implementations, we typically suggest a “soft” go-live with a core group of employees several weeks before the official cutover, which serves as a way to get people comfortable with the system, test the system using real data, and work out kinks along the way. This helps balance managing business risk with creating a sense of ownership among employees, which is critical to an ERP organizational change management program.
