Table of Contents

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.

General Overview Configuration Management Service Desk Incident Management Problem Management Change Management Release Management Availability Management IT Service Continuity Management Capacity Management IT Financial Management Service Level Management

--------------------------------------------------------------------------------------------------------------------------------------------------------------1. General Overview ITIL Service Support Processes (Operational Processes): y y y y y Configuration Management Incident Management Problem Management Change Management Release Management ITIL Service Delivery Processes (Strategic Processes): y y y y y Availability Management IT Services Continuity Management Capacity Management Financial Management Service Level Management ITIL Functions (Non-Process): y Service Desk 2. 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: y y y All the resources needed to deliver services Configuration item (CI) status and history Configuration item relationships Specific Configuration Management tasks:

y y y y y

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):

y y y y

Is needed to deliver a service Is uniquely identifiable Is subject to change Can be managed A Configuration Item (CI) has:

y y y y

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. 3. Service Desk The Service Desk concentrates on incident lifecycle management and performs the following primary functions: y y y y 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: y Calls

y y y y

Questions Requests Complaints Remarks The goal of the Service Desk is to:
1. 2. 3. 4.

To To To To

restore the service as quickly as possible manage the incident life-cycle (coordinating resolution) support business activities generate reports, to communicate and to promote

The different Types of Service Desks include: y y y 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. 4. 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: y y 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: y y y Acceptance / logging Registering events Consult the CMDB

y y y

Classification Resolution Closure Incident reporting includes:

y y y y

Daily reviews of incident and problem status against service levels Weekly management reviews Monthly management reviews Proactive service reports 5. 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 sproactive approach towards eliminating inefficiencies from the IT environment. Primary process inputs:

y y y y y y

y y y y y y

y y y

Incident details Configuration details Defined workarounds Primary process outputs:

y y y y

Known Errors (KE) Requests for Change (RFC) Management information matching Updated Problem records including: yWorkarounds ySolutions (Fixes) The Problem Control sub-process includes:

y y y

Identification Classification Assign Resources

y y

Investigation and Diagnosis Establish Known Error The Error Control sub-process includes:

y y y y

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:

y y y

Trend Analysis Targeting Support Action Providing Information to the Organization 6. 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:

y y y y y y

Filtering Changes Managing Change Process Managing Changes Chairing CAB and CAB/EC Review and Closure Management Information The process inputs include:

y y y

Requests for Change (RfC) CMDB / CI data Forward Schedule of Changes (FSC) The process outputs include:

y y y y

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

y y

Little impact on current services Change Manager may authorizes Requests for Change (RfC) Category 2

y y y

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

y y y

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. 2. 3. 4. 5. 6. 7. 8.

Request for Change (RfC) Registration & Classification Monitoring & Planning Approval Building & Testing Authorizing Implementation Implementation Evaluation

Tip: Additional Change Management considerations: y y Change backout plan(s) should always be in place prior to implementation All changes should be reviewed prior to implementation 7. 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: y y y y y y y 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: y y y y y Release Unit Full / Package / Delta Releases Numbering Frequency Emergency Change Release Management version control should include: y y y y Development Testing Production Release (Go-Live) Archiving The primary activities within the Release Management process should include: y y y Software Control & Distribution (Operational Release) Change Management (Release Control) Configuration Management (Release Control & Administration) 8. Availability Management The primary goal of Availability Management is to predict, plan for and manage the availability of services by ensuring that: y y y 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:

y y y y

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. 9. 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:

y y y y

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

y y y

Determining the value of assets Determining threats Determining vulnerabilities Risk Management

y y y

Outlining countermeasures Planning for potential disasters Managing a disaster Infrastructure options specific to the ITSCM process include:
1. 2. 3. 4. 5.

Do Nothing Manual Workarounds Reciprocal Arrangements Gradual recovery ( Cold Standby ) Intermediate Recovery ( Warm Standby )

6.

Immediate Recovery ( Hot Standby )

An effective IT Service Continuity Management (ITSCM) plan should include the following sections: y y y y y y IT Administration Infrastructure Overview Operating Procedures IT Personnel IT Security Contingency Site(s) Testing and reviewing the ITSCM plan should include the following activities: y y y y y 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 10. 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. pecific objectives are achieved through: y y y y Demand Management (Business Capacity Management) Workload Management (Service Capacity Management) Resource Management (Resource Capacity Management) Performance Management of: yInternal and external financial data yUsage 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: y y y y y y 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. y y y y y Capacity Management Modeling includes: Trend Analysis Analytical Modeling Simulation Modeling Baseline Models

11. 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: y y y y y 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: y y y y y y 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: y y y y y 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: y y y 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.

12. 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: y y y y y y y 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: y y y y y y y y y 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): y y y y y y 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: y y y y y y y y 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.