INFORMATION TECHNOLOGY INFRASTRUCTURE LIBRARY (ITIL) Foundations Version 3

Presented by Hippolytus NJI

1

Introduction
ITIL is intentionally composed of a common sense approach to service management do what works. And what works is adapting a common framework of practices that unite all areas of IT service provision toward a single aim delivering value to the business. The following list defines the key characteristics of ITIL that contribute to its global success:

Non proprietary Non-prescriptive Best practices Good practices

ITIL Background
Set of books that describes best practices and how processes are optimized Explains how processes are formalized within and organization Provides a framework for terminology and objectives Each publication addresses a part of the framework Seven recent publications upgraded to v3 Originally a bunch (10) books with 40 other supplemental books.
3

Outline of topics
Service support
Incident management Problem management Configuration management Change management Release Management Release categories

Service delivery
Service level management Capacity management IT service continuity management Availability management Financial management for IT services

ITIL v3 Core Publications

ITIL Service Strategy Publication

Looks at alignment of business and IT strategy Making sure service life-cycle focuses on customer results Relates strategy to associated process elements Put in place solid business goals, requirements and service management principles

ITIL Service Design Publication

Provides guidance on production and maintenance of IT policies Design to meet current and future business needs Also addresses architectures and documentation for design of targeted, innovative IT solutions/processes

ITIL Service Transition Publication

Provides guidance and activity assessment for service transition in operational business environment Broad role of change management, release, and deployment administration Considers risks, benefits, delivery mechanisms, and support of ongoing operational services
8

ITIL Service Operation Publication

Includes operational aspects of IT service management lifecycle Also includes service support and ICT infrastructure management from ITIL v2 Covers incident, event, request, problem, and identity management Addresses team and function aspects of service management
9

ITIL Continual Service Improvement Publication

How to deliver consistent, repeatable process activities Emphasizes importance of continual improvements Focuses on process elements of identifying and introducing service management improvements Also deals with service retirement issues.
10

Benefits
Service agreements are more customer-focused Quality, reliability, availability, cost are better managed Communication with IT organizations improved Develops more efficient, lucid structures focused Better control of infrastructure and services Framework for IT out-sourcing Changes culture towards services and quality management Frame of reference for standardization

11

Pitfalls
May involve drastic changes in business culture long ramp-up Risk of over-engineering and bureaucratic overhead Baseline data is critical to analyze result/improvements Commitment is needed from all levels of business Cant isolate tasks to single team, committee, or department Investments and resources must be available and cost can inflate quickly Must understand ITIL is a framework of best practices and not a document like magna carta / Cameroon Constitution

12

IT Service Management (ITSM)

Overview Service management defined Services and quality Organization and policy Process management

13

IT Service Management (ITSM)

Definitions (some):
Customer: Someone who buys goods or Services. The Customer of an IT Service Provider is the person or group who defines and agrees the Service Level Targets. The term Customers is also sometimes informally used to mean Users, for example "this is a Customer focused Organization". Service: A means of delivering value to Customers by facilitating Outcomes Service Level Targets: A commitment that is documented in a Service Level Agreement. Service Level Targets are based on Service Level Requirements, and are needed to ensure that the IT Service design is Fit for Purpose. Service Level Targets should be SMART, and are usually based on KPIs.
14

IT Service Management (ITSM) (Definitions continued)

Service asset: any capability or resource that can be provided by a service provider Service management : Set of specialized organizational capabilities for providing value to customers

Service Management Lifecycle : An approach to IT Service

Management that emphasizes the importance of coordination and Control across the various Functions, Processes, and Systems necessary to manage the full Lifecycle of IT Services. The Service Management Lifecycle approach considers the Strategy, Design, Transition, Operation and Continuous Improvement of IT Services.

15

IT Service Management (ITSM)

(Continued)
Service Management Lifecycle An approach to IT Service Management that emphasizes the importance of coordination and Control across the various Functions, Processes, and Systems necessary to manage the full Lifecycle of IT Services. The Service Management Lifecycle approach considers the Strategy, Design, Transition, Operation and Continuous Improvement of IT Services.

16

Demings quality cycle

1. 2. 3. 4. 5.

Design/revise the business process components to improve results Put the plan in place and measure performance Asses measurements and report results to decision makers Decide upon the change we need to improve the process and then we act The process starts all over again.
17

 Vision, Objectives and Policies

Mission and Objectives Mission statement Short, clear written description of the objectives of the organization and the values that it believes in

