Detailed outline of an Information Technology Infrastructure Library (ITIL) is a set of practices for IT service management (ITSM) that focuses on aligning IT services for Software Companies

1. Introduction to Service
Management
ITILS Services for Software
Companies
Daniel Brody© 2014

2. Service Components

3. Process Orientated Working
Incident Management
Problem Management
Service Level Management
Change Management

4. What is ITIL?
IT Infrastructure
Library

5. IT Infrastructure Library
• A set of books describing code
of best practice for IT Service
provision
• UK Government
• First edition – Late 80’s
• Revised in 2000
• Non-proprietary
• Platform independent
ITIL

6. Two Books
Service Delivery
Service Support
ITIL’s Service Management

7. Service Support
Focuses on the day to day operation and
support of IT Services

8. Service Delivery
Focuses on long term planning and
improvement of IT Service provision

9. ITIL Publications
Planning to Implement Service Management
The Business Perspective
Application Management
ICT Infrastructure Management
Security Management
Service Support
Service Delivery
Planning to Implement Service Management
Service Management
Service
Support
Service
Delivery
T
h
e
B
u
s
i
n
e
s
s
The
Business
Perspective
Applications Management
ICT
Infrastructure
Management
T
h
e
T
e
c
h
n
o
l
o
g
y
Security
Management

10. IT Service Management
….
Foundation
Support

11. Configuration Management

12. Mission
To identify, control and audit the information
required to manage IT services by defining and
maintaining a database of controlled items, their
status, lifecycles and relationships and any
information needed to manage the quality of IT
services cost effectively

13. Asset Management
vs
Configuration Management

14. Objectives
• Identify & record management information
• Account for all IT assets & configurations
• Control the information in the database
• Ensure that information reflect reality
• Provide a basis for management
• Provide status of components

15. Key Terms

16. Configuration
• Hardware
• Software
• Documentation
• Communication
• Environmental Equipment
• Staff
Anything that needs to be controlled

17. Configuration Item (CI)
PC
KeyboardMonitor System Unit
CD ROM Stiffy
Drive
MemoryHard
Drive
CPU
•A component within a configuration
•A configuration in its own right

18. How low do you go???
• CI Levels
– Lowest level of independent change
– Who are you and what are you doing?
– Information value vs collection effort

19. Attributes
Memory
PC
KeyboardMonitor System Unit
CD ROM Stiffy
Drive
MemoryHard
Drive
CPU

20. Key Terms
• Relationship
– Primary
– Secondary
• Baseline
– Snapshot of a CI at a time or stage
• Variant
– A baseline with minor differences
• Model, Version and Copy numbers
– Type
– Unique
– Version / Copy

21. Life Cycles
• Stages in the life of a CI
• Allow CIs to be moved and tracked
Ordered
Delivered
Set up
Installed
Withdrawn
Maintenance

22. Key Activities

23. Stages in Configuration Management
• Identification
• Control
• Status Accounting
• Verification / Audit

24. Identification
• Logical
– What items need to be recorded?
– What do we need to know about them?
• Physical
– Marking items that are under Configuration
Management control
Logical & Physical

25. Basic Principles
• CIs must be uniquely identified
• Prominent & clearly visible
• Meaningful naming
• Copy numbers must be catered for
• Cater for growth

26. Control
• Information in the CMDB
– Access
– Changes
– Adding new items
• To achieve control
– Agree and freeze CI specification
– Only allow changes through change management

27. Status Accounting
• Uses lifecycles and attributes
• Records and reports on
– Current data
– Historical data

28. Verification & Audit
• Does the CMDB reflect reality?
• Accuracy is improved by
– Active rather than passive CMDB
– Automatic updating
– Integration with other processes
– Automatic checks

29. The CMDB

30. Accounts Sales Marketing Manufacturing
Inventory Purchasing Distribution HR
Information Management

31. Accounts Sales Marketing Manufacturing
Inventory Purchasing HRDistribution
Management
Information

32. Accounts Sales
HR
Distribution
Marketing
Manufacturing
InventoryPurchasing
Management
Information
Corporate
Database

33. NETWORK SLMCHANGEPROBLEM
CAPACITY FINANCIAL SERVICE DESK PERFORMANCE
CMDB

