Most businesses use some form of an Enterprise Resource Planning (ERP) system. Many have a terrible time during initial implementation or during subsequent upgrades. Despite this, ERP systems are here to stay. ERP systems (such as Oracle, MAS90, and SAP) are the information systems used to take, manufacture, ship, and account for customer orders, as well as to manage finance, purchasing, sales, planning, and inventory. Once you convert to an ERP system, upgrades and transitions to new systems become a fact of life.

Miss-managed implementations can temporarily cripple operations, cause sharp spikes in workload and stress, and negatively impact the bottom line in a manner far greater than the projected project costs. Research, such as the Standish Report on Project Success, indicates that most implementations go poorly. In fact, only 34% finish on time and within budget, while the rest are either abandoned in midstream (15%), or incur cost and schedule overruns or missing functionality (51%).

The ideas below are not a prescription for all implementations but rather a set of critical levers that may apply to your situation. The list only includes items that I think are often missing or done in a haphazard way. As you think about your situation decide which levers to pull in order for your implementation to be as successful as possible.

Obtain support from the top but build support throughout the system – The top leader in your organization must make it clear to everyone that you are implementing a new system and set the expectation that the success or failure is dependent on the whole organization, NOT just the project team.

Set the scope to minimize the impact on the manufacturing floor – Many businesses have multiple systems from different vendors. Each ERP implementation project must choose which old systems get replaced or interfaced into the new system. The process of building appropriate scope should be discussed with key managers with as much clarity as possible as to the risks and benefits to each decision. To the extent possible the manufacturing floor systems should be kept intact unless a clear advantage is shown in replacing the existing systems. If you disrupt the floor, the pain to the customer, and thus to your bottom line, can be immense. The Business Unit I worked for retained our floor system; other BU’s did not and paid a tremendous price for it in the form of missed deliveries and disgruntled employees.

Don’t sell it once it’s bought – Tell the end users with as much clarity as possible what you think they will gain and lose as a result of the software systems. Do not sugarcoat anything. Be honest about how difficult and the amount of work the implementation will require. Most end users have been through system changes before and know that it can be very difficult. If you are upfront with them they will respect you more in the end. On the other hand, if you only point out the great things the system will do while ignoring the constraints, potential problems, and amount of work, you will not only build resistance to the new system but potentially damage your credibility.

Spend time educating the managers above the people who will use the system – The project manager must spend significant time educating key managers on the project. Keep them informed regarding next steps in the time line, project issues, potential problems, key decisions that must be made, and, perhaps most importantly, ongoing resource needs.

Involve the real end users – When configuring the system make sure you involve the people who will do the work, NOT merely a representative. These end users must be your top players and be able to point out any potential issue that will hurt the business. Issues can be solved if raised, but if they are never raised until you start using the system you will be in serious trouble. IT People often say, “Just turn the system on, then we will stabilize it.” Do not listen to this logic; it will cause you way more pain than it’s worth. Instead, pay now and involve the end users in each step of the way. During the implementation above the end users raised over 500 issues through the testing process. We still had a few surprises at “go live,” but imagine how many we would have had if they only raised 50 issues?

Cultivate input – During software configuration the goal is to get as much input as possible. When end users raise issues, listen, paraphrase, and write them down. If you can add a “thanks,” that is even better. The number one factor on how much input you will generate is how you receive it when it starts coming. After you are clear about the issue they raise, then have a predetermined process to determine whether, and/or how, and when it will be solved. That process must be clear to all participants and continue to be taught, refined and clarified as the project progresses.

Clarify what can be changed and what has to be lived with – Another key to input from your end users is to clarify what has to be adopted and what can be adapted. Don’t expect this to be a one time easy conversation. Software systems are complex. The average person will not be able to grasp all the information immediately, and some will push the same issues several times until they really understand it. And well they should, because frequently, when pushed, the project team can create solutions that they didn’t initially envision, and solve problems that they didn’t think they could solve.

The configuration process is a game in which there are several levers that can be pulled, thousands perhaps, and each lever leads to another set of potential solutions and problems. The project team has a full time job to educate the end users helping in the configuration process. This education must be done with patience and grace. The key to good involvement is to set boundaries while rewarding feedback.

Be aware of the trade off between better data for the organization, and more work for end users – Better information does not come free. In all systems anything that you want to obtain at the back end must be input into the system by an end user. In our business the financial people wanted information on the product by piece. A reasonable request, but that information is not used by anyone else in the organization to make better business decisions, and it would have cost an extra man hour per shift to input the data (as determined through a time study). Getting this data would have cost thousands and given very little for the business in return. Make sure you have a decision process in place that helps sort through the validity of asking for additional input and balances that with basic operation needs.

Have the right and enough technical resources – ERP systems are at best well constructed software programs that are robust and flexible. At worst they are poorly written pieces of software that break down more than they operate. Each have series of modules specific to the different business areas such as planning and finance. Many have new modules to meet an ever expanding list of requirements and are filled with bugs and complexities. Expect to spend a lot of money on technical resources to assist with the more complex or newer modules, or to suffer the consequences if you don’t. Slow progress in getting modules up to speed could signal the wrong, or most likely, insufficient technical resources. With technical resources, you truly pay now or pay later.

Create clarity of decision making, especially when it comes to moving from testing to using the system – Most software implementation projects proceed in stages from configuration to testing, and finally “go-live.” At each stage, there should be a decision making process which balances influence from the end users who are helping to configure the system. Including the end users creates a decision matrix between the BU lead team, the local lead team, the end users, and the project team. Do not allow the project team to make decision recommendations to the BU and location lead team without the voice of the end users.

During our implementations, at the end of each stage, end users from each area impacted by the project raised their critical issues to the local lead team. They also indicated if their area was ready to move forward to the next stage or should take a “time-out” and solve critical issues. The local lead team weighed the information in terms of overall impact to the location and made their suggestion to the BU lead team who in turn made the final decision. The project team facilitated the process as well as added their opinions.

The above process caused several things to happen. First, we did not go live on a few occasions as planned. Second, the end users and the location lead team were significantly informed of each issue at risk. Finally, when we did go live the end users were ready and in most cases, were actually lobbying to turn the system on.

Do not skimp on go live support – Most people understand that there is a difference between classroom training and working in a live system. Make sure you have enough support to help anybody with keystroke needs for the first few weeks after go-live, and do not leave until the end users and the internal location person say it’s ok.

Every ERP system, like every business and every location, is different. Each has its own problems that must be solved to achieve an effective implementation. While it would be wise to consistently assess the items above, the need for action will be situational. I have seen software systems implemented where no additional technical expertise was needed, for instance, but I have also seen projects suffer because the right help was obtained only after a delay.

I cannot say this enough: to be most effective, besides choosing the right system, you must plan all facets of your implementation. This guide is intended to help prep and plan your ERP system adventure.

By Chris Crosby