Incident Management in IT Tips
I am currently working with a client to help them improve their IT service management processes and tools.
Whenever I work on such tasks, I find things I can learn, this time I got to thinking 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 to their own needs.
What is an incident?
The most popular collection of IT service management practices in the world right now – ITIL gives the following definition of an incident:
“Unplanned interruption of an IT service or 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 the customer’s business, but clearly describes the incident as something that is done to IT. This is how it sounds, however, when we manage incidents, subconsciously habitually think more about IT than about customers.
My client defines an incident differently. The incident is
“any deviation of the product of business processes 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 setups with which people work on incidents.
Who can propose an action to resolve the incident?
Typically, incident management focuses on IT issues. Necessary actions are proposed by the IT staff responsible for resolving the incident. If they require customer involvement in a solution (some action is required), then it often does not appear to be 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 counter” and no longer counts the time it takes for a customer to complete an action in its incident management process metric target.
If we proceed from the idea of an incident as a deviation as 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 the IT service, the IT team members will be actively involved, but they will not only focus on the incident within IT, but also the incident management work 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 with a cumulative effect on outcomes, until the incident is resolved. This is an illustration of how a seemingly small change in definition can lead to major changes in attitudes, behaviors, culture and outcomes.
Suppose that someone from the sales
department enters incorrect data into the accounting system and the results are sent to external customers with errors that customers owe this company money. According to my client’s definition, this is clearly an incident and should be registered with the Service Desk. The actions to resolve this incident will be to correct the data (possibly requiring the participation of IT personnel for low-level manipulations with databases), and this also requires interaction with the company’s customers to correct the data on their side, i.e. these are activities that will be performed by sales or marketing personnel. But any action, regardless of who, why and how it is performed, will be recorded, tracked and managed 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 a sequence of actions.
When to close an incident?
IT people tend to think that an incident can be closed as soon as normal functioning of the IT component that caused the deviation in business results is restored. But it happens that with major business problems, in order to return the business process to normal, additional work may be required from IT and often this will be a whole list of required actions.
ITIL recommends that an incident 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 within a certain time.