Service Requests and Change Management

I was having a discussion with a learner this morning about the difference between Service Requests and Standard Changes.

This learner's organization publishes a list of standard services that users can request via a self-help tool. The Service Request will be routed to the Service Desk. The Service Desk will review the request. If appropriate, the Service Request may be fulfilled by applying a Standard Change that has been approved by Change Management.

By definition, a Standard Change is a pre-approved, low risk change (such as a new hire) that can be fulfilled almost immediately. Standard Changes must be recorded, possibly as a Service Request. They do not require operational oversight by the CAB.

It is important to note that not all Service Requests are Standard Changes. Service Requests can include questions, queries, complaints and compliments. Similarly, not all Standard Changes are Service Requests. Standard Changes can include batch jobs, patches and other low risk changes that are not "requestable" by the user. Any Service Request or Standard Change that presents a higher risk may require reassessment and reclassification by Change Management.

Efficient Request Fulfillment requires good process integration between Change Management and Request Fulfillment. It is also important to provide the Service Desk staff with the training and empowerment to fulfill Service Requests and apply Standard Changes when appropriate. Finally, users must be made aware of the Request Menu and fulfillment procedures.

Undervalued Evaluation

I have been reading Service Transition and am struck again that one of the most undervalued processes is Evaluation. The purpose of Evaluation is to provide a consistent and standardized method for determining the performance of a service change. The actual performance of a change is assessed against its predicted performance. Any detected can therefore be understood and managed.

One of the goals of Evaluation is to provide effective and accurate information to Change Management. The objective is to:

• Evaluate the intended effects of a service change as well as the unintended effects of the change. For example, does the change meet the requirements agreed to in Service Design? Does this change have any negative effects on availability, capacity, etc…?
• Provide good quality outputs from the evaluation process so that Change Management can asses whether a service change is to be approved or not.

Triggers for the Evaluation Process:

• Request for Evaluation from the Service Transition manager or Change Management
• Activity on Project Plan

Inputs for the Evaluation Process:

• Service Design package
• Service Acceptance Criteria
• Test results and report
  

Outputs for the Evaluation Process:

• Evaluation Report for Change Management

The Evaluation Report which is passed to Change Management contains the following components:

• Risk profile – a representation of the residual risk left after a change has been implemented
• Deviations Report - difference between predicted and actual performance following the change implementation
• Recommendations – A report to Change Management to accept or reject the change
• Qualifications Statement - What effect did the change have on the state of the service?

The Evaluation process brings a tangible benefit to the business. Its helps ensure that customer expectations for the service change are realistic. By reporting on predicted performance and reporting on actual performance of the service change, Continual Service Improvements can be highlighted for future service changes.

I would highly recommend taking a closer look at this important process.

ITIL V3 and MOF 4.0

Since 1999, Microsoft has offered its own framework for IT Service Management. The analogy with ITIL has always been clear, which is quite obvious as both frameworks offer documented 'best practice' guidance for IT Service Management. There are plenty of interesting differences though.

In a cross-reference document, Microsoft illustrates how MOF and ITIL play leap-frog. The document offers a detailed analysis of the similarities and differences of both frameworks.

More information: go to MOF or download the paper here: Cross-reference MOF-ITIL.

ITIL's Service Design 5

What does the Service Design stage actually design? Many readers of ITIL V3 assume that Service Design is primarily responsible for IT services. In fact, this stage is responsible for five different aspects:

• Service solutions
• Service management systems and tools
• Technology architectures and management systems
• IT and service management processes
• Measurement methods and metrics

ITIL’s holistic approach to design ensures consistency and integration across the full portfolio of IT services. Consideration of each design begins with an assessment of the “as-is” situation, with a view to identifying relationships, dependencies, compatibility, and, especially, opportunities to leverage existing capabilities and resources (service assets). Both opportunities and gaps are identified. This may validate the design of the new service, or may indicate the need to modify or adapt the design of the new service or other existing services.

Service Design is charged with designing services that deliver business value while being manageable, supportable, cost-effective, and flexible enough to scale and incorporate enhancements throughout the operational lifetime of that service.

Strongly emphasized in V3 is the idea that everyone in the IT organization is responsible for the successful provision of value to business customers in the form of IT services.

This is fundamental to ITIL’s treatment of the five aspects of design. Service Design must consider the requirements of all other stages of the service lifecycle. Likewise, processes and participants in other stages of the lifecycle have the responsibility to provide feedback on how well these goals are achieved in testing and in the live environment, and how design of IT services might be improved to optimize total cost of utilization of services throughout their operational lifetime.