7 ITIL management practices
The ITIL SVS includes:
• 14 general management practices
• 17 service management practices
• 3 technical management practices.
All practices are shown in Table 7.1. They are subject to the four dimensions of service management (see Figure 4.1).
Candidates must be able to recall the purpose of the practices listed in Table 7.2, plus those stated in section 7.3, where covered under the practice description.
Table 7.1 The ITIL management practices
General management practices |
Service management practices |
Technical management practices |
Architecture management Continual improvement Information security management Knowledge management Measurement and reporting Organizational change management Portfolio management Project management Relationship management Risk management Service financial management Strategy management Supplier management Workforce and talent management |
Availability management Business analysis Capacity and performance management Change enablement Incident management IT asset management Monitoring and event management Problem management Release management Service catalogue management Service configuration management Service continuity management Service design Service desk Service level management Service request management Service validation and testing |
Deployment management Infrastructure and platform management Software development and management |
Table 7.2 Purpose statements for the key ITIL management practices
Information security management |
To protect the information needed by the organization to conduct its business, including understanding and managing risks to the confidentiality, integrity, and availability of information, plus other aspects such as authentication (ensuring someone is who they claim to be) and non-repudiation (ensuring that someone can’t deny that they took an action). |
Relationship management |
To establish and nurture the links between the organization and its stakeholders at strategic and technical levels, including identification, analysis, monitoring, and continual improvement of relationships with and between stakeholders. |
Supplier management |
To ensure that the organization’s suppliers and their performances are managed appropriately to support the seamless provision of quality products and services, including creating closer, more collaborative relationships with key suppliers to uncover and realize new value and reduce the risk of failure. |
IT asset management |
To plan and manage the full lifecycle of all IT assets, to help the organization: • maximize value • control costs • manage risks • support decision-making about purchase, re-use, retirement, and disposal of assets • meet regulatory and contractual requirements. |
Monitoring and event management |
To systematically observe services and service components, and to record and report selected changes of state identified as events. It identifies and prioritizes infrastructure, services, business processes, and information security events, and establishes the appropriate response to those events, including responding to conditions that could lead to potential faults or incidents. |
Release management |
To make new and changed services and features available for use. |
Service configuration management |
To ensure that accurate and reliable information about the configuration of services, and the configuration items (CIs) that support them, is available when and where needed, including information on how CIs are configured and the relationships between them. |
Deployment management |
To move new or changed hardware, software, documentation, processes, or any other component to live environments. It may also be involved in deploying components to other environments for testing or staging. |
Candidates must be able to recall the definition of the terms listed in Table 7.3, plus those stated in section 7.3, where defined under the practice description.
Table 7.3 Definition of terms for the ITIL management practices
IT asset |
Any financially valuable component that can contribute to the delivery of an IT product or service. |
Event |
Any change of state that has significance for the management of a service or other CI. Events are typically recognized through notifications created by an IT service, CI, or monitoring tool. |
Configuration item |
Any component that needs to be managed in order to deliver an IT service. |
7.3 Understanding the ITIL management practices
Candidates need to have an understanding of the ITIL practices described in this section.
Purpose
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.
Definition: Continual improvement register (CIR)
A structured document or database used to track and manage improvement ideas from identification through to final action.
Included in the scope of the continual improvement practice is the development of improvement-related methods and techniques, and the propagation of a continual improvement culture across the organization, in alignment with its overall strategy. It is vitally important that everybody, every part of the organization and every undertaking, is concerned with identifying improvement opportunities. If this isn’t the case, then dealing with daily operational concerns and issues will eclipse continual improvement efforts.
Continual improvement is embedded within the ITIL service value system (see Chapter 5). The SVS also includes the continual improvement model (see Figure 7.1), which gives a structure to continual improvement and helps to identify improvement opportunities, from high-level organizational changes to changes to individual services and CIs.
Figure 7.1 The continual improvement model
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
• making business cases for improvement action and looking at the return on investment (ROI)
• planning and implementing improvements
• measuring and evaluating improvement results
• coordinating improvement activities across the organization.
There are many methods, models, and techniques that can be employed for making improvements. Examples of these techniques include SWOT (strengths, weaknesses, opportunities, and threats) analysis, a balanced scorecard review, and internal and external assessments and audits.
There are numerous approaches to continual improvement including Lean methods, which focus on eliminating waste; Agile methods, which focus on making incremental improvements; and DevOps methods, which work holistically and ensure that improvements are not only designed well but applied effectively.
Although there are several methods available, organizations should not try to formally commit to too many different approaches. It is a good idea to initially select a few key methods that are appropriate, and cultivate those methods. In this way, teams will have a shared understanding of how to work together on improvement opportunities. Later the organization may want to try new approaches or allow for innovation.
Continual improvement is everyone’s responsibility. It is recommended that a small team is dedicated to leading continual improvement efforts and advocating the practice across the organization. Although this team will focus on this work full-time, it is critical that everyone in the organization understands that active participation in continual improvement activities is a core part of their job. This includes the highest level of the organization, responsible for embedding continual improvement into the way people think and work. In other words: ensuring that a key part of the organization’s culture is not settling for the status quo, but is continually looking for ways to do things better or to be more cost-effective.
To ensure that this is more than a good intention, it is wise to include contribution to continual improvement in all job descriptions and every employee’s objectives, and in contracts with external suppliers and contractors.
Suppliers also have a responsibility for improvement. A contract with a supplier should include details of how it will measure, report on, and improve its services over the life of the contract.
The continual improvement practice should be supported by relevant data sources and data analysis to ensure that each potential improvement is sufficiently understood. CIRs are used to document and prioritize these improvement ideas. As new ideas are documented, CIRs are constantly reprioritized. The use of CIRs provides additional value because they help to make things visible. This is not limited to what is currently being done, but also to what is already complete and what has been set aside for further consideration later.
The continual improvement practice is integral to the development and maintenance of every other practice, as well as to the complete lifecycle of all services and the SVS. In particular, the problem management practice can uncover issues that will be managed through continual improvement. The changes initiated through continual improvement may fail without the critical contributions of the organizational change management practice, and many improvement initiatives will use project management practices to organize and manage their execution.
Table 7.4 summarizes how the ITIL guiding principles relate to the continual improvement practice.
Table 7.4 Key ITIL guiding principles in continual improvement
Focus on value |
Looking to identify and improve value from every perspective is the core driver for continual improvement |
Start where you are |
Step 2 of the continual improvement model is ‘Where are we now?’; all improvements should be based on this premise |
Progress iteratively with feedback |
It is not possible to do everything at once, so it is imperative that we use feedback before, throughout, and after each iteration, to ensure that actions are focused and appropriate |
Collaborate and promote visibility |
Continual improvement is everyone’s responsibility; working together across boundaries produces results that have greater buy-in, more relevance to objectives, and better likelihood of long-term success |
Think and work holistically |
No service, product, or improvement initiative stands alone |
Keep it simple and practical |
Always use outcome-based thinking to produce practical solutions that deliver results |
Optimize and automate |
For all improvement opportunities, resources of all types, particularly human resources, should eliminate anything that is truly wasteful and use technology to achieve results wherever possible |
Purpose
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.
Definition: Change
The addition, modification, or removal of anything that could have a direct or indirect effect on services.
The scope of change enablement includes all IT infrastructure, applications, documentation, processes, supplier relationships, and anything else that might directly or indirectly impact a product or service.
The organizational change management practice focuses on the people aspects of change, to ensure that organizational transformation changes are implemented successfully. Typically, change enablement focuses on changes to products and services.
Change enablement balances the need to make beneficial change (delivering additional value) with the need to protect customers and users (potentially adverse impacts of change).
All changes should be assessed to determine their risks and expected benefits for the organization. All changes must be authorized, in an appropriate timeframe, before deployment.
The person or group that authorizes a change is known as the change authority. Different change authorities should be assigned to each type of change. It is essential that the correct change authority is assigned to each type of change, to ensure that change enablement is both efficient and effective.
There are three types of change that are each managed in different ways.
• Low-risk, pre-authorized changes that are well understood and fully documented, and can be implemented without requiring additional authorization.
• They have accepted and established steps to implement, typically initiated as service requests or operational changes.
• Procedures for standard change should undergo a full risk assessment and authorization when being created or modified, as for any other change; this risk assessment does not need to be repeated each time the standard change is implemented.
• Changes that need to be scheduled, assessed, and authorized.
• Change models based on the type of change determine the roles for assessment and authorization. To illustrate:
• Some normal changes can be low risk, where the change authority is someone who can make rapid decisions, often using automation to speed up the change.
• Some normal changes can be very major, where the change authority is the management board (or equivalent).
• Initiation is triggered by the creation of a change request, done either manually or by an automated pipeline. If automated, this will normally cover most steps of the change enablement process.
• Changes that must be implemented as soon as possible; for example, to resolve an incident or implement a security patch.
• Not typically included in a change schedule.
• Assessment and authorization are expedited to ensure they can be implemented quickly.
• Wherever possible, emergency changes should be subject to the same testing, assessment, and authorization as normal changes. However, it may be acceptable and necessary to:
• defer some documentation until after implementation
• implement with less testing due to time constraints.
• A separate change authority for emergency changes may be established, e.g. a limited group of senior managers with an understanding of the associated business risks.
• These are perceived as risky, and so should be kept to an absolute minimum.
The change schedule helps to plan change, support communication, avoid conflict, and assign resources. After changes have been deployed, it can provide the information needed for incident management, problem management, and improvement planning. Communication of the changes is vitally important to ensure people are fully prepared before they are deployed.
Table 7.5 summarizes how the ITIL guiding principles relate to the change enablement practice.
Table 7.5 Key ITIL guiding principles in change enablement
Focus on value |
The key aspect of change approval is the value that the change will create Create value for users by initiating and implementing improvement changes with minimum impact and disruption to normal service |
Collaborate and promote visibility |
Working with many groups is required for change enablement to be successful |
Think and work holistically |
Understand potential impacts of change across other services and environments |
Keep it simple and practical |
Translate technical terms to make changes easy to understand for non-technical audiences |
Optimize and automate |
Use automation wherever possible, especially for standard changes |
Purpose
To minimize the negative impact of incidents by restoring normal service operation as quickly as possible.
Definitions
• Incident An unplanned interruption to a service or reduction in the quality of a service.
• Major incident An incident with significant business impact, requiring an immediate coordinated resolution. It is typically managed using separate processes. IT security incidents often fall into this category.
Incident management can be the key to high levels of customer and user satisfaction – there are proven correlations between speed and effectiveness of recovery after failure and satisfied customers and users.
All incidents should:
• Be logged in an incident record Logging ensures that incidents remain visible and are more easily managed.
• Have a target resolution time Target resolution times are:
• agreed and documented, often in service level agreements
• communicated to ensure that stakeholder expectations for service restoration are realistic.
• Have a priority assigned Agreement on priorities ensures that incidents with the highest business impact are resolved first. To aid management and avoid over-consumption of resources, low-impact incidents must be managed efficiently.
• Be linked to other service management artefacts Linking incidents to related CIs, changes, problems, known errors, and other knowledge enables quick and efficient diagnosis and recovery.
Tip 
Use IT service management tools to allow automated matching of incidents to other incidents, problems, or known errors.
• Have visibility through communication Good-quality updates should be provided in a timely fashion to stakeholders, including information about symptoms, current and likely business impacts, other services or CIs affected, any actions completed, and those that are planned. Tools typically timestamp and provide information about the people involved, so that all stakeholders can be kept informed.
• Be properly diagnosed and have a resolution applied Incidents may be diagnosed and resolved by many different groups internal and/or external to the organization, depending on the complexity of the issue or the incident type. All groups need to understand their role in the incident management process. Incidents may be diagnosed and resolved in a number of ways including:
• resolution by the users themselves, using self-help capabilities
• resolution by the service desk
• escalation to a support team for more complex incidents, routing to the teams based on a category established when the incident is first recorded
• escalation to suppliers or partners, who support their products and services
• collaboration through temporary teams, including representatives of many stakeholders (service provider, suppliers, users, etc.), working on the highest-complexity incidents and all major incidents
• invocation of disaster recovery plans, in the most extreme cases, for incident resolution, via the service continuity management practice.
Tip
Organizations are now using swarming for incident resolution, a technique that involves many different stakeholders working together initially, until it becomes clear which of them is best placed to resolve the incident.
Table 7.6 summarizes how the ITIL guiding principles relate to the incident management practice.
Table 7.6 Key ITIL guiding principles in incident management
Focus on value |
Prioritize and resolve the incidents with the highest business impact |
Start where you are |
Ensure that previous or existing incident investigation information (known errors, incident resolutions etc.) is used to help resolve incidents |
Collaborate and promote visibility |
Record and update incident records for knowledge sharing. A high level of collaboration within and between teams through techniques, such as swarming, is vital to successful incident resolution. |
Optimize and automate |
Allow simple incidents to be resolved with the minimum of effort. Enables effective incident logging, matching with known errors and running scripts for automated incident resolution. |
Purpose
To reduce the likelihood and impact of incidents by identifying actual and potential causes of incidents, and managing workarounds and known errors.
Definitions
• Problem A cause, or potential cause, of one or more incidents.
• Known error A problem that has been analysed but 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 management is responsible for investigating the underlying causes of incidents and, where possible, proactively preventing incidents from occurring. It is imperative that these underlying causes are investigated to reduce, or ideally eliminate, recurring incidents.
There is a close relationship between the incident management and problem management practices, but it is important to differentiate between them, as incidents and problems are managed in different ways. Incident management focuses on restoring normal service as quickly as possible. However, problem management creates workarounds for the incident management practice to use, documents known errors and, where possible, prevents incidents from happening, or prevents or reduces the impact of the incidents that occur.
Figure 7.2 The phases of problem management
Problem management involves three distinct phases, as shown in Figure 7.2.
7.3.4.1 Problem identification
Problem identification activities identify and log problems, including:
• performing trend analysis of incident records
• detecting duplicate and recurring issues by users, service desk, and technical support staff
• during major incident management, identifying any risk that an incident could recur
• analysing information from suppliers and partners
• analysing information from internal software developers, test teams, and project teams.
Activities include problem analysis, and documenting workarounds and known errors.
Problems are prioritized for analysis based on potential impact and probability. It is not essential to analyse every problem; it is more valuable to make significant progress on the highest-priority problems than to investigate every minor problem.
Problem control should consider all contributory causes of incidents, including causes that initiate them, and those that contribute to their duration and impact. Problems should be analysed from the perspectives of all four dimensions of service management.
When a problem cannot be resolved quickly, identifying and documenting a workaround is useful so that the service desk and incident management practices can restore normal service more quickly after an incident occurs.
Where resolving the problem is not viable from a technical or financial perspective and the impact is not causing major business disruption, an effective incident workaround can provide a permanent way of dealing with incidents. In this case, the known error record remains open indefinitely, or possibly until a future release.
Error control occurs when a fix for an error is known and a permanent solution is required due to its impact; or when a workaround has been documented and a decision has been made not to live with the workaround.
Error control activities include identification of potential permanent solutions that 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 a workaround should be re-evaluated each time it is used, as the workaround may be improved based on the assessment.
As well as the incident management practice, problem management activities closely interface with risk management to identify, assess, and control risk; and with change enablement to initiate changes to eliminate problems, and to take part in post-implementation reviews. Problem management solutions can be treated as improvement opportunities, and may be documented in the CIR and a knowledge management system.
Problem management activities often rely on the knowledge and experience of staff, rather than detailed procedures. To diagnose problems, staff often need to understand complex systems and to consider how failures might have occurred. This analytical and creative ability requires training, mentoring, and experience.
Table 7.7 summarizes how the ITIL guiding principles relate to the problem management practice.
Table 7.7 Key ITIL guiding principles in problem management
Focus |
on value Identify the problem resolutions that give the greatest return on investment |
Start where you are |
Ensure that previous root-cause investigations are considered each time |
Collaborate and promote visibility |
Identify the causes of incidents by working with internal teams across multiple practices, and with external organizations |
Think and work holistically |
Use the four dimensions of service management to ensure coordination of all aspects of an improvement initiative |
Optimize and automate |
Use automation wherever possible to identify problems and document workarounds |
7.3.5 Service request management
Purpose
To support the agreed quality of a service by handling all predefined, user-initiated service requests in an effective and user-friendly manner.
Definition: Service request
A request from a user or a user’s authorized representative that initiates a service action which has been agreed as a normal part of service delivery.
Service requests are pre-defined and pre-agreed as a normal part of service delivery. They can usually be formalized, with a clear, standard procedure for initiation, approval, fulfilment, and management. Service requests are not a failure or degradation of a service, which are handled as incidents.
The steps to fulfil the request should be well known and proven. This allows the service provider to agree times for fulfilment, and to provide clear communication of the status of the request to users.
Service requests and their fulfilment should be standardized and automated to the greatest degree possible. However, some service requests may require authorization due to financial or security restrictions.
Each service request may include one or more of the following:
• request for a service delivery action, e.g. providing a report or replacing a toner cartridge
• request for information, e.g. how to undertake a task or answer a query (such as what the office opening hours are)
• request for provision of a resource or service, e.g. providing a phone to a user, or providing a virtual server for a development team
• request for access to a resource or service, e.g. providing user access to a system
• feedback, compliments and complaints.
Table 7.8 summarizes how the ITIL guiding principles relate to the service request management practice.
Table 7.8 Key ITIL guiding principles in service request management
Focus on value |
Create value for the users by streamlining and expediting the handling of straightforward, recurring requests |
Collaborate and promote visibility |
Work with various teams to ensure successful fulfilment of service requests |
Think and work holistically |
Understand service offerings across the organization, allowing a holistic view of what can be updated or improved |
Keep it simple and practical |
Service requests should be simple to set up and to implement |
Optimize and automate |
Automate the practice wherever possible |
Purpose
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 single point for users to report issues, queries, and requests, and where they are acknowledged, classified, owned, and actioned. As such, the service desk significantly influences user experience and users’ perceptions of the service provider.
Types of service desk range from a team of people physically co-located to a distributed mix of people connected virtually, and to automated technology and bots. The function and value of the service desk remain the same, regardless of the model. It is increasingly the provider of a total support service for the organization, rather than being the place where only technical issues are logged. To deliver such a service, the service desk requires a practical understanding of the wider business context, the business processes, and the users.
Tip
Ensure the service desk understands the business context of the incidents and service requests it deals with. For example, rather than a broken printer being the issue, the real business impact is the inability to use a report that cannot be produced.
7.3.6.1 Service desk access channels
Service desks provide a variety of channels for access. Those used by an organization are defined by factors such as user preferences, corporate culture, value, and technological feasibility. These include:
• Phone calls Includes specialized technology, such as interactive voice response (IVR), conference calls, and voice recognition.
• Portals and mobile applications Supported by service and request catalogues and knowledge bases.
• Chat Live chat and chatbots.
• Email Supports logging, updating, follow-up surveys, and confirmations.
• Walk-in service desks Popular where hands-on support is required.
• Text and social media messaging Useful for major incident notifications and contacting specific stakeholder groups.
• Public and corporate social media and discussion forums Enables service provider contact and peer-to-peer support.
7.3.6.2 Service desk organization and tools
Some service desks limit when service cover is available; for example, 06.00–18.00, Monday–Saturday. Staff typically work in shift patterns to provide consistent support levels across service hours.
Centralized service desks work in a single location, requiring technology support, including:
• intelligent telephony systems – computer-telephony integration, IVR, and automatic call distribution
• workflow systems for routing and escalation
• collaboration tools
• workforce management and resource planning systems
• knowledge base
• call recording and quality control
• remote access tools
• dashboard and monitoring tools
• configuration management systems.
Virtual service desks allow agents to work from multiple locations, often using cloud-based solutions. This requires all of the functionality of the centralized service desk technology, with additional elements to satisfy more complex routing, collaboration, and escalation.
7.3.6.3 Service desk staff training requirements
A range of training and competencies is required across technical and business areas. The ideal service desk staff member is able to use available skills, knowledge, people, and processes to:
• understand and diagnose an incident, in terms of business priority
• take appropriate action to resolve it.
Key competencies required include:
• excellent customer service skills, such as empathy
• incident analysis and prioritization
• effective communication
• emotional intelligence.
Table 7.9 summarizes how the ITIL guiding principles relate to the service desk practice.
Table 7.9 Key ITIL guiding principles for the service desk
Focus on value |
Encompasses many perspectives, including the experience of customers and users, with the service desk in prime position to influence this. |
Collaborate and promote visibility |
No matter how efficient the service desk is, there will always be issues that need escalation to and from other teams, both internally and externally. Support and development teams need to work in close collaboration with the service desk to deliver a ‘joined up’ approach to users and customers. |
Think and work holistically |
Deliver service desks through effective and efficient management, and dynamic integration of information, technology, organization, people, practices, partners, and agreements, which should all be coordinated to provide a defined value. |
Optimize and automate |
Increased automation (e.g. artificial intelligence, robotic process automation, and chatbots) allows service desks to provide more self-service logging and resolution via online portals and mobile applications. The impact of removing some telephone contacts and low-level work enables more focus when personal contact is needed, driving improved customer experience. |
7.3.7 Service level management
Purpose
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.
Definitions
• Service level One or more metrics that define expected or achieved service quality.
• Service level agreement A documented agreement between a service provider and a customer that identifies both services required and the expected level of service.
Service level management provides end-to-end visibility of an organization’s services by:
• establishing a shared view of the services and target service levels with customers
• ensuring that, for identified services, defined service levels are met through the collection, analysis, storage, and reporting of relevant metrics
• performing service reviews to ensure the current services continue to meet the needs of the organization and its customers
• capturing and reporting on service issues, including performance against defined service levels.
Skills and competencies required for service level management include relationship management, business liaison, business analysis, and commercial/supplier management. A pragmatic focus on the whole service is required, as well as its constituent parts; for example, basic component metrics (such as percentage system availability) do not represent the whole service.
Successful service level agreements (SLAs):
• relate to a defined service in the service catalogue
• relate to defined outcomes, not just operational metrics; they are often achieved with balanced bundles of metrics, e.g. customer satisfaction and key business outcomes
• reflect an ‘agreement’, i.e. engagement and discussion between the service provider and service consumer, involving all stakeholders (e.g. partners, sponsors, users, and customers)
• are simply written and easy for all parties to understand and use.
It is important to be careful using single-system-based metrics, as targets can result in misalignment and a disconnect between service partners regarding the success of the service delivery and the user experience. For example, a service provider can successfully meet an SLA based only on the percentage of uptime of a service; but if the downtime occurs during a business-critical period, significant business outcomes are lost, leading to poor or failing customer perception. This is referred to as the ‘watermelon SLA’ effect.
Service level management requires focus and effort to engage and listen to the requirements, issues, concerns, and daily needs of customers:
• Engagement To understand and confirm the actual ongoing needs of customers
• Listening For relationship-building and trust-building, to show customers they are valued and understood, helping to move the provider from always operating in a ‘solution mode’ towards building new, more constructive partnerships.
The activities of engaging and listening help to build improved relationships, and to focus on what really needs to be delivered. They also give service delivery staff an experience-based understanding of the day-to-day work that the business does with its technology, enabling them to deliver a more business-focused service.
Service level management collates and analyses information from several sources:
• Customer engagement Initial listening, discovery, and information capture to determine metrics and measurement; ongoing progress discussions.
• Customer feedback Gathered from multiple sources, both formal and informal, including surveys and key business-related measures. These measures are agreed between the service provider and the customer, based on what the customer values as important (e.g. a set of SLA metrics or a specific business activity).
• Operational metrics Low-level indicators of various operational activities, e.g. system availability, incident response and fix times, change and request processing times, and system response times.
• Business metrics Any business activity deemed useful or valuable by the customer and used as a means of gauging the success of the service, ranging from simple measures (e.g. ATM availability) to successful completion of business activities (e.g. passenger check-in).
Once the feedback is gathered and collated for ongoing review, it can be used as input to design suitable measurement and reporting models and practices.
Table 7.10 summarizes how the ITIL guiding principles relate to the service level management practice.
Table 7.10 Key ITIL guiding principles in service level management
Focus on value |
Establish agreements that ensure value is created for the service consumer and service provider |
Start where you are |
When creating SLAs, initially agree targets that have already been accepted as meeting requirements |
Progress iteratively with feedback |
The service review is an important aspect of service level management, where opportunities for improvement can be identified |
Collaborate and promote visibility |
Many different groups are involved in agreeing and achieving SLAs |
Think and work holistically |
The outcomes achieved by the service provider and service consumer will suffer unless the organization works on the service as a whole, not just on its own parts |
Keep it simple and practical |
It is important that everyone can understand the requirements |
Optimize and automate |
Automate monitoring and reporting wherever possible |