CHAPTER 11: ITIL PRACTICES INTRODUCED
“A practice is a set of organizational resources designed for performing work or accomplishing an objective.”
Each ITIL practice supports multiple service value chain activities. Practices are made up by resources from the four dimensions of service management:
•Organizations and people
•Information and technology
•Partners and suppliers
•Value streams and processes
The ITIL SVS features 34 practices:
•14 general management practices
•17 service management practices
•3 technical management practices
Table 21: ITIL Practice Types
| General management practice | These practices are adopted and adapted for service management from business management. |
| Service management practice | These practices have originated and developed in service management and ITSM. |
| Technical management practice | These practices originated in technology management and have been adapted for service management. |
In the following chapters we will look at the 34 practices in more detail, including practice considerations based on the author’s experiences working in ITSM. Remember that these practices are part of the ITIL SVS.
From processes to practices
One of the notable changes that has taken place in the evolution from ITIL v3 to ITIL 4 is a shift in terminology from ‘processes’ to ‘practices’.
The ITIL definition of a practice is:
“A set of organizational resources designed for performing work or accomplishing an objective.”
The ITIL definition of a process is:
“A set of interrelated or interacting activities that transform inputs into outputs. A process takes one or more defined inputs and turns them into defined outputs. Processes define the sequence of actions and their dependencies.”
This change will have an impact on many ITSM organisations that are used to thinking in terms of processes (for example, an incident management process), and assigning roles, creating procedures, etc. within a process framework. The change from processes to practices is partly driven by a need to address a criticism often levelled at ITIL – that it is bureaucratic, inflexible and doesn’t integrate with newer ways of working like Agile and DevOps that are gaining popularity in IT. ITIL 4 encourages organisations to think beyond process workflows and, for each practice area, to consider:
•Suppliers and partner relationships
•Roles, skills and competencies
•Continual improvement
•Information and data
•Supporting technology and toolsets
•Metrics, measurement and reporting
•Interfaces
Processes, procedures and policies still have relevance but are now part of a wider practice-based perspective.
What does this mean for organisations that have an established, process-driven approach for ITSM? As with any organisational change, it certainly doesn’t mean creating massive upheaval for no reason. ITSM teams can analyse whether their processes are effective and look at the broader practice perspective as part of their regular process improvement analysis activities. Look for opportunities to make an improvement, but don’t make changes for the sake of it.
The common sense, good practices for ITSM processes are still relevant; here’s a reminder. Processes should be:
•Closed-loop systems
•Documents and shared
•Directed by policies
•Reusable
To be effective, service management processes should be set up as closed-loop systems. This means that they should request feedback and use it to improve the way they perform. If processes don’t work on this closed-loop model, they will not improve, and no lessons will be learned. From an ITIL 4 perspective, the process feedback is used holistically to make improvements across the SVS; processes do not operate in isolation.
Processes should also be documented so they can be shared and used throughout an organisation. If there isn’t a definitive agreed version of a process, different teams will carry out the activities in different ways – all of them believing they are following the process properly.
Processes are directed by policies. Policies are used to document management expectations and their intentions for the process. The policy is then used to make sure the process development and implementation is done in a way that is consistent with management intentions. From an ITIL 4 perspective, policies will be driven by governance and principles defined as part of the SVS.
Within service management, one of the ways that processes deliver value is by being reusable. This means, for example, that one change enablement process can be used across the organisation, rather than each programme or project developing its own change enablement process. Reusable processes can be measured, monitored and improved.
Process models
To support organisational understanding of processes, we can document them using a process model. A process model is a way of designing and mapping a process and can be effective if you need to develop a new process or update an existing one. Figure 10 shows a simplified process model.
Every process must have inputs and outputs. An input triggers a process, for example, a call to a service desk will start the fault resolution or diagnostic process.
Outputs mean the iteration of the process is complete and it has served its purpose. As part of the output, the process requests feedback, which makes sure it is working as a closed loop – learning lessons about how it is working and its level of customer satisfaction.
Activities that need to happen to turn the input into an output are documented in the ‘activities’ box. These activities might include roles, procedures, workflows and metrics.
Process controls should also be in place to make sure the process works properly and doesn’t become ineffective over time. Controls could include nominating a process owner, checking the process’ alignment with policy and principles, and checking the feedback received.
Figure 10: A simple process model
Process enablers is a term used to describe the resources that we use to make the process work, for example, technology or people. A perfect process will deliver no value if there aren’t enough resources to implement it.
Remember: a process model doesn’t have to be complicated. You can start by brainstorming the process with a group of stakeholders. This will help you document the right steps, so that they can be agreed. Once a common process is defined and agreed, you can automate it using a service management toolset, if appropriate. Process models are also useful for education, as they are a quick and easy way to explain a process to staff members. You will notice that this is similar to the value stream mapping exercise we described in earlier chapters. Both process modelling and value stream mapping are useful ways to make work visible, helping to get consensus from stakeholders and identify issues and bottlenecks.
Have a go: why not draw your own process model? Incident management and change enablement are great places to start.