In the process of implementing an enterprise application suite like enterprise resources planning (ERP) or enterprise asset management (EAM), an almost infinite number of things can go wrong. A successful implementation depends not only on selection of the correct application, but on the quality of the communication between you and your application vendor or implementation consultants.
Some of the more disastrous ERP implementations that you read about in the news—the ones that public companies blame for their poor financial performance, going well over budget and taking years to complete—might be blamed on the complexity of the product being implemented or perceived unresponsiveness of the implementation consultants. But the success of the implementation often depends on the customer organization and the project management ability of their implementation team. Those on the receiving end of an implementation are in a very challenging position because in many cases, none of the team members has been through an implementation before. Ostensibly, the team representing an application vendor or implementation consultant should be more experienced and professional, but miscues on their part are not unheard of either.
In white papers, there is no shortage of advice about what best practices can lead to success. But equally important is a thorough understanding of what worst practices are to be avoided during an implementation. Problems during implementation are never deliberate. But in this white paper, we will review four practices that should be avoided unless one wants to go out of one’s way to cause their implementation to tank.
UNDERESTIMATE THE STRATEGIC IMPORTANCE OF THE IMPLEMENTATION PROCESS
This is a very broad topic, but a failure to understand the various ways that an enterprise application implementation is strategically critical to your business can cause a number of problems. But perhaps the most common result of this cognitive failure is reflected in the type of people a company might assign to an implementation team and the problems that naturally ensue.
Some companies are understandably reticent to devote their most valuable human assets to a months-long implementation process and instead, assign more Junior people to the team. This tends to create problems of vision as younger, less experienced employees of a company or those in staff-level positions tend to have an excellent grasp of their own jobs but a lack of understanding when it comes to the company’s strategic goals or company operations as a whole. They may be more likely than their more experienced peers to be interested only in making their own job easier, perhaps at the expense of others in the organization, skewing project resources accordingly.
Another common error is to heavily load the team with C-level executives. These senior players have an excellent grasp of where the company is today and where it needs to go tomorrow, so their buy-in is vital to the project. However, senior executives are often lacking when it comes to the specific processes and activities that are used within the company. A hands-off manager will be at a loss when it comes to discussing precisely how things are done within the company today and how, on a granular level, it is reasonable and desirable for business processes to be executed in the new software.
So who belongs on the implementation team? Choose middle managers who are key users of the software and have extensive knowledge of both company strategy and detailed processes. They must be empowered to make decisions regarding the implementation, necessitating C-level buy-in and support, and will be responsible for determining how the application is used and dictating the business’ process flows for a long time.
Another way that a failure to appreciate the strategic importance of the implementation manifests itself is to assign what might be the right team but then give them no time to work on the implementation. Once the team is chosen, it is vital to make sure their regular jobs are backfilled so they have time to concentrate on the implementation. In too many circumstances, I have seen situations where someone is assigned to an implementation team and are told they still need to do their job and need to implement this ERP package on the side. That is not a viable situation as the implementation will be starved for resources. It will either grind to a halt or will be forced to move ahead with inadequate information, resulting in multiple problems at go-live.
BITE OFF MORE THAN YOU CAN CHEW
There are two ways to try to do too much too fast with an ERP implementation. One is to try to implement too much with regard to geography or sites all at one time. Some ERP vendors and implementation providers advocate the “big bang,” encouraging companies with multiple locations to take their entire organization live all at once. But often, that proves to be too much for an organization to handle.
In many cases, it is better to implement an enterprise application at one or two sites at a time. This allows a company and its implementation consultants to work kinks out of the business models and process flows that were decided upon by the implementation team.
Another way to bite off more than you can chew is to make too many dramatic changes in your organizational culture all in one felt swoop. When you buy packaged software, you are not only buying technology, but a way of doing business that can improve the efficiency of your organization. In many cases, elements of an application’s functionality may represent business practices that you currently do not engage in, either because they have not been a part of your corporate culture or because they are not supported by your legacy system. Each of these process improvements and best practices are likely good opportunities to move your business forward, but trying to implement all of this functionality at the same time may prove to be too much for a business’ management structure and employee base to absorb. Consider that Vitamin C is a very good thing, but trying to take too much of it at one time can upset your stomach!
In order to avoid disruption that can result from change that comes too quickly, it often makes sense to take a more gradual approach. At the initial implementation, reach out to your functional leaders to see whether or not adding various elements of new functionality creates too great a burden. Sometimes better to go live with functionality you currently have in your legacy system, and then schedule add-ons when you are genuinely ready for them after an initial stabilization period.
REPLICATE YOUR LEGACY SYSTEM ON NEW SOFTWARE
While trying to change too quickly is one way to hobble your enterprise application implementation process, trying to avoid change altogether can be just as damaging.
Some people just don’t like change, and the idea of abandoning the way they have done things in the past upsets them. These people, if they are part of an implementation team, come into the project with their own paradigms and their own ideas of how things should work, which are often based on the old system. Oftentimes, it does make sense to go live first on just enough functionality to replace the legacy system, but resistance to change of this nature can bring an implementation to a halt. A fervent desire to replicate an existing environment can be very granular, and team members may even have a specific idea of what screens they should see, what reports they should get and what buttons they click. People who are reticent to move away from their legacy system focus on the functions of the software rather than the business requirements behind those functions, and often request numerous modifications to the new environment, which cause cost to spiral without real business benefit.
It is important for an implementation consultant to understand the current processes and how the legacy system is being used. That is why a consultant will ask not only what processes are currently being followed, but what are the underlying reasons for each of these process. Sometimes, these questions are asked to make sure that each process is necessary, but this line of questioning can also determine the business need that process is fulfilling. An implementation consultant or applications vendor should understand that anything their customer does in their current process is likely done for a good reason, and it is their job to find what that reason is and then find the best way to satisfy that underlying need in the new software. Their goal should not be to replicate the way things are done in the legacy system. Indeed, most times, an implementation may bring a slightly different process flow, different screens and different reports. People assigned to a company’s implementation team have to be able to think outside the box and realize that their business requirements are being met even if the screens and buttons are not exactly the same.
There is a relationship between the ability to successfully navigate this process and the degree to which the right people were assigned to be a part of the implementation team. It is crucial that the implementation team be able to look beyond the superficial elements of the legacy system, and see past the screens and reports to which they have become accustomed. They need to envision how the new application will be made to meet their underlying business requirements.
Implementation team members must be comfortable opting for a slightly different approach or a slightly different process in order to meet the strategic goals a new enterprise application is meant to achieve. In some cases, team members should even be empowered and unafraid to suggest organizational changes outside the application that will better accommodate a new process flow and make for a smoother implementation. Perhaps certain departments should be merged, or people who had worked on opposite sides of a building should be moved to better facilitate the new way things are to be done. With too great an attachment to the past, it is hard to realize a more productive and streamlined future!
REINVENT THE WHEEL
A fourth and final way to kludge an enterprise applications implementation process is to reinvent the wheel by disregarding established implementation methods. Regardless of the implementation provider you choose or the enterprise software product you choose, your implementation team will come in with an implementation method, with specific steps to go through in order to ensure success. This implementation method is proven, and has been developed over long experience at dozens, hundreds or even thousands of companies.
An implementation consultant or application vendor follows this method because it suits their approach and the software in question. While methods of different implementation providers may vary, a viable method will generally include four distinct steps:
Mapping: At this stage of the project, a consultant will identify the business processes you will implement and determine how, at a business process level, they will be handled by the software. IFS, for instances, uses its own IFS Business Modeler software for documentation of all process levels, automating the process of finding functional gaps and working them through to a solution.
Implementation/Definition: During the implementation/definition phase, the consultant and implementation team will take the process maps and work through the details. There might be several rounds of work routine documentation, modeling data migration to make sure processes are well-documented and they will work.
Testing: During the testing phase, the consultant and implementation team will tie all of the processes together and test them to make sure they will work. One way to do that is to run several days of the company’s transactions through the system end-to-end in a controlled business simulation environment.
Rollout: After mapping, implementation/definition and testing are completed, it is time to roll the application out to users in the organization. This step involves training of the end users and ensuring that the IT infrastructure is in place to run the application prior to going live.
All of these steps are absolutely necessary. But sometimes, in a budget crunch or on a tight timeline, there is the temptation to cut out some testing or cut out some mapping. Even if you are not trying to reinvent the wheel in its entirety, it is not advisable to simply remove a few spokes to see how it holds up under load! Skimping on any of these steps comes with a degree of risk that needs to be recognized. Straying from the established implementation method creates the opportunity for things to go wrong at a critical time—during go-live week or after go-live as poor preparation comes home to roost. Typically, problems that result from diverging from proven methods cost more to fix than a more thorough and systematic implementation would have cost to begin with.
