Capability: ITIL/COBIT-Based Management Process

On This Page

Introduction
Requirement: Support and Change Management Process
Checkpoint: Support and Change Management Process

Introduction

Best practice processes must be defined for all tasks highlighted in the Infrastructure Optimization Model in order to receive maximum benefit and performance. The following table lists the high-level challenges, applicable solutions, and benefits of moving to the Standardized level in ITIL/COBIT-Based Management Process.

Challenges	Solutions	Benefits
Business Challenges Systems are complex, incompatible, expensive, and provide limited services throughout the organization IT Challenges Few IT policies and automated processes in place Multiple hardware and software configurations Reactive support, incident, and problem management procedures No asset life-cycle management strategy Lack of change or release management processes	Projects Evaluate current operations framework with  a self-assessment tool Validate change preparation with release readiness practices Define incident and problem management procedures Develop and implement a comprehensive help desk strategy	Business Benefits End users have a known service level agreement and contact for troubleshoot problems, improving workforce productivity Changes are easier to implement due to known, repeatable processes IT Benefits IT operations are documented and understood by IT staff and the business organization Simple configuration management improves IT operational efficiency and future deployment activities

The Standardized level of optimization requires that your organization has defined procedures for incident management, problem management, user support, configuration management, and change management.

Requirement: Support and Change Management Process

Audience

You should read this section if you do not have a process for problem, incident, service, configuration, and change management.

Overview

Infrastructure optimization goes beyond products and technologies. People and processes compose a large portion of an organization’s IT service maturity. A number of standards and best practice organizations address the areas of people and process in IT service management. The Microsoft® Operations Framework (MOF) applies much of the knowledge contained in the IT Infrastructure Library (ITIL) and Control Objectives for Information and related Technology (COBIT) standards and makes them actionable and achievable for Microsoft customers.

Phase 1: Assess

The goal of the Assess Phase in operations management is to evaluate the organization’s current capabilities and challenges. To support the operations assessment process, Microsoft has developed the Microsoft Operations Framework (MOF) Service Management Assessment (SMA) as part of the MOF Continuous Improvement Roadmap, and a lighter online version called the MOF Self-Assessment Tool.

The MOF Service Management Assessment is focused on enhancing the performance of people and IT service management processes, and enabling technologies that improve business value. All recommendations generated as a result of the SMA are detailed and justified in business value, and a detailed service improvement roadmap is provided, supported by specific key performance indicators to monitor progress as improvements are implemented.

Phase 2: Identify

The results of the MOF Service Management Assessment form the basis of the Identify Phase. The Assessment will often expose several areas of potential improvement in IT operations. During the Identify Phase we consider these results and prioritize improvement projects based on the business need. Tools and job aids are included in the MOF Continuous Improvement Roadmap to assist with this prioritization.

Phase 3: Evaluate and Plan

The Evaluate and Plan Phase for operational improvement relies on the identified and prioritized areas for improvement. The MOF Service Improvement Program (SIP) guidance enables this phase. SIP is split into two major areas of focus: specific MOF/ITIL process improvement and service improvement guidance. This guidance is delivered through a tool that assists users in identifying their specific trouble points, provides focused guidance for remediation, and is supported by key performance indicators to measure process improvement.   

Recommended Processes for Moving to the Standardized Level

The recommendations in this section are based on common issues found at the Basic level and areas of improvement sought by the Standardized level. These are only recommendations and may be different for your specific organization or industry.

At the Basic level, a large amount of time is typically spent managing problems or servicing requests. As IT service management moves into a Standardized level, problems and requests are prioritized and increasingly managed with tools. Although not formalized in policy, acceptable service levels are communicated and maintained and users know who to contact for IT services. Additionally, team roles, responsibilities, and areas of operational ownership are defined.

