Commonly Underestimated Areas in an ERP Implementation

By Mark Laing, VP of Information Technology, Ascom and Karthik Gopalakrishnan, Global ERP Manager, Ascom

Mark Laing, VP of Information Technology, Ascom

Any ERP deployment is a significant step for any company. The expectation is that the new ERP system will provide a more modern business solution, using latest technologies that will help users, and ultimately support in driving the business forward. To achieve this goal, a carefully planned process is taken to deploy an ERP system. Almost everyone in the ERP community is more than familiar with the typical deployment lifecycle of an ERP system - requirements gathering, design, develop, test, deploy. If we search the internet for “ERP deployment” there is a ton of information available on how to deploy an ERP system. But still, in spite of this wealth of information, experience and skills in this area, not all deployments happen within the constraints of the project. Many projects are ridden with time slippage, over-budgets, poor quality, and frustrated users.

Time, cost, quality and adoption are the 4 pillars on which any ERP deployment stands. While time and cost are high-visibility aspects in an ERP deployment, quality and user adoption determine the success or failure of the deployment to a large extent. This article lists these frequently underestimated areas of an ERP deployment that often proves costly.

Data loads

Any ERP implementation requires initial data loads to take place. At the outset, initial data loads sound like a simple purely IT task. After all, it is just a matter of export legacy data-map fields to new ERP system-import data, right? Wrong. In reality, data loads are in reality a functional fit-gap analysis process - viewed from a data standpoint. A data load process requires an understanding of how the fields from the legacy system, maps to the new ERP system. If we blindly map all legacy fields, we would create a whole lot of new fields, and not leverage the features of the new ERP system.

So, data load really comes down to deciding between leveraging existing fields VS creating new fields, which translates to balancing between retaining legacy processes versus adopting the more efficient processes of the ERP system. And such a decision cannot be made unless there is a thorough review and comparison of the legacy and new ERP system. A good deployment plan must account for such extended duration for data loading, and have active involvement from the business owners.

Testing

How much testing is sufficient testing? Testing can be done with three iterations, and can also be done with 30 iterations. The question is: how much testing is enough? There is no definitive answer to this. Consequently, testing is often the easiest phase of the project to shrink. After all, isn't testing only checking that what you have built to work in a certain way, actually works in that way?

When the go-live is just a few days away, it is tempting to skip through testing quickly, perform a few basic tests, and move to deployment. But that in turn compromises the quality of the system. Regression testing is an important step in the deployment of ERP systems to ensure that everything works as expected. In any ERP implementation that involves so many moving parts, coordinating activities is a challenge and delays are bound to happen.

Karthik Gopalakrishnan, Global ERP Manager, Ascom

It is futile to fight such delays and try to attain a no-time-slippage project execution. Instead, it is more prudent to plan for these delays, and incorporate them into the project plan. A common rule of thumb is be to have a 10-15 percent buffer time. That way, any unexpected (or expected, rather) delays can be mitigated.

Exceptions and contingencies

Any process executed in an ERP system has a so-called "happy path", which is the common, most basic scenario of that process, and assuming that nothing goes wrong. But for every happy path, there are a hundred not-so-happy paths - what-if scenarios, special cases, etc. It is not practical to expect that the new ERP system would address every such scenario. But, users need to be informed how these scenarios are to be handled - whether these are steps within the system or outside the system. Such documentation of workaround steps and contingency plans can prevent panicky emails, escalations etc. on the day of go-live.

User engagement

During an ERP implementation, system users often have to do double work, work on their day-to-day activities in the legacy system, as well as participate in the design/ test/ training of the new system. This double work often causes stress among users. User adoption is critical for any system, and it is important to keep both the team members and overall users engaged and excited about the project. Users must view the new system as an improvement to the quality of their daily activities, and not as a change that management wants and they need to deal with. To achieve this, the user involvement in the project must be carefully thought through - not too much that it hinders with their work, not too little that they feel isolated - just the right amount to keep them excited. To top of all, management must take it on themselves to be evangelists of the new system and imprint a positive mindset in the users about the new system.

Chronological milestones

ERP deployment milestones are often set based on the phases of the project. For example, in a typical waterfall model, the project phases are decided, and then time duration allocated to each phase, and based on that, a go-live date is decided. While this is not a wrong approach, relying entirely on this plan alone for project management, can be risky. That is because single phase in a waterfall model can potentially keep project team members disconnected for long periods of time, while work is in progress. For example, if the development phase is estimated to take two months, then there is a stagnation of the project for that period, while the development is in progress. Then, at the end of two months, if the final product is not as expected, that is 2 months of work that is lost.

A better approach is to have the deployment timeline divided into units of time. Instead of asking how much time will the Development phase take to complete, it is better to ask, what can be developed in the next X weeks, and repeat the same ongoing. This way, the entire team is constantly kept well-informed of the deployment, and any slippages are caught sooner.

Post deployment

Often times, the general perception when making a ERP deployment plan is, Go-live = deployment completed. In many project timeline documents, the last line of the plan is GO LIVE. Post deployment actions are often an afterthought.

Post go live activities are just as critical as the project itself. This is the phase where the knowledge of the Vendor’s project implementation team, must be transitioned to their support team, so that there is seamless support available. Since that transition would probably not happen on the day of go-live, support must be provided by the implementation team for a few days/weeks post deployment, and slowly phased out. Post deployment activities could also include maintenance on the legacy ERP systems, data extractions, etc. Having a clear post-deployment support strategy upfront will ensure that users know how to report issues, and the vendor knows what is expected off of them post deployment.