ITIL practices

The ITIL practices are those practices that the ITIL framework recognizes as practices. The ITIL definitions may differ from the others. According to the ITIL Foundation 4e by Axelos,

A practice is a set of organizational resources designed for performing work or accomplishing an objective.

In the ITIL universe, each practice supports multiple activities of the ITIL service value chain and includes resources based on the four dimensions of service management.

Trivia

Cap practice

According to the service value system developed by AXELOS Limited, the continual improvement practice caps not only the general management practices it belongs to, but also all the other practices.

Categories

• General management practices
• Service management practices
• Technical management practices

General Management Practices

General management practices have been adopted/adapted for service management from general business management domains.

15 practices

There are 15 general management practices:

1. To understand according to Bloom's taxonomy for the ITIL 4 Foundation exam:
   • Continual improvement practice
2. To recall according to Bloom's taxonomy for the ITIL 4 Foundation exam:
   • Information security management practice.
   • Relationship management practice.
   • Supplier management practice.
3. Not covered by the ITIL 4 Foundation exam:
   • Architecture management practice.
   • Knowledge management practice.
   • Measurement and reporting.
   • Portfolio management practice.
   • Organizational change management practice.
   • Project management practice.
   • Risk management practice.
   • Service financial management practice.
   • Strategy management practice.
   • Workforce and talent management practice.

Continual Improvement

Main wikipage: Continual improvement practice

The purpose of the continual improvement practice is 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.

Information Security Management

Main wikipage: Information security management practice

o The purpose of the information security management practice is to protect the information needed by the organization to conduct its business.
o Includes understanding and managing risks to:
▪ Confidentiality
▪ Integrity
▪ Availability
▪ Authentication
▪ Non-repudiation

Relationship Management

Main wikipage: Relationship management practice

o The purpose of the relationship management practice is to establish and nurture the links between the organization and its stakeholders at strategic and tactical levels.

Supplier Management

Main wikipage: Supplier management practice

o The purpose of the supplier management practice is to ensure the organization's suppliers and their performance are managed appropriately to support the provision of seamless, quality products, services and components.
o This can include creating closes, more collaborative relationships with key suppliers to uncover and realize new value and reduce risk of failure.

Service Management Practices

o Service management practices have been developed in service management and IT service management (ITSM) industries.

17 practices

There are 17 service management practices:

1. To understand according to Bloom's taxonomy for the ITIL 4 Foundation exam:
   • Change control practice.
   • Incident management.
   • Problem management practice.
   • Service desk.
   • Service level management practice.
   • Service request management practice.
2. To recall according to Bloom's taxonomy for the ITIL 4 Foundation exam:
   • IT asset management practice.
   • Monitoring and event management practice.
   • Release management practice.
   • Service configuration management practice.
   • Service continuity management practice.
3. Not covered by the ITIL 4 Foundation exam:
   • Availability management practice.
   • Business analysis practice.
   • Capacity and performance management practice.
   • Service catalogue management practice.
   • Service design practice.
   • Service validation and testing practice.

Change Control

Main wikipage: Change control practice

o The purpose of the change control practice is to maximize the number of successful IT changes by ensuring that risks have been properly assessed, authorizing changes to proceed, and managing the change schedule.

o The scope of change control is defined by each organization. It will typically include all IT infrastructure, applications, documentation, processes, supplier relationships and anything else that might directly or indirectly impact a product or service.
o A change is the addition, modification, or removal of anything that could have a direct or indirect effect on IT services.
▪ Standard
● Pre-authorized
● Implement without additional authorization
▪ Normal
● Authorization based on change type
● Low-risk, someone who can make rapid decisions
● Very major
▪ Emergency
● Expedited assessment and authority
● May be separate change authority
o The person or group who authorizes a change is known as a change authority.
▪ In high velocity organizations, it is a common practice to decentralize change approval, making the peer review a top predictor of high performance
o The change schedule is used to help plan changes, assist in communication, avoid conflicts and assign resources.

Incident Management

Main wikipage: Incident management

o The purpose of the incident management practice is to minimize the negative impact of incidents by restoring normal service operation as quickly as possible.
▪ An incident is an unplanned interruption to a service, or reduction in the quality of service.

● Incidents should be logged.
● Incidents should be managed to meet agreed target resolution times.
● Incidents should be prioritized.
o Design the incident management practice appropriately for different types of incidents
▪ Incidents based on different impact
▪ Major incidents
▪ Information security incidents
o Prioritize incidents
▪ Based on agreed classification
▪ Ensure incidents with highest business impact are resolved first
o Use a robust tool to log and manage incidents
▪ Link to configuration items, changes, problems, known errors and other knowledge
▪ Provide incident matching to other incidents, problems or known errors
o Incidents may be escalated to a support team for resolution. The routing is typically based on the incident category. Anyone working on an incident should provide quality, timely updates. Incident management requires a high level of collaboration within and between teams.
o Some organizations use a technique called swarming to help manage incidents. This involves many different stakeholders working together initially, until it becomes very clear which of them is best placed to continue and which can move on to other tasks.
▪ Collaboration can facilitate information sharing and learning as well as helping to solve the incident more efficiently and effectively.

Problem Management

Main wikipage: Problem management practice

o 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.
▪ A problem is a cause, or potential cause, of one or more incidents
▪ A known error is a problem that has been analyzed and has not been resolved.
o A workaround is 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.
▪ Workarounds are documented in problem records
▪ Workarounds can be done at any stage, it doesn't need to wait for analysis to be complete
▪ If a workaround has been documented early in problem control, then this should be reviewed and improved after problem analysis is complete
o Problem Management interacts with:
▪ Incident management
▪ Risk management
▪ Change control
▪ Knowledge management
▪ Continual improvement

