Incident Management for ERP Projects

A bad plan with good execution can be considered a dream come true, but a good plan with poor execution can be a nightmare. Monitoring incident management statistics can be an effective yard stick for assessing issues, risk and successful implementation of any enterprise resource planning (ERP) project.

What Is Incident Management?

In the context of a project execution, e.g., ERP implementation, incident management refers to a process that enables end users to report issues identified/experienced by them. This allows for analysis of such issues so that the team providing support to resolve these kinds of issues can take corrective and/or preventive action for business continuity (figure 1).

Traditionally, an incident management framework for an enterprise could be restrictive in scope. An example is an organization that is up and running in its normal business. For such an enterprise, incident management could be restricted to fix issues such as no intraoffice connectivity, downtime for emails or some applications (apps), and so on. However, the objective of such incident management is to fix routine issues in general.

Effective incident management can not only help identify risk factors and gaps in the design or process, but can also help facilitate timely resolution of issues that can escalate. In this way, incident management can restore confidence in new ERP systems for the business to function as usual, especially during the post-deployment period.

Before delving into how incident management can help identify risk factors and gaps during the early stages of ERP deployment, it is important to consider the framework that would be most useful to make the incident management process more effective for all stakeholders, be they the end users, support teams or business managers at large.

Change management is an integral part of any big transition. One of the biggest challenges to change management is end-user resistance to embracing new systems. This can be an outcome of many complex factors including emotional attachment to existing systems, exposure of the people concerned, individual flexibility, leadership, and conveying and driving change. Regardless of any of these reasons, embracing new systems tends to generate an element of anxiety. Conventionally, end-user trainings are expected to address any anxiety or reluctance end users experience. Even after training, end users typically still have anxiety around issues such as to whom to reach out to in case any issues are faced immediately upon go-live, what the turnaround time to fix such issues might be, and the impact of any issues on end users’ work responsibilities and, consequently, on the business.

To understand the risk to business and end-user concerns, one can consider an example of a procurement resource in a supply chain department on the second day after go-live. In this scenario, there are issues on creating a purchase order to a vendor that provides rail and transportation services and has the potential to disrupt operations of the organization. If such issues are not handled promptly, not only can it lead to disruption of the organization’s operations, but it can also adversely impact its reputation with its clients.

To avoid situations wherein the end user is forced into panic mode, it is imperative that the end users have information on whom to go to for support and any mechanism to report such issues should they arise. A well-structured communication process is vital to identify and report issues, and it can go a long way in streamlining the resolution of issues (figure 2).

The following strategies can be useful for ensuring effective incident management:

• Identify the number of end users by each function and process, which should include those who are in scope and could potentially be impacted by an incident.
• Create a team of super users—field representatives and additional support staff who can be reached promptly for any issues on the ground.
• Implement a mechanism to log issues, which can be recorded, reported, analyzed and resolved.
• Identify a workflow for each function to record and report issues (figure 3). The volume of incidents that could be faced by any organization immediately after go-live depends on the structure and size of the organization.

The channels specific to each process shown in figure 2 can help triage incidents easily, and dedicated teams can then attend to them based on the level of severity of each incident.

To make the overall process effective and results-oriented, it is important:

• To triage the incidents correctly within various functions, whether they are finance, supply or distribution. Also, within finance (since there are typically subprocesses such as accounts payable, accounts receivable, tax, treasury), incidents should be channeled to the right point of contact for resolution.
• Depending on the volume of incidents anticipated, that the support team is sufficiently staffed so that incidents are resolved in a timely manner. Often, one of the biggest causes of delays culminating in business risk is a delay in resolving incidents due to inadequate staffing or lack of expertise.
• To ensure that incidents get the right attention, prioritizing incidents as critical, high, medium and low is helpful (figure 4). This can also be part of communication to end users during the early part of planning and training so that the most serious issues are handled based on priority accorded.
• That these incidents are reviewed collectively at regular intervals, perhaps weekly to begin with, to gauge the number of issues by function and how many of them were critical, high, medium and low (figure 5). This will help to substantiate which function or process requires more attention, thereby assessing business impact. In the statistics shown in figure 5, it is important to note that the percentages of incidents closed are the highest for incidents classified as critical and high.
• While setting up this process, it is advisable to keep a benchmark for turnaround time of closure of incidents, for example, all critical incidents are to be closed in 3-5 hours, high incidents are to be closed within one day, medium incidents within three days and low within seven days. This will aid in resource planning and the timely resolution of issues based on priorities.
• Last, but not least, it is important that the closure of incidents is results-oriented, meaning the issue is actually resolved and is not closed via an administrative processing of the incident.
  Monitoring at predefined intervals, perhaps weekly during the first month of go-live, can promote an objective and transparent basis for determining:
  • Level of preparation that was done pre-go live and its results
  • Lessons learned for necessary action on future deployments
  • Mechanisms for all stakeholders to review progress
  • Parameters developed as part of the exit criteria for post-deployment support and gauging the success of project implementation/deployment more objectively
  • Analysis of the nature of incidents can provide internal controls and governance a window into issues that might have crept into the initial go-live period and can provide visibility to issues much earlier compared to conventional standard audit programs that will come in to play at a later date

View Large Graphic.

An environment that reflects clarity and guidance goes a long way toward building a sustainable support system regardless of the issues that may arise.

There are a number of examples of incidents that could be eye-openers. These are illustrated in figure 6.

These examples of incidents make it evident that issues experienced by an organization can be multilayered and, not only can the issues impact business continuity, but they can also cut across t he domains of internal controls and governance.

Conclusion

Internal risk and control’s (IRC’s) role is not only vital in the ERP design and pre-deployment stage, but equally important in post deployment. As the age-old saying goes, “A stitch in time saves nine.” Early engagement of internal audit and governance teams can not only neutralize issues that could otherwise become perennial, but also help to avoid unpleasant surprises at a later date.

A blend of foresight, planning, communication and a proactive approach can resolve concerns in a timely manner and transform a seemingly difficult path into a cakewalk.