When organizations begin to embrace ITSM best practices and embark on the long journey toward ITIL maturity, one of the biggest stumbling blocks we see our clients encounter is appropriately defining, and properly delineating between Incidents, Service Requests, and Problems. While it may seem obvious to some, many struggle to grasp the differences—and how important it is to understand each of these operational processes.
Incident vs. Service Request
ITIL version 2 did not do much to differentiate between Incidents and Service Requests. Often, people well versed in the older iterations of the ITIL framework will argue vehemently that there really is no difference – that a Service Request is just a fancy name for an Incident that was an afterthought. However, ITIL version 3 taught us that there are, in fact, distinct and important differences between these two types of Service Desk records. Incidents, simply put, are events that result in interruption of one or more Services. Service Requests do not specifically result in the same degradation or failure. Instead, they are needs or wishes for enhancements or changes. They seldom spawn actual Change Requests (though it is possible). These include things such as getting a replacement monitor, or a new desktop printer. Requests for things like system or network access.
I have personally found that the biggest point of contention when differentiating between Incidents and Service Requests comes from Password Reset/Recovery. My argument is always that this is a Service Request, while others may hold that it is an Incident because it degrades an individual’s ability to perform their primary job function. The bottom line, however, is that the organization as a whole must come to an agreement on what type this is. We can argue until we are blue in the face, but there must be consensus at the end of it all. Don’t get caught in the minutiae, make a decision to improve your Service Desk and move forward.
Problem Management
The third member of this confusing triad is Problem Management. I have heard countless misconceptions about what a Problem is (or is not), and I believe that this is the primary reason for its underutilization within Service Operation. First and foremost, a Problem is not an Incident. Not at all. An Incident does not become a Problem. Problems are not just ‘really impactful’ Incidents. There is no magic ratio of Incident to Problem—I have actually heard someone claim that ITIL requires one Problem for every Incident. And Problems are not resolved when an outage has been mitigated.
No, the misunderstood Problem is none of these things. A Problem is an issue for which the root cause has not yet been determined. For example, a server crashing in the middle of the night is a Problem. This is especially true if there is reasonable evidence that it will happen again. There may be an associated Incident raised if the crash causes degradation or failure of a Service, but that may not happen if your infrastructure is highly redundant. But a server crash in itself does constitute a Problem. Why did the server crash? This is the question that Problem Management always asks, “Why?” While Incident Management is focused solely on restoring service as quickly as is reasonable (fighting the symptoms), it has no interest in why the outage occurred (understanding and eliminating the cause). Problem Management is the investigation act that figures out the root cause and seeks to resolve that in order to keep the Problem from recurring. Problems can have workarounds. Sometimes the workaround becomes permanent because either the root cause cannot be found, or fixing the root cause would be overly burdensome in some fashion (financially, resource-wise, etc.). An Incident always needs to be resolved. The Service must be restored. Period.
A great way to understand the difference between Incidents, Requests, and Problems is to think about changing a tire on your car. If you are in the middle of nowhere and you have a flat, you pull over, get out the jack and swap out the flat tire for your spare. You have resolved the Incident—in this case the interrupted Service was your travel from one point to another. But this also constitutes a Problem. You have now reduced the redundancy of the system. Another flat will be catastrophic. So you need to replace the flat tire itself as soon as possible to resolve this problem. And, for bonus points, perhaps you even submit a Service Request to change the other three tires as well, in case they are all close to failure.
These three processes are all extremely important to providing great service to your customers. And understanding the differences, properly identifying each, and resolving each appropriately will go a long way to improving the efficacy of your Service Desk.