Vision

Policy

Planning Tasks and Actions

Time Quantity Quality Cost Revenue

Implementation

BSC, KSF, KPI 18

Good Corporate objectives

S Specific M Measurable A Appropriate R Realistic T - Time bound

19

Process Management
a.k.a. Manage to Process
A Process is a structured set of Activities designed to accomplish a specific Objective. A Process takes one or more defined inputs and turns them into defined outputs. A Process may include any of the Roles, responsibilities, tools and management Controls required to reliably deliver the outputs. A Process may define Policies, Standards, Guidelines, Activities, and Work Instructions if they are needed. Three questions: Why, Where and How Measurement and Control (metrics) Process relationships Policy, Stds, GL, Vision/Mission/Objectives Measure, Control, Asses
Input (Services)

Output (Impl) Actions

20

Process definitions describe actions, dependencies and sequence. Processes have the following characteristics: They are measurable and are performance driven. Managers want to measure cost, quality and other variables while practitioners are concerned with duration and productivity. They have specific results. The reason a process exists is to deliver a specific result. This result must be individually identifiable and countable. They deliver to customers. Every process delivers its primary results to a customer or stakeholder. They may be internal or external to the organization but the process must meet their expectations. They respond to a specific event. While a process may be ongoing or iterative, it should be traceable to a specific trigger.
21

Service Desk Support

Outline
SD vs HD and Call Centre Functions and activities of SD Types of SD rollout SD personnel Critical Success Factors (CSF)

Front desk for the IT departments. Central point of contact between the IT and the users
22

Service Desk Support

SD vs HD & CC HD historically involved in incident response Not a single point of contact for users CC usually handles large call volumes SD has large responsibility than telesales or Incident Support SD is the consolidated, comprehensive, single interface between users and IT
23

Service Desk Support

IM
CM SLM

SD

RM CM

24

Service Desk Support

Functions and activities of SD
Enhance user access to IT service 1st line liaison Faster response | turnaround to requests while recording and tracking incidents and complaints Improve communication and teamwork by informing customers about status, progress, assessment, changes (S-term & L-term) Escalates procedures based on SLAs Managing requests, tickets, change lifecycles Coordinate with third party solution providers All in a bid to boost productivity
25

Service Desk Support

Types of SD rollouts
Centralized SD Local SD Virtual SD

26

Service Desk Support

Centralized SD
Centralized responsibility for accepting and recording service calls, routing, monitoring and escalating Unified business operations support Uses a common incident reporting| recording system Bridges physical aspect with operational aspect of the organization via direct contact Rapid responses and close proximity are objectives Production And Operation

User site

IT SD

Biz Ops SD

27

Service Desk Support

Local SD (Distributed) Model

Centralized SD

Local SD A (Distributed.)

Local SD B (Distributed)

Local SD C (Distributed)

Dist. SDs are suitable b/w sites, floors, bldgs, for a closer attention. The goal is to get the SD closer to the users
28

Service Desk Support

Virtual SD
Modern specialized version of LSD Several LSDs virtualized as single telecom unit Provides global, round-the-clock (follow the sun) Support Difficult to provide on-site support Phone #s are often re-routed as network centers transition according to the business hour Excellent solution for large multinational organization
SD personnel Call centre personnel Unskilled / call recording Skilled SD Expert SD
29

Service Desk Support

SD Personnel Attributes
Articulate, organized, and customer-focused Trained in patient inter-personal skills Must understand business objectives and that user problem affect business there is no SD w/without user / customer Might need bilingual skills Must be willing to find the answers

30

Service Desk Support

Critical factors for SD success
Know the business needs and goals, and how they are aligned with the customer/user requirements Invest in training in all involved areas Clearly define SD objectives and deliverables; is SD just a front-end routing, is it a Dist., decentralized, etc. SLAs must be practiced, with broad by-in, and reviewed | assessed regularly. Benefits of SD should go straight to the bottom line Must be easy and faster to reach and should be very operational
31

INCIDENT MANAGEMENT (IM)

Overview Incident lifecycle Incident escalation Functional vs hierarchical escalation Benefits, costs and challenges

Incident: An unplanned interruption to an IT Service or a reduction in the Quality of an IT Service. Failure of a Configuration Item that has not yet impacted Service is also an Incident. For example Failure of one disk from a mirror set. Incident management: The Process responsible for managing the Lifecycle of all Incidents. The primary Objective of Incident Management is to return the IT Service to Users as quickly as possible with the least impact on the service.