34. PROBLEM
CAPACITY
CHANGE
FINANCIAL
SERVICE DESK
PERFORMANCESLM
Management
Information
CMDB

35. Underlying Databases
VIRTUAL
CMDB

36. Benefits, costs & problems

37. Benefits
• Accurate information & documentation on CI’s
• Control of valuable CI’s
• Legal Obligations
• Financial & expenditure planning
• Registration of Software Changes
• Contingency planning
• Improving Release Management
• Improved security
• Trending data

38. Costs
• Staff costs
– Initial audit
– Management
• HW & SW identification & Level of control
• Number of users who have access
• Need for tailoring
• Diversity & quality of information
• Level of integration

39. Possible Problems
• Incorrect CI level
• Emergency changes
• Over-ambitious schedules
• Circumvention of procedures
• Manual systems
• Over expectation
• Isolated implementation
• Difficult without Change Management
• Difficult to cost justify
• No operational use of the system

40. Change Management

41. Mission
To manage all changes that could impact on IT’s
ability to deliver services through a formal,
centralised process of approval, scheduling and
control to ensure that the IT Infrastructure stays
aligned to business requirements with minimum risk

42. Objectives
• Manage the process of:
– Requesting changes
– Assessing changes
– Authorising changes
– Implementing changes
• Prevent unauthorised changes
• Minimise disruption
• Ensure proper research and relevant input
• Coordinate build, test and implementation

43. Scope
 Hardware
 System Software
 Communications Equipment and Software
 ‘Live’ Application Software
 All documentation, plans and procedures relevant to the
running, support and maintenance of live systems
 Environmental Equipment

44. Key Terms

45. Key Terms and Roles
• Request for Change (RFC)
– Contains all necessary information to make the change
• Change Advisory Board (CAB)
– Assesses resource requirements and impact
– Advises the Change Manager
• CAB Emergency Committee (CAB/EC)
– Urgent changes
– 1-3 senior staff

46. • Forward Schedule of Change (FSC)
– Details of approved changes & dates
• Projected Service Availability (PSA)
– Best time for change to be implemented
• Change Model
– Pre-defined path
• Standard Change
– Pre-authorised change

47. Change Management Procedure

48. Initiate Change
Filter Requests
Initial Priority
Decide Category
Urgent?
Normal Change
Procedure
Reject
To urgent procedure
Yes
Change Model?
To Change Model
procedure
Yes
Minor Significant Major
Assess impact and resources. Confirm priority and ScheduleAuthorised?
No
Yes
Refers RFC upwards. IT Director
decides then passes to CAB for
actioning
Circulates RFCs
to CAB members
Authorises and schedules
change. Report action to
CAB

49. Independent Testing
Build change, Testing &
back out Plans
Co-ordinates
implementation
Working?
Monitor/Review Change
Back out / Refer back to
CAB
Normal Change
Implementation
Procedure
From Normal Change
Yes
No
Successful?
Yes
Close
No
To Start
Failure
Update Documentation

50. Urgent CAB or
CAB/EC meeting
Assess impact resource
requirements and urgency
Urgently prepares the
change
Urgent? To normal procedure
Urgent Change
Procedure
Time for test? Urgent Testing
Yes
No
Yes
Failure
No
Co-ordinate
implementation

51. Satisfactory?
Co-ordinates
implementation
Implements back-out
plans. Change is
referred back to
CAB/EC
Ensure records are
brought up to date
Review Change
Urgent Change
Procedure
Satisfactory?
No Yes
CloseTo Start

52. Benefits, Costs & Problems

53. Benefits to Business
• Greater IT & business alignment
• Higher availability
• Increased productivity
• More communication – greater trust
• IT can handle more changes
• Balance between need for change & potential impact

54. Financial Benefits
• More accurate forecasting
• Better quality decisions
• Reduction in amount of rework

55. IT Benefits
• Easier to meet SLA’s
• Fewer change failures
• Back out plans – easier restore
• Valuable input for problem & availability
• Increased productivity of IT Staff

56. Costs
• Software costs
• Integration & modification
• Staff
• Accommodation

57. Possible Problems
• Bureaucratic procedures
• Resistance to “control culture”
• Bypassing of procedures
• Integration to Configuration Management
• Inaccurate information
• Handling urgent changes
• Detecting unauthorised changes
• Too broad scope for a change
• Unclear ownership

