Incident, Problem, Change, Service Request?

An Event is basically any state change that is supposed to trigger some action. Typically Monitoring applications watch the IT systems and platforms and raise an event in case an anomaly is detected. The reaction to an event may be an automatically started action, it can be recorded in the log for future analysis, or it can be displayed on the screen in the control room. In advanced Event Management processes, an incident ticket may be created and submitted automatically. Note: An Event is not always an indicator of something bad happening. Interesting events can be logged only to create an audit trail.

An Incident is any situation where the system or applications deviate from their specifications, or if the users cannot do their tasks. Incident Management is perhaps one of the most visible delivery processes. The scope of Incident Management usually includes user guidance, incident analysis, corrective actions, developing a workaround, closing the ticket without action, closing the ticket as impossible to be handled by the Incident Management, etc. Typically, Incidents are categorized and prioritized by their criticality and extent. Each category may have their own targets for time-to-resolve. The ticketing system makes sure that the tickets do not get lost.

A pretty common policy is to keep the program code beyond the scope of Incident Management. If there is a need to touch the code, the case is transferred to the Change Management process or to the application development practice.

A Problem in the ITIL language is not a synonym of the word "Incident". Instead, it is the root cause of an incident. Sometimes, people tend to believe that for each incident, Problem Management must be started to find the root cause. This is not true. Problem Management perhaps is the most misunderstood practice of ITIL. Problem Management actually is a project, not a process, and its cost may be high. Usually, Problem Management is used when there are recurring similar incidents, or a difficult issue which cannot be solved by normal Incident Management process. Problem Management can be used proactively, too, to prevent incidents from happening.

As the implied cost and effort might be high, there shall always be a business case to start Problem Management. It may involve several organizations and companies to complete. Therefore, it is recommended to create some criteria on when Problem Management should be considered. The service agreement shall contain statements to make both the customer and the service provider commit to join the Problem Management project when needed.

While the focus of Incident Management usually is at the lower tiers of the support model, Problem Management is about senior specialist work.

The Problem Management plans and submits action requests instead of taking actions by itself. Therefore, it does not overlap with the other processes.

The diagram shows that Problem Management is often an iterative loop. The loop is repeated until the actions are considered sufficient. It is good to note that Problem Management does not necessarily lead to any actions but to a decision tolerate the current situation, either permanently or temporarily.

A Change is any change to the production systems and infrastructure. (The application changes and development are usually managed by a separate path.) There are two main stages for each change: an Impact Analysis and Design for Implementation. These can be very far apart in time. Both are subject to an authorization to proceed. Often, changes are categorized by their risk and urgency. There shall be a procedure to implement emergency hot fixes without full-scale authorization. However, the change shall be reported and approved afterwards. (If this step is ignored, sooner or later all changes will be implemented as emergency hot fixes to bypass the authorization gates.)

A Service Request is often seen as a sister to an Incident, because it is also based on tickets and usually managed using the same ticketing system. However, it may be a half-sister or a cousin; being a close relative is an illusion for many reasons.

Basically, a service request is anything a user requests from an IT organization. It can be a standard request i.e. some prepackaged deliverable. It is up to the Service Portfolio design which deliverables are to be produced via Service Requests. Again, it is a management decision whether the requests are charged or not, whether they require an approval of a supervisor or not, and what the lead time is.