32

Incident Management
Overview
Lower or even eliminate the effects/occurrence of IT interruptions, disturbances or quality reduction Must get users back to work ASAHP Hire qualified personnel to record, classify, and escalate (if required) all incidents Progress should be monitored Incidents must all be resolved Process must be closed after resolution with accompanying documentation
33

Incident Management
Escalation
Pass incident unto higher Expertise /authority level Functional (horizontal) escalation Hierarchical (vertical) escalation 1st line (Tier 1) Service Desk Nth line, N-tier Vendors, suppliers & consultants 3rd line, Tier 3 - Developers and architects 2nd line (Tier 2) Network/server mgmt or central processing

NB: Develop horizontal first then vertical

Users, power users, customers, app. mgmt

34

Expanded Incident Lifecycle

MTTR - Mean Time To Repair or downtime = MAINTAINABILITY Response Time

Recovery time

Detection

Repair

Restore

Incident

Diagnosis

Recover

Incident

Detection Time

Repair time

MTBF Mean Time Between Failures or Uptime =AVAILABILITY & RELIABILITY

MTBSI Mean Time Between System Incidents = RELIABILITY

35

Incident Management
.

More accurate operations

Reduce impact on business Improve user productivity Obtain independent, customer-focused incident monitoring Objectives and Benefits Make SLA information more readily available Lower cost of doing business

Improved user satisfaction

Keep problems from escalation

Active monitoring of user domains and services

React quickly and efficiently

36

Incident Management
Incident records vs Problem record
Incident records are end-user focused Incident reporting mgmt focuses on measurements of downtime and business impact Problem records start with IT mgmt decision to invest in resources and end-user downtime for root cause investigation and implementation Problem records focus on internal IT process Mgmt reporting on problems focuses on root causes and implementing structural resolutions
Note: A problem is the unknown underlying cause of one or more incidents

37

Incident Management
Incident life-cycle
Detect And record Classify And Support Investigate And Diagnose

Process Service request

Close The request

Resolve And Recover

38

Incident Management
Benefits, costs and challenges
Benefits: Greater effectiveness, reduced business impact Proactive enhancements and changes Business-focused SLA mgmt Improved monitoring and performance (Sce qlt) Better staff utilization and efficiency Eliminate future incidents and service requests More accurate DB Improved customer/user satisfaction
39

Incident Management
Benefits, costs and challenges
Cost:
Initial planning and implementation communication Training and ramp-up (pilot test resolutions prior to implementing) Hardware and software tools

40

Incident Management
Benefits, costs and challenges
Challenges:
Users/staff bypass procedures Incident backlog process overload Too many escalations Lack of clear definitions, SLAs, commitment.

41

PROBLEM MANAGEMENT (PM)

OUTLINE

Problem defined PM vs IM Goals and objectives Problem mgmt process The Problem Manager

42

Problem Mgmt
Problem Management is the Process responsible for managing the Lifecycle of all Problems. The primary Objectives of Problem Management are to prevent Incidents from happening, and to minimize the Impact of Incidents that cannot be prevented. Problem A cause of one or more Incidents. The cause is not usually known at the time a Problem Record is created, and the PM Process is responsible for further investigation. PM is closely related to SD and IM Main concern is eliminating infrastructure errors Underlying causes of actual and potential failures Tracks and monitors infrastructures
Problem Known errors
A problem for which the root cause is known and temporal work-around has been sort

RFC
43

Problem Mgmt
PM vs IM The two actually have contradictory goals many organizations combine the two processes detrimentally PM should support IM by workarounds, and temporary solutions PM takes time to identify the root cause of incidents often extended periods of unplanned downtime Optimally the two processes have to be separated PM is often escalation point for SD and IM
44

Problem Mgmt
PM Goals and Objectives

Fire-fighting and fire-prevention Minimize adverse effects on business Proactively prevent the occurrence of incidents, problems and errors (i) ID errors (ii) Decision making (iii) Act accordingly Present proposals for improvement, rectifying errors, responding to RFCs Identify weaknesses | vulnerabilities in infrastructure
45

Problem Mgmt
PM Process
INPUTS MAIN ACTIONS OUTPUTS

Incidents SD Fixes & workarounds Config data/info from vendors, etc

Problem control Error control Proactive mgmt Reports/documentation

Problem DB RFCs Problem record Closed records

