RSMUS.comFor some of you out there, reoccurring childhood nightmares were replaced at some point in your life by a horror that many cannot imagine. This horror is the long and painful failed ERP implementation. To set the stage appropriately, I’d like to define failure as either 80% of budget spent and the project never being implemented or re-implementation of another solution within a couple years. The problem with a failed ERP project is that outside of extreme cases of gross negligence or misrepresentation, the warning signs of failure are there and the problem is known at a time where corrective measures could have been taken to save the day. Nonetheless, sometimes they fail.
The following are the top three real world reasons an ERP project fails.
1. Lack of Managerial Ownership and Buy In
ERP projects are large undertakings often with deep ties to how your people work. Plainly said, goal setting and direction need to come from executive management – operational and financial areas equally – for an ERP undertaking. If the senior management of a project are all on board with the goals of the initiative, that message will reverberate downward and those who have to complete the detailed litany of decisions needed to complete an ERP project will make better decisions knowing this.
2. Change Management
The change management that I mention here isn’t the area of focus of many ERP projects. I hate to let the cat out of the bag, but you probably did not want to pay more than you felt necessary or should in your sales cycle, and paying for the management of change management may have been left out.
As an aside, I’m writing this on a flight to a client site and I’m looking over my shoulder, prepared for one of our sales reps to give me the evil eye as if they know I just made their job a little harder.
ERP Directors, Managers and consultants are in the software consulting business, traditionally. Pro-actively tackling a problem that deals with inherent issues in culture and processes is not something for which many people will volunteer. Organizations can employ their ERP delivery partner to manage the big picture effects of the work you have contracted them out to do. This is recommended versus doing nothing proactively.
3. Poor Fit and Function
This one is different than the first two in that it is harder to assess without trusting an outsider if you are part of a selection committee or executive management. Fit and function are related to whether or not two key areas are being achieved. 1) If the solutions provided by both the overall ERP package or the solutions of the implementation firm are a good fit for your company and 2) if the functions you need to do are provided for out of the box. As such, there are two accepted norms at play here. One is that you are willing to accept the rigid software’s solution as your new normal and adapt to it. The other is that you customize the heck out of whatever software you choose to fit your processes and people. There is merit to both of these solutions.
I might suggest, however, a hybrid approach. Pick a solution where you believe the vanilla solution fits your business and implement with this assumption. Modifying the system, for systems that are flexible enough to allow modifications, should be reserved for core business critical gaps. For non-business critical gaps, process changes should be employed. If you do this well you’ll be operating a solution that is 80% vanilla and 20% custom.
There it is – the definitive end all be all to ERP deployment failures. Well no, not quite – but if you have these three things in mind as you progress through your new ERP selection and subsequent deployment, you’ll be better off than most.
Jeremy Greenwood
