3.2. Service Desk Goal Statement

The Service Desk extends the range of services and offers a more global-focused approach, allowing business processes to be integrated into the Service Management infrastructure. It not only handles incidents, Problems and questions, but also provides an interface for other activities such as customer Change requests, maintenance contracts, software licenses, Service Level Management, Configuration Management, Availability Management, Financial Management for IT Services, and IT Service Continuity Management.

3.3. Service Desk Benefits

· Improved Customer service, perception and satisfaction

· Increased accessibility through a single point of contact, communication, and information

· Better-quality and speedier turnaround of customer requests

· Improved teamwork and communication

· Enhanced focus and a proactive approach to service provision

· A reduced negative business impact

· Better managed infrastructure and control

· Improved usage of IT support resources and increased productivity of business personnel

· More meaningful management information for decision support” (SS 4.1.8)

3.4. Service Desk Critical Success Factors

· Business needs are understood

· Customer requirements are understood

· Investment is made in training for Customers, support teams and Service Desk staff

· Service objectives, goals and deliverables are clearly defined

· Service levels are practical, agreed, and regularly reviewed

· The benefits are accepted by the business (SS 4.10.1)

3.5. Service Desk Key Performance Indicators

· "The number of requests being handled by the Service Desk, with this initially needing to take into account requests passed directly to second-line support groups

· The types of request that staff are spending the most time on, such as

· Equipment failures

· Business application problems

· Telecommunications

· Customer queries

· Installations/upgrades

· The types of request that are taking the longest time to turnaround to the Customer by:

· First-line support

· Second-line internal support groups

· Third-party support groups

· Suppliers

· Which Customers require the most support, and in which areas – this information can be used to develop training programs for both Customer staff and Service Desk and support staff" (SS 4.4.7)

3.6. Service Desk Possible Implementation Problems

· Unrealistic expectations

· Charging can cause the Users to find back-door support options

· Misaligned communications

3.7. Service Desk Tools

· Configuration Management Database

· Service Catalog

· Service Level Agreements, Operational Level Agreements and Underpinning Contracts

· Users Manual

· Support procedures

· Notification and escalation lists

· Customer Surveys

· Knowledge base including list of known errors

· Soft skills such as active listening

· Time tracking

· Reports

· Work load analysis

3.8. Service Desk Inputs and Outputs

When fully implemented the Service Desk will serve as the single interface for IS Users. The following diagram illustrates the types of inputs and outputs into the Service Desk.

Inputs:

· Data feeds (assets, etc)

· Incidents: Desktop, Security, Network, System, Application & Operational

· Requests for status

· Questions

· Service Requests

o Incident product purchases

o Application queries

o Requests for equipment moves, installations, upgrades and enhancements

o Requests for consumables

Outputs:

· Management Information and Monitoring

· Support: Desktop, Security, Network, System, Application & Operational

· Third Party Support

· Sales, Purchase, Contract & Account Management Support

· Communicate status and schedules

Activities:

· "Receiving calls, first-line Customer liaison

· Recording and tracking Incidents and complaints

· Keeping Customers informed on request status and progress

· Making an initial assessment of requests, attempting to resolve them or refer them to someone who can, based on agreed service levels

· Monitoring and escalation procedures relative to the appropriate SLA

· Managing the request life-cycle, including closure and verification

· Communicating planned and short-term changes of service levels to Customers

· Coordinating second-line and third-party support groups

· Providing management information and recommendations for service improvement

· Identifying Problems

· Highlighting Customer training and education needs

· Closing Incidents and confirmation with the Customer

· Contributing to Problem identification" (SS 4.4.1)

3.8.1. Service Desk Inputs and Outputs Diagram

3.8.2. Service Desk Inputs and Outputs Description

Interface	Description
Data feeds (assets, etc)	The Service Desk is the communications center for the users and for IS Support. It is the hub of multiple types of data, including Security, Network, System, Application and other Operational Incidents. It is also the recipient of multiple types of communication including automated interfaces, manual data interfaces and human interfaces. Automated monitoring will feed Incidents into the Service Desk. Where possible, those Incidents feeds should be directly integrated into the Configuration Management Database (CMDB) in order to automatically create new Incident Records. Where the automated monitoring cannot be interfaced, the Service Desk will be called upon to read emails, browse monitoring consoles and check web pages to find data and then manually create Incident Records. Additionally, the Service Desk is the primary interface for both users and IS support. Phone calls and emails from users and IS support must be processed manually and keyed into the CMDB to create new Incident Records.
Security Incidents
Network & System Incidents
Application Incidents
Operational Incidents
Service Desk	The Service Desk is an organization with multiple responsibilities. Those responsibilities are documented within the ITIL processes. The primary responsibility is the implementation of the Incident Management process.
Management Information and Monitoring	As the communications center for IS, the Service Desk is the organization responsible for ensuring that all Incidents are recorded in the CMDB as Incident Records. That consolidation allows management to quickly assess the health of the organization and examine trends.
Desktop Support	The Service Desk is a two-way communications center. Incidents that cannot be managed within the Service Desk are escalated outward functionally to support groups and hierarchically to management. The Service Desk also provides the interface between the technical support teams and the users for status updates, to facilitate diagnosis, to implement work-arounds and other activities as required supporting the ITIL processes.
Network Support
Application Support
Systems & Operations Support
Third Party Support	When escalations and implementations are managed by third party support companies, the Service Desk is the organization called on to facilitate communication. This activity is simply an extension of the communication described above for IS support.
Sales, Purchase, Contract & Account Management Support	As the single point of contact for the user community, the Service Desk is also called upon to provide communications for other processes. These other communications should be documented as Service Requests so that there is a clear distinction between the support of the infrastructure and the support of the users.

3.9. Service Desk as a Function

Service Desk is a Function and not a Process. The primary function of Service Desk is to implement the Incident Management process. Please refer to the description of Incident Management and review that process flow as that process flow is the focus of the Service Desk.

3.10. Service Desk Relationships with other Service Management Processes

Service Desk with Incident Management

Service Desk can be the customer interface to the ITIL processes (2.11)

Service Desk can implement Incident Management (2.11)

Service Desk can provide life-cycle management of Incidents including: receive, record, classify, prioritize, triage, notify, escalate, track, communicate status and report.

Tools, such as the list of Known Errors, used by Service Desk also support Incident Management.

Second level and third level Incident Management may be outside the Service Desk.

Service Desk should document issues that impact the SLA.

Service Desk should define the relationship to "Super Users".

Service Desk should implement and publish customer satisfaction surveys.

Service Desk can feed Incidents into the Incident Management process

Service Desk is responsible for the monitoring and resolution of all Incidents

Second level and third level Incident Management may be outside the Service Desk.

Service Desk is responsible for registering all Incidents

The Service Desk will generally be responsible for Incident resolution and often handles up to 85% of the Incidents

The Service Desk monitors the progress on all registered Incidents

Service Desk assigns the Priority

It is recommended that all five Service Support processes and the Service Desk be implemented as a unit

Incident closure should be handled by the Service Desk even if the resolution was determined outside of the Service Desk

Incidents, Problems, Known Errors, Requests for Change should all be stored or linked into the Configuration Management Database so that that records can be shared (2.9)

Changes may create new Incidents (2.9)

There should be a close interface between Incident, Problem, Change Management and the Service Desk (2.9)

Service Desk with Problem Management

Service Desk can be the customer interface to the ITIL processes.

Service Desk interfaces with Problem Management include Problem identification, escalation and enforcement of SLA/OLA requirements.

Service Desk should escalate to Problem Management when it is unclear how to proceed with Incident Management.

Problem Management must only accept Problems from the Service Desk or the Service Desk will loose control of the process

Service Desk is responsible for disseminating the information about the work-around or resolution once Problem Management defines it

Problem Management must be kept separate from the Service Desk due to conflicts in interests.

Service Desk with Configuration Management

Service Desk can be the customer interface to the ITIL processes.

Service Desk should be integrated with Configuration Management.

Service Desk is dependent on the Configuration Management tools.

Service Desk with Change Management

Service Desk can be the customer interface to the ITIL processes (2.11)

Service Desk should be integrated with Change Management.

Even self-service style "Service Desk" functionality must integrate with Change Management.

Service Desk might act as the focal point for Requests for Change from the Users, distribute the Forward Schedule of Change on behalf of Change Management and keep the Users informed regarding the progress of their Changes (2.11)

The Service Desk may be given delegation to implement standard Changes to circumvent Incidents within its sphere of authority. The scope of such Changes should be predefined and the Change Management function should be informed about all such Changes. Prior approval of Change Management is essential before Changes of specification of any Configuration Item are implemented (2.11)

Change Management can delegate authority to the Service Desk to implement changes

The Service Desk is usually asked to handle customer notification regarding Changes

Effective Change Management relies on the Service Desk and Configuration, Problem and Release Management

The Service Desk must be kept informed of the details of each Change (2.7)

Service Desk with Release Management

Service Desk can be the customer interface to the ITIL processes.

Service Desk should be integrated with Release Management.

Even self-service style "Service Desk" functionality must integrate with Release Management.

Service considerations must be included in release planning.

The Service Desk must be informed about any changes in the vendor support agreements

Release Management should inform the users when there are changes to the vendor support agreements, but the Service Desk may need to repeat that communication

Problem Management and Service Desk personnel must be trained to use and support the new Release

Service Desk with Service Level Management

Service Desk can be the customer interface to the ITIL processes.

Service Desk uses Service Level Agreements and can provide enforcement on the Service Level Agreement and Operational Level Agreement requirements.

Service Desk uses the Service Catalog to define agreed expectations and identify the appropriate support process.

The Service Desk is in the direct firing line of any impact on the SLAs and as such needs rapid information flows (2.11)

Service Desk Incident Records can be used to identify the services when constructing a Service Catalog

Verify that the Service Level Agreements are achievable before agreeing

It is important that the Customer reports Incidents promptly so that the Incident can be resolved within the time allotted in the Service Level Agreement

Many organizations use their Service Desk linked to a comprehensive Configuration Management Database to monitor the Customer's perception of Availability

The Service Desk can monitor Incident response times and Incident resolution times

The Service Desk can monitor compliance with the Underpinning Contracts

The Service Level Agreements related to Incidents and Problems must be clearly visible in the Service Desk tool to facilitate communication, monitoring and escalation

The Customer's perception of response time should be recorded and Problem Management should investigate repetitions

Planning for a new Service should include the Service Desk, Change, Configuration and Release Management to verify resource and training requirements

Service Desk with Financial Management

Service Desk can be the customer interface to the ITIL processes.

Service Desk can integrate with Financial Management.

Service Desk and integrated Service Management processes are likely to be able o provide data to be input to cost calculation (SD 5.5.8)

Training materials must be produced to explain the IT Accounting and/or Charging system. The Service Desk might be one of the users of this documentation (SD 5.6.1)

Sources of data for the costing / charging model are Service Desk calls, workload data from the Capacity Management Database, inventories from the Configuration Management Database and planned acquisitions (Capacity Plan) (SD 5.6.2)

Service Desk with Capacity Management

Service Desk can integrate with IT Service Capacity Management.

Service Desk can recommend improvements to Capacity Management.

Service Desk may refer performance related Incidents to Capacity Management to assess (SD 6.2)

Capacity Management works with Problem Management to give Incident Management diagnostic tools, automated alerting and updates to Known Errors (SD 6.7.1)

Service Desk with IT Service Continuity Management

Service Desk can be the customer interface to the ITIL processes.

Service Desk can integrate with IT Service Continuity Management.

Service Continuity will interface with Service Desk for statistics on prior activities (SD 7.1.8)

Service Continuity is not focused minor technical faults unless that fault can cause a major impact on the business. Those risks are to be worked through Incident and Problem Management, addressed through Availability and Problem Management and resolved through Change and Configuration (and Release) Management (SD 7.2.2)

Criteria need to be established in advance as to when an Incident or Problem will be escalated to Service Continuity Management (SD 7.3.5)

The Service Desk has an important role to play if business continuity is invoked (2.4)

Service Desk with Availability Management

Service Desk can be the customer interface to the ITIL processes.

Service Desk and Incident Management handling of an Incident can significantly impact how this Incident affects Availability (processes, notifications, escalations, diagnostics, detection) (SD 8.5.4)

Diagnostic tools can help Problem Management resolve faster (SD 8.5.4)

The Incident should only be closed when the Users have verified that Service has been restored (SD 8.5.4)

Every component should have a designated maintenance strategy (planned downtime) incorporated into the service agreements (SD 8.5.6)

Service Desk, Change and Problem Management should provide data on downtimes (planned and unplanned), but this should be augmented by automated monitoring (SD 8.8.1)

Service Desk, Incident, Problem, Change and Service Level Management provide inputs into a Service Outage Analysis (SD 8.9.8)

Available Management can use the Expanded Incident LifeCycle and work closely with Incident and Problem Management to insure that failures are not repeated (SD 8.9.9)

4. Incident Management

4.2. Incident Management Goal Statement

The primary goal of the Incident Management process is to restore normal service operation as quickly as possible and minimize the adverse impact on business operations, thus ensuring that the best possible levels of service quality and availability are maintained. ‘Normal service operation’ is defined here as service operation within Service level agreement (SLA) limits.

4.3. Incident Management Benefits

“For the business as a whole:

· Reduced business impact of Incidents by timely resolution, thereby increasing effectiveness

· The proactive identification of beneficial system enhancements and amendments

· The availability of business-focused management information related to the SLA

For the IT organization in particular:

· Improved monitoring, allowing performance against SLAs to be accurately measured

· Improved management information on aspects of service quality

· Better staff utilization, leading to greater efficiency

· Elimination of lost or incorrect Incidents and service requests

· More accurate CMDB information (giving an ongoing audit while registering Incidents)

· Improved User and Customer satisfaction” (SS 5.4)

4.4. Incident Management Critical Success Factors

· "An up-to-date CMDB is a prerequisite for an efficiently working Incident Management process. If a CMDB is not available, information about Configuration Items (CIs) related to Incidents should be obtained manually, and determining impact and urgency will be much more difficult and time-consuming.

· A ‘knowledge base’ in the form of an up-to-date Problem/error database should be developed to provide for resolutions and Work-arounds. This will greatly speed up the process of resolving Incidents. Third-party Known Error databases should also be available to assist in this process.

· An effectively automated system for Incident Management is fundamental to the success of a Service Desk. Paper-based systems are not really practical or necessary, now that good and cheap support tools are available.

· Forge a close link with the Service-Level Management (SLM) process to obtain necessary Incident response targets. Timely Incident resolution will satisfy Customers and Users." (SS 5.5.2)

4.5. Incident Management Key Performance Indicators

· "Total numbers of Incidents

· Mean elapsed time to achieve Incident resolution or circumvention, broken down by impact code

· Percentage of Incidents handled within agreed response time (Incident response-time targets may be specified in SLAs, for example, by impact code)

· Average cost per Incident

· Percentage of Incidents closed by the Service Desk without reference to other levels of support

· Incidents processed per Service Desk workstation

· Number and percentage of Incidents resolved remotely, without the need for a visit" (SS 5.9)

4.6. Incident Management Possible Implementation Problems

· “No visible management or staff commitment, resulting in non-availability of resources for implementation

· Lack of clarity about business needs

· Working practices not being reviewed or changed

· Poorly defined service objectives, goals and responsibilities

· No provision of agreed Customer service levels

· Lack of knowledge for resolving Incidents

· Inadequate training for staff

· Lack of integration with other processes

· Lack of, or expense of, tools to automate the process

· Resistance to change” (SS 5.5.3)

4.7. Incident Management Tools

· Configuration Management Database with automation for matching the Incident to the appropriate Configuration Item

· Automated monitoring with an interface to automatically create Incident Records

· Escalation timers

· Ability to route Incident Records to other Service Desk locations and to other groups

· Automation for Classification

· Auto-Call Distribution telephone system

· Diagnostic tools

· Knowledge base including list of known errors

4.8. Incident Management Inputs and Outputs

Inputs:

· Incident details sourced from (for example) Service Desk, networks or computer operations

· configuration details from the Configuration Management Database (CMDB)

· response from Incident matching against Problems and Known Errors

· resolution details

· response on RFC to effect resolution for Incident(s)

Outputs:

· RFC for Incident resolution; updated Incident record (including resolution and/or Work-arounds)

· resolved and closed Incidents

· communication to Customers

· management information (reports)

Incident Management activities:

· Incident detection and recording

· Classification and initial support

· investigation and diagnosis

· resolution and recovery

· Incident closure

· Incident ownership, monitoring, tracking and communication

4.8.1. Incident Management Inputs and Outputs Diagram

4.8.2. Incident Management Inputs and Outputs Description

Interface	Description
Service Desk	Service Desk acts as the interface into Incident Management for most of the users of the process. The Service Desk accepts customer input from telephone calls, emails and other communications and generates Incident Records. The Service Desk may also be authorized to accept input from various automation processes and transcribe those inputs into Incident Records. Service Desk also communicates outwardly from Incident Management to inform users and management of status, provide work-arounds and confirm resolutions. The extent of the interface between the Service Desk and Incident Management is further detailed in the description of the Service Desk Function.
Computer Operations	Computer Operations and Networking are simply placeholders to indicate 1) that the IS associates and contractors are also users of the Incident Management system and 2) that automated monitoring jobs should be configured to feed Incidents into the Incident Management system. These source objects are included as a reminder that both the human and automation interfaces can either interface through the Service Desk or directly into the Incident Management system.
Networking
Procedures	All of the ITIL processes are interconnected and interdependent. Procedural documents used by all of the ITIL processes should include the process for reporting Incidents into the central Incident Management process. This will ensure consistency in the classification, management, notification and escalation processes.
Other sources of Incident	The ITIL definition for an Incident is: “any event which is not part of the standard operation of a service and which causes, or may cause, an interruption to, or a reduction in, the quality of that service.” Every “Incident” must be reported into the central Incident Management system.
Service Request Procedures	The ITIL definition of a Service Request is simply: “Every Incident not being a failure in the IT Infrastructure.” The intent here is to designate whether an Incident Record is processed through the Incident Management process or through some other standard process. The purpose for this separation is to ensure that metrics on the reliability of the infrastructure are not inflated by “business as usual” user requests.
CMDB	CMDB stands for the “Configuration Management DataBase”. The complete definition of the infrastructure, the relationships between the components and the interrelationships of those components with the other ITIL processes is to be accessible through one central repository. The definition and usage of this repository is contained in the Configuration Management section of this document.
Change Management Process	Incident Management generates both inputs into Change Management and it receives outputs from that process. Inputs from Incident Management into Change Management will be made through the Request for Change process. The outputs from Change Management to Incident Management consist of status updates and management reports including the Forward Schedule of Changes. The Forward Schedule of Changes is used by Incident Management to advise the users and customers about the schedule for implementing the required Resolutions.
Problem Error Database	The Problem Error Database is an essential tool maintained by the Problem Management process. Since Problem Management is not included in this phase of the ITIL implementation, it is important to document a deviation from the defined ITIL processes.
Incident Management Process	The Incident Management Process is defined in the next section of this document.

4.9. Incident Management Process Flow

4.9.1. Incident Management Process Flow Diagram

4.9.2. Incident Management Process Flow Description

Aspect	Description
Ownership, monitoring, tracking and communication	Incident Management has an overriding requirement to take ownership of Incidents, monitor the Incident, track progress on restoring normal service and communicate. This aspect of the overall process is distinct in that it is interrupt driven. In contrast, the other aspects of the Incident Management are sequential.
Incident detection and recording	The sequential aspect of Incident Management begins when an Incident is detected. Detection can be a manual process or it can be implemented through automation.
Initial classification and support	As soon as the Incident has been detected, it is important to create an Incident Record to match this Incident with the appropriate Configuration Item(s). The Classification process then identifies the Category, Impact and Urgency for the Incident. Using that information the appropriate resource is identified
Service Request	The ITIL definition of a Service Request is simply: “Every Incident not being a failure in the IT Infrastructure.” The intent here is to designate whether an Incident Record is processed through the Incident Management process or through some other standard process. The purpose for this separation is to ensure that metrics on the reliability of the infrastructure are not inflated by “business as usual” user requests.
Service Request procedure	Pre-defined procedures are required for all Service Requests.
Investigation and diagnosis	Incidents that are “a failure in the IT infrastructure” must be investigated and diagnosed. Incident Management experience should be captured into standard diagnostic processes. Those processes will typically include a check against related open Incidents, a search through the Problem Error Database, a check against the Forward Schedule of Changes, use of appropriate diagnostic tools and standardized troubleshooting processes.
Resolution and recovery	“The primary goal of the Incident Management process is to restore normal service operation as quickly as possible.” This can be accomplished through a break-fix process, by implementing a work-around, or by following the defined process for implementing a Change. The precise boundaries of responsibility must be defined to ensure that Incident Management does not overreach into Problem Management or Release Management.
Incident closure	Incident Closure is always the responsibility of the Incident Management team, regardless of which ITIL Process actually implemented the restoration of service. Incident Closure consists of verifying with the user that reported the Incident that service has been restored to a normal level.

4.10. Incident Management Line Escalation

4.10.1. Incident Management Line Escalation Diagram

4.10.2. Incident Management Line Escalation Description

Aspect	Description
Detect and record	The sequential aspect of Incident Management begins when an Incident is detected. Detection can be a manual process or it can be implemented through automation.
Request	The ITIL definition of a Service Request is simply: “Every Incident not being a failure in the IT Infrastructure.” The intent here is to designate whether an Incident Record is processed through the Incident Management process or through some other standard process. The purpose for this separation is to ensure that metrics on the reliability of the infrastructure are not inflated by “business as usual” user requests.
Service Request procedure	Pre-defined procedures are required for all Service Requests.
Initial Support	As soon as the Incident has been detected, it is important to create an Incident Record to match this Incident with the appropriate Configuration Item(s). The Classification process then identifies the Category, Impact and Urgency for the Incident. Using that information the appropriate resource is identified
Resolved	Resolution of an Incident simply means that they symptom is no longer occurring. It is important to distinguish between Problem Resolution, implying a permanent fix, and the “restoration of normal service”. Restoration can occur through a break-fix, a work-around, through a permanent fix or simply because the error is no longer occurring.
Resolution / Recovery	Once normal service is possible, it is necessary to “recover”. Recovery can be as simple as reprinting lost reports or as complex as restoring a corrupted database. The process for recovery should be included in the process “script” for this classification of Incident.
Investigate / Diagnose	Incidents that are “a failure in the IT infrastructure” must be investigated and diagnosed. Incident Management experience should be captured into standard diagnostic processes. Those processes will typically include a check against related open Incidents, a search through the Problem Error Database, a check against the Forward Schedule of Changes, use of appropriate diagnostic tools and standardized troubleshooting processes.
ETC	Processes must be defined for functional escalation beyond the skill set available to the Incident Management team.
Close	Incident Closure is always the responsibility of the Incident Management team, regardless of which ITIL Process actually implemented the restoration of service. Incident Closure consists of verifying with the user that reported the Incident that service has been restored to a normal level.

4.11. Incident Management Relationships with other Service Management Processes

Please refer to the prior section for the relationships of Incident Management with Service Desk.

Incident Management with Problem Management

The Incident Management process includes searching for matches against open Problems, Known Errors and resolution details

Incidents are linked to Problem Records when there is a match

Incident Management can generate a Problem Record when the cause of the Incident is unknown

Incident Management is responsible for finding a resolution or a work-around

When Incident Management finds a work-around they should pass it to Problem Management for evaluation

When Problem Management finds a work-around or resolution they need to pass it over to Incident Management

It is recommended that all five Service Support processes and the Service Desk be implemented as a unit

Problem Management should be notified if there is a Major Incident

Incidents, Problems, Known Errors, Requests for Change should all be stored or linked into the Configuration Management Database so that that records can be shared (2.9)

Changes may create new Incidents (2.9)

There should be a close interface between Incident, Problem, Change Management and the Service Desk (2.9)

Incident Management forwards Incident details and work-arounds to Problem Management

Incident Management uses the documentation on known errors and work-arounds

Problem Management reacts to Incidents when escalated

Problem Management should proactively examine the history of Incidents and find trends

Improvements in the Knowledge database should allow Incident Management to resolve more Incidents and do so more quickly

Problem Management should be implemented in parallel with Incident Management, or after Incident Management

Problem Management needs to work closely with Incident Management to create and update the Categories

Problem Management can create or deploy diagnostic tools and then train the Incident Management team on how to use them

Incident Management with Configuration Management

Incident Management utilizes the Configuration Management Database and links Incidents to Configuration Items

Incident Management may uncover discrepancies in the Configuration Management Database

Inconsistencies in the Configuration Management Database should be reported to Configuration Management

It is recommended that all five Service Support processes and the Service Desk be implemented as a unit

Incident Management should use the Configuration Management database to assess the number of users impacted by an Incident

Incidents, Problems, Known Errors, Requests for Change should all be stored or linked into the Configuration Management Database so that that records can be shared (2.9)

Changes may create new Incidents (2.9)

There should be a close interface between Incident, Problem, Change Management and the Service Desk (2.9)

Provide an accurate representation of the infrastructure to support other ITIL processes

Configuration Management must be able to report on all Configuration Items impacted by an Incident or a Problem

All of the ITIL processes should be entered into the Configuration Management Database as Configuration Items and subject to Change Management (3.2)

The Configuration Management Database is used to link Incidents, Problems and other records to the Configuration Items and the Users (2.6)

Incident Management with Change Management

Requests for Change are not regarded as Incidents.

Incident Management will use the response from a Request for Change to implement a work-around or resolution

It is recommended that all five Service Support processes and the Service Desk be implemented as a unit

Replacing faulty hardware is not considered a Change

Incidents, Problems, Known Errors, Requests for Change should all be stored or linked into the Configuration Management Database so that that records can be shared (2.9)

Changes may create new Incidents (2.9)

There should be a close interface between Incident, Problem, Change Management and the Service Desk (2.9)

Incident Management is authorized to make corrections, but should seek authorization for Changes

Incident Management with Release Management

It is recommended that all five Service Support processes and the Service Desk be implemented as a unit

The Definitive Hardware Store can be used in the event of a Major Incident

Problem Management and Service Desk personnel must be trained to use and support the new Release

Release procedures may be an integral part of Incident and Problem Management (2.7)

Incident Management with Service Level Management

The detailed history that Incident Management maintains on each Incident is helpful when evaluating Service Level Agreement breaches

Functional Escalation should occur before the Service Level Agreement time has expired

Hierarchical Escalation occurs when the Service Level Agreement time is likely to expire

Service Level Management defines the time to resolve goals, often based upon Categories

Incident Management uses the time to resolve goals and the Category to determine Urgency

Incident Management gathers the data for the evaluation of Service Level Agreement compliance

Incident priorities and escalation procedures need to be agreed as part of the Service Level Management process and documented in the Service Level Agreements (2.9)

Service Desk Incident Records can be used to identify the services when constructing a Service Catalog

It is best to link the Incident Records, Problem Records, Requests for Change, etc. to defined Services

Recent Incidents and longstanding Problems often cloud the negotiation on Service Level Agreements

Verify that the Service Level Agreements are achievable before agreeing

It is important that the Customer reports Incidents promptly so that the Incident can be resolved within the time allotted in the Service Level Agreement

Many organizations use their Service Desk linked to a comprehensive Configuration Management Database to monitor the Customer's perception of Availability

The Service Desk can monitor Incident response times and Incident resolution times

The Service Level Agreements related to Incidents and Problems must be clearly visible in the Service Desk tool to facilitate communication, monitoring and escalation

The Customer's perception of response time should be recorded and Problem Management should investigate repetitions

Some of the most important targets set in the Service Level Agreements relate to service Availability and thus require Incident resolution within agreed periods (2.1)

Incident Management with Financial Management

Incident Management needs to update Incident Records with appropriate costing codes and hours worked

Financial Management assists the other ITIL Processes in assessing the cost-effectiveness of decisions (SD 5.1.6)

Service Desk and integrated Service Management processes are likely to be able o provide data to be input to cost calculation (SD 5.5.8)

Incident Management with Capacity Management

Incident Management often finds options for beneficial system enhancement

The history of Incidents and Problems is a key input into Capacity planning (SD 6.2)

Other Service Management processes can refer Incidents and Problems to Service Capacity Management when there is a breach or a risk of a breach against a Service Level Agreement. Service Capacity Management will then refer those Incidents or Problems to Resource Capacity Management (2.3, SD 6.2.2, 6.2.3, 6.7)

Reports from the Capacity Management Database are useful to many of the other Service Management processes, but especially so to Service Level Management when reviewing Service Levels and to Incident and Problem Management when investigating and diagnosing Incidents and Problems (SD 6.3.5)

It is necessary to review the Capacity Management Database to ensure the data collected is at the appropriate level and for the appropriate values so that the monitoring is not wasting resources and not missing data vital to the Incident and Problem Management processes (SD 6.6)

Incident Management must inform Capacity Management regarding all Incidents related to capacity or performance (SD 6.7.1)

Capacity Management works with Problem Management to give Incident Management diagnostic tools, automated alerting and updates to Known Errors (SD 6.7.1)

Incident Management with IT Service Continuity Management

Criteria need to be established in advance as to when an Incident or Problem will be escalated to Service Continuity Management (SD 7.3.5)

Incident Management with Availability Management

A history of prior Incidents and Problems is used in Availability planning to assess component failures

Availability Management is dependent upon the maturity of Incident, Problem and Change Management

It might be necessary to improve upon the Incident, Problem, Change and Release Management processes to achieve higher levels of Availability (SD 8.5.3)

Service Desk and Incident Management handling of an Incident can significantly impact how this Incident affects Availability (processes, notifications, escalations, diagnostics, detection) (SD 8.5.4)

Diagnostic tools can help Problem Management resolve faster (SD 8.5.4)

The Incident should only be closed when the Users have verified that Service has been restored (SD 8.5.4)

Incident and Problem Management should provide input into the Availability reports to highlight Problem "black spots" and areas for increased preventative maintenance (SD 8.7.7)

Service Desk, Change and Problem Management should provide data on downtimes (planned and unplanned), but this should be augmented by automated monitoring (SD 8.8.1)

Service Desk, Incident, Problem, Change and Service Level Management provide inputs into a Service Outage Analysis (SD 8.9.8)

Available Management can use the Expanded Incident LifeCycle and work closely with Incident and Problem Management to insure that failures are not repeated (SD 8.9.9)

5. Problem Management

5.2. Problem Management Goal Statement

The goal of Problem Management is to minimize the adverse impact of Incidents and Problems on the business that are caused by errors within the IT Infrastructure, and to prevent recurrence of Incidents related to these errors. In order to achieve this goal, Problem Management seeks to get to the root cause of Incidents and then initiate actions to improve or correct the situation.

5.3. Problem Management Benefits

· “Improved IT service quality

· Incident volume reduction

· Permanent solutions

· Improved organizational learning

· Better first-time fix rate at the Service Desk” (SS 6.4)

5.4. Problem Management Critical Success Factors

· “An effective automated registration of Incidents, with an effective classification, is fundamental for the success of Problem Management.

· Setting achievable objectives and making use of the Problem-solving talents of existing staff is a key activity. Consider ‘part-time’ Problem Management, whereby staff set aside periods when they will look at Problems away from the daily fire-fighting pressures.

· In view of the potentially conflicting interests between Incident Management and Problem Management (paragraph 6.3.1), good cooperation between both processes is essential. Both also have enormous synergy, which can help. Support staff, often involved in both processes, should be aware of the importance of balancing activities between the two.” (SS 6.5.2)

5.5. Problem Management Key Performance Indicators

· “The number of Problems and errors split by:

o status

o service

o impact

o category

o User group

· The total elapsed time on closed Problems

· The elapsed time to date on outstanding Problems

· The mean and maximum elapsed time to close Problems or confirm a Known Error, from the time of raising the Problem record, by impact code and by support group (including vendors)

· Any temporary resolution actions

· The expected resolution time for outstanding Problems

· The total elapsed time for closed Problems” (SS 6.10.1)

5.6. Problem Management Possible Implementation Problems

· “Absence of a good Incident control process, and thus the absence of detailed historical data on Incidents (necessary for the correct identification of Problems).

· Failure to link Incident records with Problem/error records, means a failure to gain many of the potential benefits. This is a key feature in moving from reactive support to a more planned and proactive support approach.

· Lack of management commitment, so that support staff (usually also involved with reactive Incident control activities) cannot allocate sufficient time to structural Problem-solving activities.

· The undermining of the Service Desk role. Problem Management staff should accept support requests only from authorized sources. Difficulties will arise if the process deals with requests from many sources since multiple reports of Incidents with the same cause may not be interpreted in the same way.

· Failure to set aside time to build and maintain the knowledge base will restrict the delivery of benefits.

· An inability to determine accurately the business impact of Incidents and Problems. Consequently the business-critical Incidents and Problems are not given the correct priority.“ (SS 6.5.3)

5.7. Problem Management Tools

· Configuration Management Database for a record of the Configuration Items, Incidents, Problems and Request for Change

· Kepner and Tregoe analysis (Scientific Method)

· Ishikawa Diagrams

· Brainstorming

· Flowcharting

5.8. Problem Management Inputs and Outputs

Inputs:

· “Incident details from Incident Management

· Configuration details from the Configuration Management Database (CMDB)

· Any defined Work-arounds (from Incident Management)” (SS 6.2)

Outputs:

· “Known Errors

· A Request for Change (RFC)

· An updated Problem record (including a solution and/or any available Work-arounds)

· For a resolved Problem, a closed Problem record

· Response from Incident matching to Problems and Known Errors

· Management information” (SS 6.2)

Activities:

· “Problem control

· Error control

· The proactive prevention of Problems

· Identifying trends

· Obtaining management information from Problem Management data

· The completion of major Problem reviews” (SS 6.2)

5.8.1. Problem Management Inputs and Outputs Diagram

5.8.2. Problem Management Inputs and Outputs Description

Interface	Description
Incident Details	The standard pathway into Problem Management is from Incident Management. Incident Records are worked by Incident Management until matching the Incident to existing Problems and Known Errors is not successful during the stage of Incident initial support and classification analysis of Incident data reveals recurrent Incidents analysis of Incident data reveals Incidents that are not yet matched to existing Problems or Known Errors analysis of the IT infrastructure indicates a Problem that could potentially lead to Incidents a major or significant Incident (serious and adverse impact on services to the Customer) occurs for which a structural solution has to be found Incident Management will then escalate to Problem Management and Problem Management will use the history of the activity recorded in the Incident Record(s) to create a new Problem Record. Subsequent Incidents that match this Problem Record will be linked to this Problem Record by Incident Management. Those additional Incidents will be evaluated by Problem Management to glean additional information about the underlying Problem.
Configuration Details	The Configuration Management Database (CMDB) is the core system that supports the ITIL processes. Incident Records and Problem Records will be linked to the Configuration Items in the CMDB. The details about those Configuration Items and the relationships between Configuration Items are valuable to Problem Management in diagnosing the Problem, assessing the impact, and preparing the resulting Request for Change.
Work-Arounds	Incident Management often generates work-arounds to Problems in order to “restore normal operations as quickly as possible”. Those work-arounds must be linked to the Problem Record so that Incident Management can quickly access this information and not expend time reinventing something that has already been developed. Additionally, the work-arounds often provide valuable information that aids Problem Management in determining the underlying cause.
Problem Management	The Problem Management process has six primary activities, as shown in the preceding diagram. The flow through the Problem Management process is also documented in the following section of this document.
Problem Control	“The Problem control process is concerned with handling Problems in an efficient and effective way. The aim of Problem control is to identify the root cause, such as the CIs that are at fault, and to provide the Service Desk with information and advice on Work-arounds when available.”
Error Control	“Error control covers the processes involved in progressing Known errors until they are eliminated by the successful implementation of a Change under the control of the Change Management process. The objective of error control is to be aware of errors, to monitor them and to eliminate them when feasible and cost-justifiable.”
Proactive	“Proactive Problem Management covers the activities aimed at identifying and resolving Problems before Incidents occur. These activities are: Trend analysis Targeting support action Providing information to the organization By redirecting the efforts of an organization from reacting to large numbers of Incidents to preventing Incidents, an organization provides a better service to its Customers and makes more effect use of the available resources within the IT support organization.”
Identify Trends
Management Info
Major Problem Reviews	On completion of the resolution of every major Problem, Problem Management should complete a major Problem review. The appropriate people involved in the resolution should be called to the review to determine: What was done right What was done wrong What could be done better next time How to prevent the Problem from happening again
Known Errors	ITIL defines a Known Error as “an Incident or Problem for which the root cause is known and for which a temporary Work-around or a permanent alternative has been identified. If a business case exists, an RFC will be raised, but, in any event, it remains a known error unless it is permanently fixed by a Change.”
Request for Change	An important distinction between Problem Management and Incident Management is that the Problem Management produces resolutions that require a Change to the environment. The Request for Change is the document used by Problem Management to interface with Change Management.
Updated Problem Record	Problem Management is responsible for maintaining an accurate and current status in the Problem Record in order to communicate with the other ITIL processes. The Service Desk will use those Problem Record updates to communicate status to the user community.
Problem Resolution	A Problem Resolution is a Change that will resolve the Problem and the Incidents linked to that Problem. This is a “permanent fix”. For example, if an Incident Record states that a web server process is no longer serving web pages, Incident Management may “restore normal operations” by stopping and restarting the web server process. That is a work-around. Problem Management may become engaged because the Incident recurs. Problem Management will then come up with a Problem Resolution, such as applying a patch to the operating system.
Incident matching	Problem Management and Incident Management work together to link Incidents to Problems so that the Release Management process can implement the Problem Resolution on each impacted Configuration Item.
Management Information	Problem Management is responsible for providing key management information including an analysis on the number of Problems and a summary on the type of closure on each.

5.9. Problem Management Problem Control Process Flow

5.9.1. Problem Management Problem Control Process Flow Diagram

5.9.2. Problem Management Problem Control Process Flow Description

Aspect	Description
Tracking and monitoring of Problems	Tracking and monitoring of Problems is an ongoing asynchronous activity. Problems need to be checked for changes in the reported errors, for diagnostic input, for third party resolutions and for communication from the users, customers and other ITIL processes. Problem Management is also responsible for updating the Problem Record on a consistent basis so that the other ITIL processes and the Service Desk can use the Problem Record for immediate status.
Problem identification and recording	The standard pathway into Problem Management is from Incident Management. Incident Records are worked by Incident Management until matching the Incident to existing Problems and Known Errors is not successful during the stage of Incident initial support and classification analysis of Incident data reveals recurrent Incidents analysis of Incident data reveals Incidents that are not yet matched to existing Problems or Known Errors analysis of the IT infrastructure indicates a Problem that could potentially lead to Incidents a major or significant Incident (serious and adverse impact on services to the Customer) occurs for which a structural solution has to be found Incident Management will then escalate to Problem Management and Problem Management will use the history of the activity recorded in the Incident Record(s) to create a new Problem Record. Subsequent Incidents that match this Problem Record will be linked to this Problem Record by Incident Management. Those additional Incidents will be evaluated by Problem Management to glean additional information about the underlying Problem.
Problem classification	When a Problem is identified, the amount of effort required to detect and recover the failing CI(s) has to be determined. Therefore it is important to be aware of the impact of the Problem on existing service levels. This process is known as ‘classification’. In practice, support effort is allocated to only a small proportion of Problems linked to a single Incident. The steps involved in Problem classification are similar to the steps in classifying Incidents; they are to determine: category impact urgency priority
Problem investigating and diagnosis	“The process of Problem investigation is similar to that of Incident investigation – but the primary objective of each process is significantly different. Incident Management’s aim is rapid restoration of service, whereas Problem Management’s aim is diagnosis of the underlying cause. Investigation activities should include available Work-arounds for the Incidents related to the Problem, as registered in the Incident record database. Problem Management activities should include updating recommended Work-arounds in the Problem record, to support Incident control.”
RFC and possible resolution and closure	The Problem Control investigation may uncover the Change required to resolve the Problem. When that occurs, Problem Control will need to follow the steps described for how Error Control records the Error resolution, generates and monitors a Request for Change, and closes the Problem when the Change has successfully resolved the Problem to the satisfaction of the user.
Error Control	“Error control covers the processes involved in progressing Known errors until they are eliminated by the successful implementation of a Change under the control of the Change Management process. The objective of error control is to be aware of errors, to monitor them and to eliminate them when feasible and cost-justifiable.” Once the Problem Control activities have been completed, the Known Error and the Problem(s) linked to that Known Error are passed to Error Control for resolution.

5.10. Problem Management Error Control Process Flow

5.10.1. Problem Management Error Control Process Flow Diagram

5.10.2. Problem Management Error Control Process Flow Description

Aspect	Description
Problem Control	“The Problem control process is concerned with handling Problems in an efficient and effective way. The aim of Problem control is to identify the root cause, such as the CIs that are at fault, and to provide the Service Desk with information and advice on Work-arounds when available.” Once the Problem Control activities have been completed, the Known Error and the Problem(s) linked to that Known Error are passed to Error Control for resolution.
Tracking and monitoring errors	Tracking and monitoring of Errors is an ongoing asynchronous activity. Errors need to be checked for changes in the reported symptoms, for diagnostic input, for third party resolutions and for communication from the users, customers and other ITIL processes. Problem Management is also responsible for updating the Error Record on a consistent basis so that the other ITIL processes and the Service Desk can use the Error Record for status.
Identify and record error	When the person performing the Error Control activities is not the person that performed the Problem Control activities, it is necessary to begin Error Control by reviewing the history of the Incident(s), work-around(s), Problem(s) and Known Error.
Assess Error	Error Assessment is the process of evaluating alternative resolutions to find the resolution that achieves the desired results cost effectively.
Record Error resolution	Once the appropriate resolution has been identified, it is important to record those details so that the Incident(s), work-around(s), Problem(s) and Known Error link to this resolution. Note that this step is highlighted here, but is already called for as part of the ongoing activity of “Tracking and monitoring errors”.
RFC	An RFC is a Request for Change. The Request for Change is the document used by Problem Management to interface with Change Management in order to Release the resolution into the production environment.
Change successfully implemented	Change Management assesses the success of a Change by verifying user satisfaction. Problem Management interfaces with Change Management to determine the implementation status and verify that the resolution is satisfactory.
Close Error and associated Problem(s)	Once the resolution has been successfully implemented, Problem Management will close the Known Error and all associated Problem Records with appropriate comments. Incident Management will use the Known Errors database to link new Incidents to this Known Error and identify the appropriate resolution.

5.11. Problem Management Relationships with other Service Management Processes

Please refer to the prior section for the relationship of Problem Management with Service Desk and Incident Management

Problem Management with Configuration Management

Problem Management utilizes the Configuration Management Database to identify details about the Incidents and Problems

It is sometimes necessary to create dummy Configuration Items to allow tracking of Problems

All support documentation must be made available to the Problem Management team

Problem Management should use the contact information in the Configuration Management Database to determine who needs to know about a work-around or resolution

Provide an accurate representation of the infrastructure to support other ITIL processes

Configuration Management must be able to report on all Configuration Items impacted by an Incident or a Problem

Problem Management uses the Configuration Management Database during trend analysis

All of the ITIL processes should be entered into the Configuration Management Database as Configuration Items and subject to Change Management (3.2)

The Configuration Management Database is used to link Incidents, Problems and other records to the Configuration Items and the Users (2.6)

Problem Management with Change Management

Request for Change is submitted in order to implement a resolution

Problem Management should examine records of recent changes to see if those changes contributed to the Problem

Problem Management should advise Change Management as to the urgency of the Problem and can escalate if the Problem becomes more critical

Requests for Change can encompass processes as well as hardware and software

Problem Management only leads to a change when there is "a state different from a previously defined condition"

Effective Change Management relies on the Service Desk and Configuration, Problem and Release Management

Problem Management with Release Management

Problem Management records should trace from Incident to Problem to Known Error to Request for Change to Release and change implementation

A Release is typically designed to resolve problems and enhance services

An Emergency Fix generally resolves a small number of Problems

A Minor Release generally supersedes by inclusion prior Emergency Fixes as well as incorporating a few enhancements

A Major Release often includes enhancements that make prior Problem fixes redundant

A Package Release bundles multiple Releases, often from different applications, together into one Release

Procedures need to be defined for Problem escalation as related to the Release process

Once the Release is successful, Problems and enhancement requests resolved by the Release should be closed

Problems caused by the Release should be linked to the Release

Problem Management and Service Desk personnel must be trained to use and support the new Release

Release procedures may be an integral part of Incident and Problem Management (2.7)

Problem Management with Service Level Management

Problem Management needs to be aware of the impact that Problems are having on Service Levels

Problems reported to vendors need to be monitored to insure that the vendor responds in a reasonable time or within the time defined in the Underpinning Contract when defined there

Problem resolution needs to be measured against the Service Level Agreements

Problem identification and resolution is easier when Service Level Management has built a strong relationship between IT and the IT Customers

It is best to link the Incident Records, Problem Records, Requests for Change, etc. to defined Services

Recent Incidents and longstanding Problems often cloud the negotiation on Service Level Agreements

It is best to pilot the Service Level Agreements with a Customer group that has a small number of Problems

Many organizations use their Service Desk linked to a comprehensive Configuration Management Database to monitor the Customer's perception of Availability

The Service Level Agreements related to Incidents and Problems must be clearly visible in the Service Desk tool to facilitate communication, monitoring and escalation

The Customer's perception of response time should be recorded and Problem Management should investigate repetitions

Service Review meetings should be held monthly, or at least quarterly to review the results and initiate a Service Improvement Program if warranted

Problem Management with Financial Management

Resolutions need to be cost effective

Some Problems do not justify the expenditure required for resolution

Financial Management assists the other ITIL Processes in assessing the cost-effectiveness of decisions (SD 5.1.6)

Service Desk and integrated Service Management processes are likely to be able o provide data to be input to cost calculation (SD 5.5.8)

Financial Management should conduct periodic audits to ensure that the Change and Problem Management processes are strictly followed (SD 5.7.11)

Problem Management with Capacity Management

Capacity Management should be the "focal point" for all performance and capacity Problems (SD 6.1.1, 6.1.3)

The history of Incidents and Problems is a key input into Capacity planning (SD 6.2)

Proactive Changes and Service Improvements are key outputs from Capacity Planning (SD 6.2)

Capacity Management should preempt performance Problems (SD 6.2)

Service and Resource Capacity Management must be proactive, anticipate the impact that Changes will have on the infrastructure and take action to preclude Problems (SD 6.2.2, 6.2.3)

Capacity Management should reduce the number of urgent Changes and reduce the risk of Problems (SD 6.4.2)

Capacity Management works with Problem Management to give Incident Management diagnostic tools, automated alerting and updates to Known Errors (SD 6.7.1)

Problem Management expertise may be called on to assist in resolving Problems related to capacity or performance (SD 6.7.2)

The Capacity Management Database needs to be linked into the Configuration Management Database to assist Service Management in assessing proposed Service Level Agreements and Problem Management in diagnosing Problems (SD 6.7.5)

Slow performance and capacity Problems can result in Unavailability of the Service to the users (SD 6.7.9)

Problem Management with IT Service Continuity Management

Criteria need to be established in advance as to when an Incident or Problem will be escalated to Service Continuity Management (SD 7.3.5)

Problem Management with Availability Management

Much of Availability Managements work is in the detection and avoidance of Problems

Fragility of components

Problem Management needs to work closely with Availability Management to identify trends and instigate remedial action (2.9)

A history of prior Incidents and Problems is used in Availability planning to assess component failures

Availability Management is dependent upon the maturity of Incident, Problem and Change Management

It might be necessary to improve upon the Incident, Problem, Change and Release Management processes to achieve higher levels of Availability (SD 8.5.3)

Diagnostic tools can help Problem Management resolve faster (SD 8.5.4)

Scheduling multiple Changes within one downtime can increase Availability, but it has the risks of increased complexity in Release Management and increased complexity for Problem Management when something goes wrong (SD 8.5.6)

Incident and Problem Management should provide input into the Availability reports to highlight Problem "black spots" and areas for increased preventative maintenance (SD 8.7.7)

Service Desk, Change and Problem Management should provide data on downtimes (planned and unplanned), but this should be augmented by automated monitoring (SD 8.8.1)

Service Desk, Incident, Problem, Change and Service Level Management provide inputs into a Service Outage Analysis (SD 8.9.8)

Available Management can use the Expanded Incident LifeCycle and work closely with Incident and Problem Management to insure that failures are not repeated (SD 8.9.9)

6. Configuration Management

6.2. Configuration Management Goal Statement

The goals of Configuration Management are to:

· Account for all the IT assets and configurations within the organization and its services

· Provide accurate information on configurations and their documentation to support all the other Service Management processes

· Provide a sound basis for Incident Management, Problem Management, Change Management and Release Management

· Verify the configuration records against the infrastructure and correct any exceptions

6.3. Configuration Management Benefits

· Provide accurate information on CIs and their documentation

· Controlling valuable CIs

· Facilitating adherence to legal obligations

· Helping with financial and expenditure planning

· Making software Changes visible

· Contributing to contingency planning

· Supporting and improving Release Management

· Improving security by controlling of the versions of CIs in use

· Enabling organizations to reduce the use of unauthorized software

· Allowing the organization to perform impact analysis and schedule Changes safely, efficiently and effectively

· Provide Problem Management with data on trends (SS 7.4.1)

6.4. Configuration Management Critical Success Factors

"Providing everyone working in Service Management and support with correct and accurate information on the present configurations with their physical and functional specifications

Defining and documenting the procedures and working practices to be followed

Identifying, labeling and recording the names and versions of the CIs that make up the IT services, infrastructure and their relationships

Controlling and storing definitive, authorized and trusted copies of specifications, documentation and software

Reporting the current status and history of all items on the IT infrastructure

Ensuring that all Changes to CIs are recorded as soon as practicable

Tracking and reconciling the actual state of the IT infrastructure against the authorized configuration records and data

Educating and training the organization in the control processes

Reporting metrics on CIs, Changes and Releases

Auditing and reporting exceptions to infrastructure standards and Configuration Management procedures" (SS 7.5.2)

6.5. Configuration Management Key Performance Indicators

· "Occasions when the ‘configuration’ is not as authorized

· Incidents and Problems that can be traced back to wrongly made Changes

· RFCs that were not completed successfully because of poor impact assessment, incorrect data in the CMDB, or poor version control

· The cycle time to approve and implement Changes

· Licenses that have been wasted or not put into use at a particular location

· Exceptions reported during configuration audits

· Unauthorized IT components detected in use" (SS 7.7.2)

6.6. Configuration Management Possible Implementation Problems

· CIs are defined at the wrong level with too much detail

· Implementation is attempted without adequate analysis and design

· Tactical schedules are overly ambitious

· Commitment is lacking

· The process is perceived to be too bureaucratic or rigorous

· The process is routinely circumvented

· Processes are inefficient and error-prone

· Expectations of what the tool can do are unrealistic

· The chosen tool may lack flexibility

· Configuration Management implemented without Change and Release Management

· Expectations about the process are unrealistic

· Proper configuration control is not in place (SS 7.4.2)

6.7. Configuration Management Tools

· Configuration Management Database

· Software configuration management tools

· Change Management support (impact analysis)

· Automation for configuration auditing

· Automation for release deployment

· Definitive Software Library

· Definitive Hardware Store

· Document management system

· Design, analysis and build tools

· Report generation tools

6.8. Configuration Management Inputs and Outputs

All of the ITIL Service Management processes and functions are dependent upon the Configuration Management process. The primary interfaces, however, are with Service Desk, Incident Management, Change Management and Configuration Management. Those flows are included in this document.

Inputs:

· Incidents, Problems, Known Errors and updates

· RFC data and status updates

· SW & HW for DSL/DHS

· Configuration audits

Outputs:

· Forward Schedule of Changes

· Projected Service Availability

· RFC, assessment and updates

· Releases from DSL/DHS & library

· Updated CIs and relationships

· Management information

· Linkages to the CDB

Activities:

· Configuration Management planning

· Configuration Identification

o Configuration structures and the selection of CIs

o CI types and life-cycles

o CI relationships

o Identification of software and document libraries

o Identification of configuration baselines

o Naming conventions

o Labeling CIs

· Control of CIs

o Registration of new CIs and versions

o Software developed in house

o Off-the-shelf CIs

o New CIs and versions from building and releasing

o Updating CIs

o License control

o Updating and archiving configuration records of withdrawn/decommissioned CIs

o Protecting the integrity of configurations

o Updating the CMDB after checking the physical items

· Configuration status accounting

· Configuration verification and audit

· CMDB back-ups, archives and housekeeping

· Adding value to the Service Management organization

6.8.1. Configuration Management Inputs and Outputs for the Incident Life-Cycle

The primary focus of the Service Desk will be Incident Management. The relationship of Incident Management with the Configuration Management Database is illustrated below.

6.8.2. Configuration Management Inputs and Outputs for the Incident Life-Cycle

Interface	Description
Start	The Incident Life-Cycle begins with first notification of an Incident. The majority of all Incidents will be reported to the Service Desk, but some Incidents currently route directly to an alternative support process.
Incident	Whether the Incident is directly reported to the Service Desk or to an alternative support process, the first action to take is to create an Incident Record. Incident Records are to be stored in the Configuration Management Database to facilitate matching against the Configuration Item and to support trending and reporting against Configuration Items. The Incident Management process is responsible for restoration of normal service. The scope boundary for Incident Management must be clearly defined so that Incident Management has a clear delineation from Problem Management. Once Incident Management has reached that boundary, it is the responsibility of Incident Management to escalate to Problem Management.
Problem	Escalation to Problem Management is documented by creating a Problem Record in the Configuration Management Database. Problem Records should be in the Configuration Management Database for reasons similar to those listed above for Incidents. Additionally, it is important that searches and reports can quickly identify the linkages between Incidents and Problems. The flow through Problem Management is divided into Problem Control and Error Control. The primary duty of Problem Control is to take symptoms and isolate them to the underlying cause. Once isolated, the underlying cause can be defined as a Known Error.
Known Error	ITIL defines a Known Error as: “An Incident or Problem for which the root cause is known and for which a temporary Work-around or a permanent alternative has been identified. If a business case exists, an RFC will be raised, but, in any event, it remains a known error unless it is permanently fixed by a Change.” It is important that Known Errors be recorded in the Configuration Management Database to: 1) Allow Problem Management to link the Known Error to the Problem Records and thus to the Incident Records 2) Allow the Service Desk to advise the user on the status of the investigation into a permanent resolution to their Problem 3) Allow Configuration Management to advise Change Management with the list of Configuration Items
Request for Change	Once it is recognized that a Change is required in order to resolve a Known Error, the Problem Management team must to create a Request for Change. The Request for Change belongs in the Configuration Management Database so that it can be linked to the Known Error, and thus linked to the Problem Records, Incident Records and underlying Configuration Items.
Change Authorized	The status of the Request for Change must be tracked. The flow through the Change Management process is described elsewhere in this document. Each status update, however, must be recorded in the Configuration Management Database so that it is clearly visible to all who need status. The Service Desk, as the primary interface to the users, will use this status, via the linkage to the user’s Configuration Items, to advise the users as to the progress on resolving their Problem.
Change tested, Implemented and Released	Release Management must be able to update the Request for Change and appropriate Configuration Items to document the progress of their work.
End	The Incident Life-Cycle ends when the underlying Problem has been resolved to the satisfaction of the user and all tributary Incidents closed.

6.8.3. Configuration Management Inputs and Outputs for Change Management

The complexity of the interface between Change Management and Configuration Management is illustrated in the following diagram and text.

6.8.4. Configuration Management Inputs and Outputs for Change Management

Interface	Description
Request for Change Register and allocation RFC number	A Request for Change is the entry point into the Change Management process. It is important that all Requests for Change be recorded in the Configuration Management Database so that they can be properly linked to the Configuration Items that will be affected.
Reports & Configuration audit to check environment	Many Changes have prerequisites. It is the responsibility of Configuration Management to ensure that the Configuration Items are accurate so that the impact assessment can proceed.
CMDB	CMDB stands for Configuration Management Database. This is the central repository for all configuration information. It is also recommended that all Incident Records, Problem Records, Known Errors and Requests for Change be linked through this repository.
Definitive Software Library	The library in which the definitive authorized versions of all software CIs are stored and protected. It is a physical library or storage repository where master copies of software versions are placed. This one logical storage area may in reality consist of one or more physical software libraries or file stores. They should be separate from development and test file store areas. The DSL may also include a physical store to hold master copies of bought-in software, e.g. a fireproof safe. Only authorized software should be accepted into the DSL, strictly controlled by Change and Release Management. The DSL exists not directly because of the needs of the Configuration Management process, but as a common base for the Release Management and Configuration Management processes.
Assess Analyze impact, broker agreement where assessors differ	Change Management is dependent upon Configuration Management to provide an accurate and comprehensive description of the impact from the proposed Change. Change Management will then use that assessment during evaluation and approval.
Reports on CIs, areas & parties impacted	The key benefit of a Configuration Management Database is the definition of the relationships between Configuration Items. Configuration Management makes use of those relationship definitions when assessing the impact that a proposed Change will have on the infrastructure and on the vital business functions.
Approved Change	The Change Advisory Board will meet and reject, approve or approve with conditions.
Update CM records	It is the responsibility of Configuration Management to record the status of the Request for Change in the Configuration Management Database. This is an on-going effort, but it is highlighted here as a reminder of the importance of this effort.
Implement Change This will involve pre-release testing where software changes are required	The Change Management process will authorize a release schedule based upon the details accompanying the Request for Change. Release Management will then ensure that the appropriate development and testing processes are followed.
Release & distribute new versions of software and hardware with documentation	When the Release is ready, Release Management is authorized to begin distributing the Release. Implementation of the Release, however, must follow the pre-approved schedule.
Baseline, release software from DSL & update DSL & CM records	When the Release is ready, Release Management will provide Configuration Management with a release package. Configuration Management is responsible for uploading the Release into the Definitive Software Library and updating the appropriate Configuration Management Database records.
Post-Implementation Review Has change met originator's expectations?	“Following successful implementation of Changes to resolve errors, the relevant Known error record(s) is closed, together with any associated Incident or Problem records. Consideration should be given to inserting into the process an interim status, on the Incident, Known Error and Problem records, of ‘Closed pending PIR’ to ensure that the fixes have actually worked. A Post-Implementation Review (PIR) can then confirm the effectiveness of the solution prior to final closure.”
Close Change	The Change can only be closed when the user has verified that the Problem has been resolved.
Check all CM records were updated	It is the responsibility of Configuration Management to insure that all of the linked Requests for Change, Known Errors, Problem Records, Incident Records and Configuration Items are appropriate updated to record the implementation of the Release and the resolution of the Problem.
End	The end of this Process.

6.9. Configuration Management Process Flow

6.9.1. Configuration Management Process Flow Diagram

6.9.2. Configuration Management Process Flow Description

Aspect	Description
New	When Configuration Management first initiates, it is necessary to begin planning for the Configuration Management Process. This same task recurs whenever significant changes are scheduled.
Planning	ITIL defines planning as “defining the purpose, scope, objectives, policies and procedures and the organizational and technical context, for Configuration Management.”
Identification	ITIL defines Identification as “selecting and identifying the configuration structures for all the infrastructure’s CIs, including their ‘owner’, their interrelationships and configuration documentation. It includes allocating identifiers and version numbers for CIs, labeling each item, and entering it on the Configuration management database (CMDB).” The key distinction between an ITIL Configuration Management Database and a simple asset tracking system is the ability to define and track the relationships between the Configuration Items.
Control	Control is the core within Configuration Management. ITIL defines this as “ensuring that only authorized and identifiable CIs are accepted and recorded, from receipt to disposal. It ensures that no CI is added, modified, replaced or removed without appropriate controlling documentation, e.g. an approved Change request, and an updated specification.” That definition is too succinct in that Control is the daily activity for the Configuration Management group.
On Demand	While Planning, Identification and Control flow in a linear sequence, “Status Accounting” and “Verification and Audit” are only executed as required.
Status Accounting	ITIL defines Status accounting as “the reporting of all current and historical data concerned with each CI throughout its life cycle. This enables Changes to CIs and their records to be traceable, e.g. tracking the status of a CI as it changes from one state to another for instance ‘under development’, ‘being tested’, ‘live’, or ‘withdrawn’.” This is the activity of generating reports, updating status and supplying data to the other ITIL processes.
Verification and Audit	Periodically it is best practice to validate the Configuration Items by performing a physical inventory of the assets. ITIL defines this activity as “a series of reviews and audits that verify the physical existence of CIs and check that they are correctly recorded in the Configuration management system.”

6.10. Configuration Management Relationships with other Service Management Processes

Please refer to the prior section for the relationship of Configuration Management with Service Desk, Incident and Problem Management

Configuration Management with Change Management

Provide an accurate representation of the infrastructure to support other ITIL processes (2.6)

Verify that no Configuration Items are modified without going through the Change Management process

Configuration Management works together with Change Management and Release Management to deploy new and updated deliverables

Policies should be jointly developed by Configuration Management, Change Management and Release Management

Configuration Management is responsible for assessing the impact from proposed changes (2.6)

Configuration Management needs to document the history of changes for each Configuration Item

Configuration Management is responsible for verifying that the environment is compatible with the proposed change

New builds should be verified against the specifications and documented as an "as-built" configuration

Audits should be conducted by Configuration Management to insure that all changes have gone through the proper process

All of the ITIL processes should be entered into the Configuration Management Database as Configuration Items and subject to Change Management (2.6, 3.2)

It is best practice to implement Change and Configuration Management at the same time

Configuration Management is responsible for assessing the impact from proposed changes

Configuration Management needs to document the history of changes for each Configuration Item

The manager of the Configuration process can also manage the Change process

Effective Change Management relies on the Service Desk and Configuration, Problem and Release Management

Change Management depends upon the accuracy of the configuration data to ensure the full impact of making Changes is known (2.7)

Configuration Management with Release Management

Provide an accurate representation of the infrastructure to support other ITIL processes

Configuration Management works together with Change Management and Release Management to deploy new and updated deliverables

Policies should be jointly developed by Configuration Management, Change Management and Release Management

Release Management is responsible for populating the Definitive Software Library

Release Management must insure that all changes are reflected in the Configuration Management Database

Details about the build process and build environment should be recorded when a build is moved into the Definitive Software Library

All of the ITIL processes should be entered into the Configuration Management Database as Configuration Items and subject to Change Management (3.2)

Release Management is dependent upon the success of Configuration Management (2.6)

Release Management is to insure that the required software, hardware, documentation, etc are properly archived (DSL, DHS, etc) and that only authorized versions are installed

Release Management coordinates all Changes with Configuration Management and Change Management (2.8)

Release Management works with Configuration Management and Change Management to insure that the Configuration Management Database is accurately maintained (2.7)

Release Management should work to update the Configuration Management Database during the build cycle in anticipation of the release

When a Release is managed in phases, the Configuration Management Database should use a unique identifier to link the individual releases into one Release

The Definitive Software Library must be protected from unauthorized change

All additions to the Definitive Software Library must have corresponding entries in the Configuration Management Database

The Configuration Management Database should designate where the Release is to be applied

The Configuration Management Database should be updated with status to indicate receipt of the media, etc.

The detail description on how to build the Release should be a Configuration Item

The detailed description of the test environment should be a Configuration Item

The process for disposing of retired assets must be documented

Configuration Management should ensure that all pre-requisites have been met

Configuration Management should ensure that the Release has been successfully applied to all designated locations

Configuration Management and Release Management can work as one organization or can be combined with Change Management

Minimizing the number of variants will make Release Management easier

Ideally the users should be able to quickly determine the version of every component on their desktop from one screen

Configuration Management with Service Level Management

Provide an accurate representation of the infrastructure to support other ITIL processes (2.6)

Service Level Management can use the Configuration Management Database to house details about the services and link those services to Configuration Items

All of the ITIL processes should be entered into the Configuration Management Database as Configuration Items and subject to Change Management (3.2)

The Service Catalog can be stored as Configuration Items in the Configuration Management Database

It is best to link the Incident Records, Problem Records, Requests for Change, etc. to defined Services

Many organizations use their Service Desk linked to a comprehensive Configuration Management Database to monitor the Customer's perception of Availability

Changes to a Service Level Agreement must be reflected in the Service Catalog

Planning for a new Service should include the Service Desk, Change, Configuration and Release Management to verify resource and training requirements

Configuration Management with Financial Management

Configuration Management is responsible for verifying receipt of new Configuration Items

The Configuration Management Database describes the corporate assets

All of the ITIL processes should be entered into the Configuration Management Database as Configuration Items and subject to Change Management (3.2)

Financial Management needs to know the components utilized by each business unit especially when Charging is in place (2.6)

Financial Management works with Capacity, Configuration and Service Level Management to estimate the costs for the desired Capacity (2.2, SD 5.1.5)

Financial Management assists the other ITIL Processes in assessing the cost-effectiveness of decisions (SD 5.1.6)

Cost is an attribute of a Configuration Item (SD 5.1.5)

Service Desk and integrated Service Management processes are likely to be able o provide data to be input to cost calculation (SD 5.5.8)

The IT Accounting group must be trained on the fundamentals of Capacity, Change, Configuration and Service Level Management (SD 5.5.9)

Financial Management should conduct periodic audits to ensure that the interfaces into Configuration, Capacity and Service Level Management are working and provide the necessary workload information (SD 5.7.11)

Financial Management should work with Configuration Management to ensure that the Configuration Items are up-to-date and accurate (SD 5.7.11)

Configuration Management with Capacity Management

Provide an accurate representation of the infrastructure to support other ITIL processes

The Capacity Plan and other Service Management Plans should be identified in the Configuration Management Database

All of the ITIL processes should be entered into the Configuration Management Database as Configuration Items and subject to Change Management (3.2)

Capacity Management should work with Change, Configuration and Release Management to create and implement Requests for Change to ensure that appropriate Capacity is available (2.3)

The performance requirements for a Service should be recorded as Configuration Items (SD 6.2.1)

The capacity and configuration of Configuration Items should be accessible from both the Capacity Management Database and the Configuration Management Database (SD 6.2.1)

The Capacity Management and Configuration Management Databases can be merged into one database (SD 6.2.1)

Capacity Management monitoring is linked through the Configuration Management Database to Changes both to predict the probable impact and to asses the actual impact (SD 6.3.2)

Configuration Management with IT Service Continuity Management

Provide an accurate representation of the infrastructure to support other ITIL processes

The definition of the Configuration Items and the copies in the Definitive Software Library can be used during disaster recovery

All of the ITIL processes should be entered into the Configuration Management Database as Configuration Items and subject to Change Management (3.2)

Service Continuity and Availability Management rely on the Configuration Management Database to identify components to perform risk analysis and component failure impact analysis (2.6)

Configuration Management should verify that the restored configuration matches the prior configuration

A successful Service Continuity program is dependent upon rigorous Configuration and Change Management processes (SD 7.1.4)

Service Continuity is dependent upon Configuration Management for the definition of the core infrastructure (SD 7.1.8)

Recovery planning requires an in-depth understanding of the relationships between the components in the infrastructure (SD 7.3.3)

Configuration Management with Availability Management

All of the ITIL processes should be entered into the Configuration Management Database as Configuration Items and subject to Change Management (3.2)

Configuration and monitoring data on each component is used in Availability planning

The Configuration Management Database serves Availability Management through definitions of the configuration and by recording Incidents, Problems and Requests for Change (SD 8.8.2)

7. Change Management

7.2. Change Management Goal Statement

The goal of the Change management process is to ensure that standardized methods and procedures are used for efficient and prompt handling of all Changes, in order to minimize the impact of Change-related Incidents upon service quality, and consequently to improve the day-to-day operations of the organization.

7.3. Change Management Benefits

· "Better alignment of IT services to business requirements

· Increased visibility and communication of Changes to both business and service-support staff

· Improved risk assessment

· A reduced adverse impact of Changes on the quality of services and on SLAs

· Better assessment of the cost of proposed Changes before they are incurred

· Fewer Changes that have to be backed-out, along with an increased ability to do this more easily when necessary

· Improved Problem and Availability Management through the use of valuable management information relating to changes accumulated through the Change Management process

· Increased productivity of Users – through less disruption and, higher-quality services

· Increased productivity of key personnel through less need for diversion from planned duties to implement urgent Changes or back-out erroneous Changes

· Greater ability to absorb a large volume of Changes

· An enhanced business perception of IT through an improved quality of service and a professional approach" (SS 8.4.1)

7.4. Change Management Critical Success Factors

· CM requires an appropriate tool

· Implement CM with Configuration & Release

· Plan, test and train for CM process

· Management commitment

· Audit trails in the tool

· CAB requires authority

· Introduce regular Change Slots

7.5. Change Management Key Performance Indicators

· “The number of Changes implemented in the period, in total and by CI, configuration type, service, etc

· A breakdown of the reasons for Change (User requests, enhancements, business requirements, service call/Incident/Problem fixes, procedures/training improvement, etc)

· The number of Changes successful

· The number of Changes backed-out, together with the reasons (e.g. incorrect assessment, bad build)

· The number of Incidents traced to Changes (broken down into problem-severity levels) and the reasons (e.g. incorrect assessment, bad build)

· The number of RFCs (and any trends in origination)

· The number of implemented Changes reviewed, and the size of review backlogs (broken down over time)

· High incidences of RFCs/PRs (Problem Records) relating to one CI (these are worthy of special attention), giving the reasons (e.g. volatile User requirement, fragile component, bad build)

· Figures from previous periods (last period, last year) for comparison

· The number of RFCs rejected

· The proportion of implemented Changes that are not successful (in total and broken down by CI)

· Change backlogs, broken down by CI and by stage in the Change Management process" (SS 8.7)

7.6. Change Management Possible Implementation Problems

· The process is perceived to be too bureaucratic or rigorous

· Cultural difficulties in getting staff, Customers and Users to adopt a single Change Management system

· The process is routinely circumvented

· Change Management implemented without Configuration Management

7.7. Change Management Tools

"For all but the smallest of organizations, a Configuration management-based tool, capable of storing all relevant configuration items (CIs), and the important relationships between them, should be used. Such a tool should have the following facilities:

· Requests for Change (RFC) and Problem Records (PR) stored upon the same database, in an easily accessible format

· The ability to identify the relationship between RFCs, PRs and CIs

· The capability to link RFCs to projects

· The means to identify easily the other CIs that will be impacted whenever a Change to any specific CI is proposed

· Automatic production of requests for impact and resources assessment to the ‘owners’ of the impacted CIs

· The ability for all authorized personnel to submit RFCs from their own terminal or location

· The ability to ‘progress’ requests through the appropriate stages of authorization and implementation and to maintain clear records of this progress

· The ability to allow Change Management staff, Change builders, testers, etc to add text to Change records

· Clear definition of back-out procedures should a Change cause problems

· Automatic warnings of any RFCs that exceed pre-specified time periods during any stage

· Automatic prompting to carry out reviews of implemented Changes

· Automatic generation of management and trend information relating to Changes

· The ability to build Changes

· Automatic production of Forward Schedule of Changes (FSC)

· A process/workflow feature" (SS 8.8)

7.8. Change Management Inputs and Outputs

Inputs:

· Requests for Change

· Configuration Management DataBase

· Forward Schedule of Changes

Outputs:

· Updated Forward Schedule of Changes

· Updated Requests for Change

· Change Advisory Board (CAB) minutes and actions

· Change Management Reports

Activities:

· Filtering Changes

· Managing Changes and the Change Process

· Chairing the CAB and the Change Advisory Board/Emergency Committee

· Reviewing and closing Requests for Change

· Management reporting

7.8.1. Change Management Inputs and Outputs Diagram

7.8.2. Change Management Inputs and Outputs Description

Interface	Description
Incident, Problem, Known Error and Request for Change linked to Configuration Items	The Configuration Management Database (CMDB) is the central repository for ITIL information. A Change is initiated with a Request for Change (RFC). That RFC should be linked to the relevant data in the CMDB including a history of Incidents and Problems. The Known Errors that this RFC is to resolve and indirect linkages to all of the Configuration Items that will be impacted by this Change.
Change Management Process and Policy	The details underlying this Change Management process must be documented in predefined processes and policies. The Change Manager uses those policies when assigning the Change to a Category, assigning a Priority and assessing the RFC. Other players in the Change Management process include the roles of Change Initiator, Change Builder, Independent Tester, Change Implementer, Change Advisory Board and Change Advisory Board / Emergency Committee. All of those roles and their responsibilities must be defined in the Change Management policies.
Build, implementation and back-out templates, policies and plans	Few Changes are truly new. Thus, those responsible for building the product, defining the implementation, testing and back out plans should have standard templates to work from. Additionally, when this work overlaps with Release Management and Configuration Management then policies for those processes must also be referenced.
Results from Testing	ITIL recommends assigning the testing of the Change, the implementation plan and the back out plan to an Independent Tester. That tester will report the results of those tests to the Change Builder and the Change Manager.
Results from Implementation	The results from implementing the Change will be reported to the Change Manager along with any secondary Incidents or Problems generated by the Change process.
User evaluation of results	An RFC is only successful if the user is satisfied that the Problem(s) addressed by this RFC have been successfully resolved.
Change Management	The flow through the Change Management process is illustrated in the diagrams immediately below this section.
Request for Change status updates, assessment and schedule	The Change Manager is responsible for coordinating the Change and providing updates to the Configuration Manager so that the RFC can be updated.
Forward Scheduled of Change, and Planned Schedule of Availability	This output is from the Configuration Management process and is included here only to fill in an obvious gap.
Communication with Service Desk, Users, Customers and other ITIL processes	This output is from the Configuration Management process and is included here only to fill in an obvious gap.
Change Review assessment, process adjustments and process metrics	Periodic Change Reviews will be scheduled. The Change Review can either be done by the Change Manager or by the Change Advisory Board (CAB). The purpose for the Change Review is to assess the success of the Change and evaluate the process.

7.9. Change Management Process Flow

The Change Management Process Flow has been separated into three. The first diagram illustrated the Authorization Flow. The second diagram shows the Implementation Flow. The first and second diagrams are really one process, separated into two diagrams to simplify the presentation. The third diagram is an alternate path that should be followed when the Change requires urgent processing.

7.9.1. Change Management Authorization Flow Diagram

7.9.2. Change Management Authorization Flow Description

Aspect	Description
Start	The Change Management process formally begins with the creation of a Request for Change (RFC). This process can begin with a form transmitted through email. The person who creates the RFC is called the Change Initiator.
Change Manager filters requests	The Change Manager assesses the RFC for completeness.
Configuration Manager logs the RFC	The Configuration Manager is responsible for administration of the RFC. All RFCs will be stored in the Configuration Management Database (CMDB). After the Change Manager filters the RFC, the Configuration Manager will enter the RFC into the CMDB.
Accepted	The Change Manager can either accept the RFC for processing, or reject it and return it to the Change Initiator for correction.
Change Manager assigned initial priority	The Change Manager will review the RFC and assign an initial priority.
Configuration Manager updates log	The Configuration Manager will shadow the Change Manager and record the priority in the CMDB.
Urgent ?	If the RFC is Urgently needed, the Change Manager will divert the RFC from the normal flow over to the Urgency Flow.
See Urgency Flow	The Urgency Flow is documented later in this document.
Change Manager decides on category	The Change Manager will continue the evaluation of this RFC and assign it to the appropriate category based upon the scope of the Change.
Configuration Manager reports on impact

3.1. Service Desk Synopsis

3.2. Service Desk Goal Statement

3.3. Service Desk Benefits

3.4. Service Desk Critical Success Factors

3.5. Service Desk Key Performance Indicators

3.6. Service Desk Possible Implementation Problems

3.7. Service Desk Tools

3.8. Service Desk Inputs and Outputs

3.8.1. Service Desk Inputs and Outputs Diagram

3.8.2. Service Desk Inputs and Outputs Description

3.9. Service Desk as a Function

3.10. Service Desk Relationships with other Service Management Processes

4.1. Incident Management Synopsis

4.2. Incident Management Goal Statement

4.3. Incident Management Benefits

4.4. Incident Management Critical Success Factors

4.5. Incident Management Key Performance Indicators

4.6. Incident Management Possible Implementation Problems

4.7. Incident Management Tools

4.8. Incident Management Inputs and Outputs

4.8.1. Incident Management Inputs and Outputs Diagram

4.8.2. Incident Management Inputs and Outputs Description

4.9. Incident Management Process Flow

4.9.1. Incident Management Process Flow Diagram

4.9.2. Incident Management Process Flow Description

4.10. Incident Management Line Escalation

4.10.1. Incident Management Line Escalation Diagram

4.10.2. Incident Management Line Escalation Description

4.11. Incident Management Relationships with other Service Management Processes

5.1. Problem Management Synopsis

5.2. Problem Management Goal Statement

5.3. Problem Management Benefits

5.4. Problem Management Critical Success Factors

5.5. Problem Management Key Performance Indicators

5.6. Problem Management Possible Implementation Problems

5.7. Problem Management Tools

5.8. Problem Management Inputs and Outputs

5.8.1. Problem Management Inputs and Outputs Diagram

5.8.2. Problem Management Inputs and Outputs Description

5.9. Problem Management Problem Control Process Flow

5.9.1. Problem Management Problem Control Process Flow Diagram

5.9.2. Problem Management Problem Control Process Flow Description

5.10. Problem Management Error Control Process Flow

5.10.1. Problem Management Error Control Process Flow Diagram

5.10.2. Problem Management Error Control Process Flow Description

5.11. Problem Management Relationships with other Service Management Processes

6.1. Configuration Management Synopsis

6.2. Configuration Management Goal Statement

6.3. Configuration Management Benefits

6.4. Configuration Management Critical Success Factors

6.5. Configuration Management Key Performance Indicators

6.6. Configuration Management Possible Implementation Problems

6.7. Configuration Management Tools

6.8. Configuration Management Inputs and Outputs

6.8.1. Configuration Management Inputs and Outputs for the Incident Life-Cycle

6.8.2. Configuration Management Inputs and Outputs for the Incident Life-Cycle

6.8.3. Configuration Management Inputs and Outputs for Change Management

6.8.4. Configuration Management Inputs and Outputs for Change Management

6.9. Configuration Management Process Flow

6.9.1. Configuration Management Process Flow Diagram

6.9.2. Configuration Management Process Flow Description

6.10. Configuration Management Relationships with other Service Management Processes

7.1. Change Management Synopsis

7.2. Change Management Goal Statement

7.3. Change Management Benefits

7.4. Change Management Critical Success Factors

7.5. Change Management Key Performance Indicators

7.6. Change Management Possible Implementation Problems

7.7. Change Management Tools

7.8. Change Management Inputs and Outputs

7.8.1. Change Management Inputs and Outputs Diagram

7.8.2. Change Management Inputs and Outputs Description

7.9. Change Management Process Flow

7.9.1. Change Management Authorization Flow Diagram

7.9.2. Change Management Authorization Flow Description