The Standardized level implies an increased use of tools to manage and monitor IT operations and infrastructure. Likewise, processes for change management, configuration management, and release management become standardized and predictable. Notably, predeployment testing and stabilizing becomes a priority. The Standardized level also implies an increased aptitude for project management, but there are still opportunities to improve integration of multiple, simultaneous projects and initiatives.

Microsoft provides the Microsoft Operations Framework (MOF) as an iterative model for defining and improving IT operations. MOF defines Service Management Functions (SMFs) as logical operational functions within an IT organization. The SMFs are grouped together into four broad areas: Changing, Operating, Supporting, and Optimizing. This guide highlights areas to improve typically found in organizations at the Basic level of optimization:

• Incident Management

• Problem Management

• Improving End-User Support Services

• Service Definition and Configuration Management

• Implementing Change Management Best Practices

Depending on the organization, improvements to these management functions might or might not have the greatest impact on operational effectiveness and improvement. We recommend that your organization at a minimum completes the online self-assessment, and preferably a full Service Management Assessment to identify the most important areas requiring process or service improvements.

Incident Management

Incident management is a critical process that provides organizations with the ability to first detect incidents, and then target the correct support to resolve the incidents as quickly as possible.

The primary goal of incident management is to restore normal service operation as quickly as possible and to minimize the adverse impact on business operations to maintain the best possible levels of service quality and availability. Normal service operation is defined as a service operation within service level agreement (SLA) limits.

The objectives of incident management are:

• To restore normal service as quickly as possible.

• To minimize the impact of incidents on the business.

• To ensure that incidents and service requests are processed consistently and that none are lost.

• To direct support resources where most required.

• To provide information that allows support processes to be optimized, the number of incidents to be reduced, and management planning to be carried out.

The following sections discuss the major processes within incident management.

Phase 4: Deploy (Incident Management)

Detection, Self-Service, and Recording

The detection process records incidents through a variety of mediums, including those reported by people contacting the Service Desk, or incidents raised by alerts in event management systems.

End users may access self-service facilities to raise their own incidents, check progress on existing incidents, and access self-help information.

All incidents must be recorded, so that they can be tracked, monitored, and updated throughout their life cycle. This information can then be used for problem management, reporting, process optimization, and planning purposes.

Service Request Handling

This process defines the handling of service requests. Different types of service requests must be handled in different ways. The Service Desk may be able to process certain requests, while other requests need to be passed to other teams, such as change management, for processing.

Classification and Initial Support

The classification process categorizes the incident by assigning a priority.

The initial support process provides a first-line resolution for incidents. This can be achieved by checking them against known errors, existing problems, and previous incidents to identify documented workarounds.

Investigation and Diagnosis

This process deals with investigation of the incident and gathering of diagnostic data to identify how the incident can be resolved as quickly as possible. The process includes escalation to higher management or to technical expertise, and functional escalation if necessary to meet SLA targets.

Major Incident Procedure

The major incident procedure addresses critical incidents that require a response above and beyond that provided by the normal incident process. Such incidents may have a major impact on the ability to sustain operations or effectively run the business. Although these incidents still follow the normal incident life cycle, the major incident procedure provides the increased coordination, escalation, communication, and resources that these high-priority events require.

Resolution and Recovery

The resolution and recovery process covers the steps required to resolve the incident, often by interfacing with the change management process to implement remedial actions. After actions have been taken, the success of the resolution is verified.

Following resolution of the incident, such as replacement of a faulty hard disk, there may be recovery actions that need to be taken, such as the restoration of data and restarting the service.

Problem Closure

This process ensures that the customer is satisfied that the incident has been resolved prior to closing the incident record.

Problem Management

By implementing problem management processes at the same time as incident management processes, organizations can identify and resolve the root causes of any significant or recurring incidents, thus reducing the likelihood of recurrence.

The objectives of problem management are to:

• Identify and take ownership of problems affecting infrastructure and service.

• Take steps to reduce the impact of incidents and problems.

• Identify the root cause of problems and initiate activity aimed at establishing workarounds or permanent solutions to identified problems.

