Incident management in IT can be not only about IT

From the translator: a curious article by Stuart Rains with a proposal on how IT can increase its value within the company, moving from incident management in IT to incident management in a 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’s management has faith and trust in IT, as well as IT personnel and processes, they possess correspondingly high levels of service culture and maturity. However, as the idea itself is worth knowing and understanding, it also fits well as a goal to be pursued.

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

Now I work with a client, helping him improve the processes and tools for managing IT services. Whenever I work 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 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:
')
“Unplanned interruption of IT services or deterioration in the quality of its provision ...”

This definition is extremely IT directed. 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 it is voiced, however, when we manage incidents, we subconsciously habitually think more about IT than about customers.

My client defines the incident differently. The incident is

“Any deviation of the 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 efficient than current installations with which people work on incidents.

Who can offer action to resolve the incident?

Typically, incident management focuses on IT issues. Necessary actions are suggested by the IT staff responsible for resolving the incident. If they need customer involvement in a solution (some action is required), then it often does not look like part of the incident management process, and IT may have little influence on (or responsibility for) how and when these actions are performed. In the worst case, IT “turns off the meter” and ceases to take into account the waiting time for the customer to perform an action in his target value of the incident management process indicator.

If we proceed from the idea of ​​an incident as a deviation in the quality of a product of a business process, then 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, the IT team members will be active, but they will not only focus on the incident inside IT, as well as work on incident management will not stop while IT waits for action from the customer’s people. Instead, the incident will continue to be actively managed, including the actions of any staff, consolidated to affect the results, until the incident is resolved. This is an illustration of how a seemingly small change in definition can lead to major changes in attitudes, behavior, culture and results.

Suppose that someone from the sales department enters incorrect data into the accounting system and sends invoices to external customers with the errors that customers owe this company money. In accordance with the definition of my client, this is clearly an incident and he must be registered with the service desk service. The actions that solve this incident will be to correct the data (possibly requiring the participation of IT staff for low-level database manipulations), and it 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 personnel. But any action regardless of who, why and how it performs will be recorded, tracked and will be controlled using the rules and tools of the incident management process. And this should give its results when restoring business processes in the form of continuity (seamlessness) and sequence of actions.

When to close an incident?

IT specialists are inclined to think that an incident can be closed as soon as the normal functioning of the IT component is restored, which has caused a deviation in business results. But it happens that in case of major business problems, in order to return the business process to a normal state, IT may require additional work and often it 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 about the result within a certain time.

An organization that follows a business-oriented definition of an incident comes to an unequivocal understanding that an incident can be closed only AFTER all customer business process deviations have been eliminated. This means that all the requested actions from the customer have already been completed and everything is now returned to its normal state.

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 IT improvement and shows how long the customer’s commitment to a service level (Service Level Agreement, SLA) is fulfilled. But for a business, this approach practically carries no value.

When you redefine the incident to a more “business” option, you are more likely to create reporting that carries business value:

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

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

Conclusion

Do you have IT service desk, which IT incidents solve intensively? Maybe now is the time to think about what you can create even more value for your organization, expanding the definition of the 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 become more involved in the overall business of the organization and be seen as a real partner in achieving business results, unlike when it bears only the functions of the servicing department, which only does what repairs it.

Image source: miningcamper