58. Release Management

59. Mission
To take an holistic view of a change to an IT Service
and ensure that all aspects of a release, both
technical and non-technical, are considered
together

60. Why Release Management?
• Large or critical
hardware roll-outs
• Major software roll-
outs
• Bundling or batching
related sets of
changes
In-house
applications
“Other” software
Utility Software
System Software
Hardware
Specifications
Assembly
Instructions
User Manuals

61. Key Concepts

62. Key Concepts
• Release
– Collection of authorised changes
– Major / minor / emergency
• Definitive Hardware Store (DHS)
– Storage of Hardware spares
• CMDB
– Definitions of planned releases
– Records of CI’s impacted by release
– Information about the target of environment

63. Key Concepts
• Definitive Software Library (DSL)
– Physical secure storage
– Source code & Original media
• Build Management
– Controlled environment
– Compiled on dedicated “build hardware”
• Release Policy
– Roles, responsibility & content
– Form part of initial planning
• Release Unit
– Components released together

64. Release Units
• Systems, suites, programs and modules
• Factors affecting the level of release
– Number and extent of changes
– Number of changes that can be managed
– Available resources and time
– Ease of implementation
– Complexity of the release

65. Release Units
System 1
Suite 2.1
Program 2.2.1
Module 2.2.2.1 Module 2.2.2.2 Module 2.2.2.3
Program 2.2.2 Program 2.2.3
Suite 2.2 Suite 2.3
System 2 System 3
IT Infrastructure

66. Development Releases -  and 
• Managed by development
• Must not affect live services
• Should not require production resources
• Customer agreement obtained
• Usage covered in SLAs
• Must not replace live systems
• Must be licensed

67. Normal Release - Full
• All components built, tested, distributed &
implemented together
• Better integrated testing
• Easier to detect & rectify problems
• Complex & will require more resources

68. Normal Release - 
• Partial release
• Contains only new or changed items
• Not as stable as full releases
• Authorisation of a delta release depends on:
– Size of a full release compared to the delta
– Urgency of required facilities
– Number of changes already made
– Potential business impact
– Available resources

69. Normal Release – Package
• Combination of release units
• Reduces number and frequency of releases
• Better integration and testing
• Less old or incompatible software
• Could result in delays to fixes or enhancements
• Greater potential for disruption

70. C1
C2
C3
C4
C3
Package
Release
Delta
Release
M1
M1
M2
M3
M4
Full
Release

71. Urgent Releases
• Disruptive and error prone
• Often used to bypass Change Management
• Controls are essential
– Use software from the DSL
– Software must be replaced through the DSL
– Must follow Change Management
– CMDB must be updated
– Version control
– Testing and documentation
– Give notice

72. Back-Out Plan
• Documents actions that will restore service
• Still part of change
• Two approaches
– A full reversal of release
– Contingency plans to restore as much as possible
• Should be verified and tested

73. Key Activities

74. Configuration Management Database (CMDB)
&
Software Library
ReleasePolicy
ReleasePlanning
Design&develop,or
order&purchase
software
Build&configurethe
Release
Fit-for-purpose
testing
ReleaseAcceptance
Roll-outplanning
Communication
Preparation&training
Distribution&
installation
Development Environment Controlled Test Environment
Live
Environment
Release Management

75. Release Policy
• Basis of subsequent activities
• Management roles & responsibilities

76. Release Planning
• Agreeing release content
• Planning phases of releases
• Produce schedule
• Assess hardware at target site
• Plan resource requirements
• Obtain quotes if upgrades are required
• Produce back out plans
• Develop quality plan
• Plan acceptance of support groups

77. Designing, Building & Configuring
• Components assembled in controlled process
• All components of release should be under
Configuration control

78. Testing & Release Acceptance
• Before going to live
• Types of testing
– Functional testing
– Operational testing
– Performance testing
– Integration testing
– Testing & back out plans
• Final acceptance & sign off – part of Change
• Rejection treated as failed change

79. Rollout Planning
• Wholesale / “big bang”
• Phased roll outs
– Geographical
– Functional
– Technological
– Combination

