Service Operation Process - High Level

The above high level process flow shows some of the relations between the Service Operation processes.

It is a common misperception that Incident Management is ‘the Service Desk process.’ This is untrue. Incidents are errors in the infrastructure that result in degradations in service. Therefore Incidents occur everywhere, and everyone in IT is a potential agent of Incident Management.

In the v2 standard Incident Management was getting stretched. A lot of this was a result of this mis-perception of it as ‘the Service Desk process.’ Incident Management was responsible for handling Service Requests; which are a class of pre-approved Change.

In v3 these Service Requests are handled with their own separate process, Request Fulfillment. These pre-approved Changes should be low risk, and each one should be clearly defined with its own process flow and set of rules. Request Fulfillment is heavily dependent on Access Management, also called ID Management, to provide definitions on an individual’s role, status and rules for accessing various applications and data.

Interaction Management is NOT an ITIL process. However, it is ‘the Service Desk process.’ Use of a separate Interaction Management process allows for a separation of Incident metrics from Requests for Information. Incidents reflect errors in the infrastructure and should be measured as part of a separate process.

A separate Interaction Management process further allows for separate management of the communications with end-users from the troubleshooting activities of Incident Management. This allows for an easier consideration of tiering the Service Desk; which may be appropriate for some organizations.

Event Management is often closely tied to Configuration Management, as the discovery and monitoring tools are often managed in concert. Event thresholds may raise Incidents directly.

Incident Management has two types of inputs to Problem Management. The first is the raising of a Problem record for an issue for which root cause must be determined. The decision to raise a problem is an organizational decision; it is a commitment to devote resources to determine the underlying cause of an issue.

The second input from Incident Management to Problem Management is a new workaround to resolve an Incident. Using the Knowledge sub-process (not to be confused with the full KM process), Problem Management reviews all workarounds to ensure their suitability. Approved workarounds are recorded in the Knowledge Base and, in the pure model (rarely seen in the wild) all Incidents are closed with reference to an approved workaround.

Change Management is a Service Transition process. It accepts inputs, in the form of new and modified Requests for Change (RFC) from Incident, Problem and Interaction Management.