Commonly Underestimated Areas in an ERP Implementation

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

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

In any ERP implementation that involves so many moving parts, coordinating activities is a challenge and delays are bound to happen. 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.