Overview1.1 Management Summary This document provides a summary of the most relevant information of the ITIL Service Support V2 book to help with preparation of the Exin certificate in I
Trang 1ITIL V2 : Service Support
Summary
Author: Pieter Dubois mail address: duboisp@be.ibm.com
Total Pages: 30 Document Version: 1.2
June, 2003
Trang 2Date of this revision: 16/06/2003 Date of next revision: TBD
Revision Number Revision Date Summary of Changes Changes marked
(1) 20/11/2002 Version 1.0
1.1 December 2002 slight adaptations
1.2 June 2003 prepare for publication
References:
Service Support (CCTA) - ISBN 0 11 330015 8
Trang 31 Overview 5
1.1 Management Summary 5
2 Introduction to ITIL 6
2.1 ITIL is 6
2.2 General Service Management benefits 6
3 Relationship between processes 7
3.1 Configuration Management 7
3.2 Service Desk 7
3.3 Incident Management 8
3.4 Problem Management 8
3.5 Change Management 8
3.6 Release Management 9
4 Configuration Management 10
4.1 Mission Statement 10
4.2 Activities 10
4.3 Benefits 10
4.4 Problems 11
4.5 Costs 11
4.6 Reporting 11
4.6.1 Management Reporting 12
4.6.2 Key Performance Indicators 12
4.7 Roles & Responsibilities 12
4.7.1 Configuration Manager 12
4.7.2 Configuration librarian 12
5 Service Desk 14
5.1 Mission Statement 14
5.2 Activities 14
5.3 Benefits 14
5.4 Problems 15
5.5 Implementation considerations 15
5.6 Service Desk type considerations 15
5.6.1 Local Service Desk 15
5.6.2 Central Service Desk 15
5.6.3 Virtual Service Desk 16
5.7 Reporting 16
5.8 Service Desk profile 16
6 Incident Management 18
6.1 Definition and mission statement 18
6.1.1 Mission statement Incident Management 18
6.1.2 Definitions 18
6.2 Activities 18
6.3 Benefits 18
6.4 Implementation Considerations & Success factors 19
6.5 Problems 19
6.6 Reporting 19
6.7 Roles & Responsibilities 19
6.7.1 Incident Manager 19
6.7.2 Incident-handling support staf 20
6.7.3 Second line support 20
7 Problem Management 21
7.1 Mission Statement and scope 21
7.1.1 Goal 21
7.1.2 Scope 21
7.1.3 Definition 21
7.2 Activities 21
7.2.1 Problem Control 21
7.2.2 Error Control 22
7.2.3 Proactive Problem Management 22
7.3 Benefits 22
Trang 47.4 Problems 22
7.5 Planning and implementation considerations 23
7.6 Reporting 23
7.7 Roles 23
7.7.1 Problem Manager 23
7.7.2 Problem Support 23
8 Change Management 24
8.1 Goal, scope and definitions 24
8.1.1 Goal 24
8.1.2 Scope 24
8.1.3 Definitions 24
8.2 Activities 25
8.3 Benefits 25
8.4 Costs & Problems 26
8.5 Planning & Implementation considerations 26
8.6 Reporting 26
8.7 Roles & Responsibilities 27
8.7.1 Change Manager 27
8.7.2 Change Advisory Board 27
9 Release Management 28
9.1 Goal, Scope & Definitions 28
9.1.1 Goal 28
9.1.2 Scope 28
9.1.3 Definitions 28
9.2 Activities 29
9.3 Benefits 29
9.4 Problems 29
9.5 Planning & Implementation considerations 30
9.6 Costs 30
9.7 Reports 30
9.7.1 Key Performance Indicators 30
9.7.2 Management Reporting 31
9.8 Roles & responsibilities 31
Trang 51 Overview
1.1 Management Summary
This document provides a summary of the most relevant information of the ITIL Service Support V2 book to help with preparation of the Exin certificate in ITIL Service Management.The following topics for all processes got particular attention:
• What is ITIL
• Mission statement different ITIL processes
• Activities of each ITIL process
• Benefits/difficulties/costs implementing ITIL process
• Links dependencies with other ITIL processes
• Information flow with other ITIL processes
• ITIL process roles and responsibilities
• Order of implementation within ITIL process
• Key Performance Indicators of and reports about the ITIL Process
Trang 62 Introduction to ITIL
2.1 ITIL is
• A Public Domain Framework: the information is publicly available and can be used
by everyone for implementation
• Best practice Framework: the information documents industry best practice
guidance While not detailing every action that should be done, which is organizationdependant, it provides the goals, general activities, inputs and outputs of the variousprocesses It provides a framework in which to place existing methods and activities
• De facto standard: ITIL by its widespread use became a de facto standard The
advantage is that there is a common language for people to speak This makeseducation very important to provide all people in the process this common language
• Quality Approach: ITIL focuses on providing high quality services with a focus on
customer relationships There is a strong relationship between the IT organizationand the Customers
• Process Based: ITIL is a process based method It sees IT Service Management
also as a Business Process and tries to organize it that way
2.2 General Service Management benefits
• Improved quality of service – more reliable business support
• Formalizes the use of procedures so that they are more reliable to follow
• Provides better view of current IT capabilities
• Provides better information on current IT services provided
• Better understanding of IT support by the business
• Better motivated staff through better management of expectations andresponsibilities
• Enhanced Customer satisfaction as it is clear what service providers know anddeliver
• More flexibility and adaptability through acknowledgement and formalizing working in
a changing environment
• Faster cycle times and greater success rates on implementing changes
Trang 73 Relationship between processes
3.1 Configuration Management
Configuration management is an integral part of all other service management processes
• Change Management: current, accurate information about all components in the IT
infrastructure makes Change management is more effective It can even be
integrated with Configuration Management As a minimum logging of all changes should be done under control of Configuration Management Also impact
assessment should be done based on data of the CMDB All change requests should be entered and updated in the CMDB
• Incident Management/Problem Management: Information from the CMDB help the
service support group to solve Incidents and Problems faster by understanding the probably cause of failure on the Configuration Item The CMDB should link Incident records and Problem records to the failing CI and the User
• Release Management: Requires the CMDB to know what CI’s have to be changed
with a new release
• Service Level Management: uses info from the CMDB to identify CI’s making up a
particular service for which SLA’s are in place With this information, underpinning agreements can be set up
• Financial Management for IT: needs to know which components are used by whom
in order to be able to charge the right departments
• IT Service Continuity and Availability management: needs to know the CI’s to
perform risk analysis and impact analysis on the service and business when a
component fails
• Service Desk: uses CMDB information on CI’s to help resolve incidents or provide
feedback on the status of a CI to the User
3.2 Service Desk
Service desk is the SPOC between service provider and Users on a day-to-day basis
• Incident Management: SD is the focal point in the incident management process It
its activities are: registering Incidents, informing Users about incidents, and
management of the incident end-to-end
• Change Management: As changes can cause incidents, and SD is the SPOC for
incidents, it should know about all changes SD can act as a focal point for Change requests of Users, and inform Users on progress of changes SD can be given delegation to implement Changes to circumvent Incidents within a scope
• Problem Management: informs the Service Desk on the progress of managing
problems
• Service Level Management: Any impact on SLA will arrive at the SD So SD needs
to know what the relevant SLA’s are such that incidents related to services with SLA’sget appropriate priority
• IT Service Continuity: If business continuity plans are invoked, SD plays an
important coordination role
• Configuration Management: good info on CI’s helps the SD managing requests
and incidents
Trang 83.3 Incident Management
• Problem Management: an incident that has a large impact or several incidents
having the same cause can lead to investigation of a problem Therefore all
Incidents should be recorded and available for investigation by Problem
Management
• Service Desk: Is the prime owner of the incident management process It
coordinates all actions required to manage an incident
• Change Management: Changes can lead to new incidents; therefore a way of
linking incidents to changes is required
• Configuration Management: the CMDB can help incident management with
identification of the CI in question Also because of interrogation & reporting reasons
it would be good to link or insert incident records in the CMDB
• Service Level Management: priorities given to incidents and escalation procedures
should be agreed upon as part of the SLM process and documented in the SLA’s
3.4 Problem Management
• Incident management: PM has to have access to accurate and comprehensive
recording of Incidents in order to examine the cause of incidents and trends that are happening
• Configuration Management: PM uses the CMDB to record/update its problem
records, and to identify CI’s exhibiting Problems
• Availability Management: is strongly connected with PM in order to identify trends
and to instigate remedial action
• Change Management: Known Errors give rise to Request for Changes which fall
under the responsibility of Change Management
• Service Desk: PM keeps SD up-to-date of ongoing Problem Resolution.
3.5 Change Management
• Configuration Management: is required for change management as it depends on
the accuracy of the CMDB to assess the full impact of a change
• Release Management: All releases have to go through change management when
implemented in production
• Service Level Management: is provided details of the Change process in the SLA’s
such that the change management procedures are known to the Users Also the impact of changes to the SLA’s are important to take into account
• Service Desk: provided details of the changes that happen such that when incidents
occur on a CI due to the changes it can inform the User about the cause
• Service Level Management: Before changes happen, their impact on SLA’s have to
be assessed
• Availability: Changes to CI’s should be evaluated against the impact on availability
of the services it provides
• Capacity Management: before implementing a change, the impact on the capacity
of the CI should be assessed Also capacity management activities will give raise to RFC’s to ensure proper capacity is available
Trang 9• Security Management: before implementing a change, the impact on the security of
the environment should be assessed
• IT Service Continuity: before implementing a change on a CI, it has to be assessed
what the impact is on the IT Service continuity plans
• Release Management: the implementation of new releases happens under the
control of change management
3.6 Release Management
• Change Management: Changes may require new releases of HW & SW The
preparation of this before it goes in production is part of Release Management, but bringing it in production happens under control of Change Management
• Configuration Management: Creating a new Release should be in close integration
with Configuration Management, where the state of all CI’s, whether they are in development/test/validation/production are updated in the CMDB
• Incident/Problem Management: should be provided with the documentation of the
new Release and procedures of incident remedial should be provided
• Service Desk: after the roll-out of a new Release, SD should be able to support this
new release in terms of requests from Users, and managing of incidents relevant to this new release
• Service Level Management: Implementation of a new release can have impact on
the SLA’s This has to be assessed and remediate in advance
• Capacity Management: The impact of a new Release on the capacity demands of
the systems on which it is implemented should be assessed
• IT Service Continuity: the impact to the business by a Release when a failure
occurs has to be validated by the IT Service Continuity process Both when during the rollout as well as during normal operation, should a failure occur, impacting the usage of this Release
Trang 104 Configuration Management
4.1 Mission Statement
Configuration Management provides IT infrastructure control through the identification, registration, monitoring and management of:
• All the Configuration Items of the IT infrastructure in scope
• All configurations, versions and their documentation
• All changes, errors, service level agreements and history of the components in general
• Relationships between the different components
• Exceptions between configuration records and the real infrastructure
Configuration Management provides a sound basis for other processes like Incident,
Problem, Change and Release management by providing accurate information on all CI’s and to the SD function
4.2 Activities
1 Planning: What is the purpose, scope, objectives, policies, procedures,
organizational & technical context for configuration management
2 Identification & registration: selection, identification and labeling of CI’s and the
relationships between them CI’s can be hardware, software, documentation Also Incident, Problem, Change records can be associated with a CI Important is the level of detail required Each CI should have a unique identifier
3 Control: Only authorized and identifiable CI’s are recorded during their whole
lifecycle time It ensures updates to CI’s are associated with Change Management documents
4 Status accounting: Reporting of current and historical data associated with each CI.
It tracks the state of a CI from one state to another: test, broken, production,
• Controls valuable CI’s: who is responsible for what CI If a CI is stolen/broke, what
should be the configuration of the replacement
• Helps with adherence to licenses: As the CMDB contains an Inventory of all
software installed in the environment, it helps with the verification of legality of installed software during audits
• Helps financial planning: is helped by interrogating the CMDB to know expected
maintenance costs, life expiry dates, replacement costs
Trang 11• Changes don’t go undetected: It provides information on all changes in the
environment which allows for investigation on other required changes like licensing eg
• Helps contingency planning: The CMDB identifies the CI’s making up a service
which helps to know what is required to restore a certain service
• Supports Release Management: When rollouts of new hardware or software
happen, information in the CMDB helps to find out what versions should be in the new release, as well as which CI’s are affected
• Improves security by controlling versions: Information on versions of CI’s are in
the CMDB so inadvertent changes to other versions becomes more difficult to go unnoticed
• Helps with impact analysis of changes: reduces the risks of implementing
Changes in the life environment
• Provides data on trends to Problem Management: Incidents affecting particular
CI’s help to find weaknesses in the IT infrastructure
4.4 Problems
• CI’s with too much detail/too little detail: causing too much work or not sufficient
control
• Implementation without design/analysis
• Overambitious schedules: making CM a bottleneck because not enough time to do
CM activities is provided
• No commitment from management: resulting in lack of control
• Perception is too bureaucratic process: resulting in trying to bypass process.
• Bypass process: for reasons of speed or malice.
• Inefficient process: because of too many manual activities
• Unrealistic expectations: CM is not a total solution
• Inflexible: Inability to process new requirements
• Isolation: implemented with no link to other processes Less effective, reducing
• HW & SW for the CMDB & DSL
• Users with access to CM system
• Customization of CM tool
• Integration with other Service Management tools
• Training and education
4.6 Reporting
Trang 124.6.1 Management Reporting
Supports Service Management activities
• Configuration audit reports
• Number of registered CI’s, versions, categories reports
• Repository capacity growth
• Change rate of CI’s in CMDB/DSL
• Backlog of CM jobs or delays caused by CM
• CM staffing issues & overtime
• Value of CI’s
• Reports on CI’s per location, business unit, service
4.6.2 Key Performance Indicators
Provides reports on how effective the process is
• Number of times the configuration is not as authorized
• Incidents/Problems tracked to wrong changes
• RFC’s that failed due to bad data in CMDB, wrong impact assessment
• Cycle time to approve/implement Changes
• Unused licenses
• Exception reports from audits
4.7 Roles & Responsibilities
4.7.1 Configuration Manager
• Develops & Implements CM policy & standards
• Evaluates existing systems and design/implementation new systems
• Proposes/agrees scope CM
• Organizes communication plan & awareness campaign
• Creates/manages the CI registration procedures
• Ensure roles & responsibilities are defined in the CM procedures
• Develops CI naming conventions and manages staff to comply with standards
• Manages interfaces with other ITIL processes and other business units
• Plans & executes population, maintenance of CMDB
• Provides reports on management and status issues
• Ensures impact analysis is possible by making sure the links between CI’s are implemented
• Ensures Changes update the CMDB
• Performs configuration audits and initiates corrective actions
• Obtain budget for having required infra and staffing taking growth of the CM process
in scope
4.7.2 Configuration librarian
• Controls receipt, identification, storage and removal of all CI’s
• Provide information on status of CI
• Assist CM manager
• Create identification scheme for CM libraries and DSL
• Create libraries to hold CI’s
Trang 13• Assist in identification of CI’s
• Maintain current status on CI’s
• Archive superceded CI’s
• Hold master copies
• Issues copies for change/review when authorized
• Maintain record on all copies issued
• Produce configuration status reports
• Assist CM audits
Trang 145 Service Desk
Function, not process
5.1 Mission Statement
The Service Desk intends:
• To be the focal point for all service requests from the business Users towards the IT organization (including 3rd party providers), and to manage them within Service Level Agreements
• To record and manage the life cycle of incidents, with an emphasis in rapid
restoration of service with minimal business impact
• To keep the User up-to-date with the status of his service request
• To provide management information on relevant topics regarding the service, like:
o Service deficiencies
o Customer training needs
o Resource usage
o Service performance & targets
• To be the window on the level of service offered by the IT organization towards the business
5.2 Activities
• Call handling.
• Recording & tracking service requests, including incidents, until closure and
verification with the User
• Request/Incident classification and initial support, including forwarding to 2nd
level, within Service Level agreements
• Keeping customer informed on request status and priority.
• Initiate escalation procedures relative to the SLA.
• Coordinating incident handling until resolution with 2nd and 3rd line support
• Helping to identify problems by recording all incidents
• Providing management information and recommendations for service
improvement
• Communication of planned changes to the Users.
5.3 Benefits
• Improvement in Customer and business service by- and perception of IT organization
• Faster response times to standard requests
• Customers better informed of progress of requests/incidents/changes
• Reduced Incident resolution times
• Improved Business & management reporting
• 2nd & 3rd level teams can work more organized, less interrupt driven
• More efficient use of resources and technology
Trang 15• More proactive and focused approach to service provision when using automated infrastructure monitoring.
5.4 Problems
• Underestimation of scale of work: implementing a Service Desk is a major Change
• No real management commitment to SD Abandoning at first sign of difficulty
(Silver Bullet lifecycle)
• Working ‘around’ the SD (or the ‘Helpless Desk).
• Not enough training for SD staff, or wrong skill set (no communication skills)
• No information provided to SD when implementing Changes or Releases,
resulting in less good service to the Business
• No alignment with business needs
5.5 Implementation considerations
• Business needs & objectives must be clear, as well as Customer requirements
• Management commitment is obtained and budget & resources is made available
• Decide on metrics of effectiveness of the Service Desk
• Investment is made for training Customers, SD staff & support teams
• Decide on the right Service Desk structure (insourced, outsourced, local, remote, virtual, customer built, off-the-shelf)
• Get professional support from outside
• Consult Customers and End Users
• Adopt a phased approach, generating quick wins Communicate them
• Measure progress
• Acknowledge it is hard work
• Advertise and sell the service
5.6 Service Desk type considerations
5.6.1 Local Service Desk
• Service Requests are logged locally
• Difficult to provide support services over multiple locations
• Duplication of skills & resources can make it expensive
• Requires common operational standards over the different SD’s
• Local skills should be known to other SD’s
• Ensure compatibility of infrastructure
• Use common management reporting metrics
• Make exchange of Incidents/Requests between SD possible
• Try to establish a logically shared database
5.6.2 Central Service Desk
• Service Requests are logged centrally
• Reduced operational costs
• Consolidated management overview
• Improved usage of available resources