• Using recorded problem and incident data, perform trend analysis to predict future problems and enable prioritization of problem management activity.

The following sections discuss major processes within problem management.

Phase 4: Deploy (Problem Management)

Problem Recording and Classification

This process deals with initial detection and recording of a problem. Problems may be reported through the incident management process or detected through analysis of the data collected by the problem management team. You must link problems to existing incidents and record the problem to facilitate prioritization of problem resolutions. After you have recorded a problem, you assess the impact on the business and determine the urgency of the resolution. This assessment determines the problem classification.

Problem Investigation and Diagnosis

This process deals with the investigation of the problem and the diagnosis of the root cause. The data can then be used to help the problem management team assess the resources and skills required to resolve the cause of the problem. The process includes dealing with major problems that require additional planning, coordination, resources, and communication, and which may result in a formal project being initiated.

Error Control

The error control process addresses successful correction of known errors. The objective is to change IT components or procedures to remove known errors affecting the IT infrastructure and thus prevent any recurrence of incidents.

Problem Closure

The problem closure process outlines the need to fully record details of all errors. It is vital to save data on the configuration items (CIs), symptoms, and resolution or circumvention actions relating to all problems. This will build up the organization’s knowledge base.

Following successful implementation of changes to resolve errors, the error record can be closed, together with any associated incident or problem records. A post-implementation review (PIR) can then confirm the effectiveness of the solution.

Improving End-User Support Services

Support services, or the Service Desk is the first point of contact for the organization. Its efficient and effective response to customer problems and concerns can do much to enhance the reputation of the company.

The objectives of the Service Desk can vary based on a number of factors, such as the size of the organization and the defined scope of the Service Desk function.

Service objectives include:

• Providing a single and central point of contact between users and the IT department.

• Providing an interface for users to other service management functions.

• Delivering the high-quality support required for achieving business goals.

• Identifying and lowering the total cost of ownership (TCO) of IT services.

• Supporting changes across business, technology, and process boundaries.

• Improving customer satisfaction.

• Retaining all customers.

• Identifying additional business opportunities.

The major processes within the Service Desk function are addressed in the following sections.

Phase 4: Deploy (Service Desk)

Record and Service Incidents

An incident is a single occurrence of an event that is not part of the standard operation of a service. An incident may cause an interruption to the normal operation of a service or a reduction in the quality of that service.

The function of the Service Desk in this case is to facilitate the restoration of the service to the affected users as quickly as possible.

Manage Service Requests

A service request could be any one of the following examples:

• A request for change.

• A request for information (that is, a query).

• An as-needed job request.

• A procurement request.

• Any communication between a user and the IT department (for example, a complaint, compliment, comment, or suggestion).

The function of the Service Desk in the case of a service request is to ensure that the request is dealt with to the satisfaction of the user, either by satisfying the request directly or by allocating the request to an appropriate resolution group.

Service Definition and Configuration Management

A key principle in effectively managing an IT infrastructure is to document its components and the relationships between them. Configuration management provides the foundation for decision-making in change management, negotiating SLAs, assessing IT capacity, and other critical processes.

Configuration management is a critical process responsible for identifying, controlling, and tracking all versions of hardware, software, documentation, processes, procedures, and other components of the IT organization. The goal of configuration management is to ensure that only authorized components, referred to as configuration items (CIs), are used in the IT environment and that all changes to CIs are recorded and tracked throughout the component’s life cycle. The configuration management process includes the following objectives:

• Identify configuration items and their relationships and add them to the configuration management database (CMDB).

• Enable access to the CMDB and CIs for other functions.

• Update and change CIs following changes to IT components during the release management process.

• Establish a review process that ensures that the CMDB accurately reflects the production IT environment.

The following sections discuss the objectives of configuration management.

Phase 4: Deploy (Configuration Management)

Establish Configuration Items (CIs)

