For years, real-world ITSM practitioners knew there were challenges with how Incident Management attempted to incorporate service requests and alerts from monitoring tools. As a result, they developed their own practices. Now, with ITIL v3, the Incident, Service Request and Event Management processes are independent and that is a great thing. Let’s step through each area and review why this is the case.

Service Requests

Traditionally, users who needed something contacted the service desk or opened their own incident record via a self-service portal. While it could be done, it was problematic. A request for information, employee moves, and so forth were lumped in with real incidents. To explain the challenge, an incident is a disruption to a service or something that may disrupt a service. A service request, on the other hand, can be viewed as everything else.

Organizations found if service requests were handled by the same group doing break/fix, often times the requests would be handled at a lower priority and subsequently the requestor would have to wait unpredictable amounts of time while incidents were handled first. This unpredictable performance damaged customer satisfaction and IT’s credibility.

Now, by having a dedicated service request process, organizations can design the process in accordance with their requirements. For example, service requests can be used to initiate new user requests, hardware moves, additional software, and so forth that then follow the appropriate workflows and integrate with other processes properly. This results in a more refined single entry into IT.

From an organizational perspective, some IT groups have further improved service by splitting the management of service requests and incidents into two different groups. This way, incidents have dedicated staff and so do the requests. As a result, the predictability of service requests being handled in a timely and efficient manner increases, as does customer satisfaction.

Event Management

In ITIL v2, practitioners realized they needed to route alerts from monitoring tools into the Incident Management process and the supporting software. The traditional method of sending pages or emails directly to specific staff could cause incidents to be delayed or completely overlooked if someone was very busy, out of the office sick, or otherwise unavailable. Instead, by opening an incident record, there could be escalation, metrics collected and so forth. The approach was very dependent on the process and technology teams implementing the integration because there wasn’t formal guidance.

Part of the challenge lays the creation of alerts and responses. Incident Management stakeholders identify as many alerts as they can based on experience. When new or changed service are implemented, alerts are defined as experienced, i.e. in reaction to incidents. “If this happens again we can detect it by monitoring ‘X’ and will send message ‘Y’ to the tool ‘Z’”. Sometimes, more emphasis is given to detecting incidents than resolving them.

Now, with Event Management, there is a robust process that begins in Service Design and flows into Service Transition to understand for each service what potential incidents may be and defines them as “events” before going “live” in production. Detection criteria and responses, ranging from automatic to console alerts with manual handling, are formally defined. The monitoring and ITSM tools are then configured accordingly in a proactive manner. Of course, as new incident types are experienced, the criteria and actions to detect and respond are formally documented and enacted in the tools as well.