Service Desk

Main wikipage: Service desk

o The purpose of the service desk practice is to capture demand for incident resolution and service requests. It should also be the entry point/single point of contact for the service provider with all of its users.
o With increased automation and the gradual removal of technical debt, the focus of the service desk is to provide support for 'people and business' rather than simple technical issues.
▪ Major influence on user experience and how the service provider is perceived by users
▪ Practical understanding of the wider organization – the empathetic link between the service provider and users
▪ The service desk can focus on excellent customer experience when personal contact is needed
▪ Support and development teams need to work in close collaboration with the service desk

o Supporting technologies for a centralized service desk
▪ Intelligent telephony systems
▪ Workflow systems
▪ Workforce management/resource planning systems
▪ Knowledge base
▪ Call recording and quality control
▪ Remote access tools
▪ Dashboard and monitoring tools
▪ Configuration management systems
o A virtual service desk allows agents to work from multiple, geographically-dispersed locations. It requires more sophisticated technology, allowing access from multiple locations and complex routing and escalation.
o The service desk may not need to be highly technical, although some are.

Service Level Management

Main wikipage: Service level management practice

o The purpose of the service level management practice is to set clear business-based targets for service performance, so that the delivery of a service can be properly assessed, monitored and managed against these targets.
o Provides the end to end visibility of the organization's services:
▪ Establishes a shared view of the services and target service levels with customers
▪ Collects, analyzes, stores and reports relevant metrics to ensure service levels are met
▪ Performs service reviews to ensure the current services continue to meet the organization and its customers' needs
▪ Captures and reports on service issues including performance against defined service levels
o A service level agreement (SLA) is a documented agreement between a service provider and a customer that identifies services required and the expected level of service.
▪ SLA is a tool to measure the performance of services from the customer's point of view.
▪ Key requirements for successful SLAs:
● Related to a defined service
● Should relate to defined outcomes, not just operational metrics
● Should reflect an agreement between the service provider and the service consumer
● Must be simply written and easy to understand for all parties
o Interacts with:
▪ Relationship management
▪ Business liaison
▪ Supplier management 

▪ Business analysis
▪ Skills and competencies
o Information Sources:
▪ Customer engagement
● Initial listening
● Discovery and information capture
● Measurement and ongoing process discussions
● Asking simple open-ended questions
▪ Customer feedback
● Surveys
● Key business-related measures
▪ Operational metrics
▪ Business metrics

Service Request Management

Main wikipage: Service request management practice

o The purpose of the service request management practice is to support the agreed quality of a service by handling all agreed user-initiated service requests in an effective and user-friendly manner.
o Service requests are pre-defined and pre-agreed and can usually be formalized with clear, standard procedures.

o Service requests are a normal part of service delivery, not a failure or degradation of service, which are handled as incidents.
o A service request is a request from a user or a user's authorized representative that initiates a service action that has been agreed as a normal part of service delivery.
§ Fulfilment of service requests may include changes to services or their components; usually these are standard changes.
o Some examples of a service request:
§ Request for a service delivery action
§ Request for information
§ Request for provision of a resource or service
§ Request access to a resource or service
§ Feedback, compliments and complaints
o Service requests and their fulfilment should be standardized and automated to the greatest degree possible,
o Opportunities for improvement should be identified and implemented to produce faster fulfilment times and take additional advantage of automation.
o Policies should be established regarding what service requests will be fulfilled with limited or even no additional approvals so that fulfilment can be streamlined.
o The expectations of users regarding fulfilment times should be clearly set, based on what the organization can realistically deliver.
o Policies and workflows are needed to redirect service requests that should actually be managed as incidents or changes.
o Some service requests require authorization according to financial, information security or other policies.
o Service request management depends on well-designed processes and procedures, which are operationalized through tracking and automation tools.
o Service requests may have simple workflows or quite complex workflows
o Steps to fulfill requests should be well-known and proven
o The service provider can agree to fulfillment times and provide clear status communication to users
o Some service requests can provide a self-service experience – completely fulfilled with automation
o Leverage existing workflow models whenever possible to improve efficiency and maintainability.

IT Asset Management

Main wikipage: IT asset management practice

o The purpose of the IT asset management practice is 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, reuse and retirement of assets
▪ Meet regulatory and contractual requirements
o An IT asset is any valuable component that can contribute to delivery of an IT product or service

Monitoring and Event Management

Main wikipage: Monitoring and event management practice

o The purpose of the monitoring and event management practice is to systematically observe a service or service component, and record and report selected changes of state identified as events.
o This practice 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.
o An event is any change of state that has significance for the management of a configuration item (CI) or IT service.

Release Management

Main wikipage: Release management practice

o The purpose of the release management practice is to make new and changed services and features available for use.

Service Configuration Management

Main wikipage: Service configuration management practice

o The purpose of service configuration management practice is to ensure that accurate and reliable information about the configuration of services, and the Cis that support them, is available when and where it is needed.
o A configuration item (CI) is any component that needs to be managed in order to deliver an IT service.

Service Continuity Management

Main wikipage: Service continuity management practice.

Technical Management Practices

o Technical management practices have been adapted from technology management domains for service management purposes by expanding or shifting their focus from technology solutions to IT services.

3 practices

There are 3 technical management practices:

1. To recall according to Bloom's taxonomy for the ITIL 4 Foundation exam:
   • Deployment management practice.
2. Not covered by the ITIL 4 Foundation exam:
   • Infrastructure and platform management practice.
   • Software development and management practice.

Deployment Management

Main wikipage: Deployment management practice

o The purpose of the deployment management practice is 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.