As you design the CMDB, you need to determine an appropriate level of detail for each CI. Then each CI in your organization can be added to the CMDB.

One of the key benefits configuration management provides, in addition to asset management, is the modeling of relationships between IT components. For example, a workstation is made up of a desktop computer, operating system, and applications, and the workstation is connected to and uses the network. The proper understanding and documentation of relationships between IT components makes it possible to perform detailed impact analysis on a proposed change.

Access Configuration Items

After you have added information about IT components and relationships to the CMDB, the information can then be used by other SMFs. Change management, for example, uses the relationships defined within the CMDB to determine the impact of a change on other components within the IT environment.

Change Configuration Items

As release management begins to make changes to IT components, corresponding changes must be made to the CMDB. Without accurate and up-to-date information, the value of configuration management is lost. This process should be done automatically wherever possible. The amount of information and the frequency of change make manual data entry impractical for all but the smallest organizations.

Review Configuration Items

The accuracy of the information stored in the CMDB is crucial to the success of the Change Management and Incident Management SMFs, as well as other service management functions. A review process that ensures that the database accurately reflects the production IT environment needs to be established.

Implementing Change Management Best Practices

Change management describes a consistent set of processes to initiate infrastructure changes, assess and document their potential impacts, approve their implementation, and schedule and review their deployment.

The goal of change management is to provide a disciplined process for introducing required changes into the IT environment with minimal disruption to ongoing operations. To achieve this goal, the change management process includes the following objectives:

• Formally initiate a change through the submission of a request for change (RFC).

• Assign a priority and a category to the change after assessing its urgency and its impact on the infrastructure or end users.

• Establish an efficient process for passing the RFC to decision makers for approval or rejection of the change.

• Plan the deployment of the change.

• Work with release management to manage the release and deployment of changes into the production environment. For more information about the MOF Release Management SMF, go to https://www.microsoft.com/technet/solutionaccelerators/cits/mo/smf/smfrelmg.mspx.

• Conduct a post-implementation review to determine whether the change has achieved its goals and determine whether to keep the change or to reverse it.

The following sections discuss the objectives of configuration management.

Phase 4: Deploy (Change Management)

Process Change Requests

Typically, any person within a business environment can request a change and, by doing so, become a change initiator. Because the pool of potential change initiators is large and consists of people with varying degrees of familiarity with the procedures involved, a process is required that produces change requests of consistent quality and completeness and discards irrelevant requests.

Assign Change Classification to Accepted Change Requests

At this stage, the change request has passed the initial screening, although it has not yet been approved. The next requirement is to classify the priority and category of the change. Even though the priority and classification have been entered by the change initiator, the change manager or a designated deputy reviews them and has the authority to change them if necessary.

Change Authorization

After a change has been correctly prioritized and categorized by the change manager, the change must be authorized.

Change Development

After an RFC has been approved (using the appropriate path based on its priority and category), it moves into the change development phase. This phase addresses the steps necessary to plan the change, develop the deliverables of the change (for example, developing new code or configuring new hardware), and the handover to the release management process for the deployment of the change into the production environment.

Change Review

Following a successful release and deployment into the production environment or, as in the case of a standard change, a deployment into production, a review process must be conducted to establish whether the change has had the desired effect and has met the requirements from the original request for change.

Recommended Reading

MOF Supporting Quadrant

MOF Changing Quadrant

Checkpoint: Support and Change Management Process

	Requirements
	Implemented incident management techniques.
	Implemented problem management techniques.
	Improved end-user support services.
	Implemented service definition and configuration management
	Implemented change management best practices.

If you have completed the step listed above, your organization has met the minimum requirement of the Standardized level for Support and Change Management Processes in the ITIL/COBIT-Based Management Process capabilities of the Infrastructure Optimization Model.

We recommend that you follow additional best practices found in the Supporting and Changing quadrants of the Microsoft Operations Framework, and to develop a base knowledge of MOF, ITIL, and COBIT concepts.