7.1 Flashcards
- 1 Explain the following ITIL practices in detail, excluding how they fit within the service value chain:
a) Continual improvement (5.1.2) including:
- The continual improvement model (4.6, fig 4.3)
b) Change enablement (5.2.4)
c) Incident management (5.2.5)
d) Problem management (5.2.8)
e) Service request management (5.2.16)
f) Service desk (5.2.14)
g) Service level management (5.2.15 – 5.2.15.1)
to align the organization’s practices and services with changing business needs through the ongoing identification and improvement of services, service components, practices or any element involved in the efficient and effective management of products and services
- Encouraging continual improvement across the organization
- Securing time and budget for continual improvement
- Identifying and logging improvement opportunities
- Assessing and prioritizing improvement opportunities
- Making business cases for improvement action
- Planning and implementing improvements
- Measuring and evaluating improvement results
- Coordinating improvement activities across the organization
Change enablement
To maximize the number of successful IT changes by ensuring that risks have been properly assessed, authorizing changes to proceed, and managing a change schedule
Change - The addition, modification, or removal of anything that could have a direct or indirect effect on services
Standard changes - often initiated as service requests, but may also be operational changes. When the procedure for a standard change is created or modified there should be a full risk assessment and authorization as for any other change. This risk assessment does not need to be repeated each time the standard change is implemented, only if there is a modification to the way it is carried out.
Normal changes - Change models, based on the type of change, determine the roles for assessment and authorization. Some normal changes are low-risk, and the change authority for these is usually someone who can make rapid decisions, often using automation to speed up the change. Other normal changes are very major and the change authority could be as high as the board of management. Initiation of a normal change is triggered by the creation of a change request.
Emergency changes - not typically included in a change schedule, and the process for assessment and authorization is expedited to ensure they can be implemented quickly. As far as possible, emergency changes should be subject to the same testing, assessment and authorization as normal changes, but it may be acceptable to defer some documentation until after the change has been implemented, and sometimes it will be necessary to implement the change with less testing due to time constraints.
Incident management
To minimize the negative impact of incidents by restoring normal service operation as quickly as possible
May use self help
• May be closed by the service desk or automatic scripting
• May involve escalation to:
• Support groups (technical, horizontal, functional)
• Management (managerial , vertical, hierarchical) • Suppliers
• Major incidents may involve dedicated or temporary teams
• Service continuity may need to be invoked for extreme cases
Problem management
To reduce the likelihood and impact of incidents by identifying actual and potential causes of incidents, and managing workarounds and known errors
Problem: A cause, or potential cause, of one or more incidents
• Known error: A problem that has been analysed and has not been
resolved
• Workaround - A solution that reduces or eliminates the impact of an incident or problem for which a full resolution is not yet available. Some workarounds reduce the likelihood of incidents
Problem identification activities identify and log problems. This includes:
• Performing trend analysis of incident records
• Detection of duplicate and recurring issues by users, service desk and technical support
staff
• Major incident management identifying a risk that an incident could recur analysing
information received from suppliers and partners
• Analysing information received from internal software developers, test teams, and project
teams
Problem control should consider all contributory causes, including causes that contributed to the duration and impact of incidents, as well as those that led to the incidents happening. It is important to analyse problems from the perspective of all four dimensions of service management. For example, an incident that was caused by inaccurate documentation may require not only a correction to that documentation but also training and awareness for support personnel, suppliers and users.
Error control activities manage known errors. A known error is a problem where initial analysis is complete; it usually means that faulty components have been identified. Error control includes identification of potential permanent solutions. This may result in a change request for implementation of a solution, but only if this can be justified in terms of cost, risks and benefits. Error control regularly re-assesses the status of known errors that have not been resolved, including overall impact on customers, availability and cost of permanent resolutions, and effectiveness of workarounds. The effectiveness of workarounds should also be evaluated each time a workaround is used. Workarounds may be improved based on the assessment.
Service request management
To support the agreed quality of a service by handling all pre-defined, user-initiated service requests in an effective and user-friendly manner
Service desk
To provide a clear path for users to report issues, queries and requests, and have them acknowledged, classified, owned and actioned.
Service request - A request from a user or user’s authorized representative that initiates a service action that has been agreed as a normal part of service delivery
Service level management
- The definition, documentation and active management of service levels
- Skills include:
- Relationship management
- Business liaison
- Business analysis
- Commercial / supplier management
• Customer engagement This involves initial listening, discovery and information capture on
which to base metrics, measurement and ongoing progress discussions.
• Customer feedback This is ideally gathered from a number of sources, both formal and
informal, including:
• Surveys: Both event-based, from immediate feedback such as follow up questions
to specific incidents, and from more reflective periodic surveys that gauge feedback
on the overall service experience.
• Key business-related measures: agreed between the service provider and their
customer, based on what the customer values as important.
• Operational metrics These are the low-level indicators of various operational activities
and may include system availability, incident response and fix times
• Business metrics These can be any business activity that is deemed useful or valuable by
the customer and used as a means of gauging the success of the service.
