IT incident management can be not only about IT

Original author: Stuart Raines
  • Transfer
image
From a translator: an interesting article by Stuart Raines with a proposal on how IT can increase its value within the company, moving from incident management in IT to incident management in the company's business processes.

The idea is not new and is known as Enterpeise Service Management. It is unlikely that it can and should be applied everywhere, but if the company management has faith and trust in IT, as well as IT personnel and processes, they have correspondingly high levels of service culture and maturity. Nevertheless, as the idea itself is worth knowing and understanding, it is also quite suitable as a goal to strive for.

Link to original
Published 01/15/2018.
Difficulty : entry level (ideology)

Now I work with a client, helping him to improve the processes and tools for managing IT services. Each time, working on such tasks, I find things that I can learn, this time I was forced to think about the client’s approach to incident management. This is a completely unusual idea with far-reaching consequences. In my opinion, other organizations can also benefit from it with some adaptation of it for themselves.

What is an incident?


The most popular collection of IT service management practices in the world today - ITIL gives the following definition of an incident:

“An unplanned interruption of an IT service or a deterioration in the quality of its provision ...”

This definition is highly IT oriented. ITIL talks about the importance of minimizing the impact of an incident on a customer’s business, but the incident is clearly described as being done with IT. So this is voiced, however, when we manage incidents, we subconsciously habitually think more about IT than about customers.

My client defines the incident differently. An incident is

“any deviation of a business process product towards an undesirable result for the business.”

This is a completely different way of thinking and its results are very different from the usual. From my point of view, it is potentially much more effective than the current installations with which people work on incidents.

Who can suggest an action to resolve the incident?


Typically, incident management focuses on IT issues. The necessary actions are proposed by the IT staff responsible for resolving the incident. If they require the customer’s participation in the solution (some action is required), then it often does not look like part of the incident management process, and IT may have a little influence on (or responsibility for) how and when these actions are performed. In the worst case, IT “turns off the counter” and ceases to take into account the waiting time for an action to be completed by the customer in its target value of the incident management process indicator.

If we proceed from the idea of ​​an incident as deviations as a product of a business process, the situation is extremely transparent and any person influencing deviations may need support in solving the incident. Whatever the reason for the interruption of IT services, IT team members will actively act, but they will focus not only on the incident within IT, and incident management will not stop while IT is waiting for action from the customer’s people. Instead, the incident will continue to be actively managed, including the actions of any personnel, the consolidated impact on the results until the incident is resolved. This is an illustration of how a seemingly small change in definition could lead to major changes in attitude, behavior, culture, and outcomes.

Suppose that someone from the sales department enters incorrect data into the accounting system and invoices are sent to the external customers with errors that customers owe money to this company. According to the definition of my client, this is clearly an incident and it must be registered in the service desk service. The actions that will solve this incident will be to correct the data (possibly requiring the participation of IT staff for low-level database manipulations), and this also requires interaction with the company's customers to correct the data on their side, i.e. These are actions that will be performed by sales or marketing staff. But any action, regardless of who, why and how it is performed, will be recorded, monitored and controlled using the rules and tools of the incident management process.

When to close the incident?


IT employees tend to think that an incident can be closed as soon as the normal functioning of the IT component has been restored, which caused a deviation in business results. But it happens that with major business problems, in order to return the business process to normal, it may require additional work from IT and often this will be a whole list of required actions.

According to ITIL recommendations, the incident should be in the “resolved” state until the customer confirms that it can be closed. In practice, many IT organizations automatically close incidents if customers do not give them feedback on the result over time.

The organization, following the business-oriented definition of an incident, comes to the unambiguous understanding that an incident can only be closed AFTER all customer process business deviations have been eliminated. This means that all the requested actions from the customer have already been completed and everything is now returned to normal condition.

What incident reports to create?


Typically, incident management reports focus on how quickly the IT organization resolves the incident. This can be useful in planning and managing the improvement of IT and shows how much the obligations to the customer are fulfilled according to the Service Level Agreement (SLA). But for business, such an approach has practically no value.

When you redefine an incident to a more “business" option, you are more likely to create reports that carry value for the business:

  • How significant were the negative consequences in the business process?
  • What are the most common causes of incidents? (Often, problems with IT will have nothing to do with it).
  • Where in the incident resolution process do the longest delays occur?

All of this data can help plan and manage how your business is managed. And how well IT helps the business.

Conclusion


Do you have an IT desk service that solves IT incidents strenuously? Maybe now is the time to think that you can create even more value for your organization by expanding the definition of an incident, including deviations from any norms in the products of business processes without taking into account the reasons that caused it. All this can help IT to become more involved in the overall business of the organization and be considered as a real partner in achieving business results, in contrast to when it carries only the functions of a service unit, which only does what repairs the breakdown.

Image Source: miningcamper

Also popular now: