General OverviewITIL Service Support Processes (Operational Processes):
• Configuration Management
• Incident Management
• Problem Management
• Change Management
• Release Management
ITIL Service Delivery Processes (Strategic Processes):
• Availability Management
• IT Services Continuity Management
• Capacity Management
• Financial Management
• Service Level Management
ITIL Functions (Non-Process):
• Service Desk
Configuration Management Summary: Configuration Management provides information on the IT infrastructure
to other ITIL processes and for decision support by IT Management. Configuration
Management enables control of the infrastructure by monitoring and maintaining
information on:
• All the resources needed to deliver services
• Configuration item (CI) status and history
• Configuration item relationships
Specific Configuration Management tasks:
• Identification and naming
• Management information
• Verification
• Control
• Status Accounting
Tip: A configuration Item (CI) is different than an Asset, which is a component of
a business process such as human resources (people), computer systems,
stationary/paper, telephones, etc.
Configuration Management Database (CMDB): A database, which contains all
relevant details of each Configuration Item (CI) and details of important
relationships between CIs.
A Configuration Item (CI):
• Is needed to deliver a service
• Is uniquely identifiable
• Is subject to change
• Can be managed
A Configuration Item (CI) has:
• a category
• one or more relationships
• one or more attributes
• a specific status at any given point in time
Configuration Item (CI) Variant: A Configuration Item (CI) that has the same
basic functionality as another Configuration Item (CI) but is different in some
small way (ex: has more memory)
Configuration Baseline: A snapshot of the state of a Configuration Item and any
component or related Configuration Items, frozen in time for a particular purpose
(such as the ability to return a service to a trusted state if a change goes wrong)
Configuration Management is critical in supporting and furthering the maturity of
all other ITIL service support and delivery processes.
Service Desk The Service Desk concentrates on incident lifecycle management and performs the
following primary functions:
• Customer Interface
• Business Support
• Incident Control
• Management Information
Tip: Remember that the Service Desk is not a process, but is an IT function.
The Service Desk is the primary point of contact for all internal and/or external
customers and handles:
• Calls
• Questions
• Requests
• Complaints
• Remarks
The goal of the Service Desk is to:
1. To restore the service as quickly as possible
2. To manage the incident life-cycle (coordinating resolution)
3. To support business activities
4. To generate reports, to communicate and to promote
The different Types of Service Desks include:
• Call Centers: Handles large volumes of general support calls generally via
telephone.
• Help Desks: Manages, coordinates, and resolves incidents as quickly as
possible.
• Service Desks: Handles incidents, problems, questions and requests for
customers submitted through one or more interface points.
Tip: for incidents (an unexpected disruption to agreed service), the Service Desk
sets a priority based on business impact and urgency. Correctly assessing priorities
enables optimal deployment of resources in the best interest of the customer.
Incident Management Incident: 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.
The goal of Incident Management is to restore normal service as quickly as possible,
with the additional objectives of:
• Minimizing adverse impact of incidents on business operations
• Ensuring that the best possible levels of service quality and availability are
maintained according to established Service Level Agreements (SLAs).
Work-Around: Method of avoiding an incident or problem.
Service Request: Requests not related to incidents or failures in the IT
environment.
Problem: The unknown root cause of one or more incidents.
Known Error: A condition that exists after successfully diagnosing the root cause of
a problem; one or more specific Configuration Items (CIs) are determined to be at
fault.
Category: Classification of a group of incidents (e.g. Application, Hardware,
Network, etc.).
Vertical Escalation: Incident(s) escalate up the management chain.
Horizontal Escalation or Referral: Incident(s) escalate across different knowledge
groups or IT domains.
Primary activities in the Incident Management Life-Cycle:
• Acceptance / logging
• Registering events
• Consult the CMDB
• Classification
• Resolution
• Closure
Incident reporting includes:
• Daily reviews of incident and problem status against service levels
• Weekly management reviews
• Monthly management reviews
• Proactive service reports
Problem Management The goal of Incident Management is to stabilize IT services through the following
activities:
• Determine the root causes of incidents
• Remove root cause points of failure
• Prevent incidents and problems proactively
• Minimize the consequences of incidents
• Prevent recurrence of incidents related to errors
• Improve the productive use of resources
Specific Problem Management tasks include:
• Facilitate Problem Control
• Implementing Error Control
• Proactive Problem Prevention
• Identifying Problem Trends
• Providing Management Information
• Performing Post Implementation Reviews (PIR)
Tip: The primary difference from the Incident Management process is Problem
Management’s proactive approach towards eliminating inefficiencies from the IT
environment.
Primary process inputs:
• Incident details
• Configuration details
• Defined workarounds
Primary process outputs:
• Known Errors (KE)
• Requests for Change (RFC)
• Updated Problem records including:
o Workarounds
o Solutions (Fixes)
• Management information matching
The Problem Control sub-process includes:
• Identification
• Classification
• Assign Resources
• Investigation and Diagnosis
• Establish Known Error
The Error Control sub-process includes:
• Error Identification and Recording
• Error Assessment
• Recording Error / Resolution (Send out RfC)
• Error Closure
Known Error: An Incident or Problem for which the root cause is known and a
temporary workaround or permanent alternative has been identified.
Proactive Problem Management involves:
• Trend Analysis
• Targeting Support Action
• Providing Information to the Organization
Change Management The goal of Change Management is to implement approved changes efficiently,
cost-effectively and with minimal risk to existing and new IT infrastructure
components.
Tip: Only approved changes should be performed in order to reduce overall risk
to the IT environment.
Specific tasks in the Change Management process include:
• Filtering Changes
• Managing Change Process
• Managing Changes
• Chairing CAB and CAB/EC
• Review and Closure
• Management Information
The process inputs include:
• Requests for Change (RfC)
• CMDB / CI data
• Forward Schedule of Changes (FSC)
The process outputs include:
• Forward Schedule of Changes (FSC)
• Requests for Change (RfC)
• CAB minutes and action items
• Change Management reports
The impact categorization of changes may include:
Category 1
• Little impact on current services
• Change Manager may authorizes Requests for Change (RfC)
Category 2
• Clear impact on services
• RfC must be reviewed by the Change Advisory Board (CAB)
• Change Manager requests advice prior to authorization and planning
Category 3
• Significant impact on the service to the business
• Considerable resources required for change
• RfC is reviewed and approved by the Change Advisory Board (CAB)
Change Management priority settings may include:
Urgent: Change is required now to avoid severe adverse business impact
High: Change needed as soon as possible; may be potentially damaging to
business service provision
Medium: Scheduled changes intended to fix minor errors or issues with
functionality
Low: Change leads to minor improvements
Change: The addition, modification, or removal of approved and/or supported
hardware, software, applications and other environment components, systems, and
related documentation.
Request for Change (RfC): Formal request and recording of details surrounding the
intended change to the IT environment, impacting one or more Configuration Items
(CIs).
Forward Schedule of Changes (FSC): Schedule that contains details of and timing
for all approved changes scheduled for implementation.
The primary Change Management process activities include:
1. Request for Change (RfC)
2. Registration & Classification
3. Monitoring & Planning
4. Approval
5. Building & Testing
6. Authorizing Implementation
7. Implementation
8. Evaluation
Tip: Additional Change Management considerations:
• Change backout plan(s) should always be in place prior to implementation
• All changes should be reviewed prior to implementation
Release Management The primary goal of Release Management is safeguard all hardware, software and
related items within the IT environment by ensuring the deployment of authorized
and tested versions of hardware and software.
Specific Release Management tasks include:
• Defining release policies
• Control of the Definitive Software Library (DSL)
• Control of the Definitive Hardware Storage (DHS)
• Distribution of software and associated Configuration Items (CIs)
• Execution of software audits
• Managing software releases
• Managing software builds
Tip: Releases are performed in conjunction with and under the control of the
Change Management process.
Definitive Software Library (DSL): Reliable versions of software in a single logical
location.
Tip: Software need not be centrally located in a DSL and may be physically
stored at different locations.
The Release Management policy should include:
• Release Unit
• Full / Package / Delta Releases
• Numbering
• Frequency
• Emergency Change
Release Management version control should include:
• Development
• Testing
• Production Release (Go-Live)
• Archiving
The primary activities within the Release Management process should include:
• Software Control & Distribution (Operational Release)
• Change Management (Release Control)
• Configuration Management (Release Control & Administration)
Availability Management The primary goal of Availability Management is to predict, plan for and manage the
availability of services by ensuring that:
• All services are underpinned by sufficient, reliable and properly maintained
Configuration Items (CIs)
• Appropriate contractual agreements with third party suppliers are in place (if
applicable)
• Changes are proposed to proactively prevent future loss of service availability
Tip: Availability Management is critical to ensuring IT organizations deliver the
levels of availability agreed upon with customers through Service Level
Agreements (SLAs).
The primary attributes of Availability Management include:
• Reliability
• Maintainability
• Resilience (Redundancy)
• Serviceability
Tip: Availability Information may be stored in an Availability Database (ADB).
Availability information is used to create Availability plan(s), dictated by the
Service Level Management process.
Mean Time to Repair (MTTR): Downtime; period of time that elapses between the
detection of an incident and actual resolution.
MTTR Lifecycle: Incident, Detection, Diagnosis, Repair, Recovery, Restoration.
Mean Time Between Failures (MTBF): Uptime; time period that elapses between
restoration of an incident and a new recurrence of the same incident.
Mean Time Between System Incidents (MTBSI): Time period that elapses
between two incidents.
IT Service Continuity Management The primary goal of IT Service Continuity Management (ITSCM) is to support the
Business Continuity Plan (BCP) process by ensuring the IT environment can be
recovered within required timeframes.
Tip: An IT Service Continuity Plan cannot be created without the existence of a
valid Business Continuity Plan (BCP).
An ITSCM plan is important in order to:
• Reduce the impact of IT infrastructure failure
• Decrease business risk and vulnerability
• Increase customer and end-user confidence
• Fulfillment of legal and/or regulatory requirements
A Business Impact Analysis (BIA) includes the following components:
Risk Analysis
• Determining the value of assets
• Determining threats
• Determining vulnerabilities
Risk Management
• Outlining countermeasures
• Planning for potential disasters
• Managing a disaster
Infrastructure options specific to the ITSCM process include:
1. Do Nothing
2. Manual Workarounds
3. Reciprocal Arrangements
4. Gradual recovery (“Cold Standby”)
5. Intermediate Recovery (“Warm Standby”)
6. Immediate Recovery (“Hot Standby”)
An effective IT Service Continuity Management (ITSCM) plan should include the
following sections:
• IT Administration
• Infrastructure Overview
• Operating Procedures
• IT Personnel
• IT Security
• Contingency Site(s)
Testing and reviewing the ITSCM plan should include the following activities:
• Initial Review (immediate / initial sign-off)
• Continuous Review (e.g. every 6 to 12 months)
• Post-Implementation (e.g. after an actual recovery has occurred)
• Documentation Reviews (and continuous updates)
• Adherence to all Change Management requirements
Capacity Management The primary goal of Capacity Management is to determine the appropriate and
cost-justifiable capacity of IT resources to ensure that agreed-upon service levels
are achieved within the required timeframes.
Specific objectives are achieved through:
• Demand Management (Business Capacity Management)
• Workload Management (Service Capacity Management)
• Resource Management (Resource Capacity Management)
• Performance Management of:
o Internal and external financial data
o Usage data
Capacity Data Base (CDB): Contains all measurements and associated metrics
used to create a Capacity Management Plan; populated with Performance
Management data used for decision support related to:
• Customer capacity requirements / demands
• Workload management
• Performance management
• Capacity planning
• Defining capacity thresholds
• Monitoring capacity
Application Sizing: Estimates resource requirements in support of a proposed
application change, ensuring all required service levels are met.
• Capacity Management Modeling includes:
• Trend Analysis
• Analytical Modeling
• Simulation Modeling
• Baseline Models
IT Financial Management The primary goal of IT Financial Management is to provide information and
control over the cost of delivering IT services delivered to business customers.
Specific cost units include:
• Equipment Cost Units (ECU)
• Organization Cost Units (OCU)
• Transfer Cost Units (TCU)
• Accommodation Cost Units (ACU)
• Software Cost Units (SCU)
Transfer Costs: Costs incurred by IT, acting as an agent for the customer, but
not allocated against the IT budget.
IT Financial Management cost types include:
• Fixed: Costs unaffected by the level of usage
• Variable: Varying costs according to level of usage
• Direct: Costs associated with the usage of a specific service
• Indirect (Overhead): Costs specific to more than one specific service
• Capital: Costs that are not diminished by usage
• Revenue (Running): Costs that diminish with usage
Specific Financial Management pricing options may include:
• No Charging: IT performs service support and delivery as a support
center
• Cost Recovery: IT performs as a service center
• Notional Charging (Cost Center): IT performs services as a cost center
• Actual Charging: Specific charges for IT products and services charged
by actual usage of these services
• Cost Price Plus (Market Pricing): IT provides services for / as a profit
center
Soft Charging: Used by Support and Cost centers to facilitate service provision
without actual exchange of currency.
Hard Costing: Money for IT services transferred between [bank] accounts
and/or departments
Tip: Profit centers focus on the value of the IT service to the customer
Three primary sub-processes of IT Financial Management include:
Budgeting: Predicting and controlling spending within through periodic
negotiation cycles to set budgets and regular, consistent monitoring of
budgets.
IT Accounting: Enabling the IT organization to fully account for expenditures
by breaking down costs by specific customer, service and/or activity.
Charging: Billing customers for actual services provided through established,
proven IT accounting methods and ongoing analysis, billing, and reporting
procedures.
Tip: Mature IT Financial Management helps streamline IT service by shaping
customer demand for services that have specific, tiered levels of service.
Service Level Management The primary goal of Service Level Management is to obtain a balance between
the demands for and supply of specific IT services through ongoing facilitation
and negotiation of business requirements with full knowledge of available IT
services and capabilities.
Specific Service Level Management (SLM) objectives may include:
• Establishing sound Business Relationship Management (BRM) between
service providers and customers
• Improving communication of IT services to the business and/or internal
customers
• Increasing the flexibility and responsiveness of IT service provision
• Balancing customer demands with the ongoing cost of IT service provision
• Measuring and reporting accurate service levels
• Implementing continuous improvement of IT service quality
• Ensuring objective conflict resolution
Specific Service Level Management (SLM) tasks should include:
• Creation of an IT Service Catalog
• Obtaining specific customer Service Level Requirements (SLRs)
• Establishing Service Level Agreements (SLAs)
• Establishing Operational Level Agreements (OLAs)
• Reviewing, creating and refining Underpinning Contracts (UCs)
• Implementing specific Service Quality Plans
• Monitoring, reviewing and reporting on IT service levels
• Establishing IT Service Improvement Programs (SIPs)
• Engaging the business through effective relationship management (BRM)
Minimum Requirements for a Service Agreement (SLA/OLA/UC):
• Timing / Period of Service Provision
• Service Description / Narrative
• Throughput (Inputs / Outputs / Service Levels)
• Service Availability
• Service [Desk] Response Times
• Sign-Off / Sponsorship (Physical Signatures)
Other Service Agreement coverage areas may include:
• Contingency arrangements
• Review procedures
• Change procedures
• Additional Support services
• Customer roles & responsibilities
• Administration requirements
• Maintenance requirements
• Amendments
Tip: Service Level Agreements must be monitored and reviewed regularly to
ensure IT products and services are being delivered optimally against all
service level requirements
