A 2010 study by the Standish Group revealed that 60% of ERP projects fail in some measure and 33% fail catastrophically. What is interesting about this (other than the riveting horror of millions spent repeatedly for naught) is that while the reasons for these failures are known, finite and consistent, most ERP projects continue to fall like lemmings into these same traps year in and year out. Why is the barrier to ERP success so high? Having assisted on dozens of successful and some failed ERP projects, here are the Top Ten reasons ERP projects fail:
- Wrong System/Wrong System Design
- Bad Data (garbage in=garbage in)
- Poorly Understood As-Is Business Processes
- Inadequate Internal IT
- Inadequate Testing
- Inadequate Training
- Inadequate Planning
- Too Big
- Too Fast
- Poor Change Management
Let’s look at first things first:
Wrong System. Most of today’s ERP systems have their roots in the financial services function’s thirst for real-time, accurate business data. Back in the dark ages of the ’80s and 90s, the idea that technology could main-line business data to the financial office was incredibly compelling. ERP offered a way to track the real time value of assets like WIP, inventory and capital costs. Keep this in mind if you are a high tech company, a service company or a capital equipment company looking to implement ERP. Be clear about whether the value you seek is rooted in finance and HR or whether you also want to optimize your manufacturing process, supply chain and vendor/customer interfaces. If it is the later, the standard issue ERP software will not necessarily fit your requirements. When you stand your out-of-the-box/no-customizations ground, be sure you know what is in the box.
Bad Data. What is your approach and timing for identifying, cleansing and preparing the business data that will be loaded into your new ERP box? When it comes to ERP, if you don’t have clean, accurate data, you have nothing. Take the time to understand the state of your existing data: where is it? Who owns it? How will you eliminate duplication? How many people from what parts of the business must do this work?
Business Processes. While ERP is great software, the software alone cannot drive business value. If you only focus on the IT implementation, your business will run worse after the implementation than before. This is because you will now force people, who have been using all kinds of work-arounds to maintain your status quo, to use a system that is blind to the real constraints of your operation. We recommend that companies that are serious about ERP spend up to a year prior to implementation understanding, re-aligning and evaluating current and proposed new ways of working. Engage your people who own and execute the work, get advice from an ERP expert regarding how to organize this step. Be sure before you start that your unique customer, process, regulatory and production needs are well understood.
Inadequate IT. You will hire a systems implementer to set up and launch your new ERP software, but who will operate, maintain and upgrade it after Go-Live? And if you have no-one in your IT department today who has already been through and lived with an ERP system, you will have to pay your system integrator to do many of the tasks best done by your own people (legacy system analysis, configuration, testing etc.). This can add magnitudes to the cost of your implementation. Prior to buying any ERP system, plan for how you will train or hire the in-house staff you will need to support and maintain the software.
Inadequate Testing. Plain and simple. If you did not test it, don’t complain when it does not work. Use people who currently manage the process to test it in the new ERP environment. You can’t test everything. Be sure you are testing what is most important for Go Live success. Then you can tweak and adjust from there.
Inadequate Training. This mistake occurs because businesses rarely anticipate the time it takes to develop customized ERP training. ERP training must be customized because every business is unique. Training must consider, who must be trained, in what locations, using what virtual tools, on what schedule, by whom and with what content. This is a large undertaking.
Inadequate Planning. As you can see from items 1 through 6, doing ERP right requires pre-ERP planning. And the planning does not stop once the system and the integrator are selected, it intensifies. Many projects fail because the business case was hastily crafted and filled with unsubstantiated assumptions and faulty metrics. We recommend a customer focused lean six-sigma approach to planning ERP to ensure that the right metrics are driving real project outcomes.
Too Big. Scale and complexity are guaranteed to drive your cost up, quality down and schedule to the right. So chunk it up, scale it back and pick a pilot that has a high probability of success. You can build on success. You go no-where but down after failure.
Too Fast. Be realistic. How fast you can go is directly correlated with the quality and availability of required skills, the cleanliness of your going in processes and data, and the change readiness of your enterprise. If you are below par on any of these, you will need more time. A good ERP consultant will be able to guide you to estimate how much time each phase should take. Be realistic. Vet your estimate eight ways from Sunday. Then fully commit to the schedule. It controls 80% of potential cost over-runs.
Poor Change Management. Let’s assume you are doing 1 through 9 reasonably well. While you are assessing your business processes and IT capabilities, you should also assess your organization’s readiness for change. As you craft your rock solid business case, mine it for both the benefits and the impacts it will have on key stakeholders, vendors and customers. Implement a steady cadence of communication, coaching and training, tailored to your key stakeholders. If you fail to do this you will likely have done steps 1 through 9 in vain. And if you fail to do steps 1 through 9, all the change management in the world will not save your project.