80. Communication, Preparation &
Training
• Support staff & customers
• Training
• Parallel working
• Involvement in acceptance process
• Rollout planning meetings

81. Distribution & Installation
• Distribution
– Equipment reaches destination in time & in tact
– Secure Storage Areas
– Checked against relevant documentation
– Final check before implementation
• Installation
– Functional checks of equipment
– Automate deployment
– Installation routines
– Include check of target
– User checklists?

82. Software ordered
Software developed
and supplied
Acceptance checks
OK?
Rectification
Action
No
Software placed in DSL
Final approval
Package built in
test environment
Operational
acceptance testing
OK?
No Build in live
environment
Distribute to live
environment
Implemented on
live environment
C
M
D
B
Normal Flow of software

83. Benefits, Costs & Problems

84. Business Benefits
• Minimum disruption
• Better quality of service
• Fewer & less frequent releases
• Effective scheduling of users for testing
• Overall reduction in business risk
• Business knows what to expect & can plan

85. Financial Benefits
• Assets more controlled
• Less time & resources spent on rework
• More responsive to revenue producing
opportunities
• Prevention of duplication of activities

86. IT Benefits
• Consistent quality of releases
• Centralised control
• Improved quality and control of changes
• Effective planning of staff activities
• Number of regressions are reduced
• Easier detection of unauthorised and incorrect
versions
• Less blame shifting

87. Costs
• Storage costs
• Build , test and archive environments
• Secure equipment stores
• Software distribution tools
• Network bandwidth
• Telecommunications
• Staff and training

88. Problems
• Circumvention of procedures
• Emergency fixes
• Distribution of builds directly from development
• Uncoordinated implementation of Software and
Hardware
• Resources not available for testing
• Test results are invalid
• Process is seen to be unclear or bureaucratic

89. Relationships
• Configuration Management
• Change Management
• Problem Management
• Service Desk
• Project Management
• Developers and suppliers

90. Service Desk

91. The Service Desk
Structure not a process
• Drive & improve service to the business
• Single point of contact
– Advice
– Guidance
– Rapid restoration to service

92. Role of the Service Desk
• Supports the incident & problem management
function
• Provide a central point of contact
– Preventing the same incident being reported to
different people over & over
– Preventing the loss of incidents
– Preventing technical people being disrupted
– Preventing unnecessary work if already known error

93. Objectives
• Single point of contact for reporting of incidents
• Accurately record information about incidents
• Co-ordinate activities to restore service to normal
• Support the incident & problem management functions
• Provide management information
• Provide support & advice to business

94. Key Elements & Processes

95. Service Desk Functions
• Log Incident
• Pre-scan phase
– Not Known Error
– Proper procedure have been followed
– Required supporting evidence is complete & present
• Incident Management
• Service Desk remains responsible
• Responsible for escalation
• Regularly feeds back to user

96. Service Desk & Change Management
• Log Changes & cross reference to problems
• Issue change schedules
• Monitor & track changes & assist with escalation
• Inform users of change once complete & update
change schedules

97. Common Features of Service Desks
• A single point of contact for all users
• A central log of all incidents
• Each incident uniquely numbered and date/time stamped
• Diagnostic scripts and other aids
• Configuration Management Support Tools
• Known Error Lists
• An impact coding system

98. Common Features of Service Desks
• Automatic escalation procedures based on impact, priority
and elapsed time
• Telephone and electronic mail communication with all
support staff
• Interface to Service Level Agreements
• Regular progress reporting
• Classification of incidents at call closure
• Regular management summaries of calls received and
resolved

99. Service Desk Structures

100. Local Service Desk
• Local desk meeting local needs
• Support staff also local
• Becomes impractical with multiple locations
• Several local desks – operational standards
• Common processes across all locations

101. Local Service Desk
Local
User
Local
User Local
User
Third Party
Support
Network &
Operations
Support
Application
Support
Desktop
Support
Service Desk First line Support

102. Centralised Service Desk
Customer Site
1
Customer
Site 2
Customer
Site 3
Third Party
Support
Network &
Operations
Support
Application
Support
Desktop
Support
Service Desk
Second Line Support

