The “How-To-Guide” to Start a Successful ERP Implementation
Search the web on “ERP Implementation failure” and you will be faced with a myriad of horror stories, as well as various studies indicating that somewhere between 50 and 70 percent of ERP implementations are considered failures. There are a lot of ways that these projects can go sideways, but the key to success is simple: well understood and defined goals.
Unfortunately, the problem that implementing a new ERP system is attempting to solve is often not well understood. An ERP project starts with the acknowledgement that the current system is outdated or not meeting a company’s present requirements, but often not enough time is spent up front exploring the shortcoming of those requirements.
Determining the company’s system requirements up front will begin defining a clear set of goals and objectives for the ERP project. With a clear set of goals and objectives in place, decision making in all aspects of the project becomes much simpler.
Why is the software being implemented?
What are the desired outcomes?
What will constitute a success?
Why the software is being implemented is answered once the key decision makers have defined the needs that the company is seeking to address. After that, it is helpful to try to attach a dollar figure to the need, as these would be the desired outcomes. If improved sales reporting is required in order to better define a company’s desired product mix, how much could profitability be potentially improved? If improved inventory control is needed, how much is currently being lost due to the present inadequate controls? If poor cash flow forecasting is the problem, what is the financing cost that could be potentially reduced? There may be hesitancy to attach an amount as there is always some guesswork involved. However, any guess is superior to not attaching a value to the goal at all, as you need to have an idea of what are the desired outcomes you are aiming for.
Once goals have been established and their value is understood, potential costs of a system have a context within which they can be measured. The estimated value of the desired outcomes may not be fully attained and there may be cost overruns, so it is clear that the potential value can not be equal to the cost. However, if you begin with a three-to-one value proposition, even if you only achieve 60 percent of your goal and you exceed the budget by 50 percent, the project is still clearly a success because it has added value to the company. Determining what constitutes a success will allow you to match your desired outcomes to the costs of the project.
Mapping Out ERP System Requirements
To better define the roadmap of a successful ERP implementation, a requirements review helps to understand how an ERP system can fill existing gaps in a company’s infrastructure. It answers the question:
How are we going to set up business processes that satisfy the identified needs?
The steps in setting up business process requirements need to keep the project goals in the forefront and work to mitigate the risk of cost overruns. Cost overruns are most common due to scope creep and seep, and due to required rework. Scope creep happens when users ask for functionality that was not defined as necessary to fulfill the project goals. Scope seep is similar, but occurs when the vendor adds functionality to the implementation that was not requested. In order to reduce these risks, the heavy lifting needs to be done up front in terms of project planning. In the words of Dwight Eisenhower, “Plans are nothing; planning is everything.” The planning process has the potential to increase the understanding of both the company’s current situation as well as better understand the goals.
Look closely at the goals and objectives you are hoping to achieve, and start to review your current processes and system to find where the gaps exist. This is the stage where Event-driven Process Chain (EPC) and Business Process Modelling (BPMN) diagrams can be very valuable. There are many tools available on the Internet to create these, but it is at this stage where a good Business Analyst can be a powerful asset. If you have a relationship with an ERP vendor, they may have staff that are well versed in these techniques. Start by documenting the current state, and then try to define how a process could work where your objectives are being met.
In addition to mapping out requirements to meet your goal, you need to map out requirements that are already being adequately addressed by your current system. If you are replacing an existing system, understand your current processes in all of the key areas that it addresses to ensure that no new gaps are introduced.
When you understand your goals, where you are, and where you want to go, product selection becomes important. Prepare to be bewildered by the features and options presented to you in demos and meetings. Things you had never considered may be presented as “must-haves”.
Your job now is to remember your goals and refer back to the planning you have done. You are looking to solve specific problems and you know the value possible when you fix those issues. That is not to say that you shouldn’t have an eye to your future needs and possibilities, but these are not the items on which to base your decision. Find a product and a solution provider that can clearly fix the issue as well as meet all of your existing process flows with a minimum of number of customizations. A re-seller with experience in your specific industry may be helpful, but more important is a vendor that clearly understands what you are trying to do and focusses on that, rather than showing you the prettiest and slickest package in a demo.
Picking the Solution and Solution Documentation
What elements of the software are needed and how will they be configured to achieve the processes defined in the Requirements?
When you have selected a vendor and a software package, your requirements package will guide you through the next stage of planning: the solution. The solution needs to address all of the requirements that were defined as either necessary to fulfill the project goals, or to match current functionality. As you define what will be implemented in the solution documentation, always check to see if the functionality can be directly matched to a defined requirement. If not, it is likely best kept out of the project and can be reviewed after go-live.
Functionality may be included in the base product, but every piece that is implemented represents a cost to both implement and train. By enforcing the need to match up to a defined requirement, you can manage scope and ensure that you achieve the items that were defined as being truly important.
Failure is most often defined as not achieving the desired objectives, or achieving them at too high a cost. By clearly understanding the needs and using that understanding to shape your implementation decisions, both you and the vendor you have partnered with are in a position to be on the right side of the equation. Know what’s important, stick to that, and don’t let yourself be distracted. The rest is just details.