SLAs, records, logs, perf. Metrics, etc

46

Problem Mgmt
PM Process

Problem control Identifying problems, investigating root cause Turn problems into known errors through classification, investigation, and diagnosis Generate RFC then resolve and close case Classification involves categorization, impact, urgency, priority, status, etc Investigation and diagnosis are repetitive to get closer to resolution Temporary or emergency fixes may be applied
47

Problem Mgmt
PM Process

Error Control Monitoring and managing known errors until they are resolved Issues RFC to Change mgmt May evaluate change in a Post Implementation review (PIR). A PIR determines whether the change was successful and identifies opportunities for improvements Can involve several departments / units Includes error identification and recording, error assessment, documentation, resolution, closing the case Tracking and monitoring is done through all stages
48

Problem Mgmt
PM Process

Proactive problem management

Focuses on quality of infrastructure and services Uses trend analysis to pre-empt problems and incidents Looks for weaknesses, performs penetration testing, keep up with vendor alerts, and bulletins Firewalls to prevent inter-domain problems Overall identification and on-going investigation of systems
49

Problem Mgmt
The problem manager

Responsible for all PM activities Maintains all problem/error control procedures Assesses effectiveness of PM process Protects integrity and independence of IM Governs proactive prevention campaigns Manages personnel and resources Develops and improve processes Conducts post-mortem reviews
50

CHANGE MANAGEMENT (CM)

Note every change is an improvement but every improvement is a change

Change mgmt in a nutshell Key terminology CM actions Change Manager role

51

Change Management
Overview

Most incidents are directly related to change CM is like a thermostat The goal of CM is to manage the change process and limit the introduction of errors and incidents related to the changes Innovations, improvements, modifications, corrections CM is tightly coupled with configuration mgmt and release mgmt
52

Change Management
Key terminology Change: The addition, modification or removal of anything that could have an effect on IT Services. The Scope should include all IT Services, Configuration Items, Processes, Documentation etc. Change History: Information about all changes made to a Configuration Item during its life. Change History consists of all those Change Records that apply to the CI. Change Management: The Process responsible for controlling the Lifecycle of all Changes. The primary objective of Change Management is to enable beneficial Changes to be made, with minimum disruption to IT Services. Change Record : A Record containing the details of a Change. Each Change Record documents the Lifecycle of a single Change.
53

Change Management
Change Actions Recording Acceptance Classification Planning and approval Coordination Evaluation
54

Change Management
Recording

All RFCs are logged with Ref. # of known error Routine, standard changes dont generate RFCs, i.e. Service requests not assessed by change mgmt RFCs come from PM IT staff, customers, legislation and mandates, vendors, suppliers, projects, etc Log should contain: RFC unique ID, cross-referenced known errors/problem #, description, reason for change, current/new versioning, info about submitter, submission date, estimated time frame, resource allocations.

55

Change Management
Acceptance Initial assessment with re-request option for RFC. Acceptance will lead to (i) Status change of existing CI (ii) Change in relationship between CIs (iii) New CI (iv) new location or owner of CI Information needed to further process change is included in the change record
56

Change Management
Classification

Priority and category are designated for accepted RFC Priorities and categories with CAB and possibly other steering committees Sample priorities : Low, Normal, High, Critical Sample Categories : - Minor impact - Substantial impact - major impact
57

Change Management
Planning Approval CM uses Change calendar or FSC (Forward Schedule for Changes) to plan FSC contains approved change details, planned implementation dates, etc CM with CAB approve three aspects of the change : financial, technical, business
58

Change Management
Coordination
Approved changes go to production specialists who construct and implement the change Changes should be pilot tested prior to implementation May involve RM IT service

Phases
Build Test
Implement

59

Change Management
Evaluation

All implemented non-standard changes should be assessed Did change meet intended goal? Are all parties satisfied with the results? What were unplanned side effect of the applied change(s) Did implementation exceed estimated cost and downtime? RFC is closed after success and evaluation Results are documented in the PIR
60

Change Management
Change manager role
Overall responsibility for CM in consultation with management and CAB May be an individual or a committee In charge of reaching all CM goals and developing methods of ensuring efficiency and effectiveness Defines the scope of CM and associated processes Receives, logs, categorizes and/or prioritizes RFCs. Convenes CAB to review. Submits CAB recommendations to possibly stakeholders like CIO, etc.
61

RELEASE MANAGEMENT (RM)

Basics Goals Release Process and activities

