Understand 7 ITIL practices Flashcards
Explain Continual improvement in detail
The purpose of the continual improvement practice is to align the organization’s practices and services with changing business needs through the ongoing improvement of products, services, and practices, or any element involved in the management of products and services.
Key activities that are part of continual improvement practices include:
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.
Explain Change enablement in detail
The purpose of the change enablement practice is to maximize the number of successful service and product changes by ensuring that risks have been properly assessed, authorizing changes to proceed, and managing the change schedule.
There are three types of change that are each managed in different ways:
Standard changes These are low-risk, pre-authorized changes that are well understood and fully documented, and can be implemented without needing additional authorization. They are 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; it only needs to be done if there is a modification to the way it is carried out.
Normal changes These are changes that need to be scheduled, assessed, and authorized following a process. 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 management board (or equivalent). Initiation of a normal change is triggered by the creation of a change request. This may be created manually, but organizations that have an automated pipeline for continuous integration and continuous deployment often automate most steps of the change enablement process.
Emergency changes These are changes that must be implemented as soon as possible; for example, to resolve an incident or implement a security patch. Emergency changes are 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. There may also be a separate change authority for emergency changes, typically including a small number of senior managers who understand the business risks involved.
Explain Incident management in detail
The purpose of the incident management practice is to minimize the negative impact of incidents by restoring normal service operation as quickly as possible.
Incidents may be diagnosed and resolved by people in many different groups, depending on the complexity of the issue or the incident type. All of these groups need to understand the incident management process, and how their contribution to this helps to manage the value, outcomes, costs, and risks of the services provided:
Some incidents will be resolved by the users themselves, using self-help. Use of specific self-help records should be captured for use in measurement and improvement activities.
Some incidents will be resolved by the service desk.
More complex incidents will usually be escalated to a support team for resolution. Typically, the routing is based on the incident category, which should help to identify the correct team.
Incidents can be escalated to suppliers or partners, who offer support for their products and services.
The most complex incidents, and all major incidents, often require a temporary team to work together to identify the resolution. This team may include representatives of many stakeholders, including the service provider, suppliers, users, etc.
In some extreme cases, disaster recovery plans may be invoked to resolve an incident. Disaster recovery is described in the service continuity management practice (section 5.2.12).
Explain problem management in detail
The purpose of the problem management practice is to reduce the likelihood and impact of incidents by identifying actual and potential causes of incidents, and managing workarounds and known errors.
Problem identification activities identify and log problems. These include:
performing trend analysis of incident records
detection of duplicate and recurring issues by users, service desk, and technical support staff
during 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.
Explain service request management in detail
The purpose of the service request management practice is to support the agreed quality of a service by handling all pre-defined, user-initiated service requests in an effective and user-friendly manner.
Each service request may include one or more of the following:
a request for a service delivery action (for example, providing a report or replacing a toner cartridge)
a request for information (for example, how to create a document or what the hours of the office are)
a request for provision of a resource or service (for example, providing a phone or laptop to a user, or providing a virtual server for a development team)
a request for access to a resource or service (for example, providing access to a file or folder)
feedback, compliments, and complaints (for example, complaints about a new interface or compliments to a support team).
Explain service desk in detail
The purpose of the service desk practice is to capture demand for incident resolution and service requests. It should also be the entry point and single point of contact for the service provider with all of its users.
Service desks provide a variety of channels for access. These include:
phone calls, which can include specialized technology, such as interactive voice response (IVR), conference calls, voice recognition, and others
service portals and mobile applications, supported by service and request catalogues, and knowledge bases
chat, through live chat and chatbots
email for logging and updating, and for follow-up surveys and confirmations. Unstructured emails can be difficult to process, but emerging technologies based on AI and machine learning are starting to address this
walk-in service desks are becoming more prevalent in some sectors, e.g. higher education, where there are high peaks of activity that demand physical presence
text and social media messaging, which are useful for notifications in case of major incidents and for contacting specific stakeholder groups, but can also be used to allow users to request support
public and corporate social media and discussion forums for contacting the service provider and for peer-to-peer support.
Explain service level management in detail
The purpose of the service level management practice is to set clear business-based targets for service levels, and to ensure that delivery of services is properly assessed, monitored, and managed against these targets.
Service level management provides the end-to-end visibility of the organization’s services. To achieve this, service level management:
establishes a shared view of the services and target service levels with customers
ensures the organization meets the defined service levels through the collection, analysis, storage, and reporting of the relevant metrics for the identified services
performs service reviews to ensure that the current set of services continues to meet the needs of the organization and its customers
captures and reports on service issues, including performance against defined service levels.
Service level agreements (SLAs) have long been used as a tool to measure the performance of services from the customer’s point of view, and it is important that they are agreed in the wider business context. Using SLAs may present many challenges; often they do not fully reflect the wider service performance and the user experience.
