Dependencies and relationships between ITSM processes

Technically, all ITSM processes in this chapter can be implemented independently in SCSM. Based on best practice, an order of implementing the process is recommended.

Getting ready

A general understanding of the objectives of ITSM frameworks is required for this recipe. Also, a basic understanding of all ITSM processes described in this chapter is required.

How to do it...

The following figure provides a diagram of information flow, trigger options, and relationships between the ITSM processes in SCSM:

The order of implementing the different ITSM processes in SCSM depends on the requirement of each individual organization, which might differ. In general, some combinations and orders of ITSM processes are a best practice to the successful implementation of SCSM.

Option 1:

1. Configuration Management
2. Incident Management
3. Problem Management

Option 2:

1. Configuration Management
2. Service Request Fulfillment (Service Catalog)

Option 3:

1. Configuration Management
2. Incident Management
3. Combination of the following:
4. Problem Management
5. Change Management
6. Release Management

Option 4:

1. Configuration Management
2. Incident Management
3. Combination of the following:
4. Problem Management
5. Change Management
6. Service Request Fulfillment
7. Release Management

The Incident Management and Service Request Fulfillment are typically supported by the Service Level Management (SLM). SLM provides information on the Service Level Agreements (SLAs) for the respective processes.

How it works...

The Configuration Management process with the Configuration Management System (CMS also commonly known as the Configuration Management Database (CMDB, provides technical information and details for all IT components (Configuration Items, CIs) for all other ITSM processes in SCSM. In addition, all ITSM processes update the CMS/CMDB with relevant information as each process is executed during its life cycle.

Incident Management is responsible for the fast remediation of disrupted IT services. Information from the Incident Records (Incident Ticket) can be used in the Problem Management process as related Problem Records. This is helpful in order to create workarounds, create Known Errors, discover the root cause of an incident, and optimize the IT services.

The Incident Management and the Problem Management processes can trigger required changes of an IT services. These changes are logged in Change Records in Change Management. A Change Record will contain different types of related activities (Review Activities, Manual Activities).

If the change is approved and all related activities in the Change Management process are completed, Release Management is responsible for rolling out the change to the affected IT service components. This will be logged as a Release Record with all the related activities of the roll-out.

An incident can also trigger a Service Request to provide a new service. For instance, an incident with the issue Can't open a file because of missing application on a client computer can be resolved by a Service Request to install the required application on the client computer.

The Service Level Management with defined Service Level Agreements supports the Incident Management and Service Request Fulfillment processes to monitor and report on the agreed SLM objectives.