103. Modem
Virtual
Service
Desk
Paris Service Desk Sydney Service
Desk
Modem
Third Party Supplier
Service Desk
Cape Town
Service Desk
Local Users
LAN
Service
Management
Database(s)
London Service
Desk
Toronto Service
Desk
fax
LAN
Durban Service
Desk
User Site ‘n’User Site I
Telephone
Local Users Remote Users

104. Virtual Desks
• Physical location immaterial
• Used for global organisation
• Benefits include
– Reduced operational costs
– Consolidated management overview
– Improved usage of available skills
– Knowledge sharing
• Onsite assistance still required

105. Outsourcing
• Have outsourcers use your Service Desk tool
• Keep ownership of management information
• Ensure suitably skilled staff
• Request details of staff
• Monitor value for money
• Check supplier dependencies
• Ensure deliverables are clearly understood

106. Service Desk
Skill Sets

107. Staff Profiles
• Understanding of business
• Understanding of IT Infrastructure
• Exceptional interpersonal skills

108. Technically Unskilled Staff
• Centralised Service Desks
• Emphasis on interpersonal skills
• Large call volumes, little support
• Administrates and coordinates calls
• Relies on diagnostic scripts and other tools
• Technical staff are not distracted or demotivated
• No in-depth support
• Potential job satisfaction is high

109. Technically Skilled Staff
• Lower call volumes, greater support
• Longer call times
• May become to involved in technical aspects
• Job satisfaction issues
• Customer satisfaction issues
• Peak time staffing issues
• Familiarity breeds contempt

110. Expert Staff
• Resolve all calls
• Staff are more important than procedures
• Will play the role of technical departments

111. Incident Management

112. Definition of an Incident
Any event which is not part of the standard operation of a
service and which causes, or may cause, an interruption
to, or reduction in, the quality of that service
Includes
• New services
• Automatically registered events

113. Mission
To minimise the impact of service disruptions
to the business by restoring that service
through effective management of incidents

114. Scope
• Inputs
– Incident details from service desk
– Configuration details
– Matched incidents, problems & known errors
– Resolution details
– RFC
• Outputs
– RFC for resolution
– Resolved & closed incidents
– Communication to Customers
– Management information

115. Objectives
• Restoration of service as quickly as possible
• Ensure timely resolution of all incidents
• Identify trends that may assist in incident
resolution
• Assist problem management in identifying trends

116. Key Concepts

117. Incident Handling
• Service Desk owns Incidents
• Progress reporting
• Incident Lifecycles
– New
– Accepted / Assigned
– Scheduled
– WIP
– On Hold / Waiting
– Resolved
– Closed

118. Levels of Support
• 1st line Support
– Service Desk
• 2nd Line Support
– Incident Management
• 3rd Line Support
– Specialist Group

119. Key Concepts (cont.)
• Ownership & Communication
– Monitor status against open Incidents
– Incidents passed between support groups
– Affected users are kept informed
– Check for similar Incidents
– Incidents that are likely to exceed SLA times
• Escalation
– Functional Escalation
– Hierarchical Escalation

120. Classification
• Category
Operating System
Application
Financials
Line
Network Connection
Modem
Monitor
Mouse
Hardware
Printer
Terminal
Connector
Software
Network

121. Impact Code
IMPACT
CODE
DESCRIPTION
TARGET
RESOLUTION TIME
High
Major service unavailable
Many Users affected
1 Hour
Medium
Customer terminal or printer
down
Cannot function
4 Hours
Low
Customer terminal or printer
experiencing intermittent
failure
8 Hours

122. Key Concepts (cont.)
• Incidents, Problems and Known Errors
– Incidents are events or occurences that degrade or
disrupt a Service
– A problem is the underlying cause of one or more
incidents that have not yet been diagnosed
– Known Errors are
• Problems that have been diagnosed and have not yet been
rectified
• Problems that have been diagnosed and for which a resolution
or circumvention exists

123. Incident Management Activities

124. Reasons for classification
• Identifying the service the Incident is
related to
• Associate the Incident with the SLA
• Selecting the most suitable support team
• Indication of the impact and/or severity
• Match Incidents to Known Errors
• Determine a reporting structure
Incident detecting
& recording
Initial classification
& support
Service
Request
Service Request
Procedure
•Service Desk
•System Monitoring tools
•Capturing base & initial data•Diagnostic Scripts
•Known Error Database
•Skill Levels
•Knowledge base and/or expert software