62

Release management (RM)

RM Basics Major release major rollout, substantial increase in overall functionality eliminate errors e.g. Softlearn V. 1, V.2, etc Minor software release includes minor enhancements, interface changes, fixes, hardware support, e.g Softlearn V. 1.1, V. 1.2, Hardware upgrades improved support / functionality
63

Release management (RM)

Goals

Garner a holistic view of IT service change Assure technical and non-technical aspects are considered RM is hands-on working group for CM Manage release planning, policy, design, building and configuration Campaign for acceptance, plans eventual rollout Conducts extensive testing (pre, pilot, post) and auditing Preparation, installation and training Storage, release, distribution, install of software or hardware solution
64

Release management (RM)

Release types: Full Test, dist. And implement all the components of the release units e.g. OS upgrade Delta (partial)- incremental Package bundle of full/delta release a set of two or more releases e.g. MS Office
65

Release management (RM)

Release mgmt process
Change Mgmt Recording, accepting, classifying, planning, bldg & testing, implementing, evaluation

SLM

Release Management (1) Policy and planning; (2)Design, Bldg&config, testing & release acceptance; rollout planning; commun ication, preparation and training; (3) Release dist. And Installation

DSL / DML C M D B

DHS

Configuration mgmt
66

Release management (RM)

Costs and pitfalls of RM Personnel, DSL/DML/DHS storage (Backup/Recovery) Build / Test / Dist. Environments Software and hardware costs installation Pitfalls/Challenges : - resistance from parties - Dist. Is out of sync - Inadequate testing
67

CONFIGURATION MANAGEMENT
Outline Concepts and Objectives Benefits CM activities Costs and problems

68

Configuration Management (CM)

Concepts and Objectives

Goal is to keep info about IT infrastructure current specific item details and relationships with other items Make sure changes have been properly logged/documented Maintain accurate topology of existing CI Provide about product policy, troubleshooting data, impact assessment, provisioning of service Concepts CI and CMDB CM goes well beyond asset mgmt
69

Configuration Management (CM)

Key definitions:
Configuration Item (CI) :Any Component that needs to be managed in order to deliver an IT Service. Information about each CI is recorded in a Configuration Record within the CMS and is maintained throughout its Lifecycle by CM. CIs are under the control of Change Management. CIs typically include IT Services, hardware, software, buildings, people, and formal documentation such as Process documentation and SLAs.

Configuration Management Database (CMDB) : A database used to store Configuration Records throughout their Lifecycle. The CMS maintains one or more CMDBs, and each CMDB stores Attributes of CIs, and Relationships with other CIs. Configuration Management System (CMS) : A set of tools and databases that are used to manage an IT Service Provider's Configuration data.

70

Configuration Management (CM)

CMDB CMDB is a DB store of Configuration Records through lifecycle CMS contains one or more CMDB Each DB stores attributes of CIs and their interrelationships CMDB is designed based on a configuration structure e.g. AD Similar to versioning control software that developers use (VMS, SCM, WebDAV)
71

Configuration Management (CM)

CI attributes ITIL mandatory = unique identifier (alphanumeric), status Optional Attributes = rev. #, location owner, asset #, manufacturer, man. Ser #, part #, release date, expiry date, config. details, license data, etc Other linked fields like other DBs = RFC #, Change #, problem #, Incident #,
72

Configuration Management (CM)

Benefits of CM Manage IT components and services Contributes to faster T-shooting and change process Better control of hardware and software Improved security and compliance Enhanced planning for procurement / expenditure Support for Capacity mgmt and Availability mgmt Foundation for IT continuity mgmt
73

Configuration Management (CM)

Change mgmt RFC Release mgmt Release mgmt Reports, logs & audits Reports Update CI details Release & Distribution Update CMDB & DSL/DML C DSL M D B DML

Classification & Planning

Release Implementation Evaluation Closure

Verify CMDB Update Hands-on / technical

74

Logical

Configuration Management (CM)

CM process
Identification (Scope) Control (DBMS)

Planning

Reporting Documentation

Verification Auditing

Status Accounting

75

Configuration Management (CM)

Costs and challenges Added software, hardware, licenses, etc DB: CMS design, implementation, maintenance Erroneous CMDB scope and CI detail are challenges Timing moving from manual to automated systems Effects of sudden changes and over reaching schedules Obtaining buy-in from mgmt / stakeholders Users / customers bypassing CM process
76

77

78