By Doug Tedder
Among the new concepts introduced in ITIL 4 are “practices”. A practice is defined as “a set of organizational resources designed for performing work or accomplishing an objective.” But don’t confuse a “practice” with a “process”. Why?
Many ITSM implementations based upon ITIL have been overly focused on processes. Now, don’t get me wrong – good service management needs good processes. But many ITSM implementations measured success in terms of number of processes implemented and not in terms of business value.
Processes do not equal Practices
I’ve noticed a tendency to equate ITIL 4’s 34 practices to ITIL v3’s 26 processes. But that is a misconceived notion. A practice is much more than a process. In fact, a practice may leverage many processes to accomplish its goals.
Processes transform defined inputs into defined outputs. By definition, processes have a very limited scope and function.
So, what’s the difference between ‘practices’ and ‘processes’?
First, processes support practices. Looking at it from an ITSM perspective, there likely is at least one or more ITIL (and non-ITIL based) processes involved as part of a practice to help an organization perform its work or accomplish an objective.
The practice concept introduced in ITIL 4 provides organizations with the flexibility to leverage ITIL and other approaches for accomplishing their objectives. Although seasoned ITSM practitioners already knew this, following a practice-based approach to service management allows an organization to leverage methodologies like Lean or Agile or others to deliver the outcomes and co-create needed value. Practices enable organizations to be more responsive and adaptable to change. And lastly, practices bring focus to meeting organizational objectives, not only on executing processes.
An example – the Service Desk Practice
To illustrate the difference and relationship between practices and processes, let’s consider the Service Desk practice. The traditional view is that a service desk acts as a single point of contact for incidents and services requests, following defined incident management or request management processes.
But is that all that a service desk does? Of course not.
The service desk may also conduct satisfaction surveys on behalf of the service provider. Some service desks also produce and maintain knowledge articles.
Service desks are also providing multiple channels for support, ranging from the telephone to chat to walk-up service. Some service desks provide concierge or “white glove” service to senior executives. A service desk is not only expected to log issues and requests within a workflow management system, but also use call management and other software to manage contacts with users. Agents at the service desk are expected to have good communication skills, exercise good judgement, and deliver outstanding customer service.
Emerging technologies, like chatbots, natural language processing, and robotic process automation are now assuming some of the traditional activities of a service desk.
Yet, none of these things are described in an incident management or service request process. In fact, processes alone do not adequately portray what an effective Service Desk does for an organization. And each organization may have specific work or objectives for its service desk that another organization may not.
Practices are much more than processes. The practice concept provides the right balance of flexibility and consistency demanded in a modern service management approach.