125. Incident detecting
& recording
Initial classification
& support
Service
Request
Investigation &
diagnosis
Resolution &
recovery
Incident Closure
Service Request
Procedure
Ownership,monitoring,trackingand
communication
• Support group accepts assignment
• Advise if work around can be provided
• Attempt resolution
• Record all details

126. • Monitor status against open Incidents
• Incidents passed between support
groups
• Affected users are kept informed
• Check for similar Incidents
• Incidents likely to exceed SLA times
• Escalation
Ownership,monitoring,trackingand
communication

127. Incident detecting
& recording
Initial classification
& support
Service
Request
Investigation &
diagnosis
Resolution &
recovery
Service Request
Procedure
Ownership,monitoring,trackingand
communication
Incident Closure

128. Incident
CMDB
Incident, Problem
& KE databases
Diagnostic data
system dumps and
journals
Support staff
allocation
Basic fact
gathering
Enquiries on
historical data
Support staff
allocation
Allocate
further support
Incident Closure
Diagnosis/
Circumventions?
Escalation
threshold
exceeded
Liaise with Problem
Management to create
Problem or Known Error
record where appropriate
Who, When
•
Results?
•
Correlations
•
Dumps, ID’s etc
•
Diagnosis and
resolution/
circumvention
action
•
What, why when?
•
When
Incident progress
summary
Free Format
text record
Diagnostic data
search
Y
Y
N
N

129. Problem Management

130. Mission
To minimise the disruption of IT services by
organising IT resources to resolve problems,
preventing them from recurring and recording
information that will improve the way in which
IT deals with problems, resulting in higher levels
of availability and productivity.

131. Scope
• Reactive
– Solving problems in response to incidents
• Proactive
– Solving problems before incidents occur
The main goal of Problem Management is the detection of
the underlying causes of an incident and their subsequent
resolution and prevention

132. Objectives
• Identify, manage and resolve problems
• Prevents recurrence of problems
• Reduce the number and severity of problems
• Minimise impact to business
• Ensure right level of staff
• Record & manage information
• Ensure vendor compliance when resolving problems

133. Key Concepts
Incident
Problem
Known Error
Change
Incident
Control
Problem
Control
Error
Control
Change
Control
Service Desk /
Incident Management
Problem
Management
Change
Management

134. Problem V Error Control
Problem Control
Transforms Problems into
Known Errors
Error control
Resolving Known Errors via
the Change Management
process

135. Problem Control

136. Problem Control
Problem Identification
Problem Classification
Problem Investigation and diagnose

137. Problem Identification
• Initial support could not match the Incident to a
known problem
• Analysis of Incidents
• Analysis of IT infrastructure
• Significant or Major Incidents

138. Problem Classification
• Impact
– Direct effect on the business
• Urgency
– The measure of business criticality based on impact and business
need
• Priority
– The order in which a series of items should be addressed
– P=I x S x U

139. Defining Priority
Priority – sequence in which an Incident or Problem
needs to be resolved
Impact – measure of the business criticality of
an incident
Severity – what is the effect on the infrastructure /
resources?
Urgency – extent to which the resolution of a Problem
or error can bear delay
Priority = Impact Severity Urgencyx xP = I S Ux x

140. Investigation & Diagnosis
• Diagnosis of root cause
• Update of problem record
• May reclassify at closure
• Methods of problem Analysis

141. Error Control

142. Error Control Activities
Error identification & recording
Error assesment
Error resolution recording
Error closure
Error resolution monitoring

143. Error Identification
• Identification of root cause
• Identification of work around
• Two sources of known errors
– Problem control
– Development

144. Error Assessment
• Assessment of resolution
– Priority, impact & urgency
• Logging of change

145. Error Resolution Recording
• Resolution recording
– Known error database
• Data on all CIs are available for incident matching

146. Error Closure
• Closed together with any Incidents
• Resolved or Closed Pending on review

147. Error Resolution monitoring
– Not responsible for RFCs
– Monitor progress
– Escalate through CAB if necessary

148. Proactive Problem Management

149. Proactive Problem Management
• Identifying and resolving problems before
incidents occur
• Activities include:
– Trend Analysis
– Targeting support action
– Providing information to business