Skip to main content

Who Moved My Process?

There are some misconceptions about ITIL® 4 and its use of the term ‘practice’ vs. ‘process’ as a component of its recently introduced service value system.

One misconception is that processes aren’t important anymore. Another is that organizations think they must completely redesign their tools in order to accommodate this change. Neither is true.

Let’s begin by taking a look at how ITIL 4 defines these terms.

Process: a set of interrelated or interacting activities that transform inputs into outputs [to accomplish an objective]. Processes define the sequence of actions and their dependencies.

Practice: a set of organizational resources designed for performing work or accomplishing an objective. Practices include resources based on the four dimensions of service management which include: organizations and people, information and technology, partners and suppliers, and value streams and – wait for it – processes.  

Both processes and practices focus on achieving an objective. Processes define specifically how to achieve that objective using well-defined, standardized procedures. Practices look more holistically at the capabilities needed to achieve that objective.

With processes, the goal is to continually improve efficiency and effectiveness by defining specifically how work gets done. A good thing…sometimes.

With practices, the goal is to create a learning organization where people are continually refining their capabilities in areas such as analysis and observation, decision making and leveraging all available sources of information. A good thing…always.

You can think about this as a continuum. On one end you have clearly defined processes, supported by structured information, that spell out – step-by-step – how to perform a set of activities. On the other end, you have a more loosely defined approach to work that leaves the specifics up to the people who have the knowledge and skills to do that work.

There are times when processes are appropriate. But they can also get in the way. Let’s walk through an example. If a user contacts the service desk to report an incident, it is absolutely critical to have a process that defines how the contact is handled and how the incident gets recorded. This process enables the contact to be handled efficiently (thus putting the user at ease) and ensures the structured information needed to handle the incident is captured (thus preventing a bunch of rework downstream).

Where we go from there, however, may vary. Sometimes it’s clear how to handle the incident, whether at the service desk or by escalating it to the appropriate support team. With complex systems, however, it’s not always that easy. If the failing component is unclear, using a traditional tiered escalation approach (and possibly having the incident bounce around for a while until it lands in the right team) will only elongate the process. Here’s where an approach such as swarming comes in to play. Swarming involves many different stakeholders working together until it becomes clear how to proceed. It’s an approach that is more loosely defined and that relies on skilled professionals using their knowledge and experience to make judgment calls about what to do and who should do it.

If the notion of ‘loosely defined’ scares you, rest assured it doesn’t mean there aren’t ground rules for how work is handled. Here’s where principles-based thinking comes into play. But principles-based thinking is a conversation for another day. Back to practices and processes.

Processes will always be important and when used appropriately, free humans up for activities that require experience and judgment. They are effectively supported by tools and can often even be automated. It’s when we start to think an existing process, or some ‘best practice’ view of a process, is the only way to do something that we run into trouble. Or when we think that all types of work can be well-defined and standardized. That rigidity will inevitably stifle innovation and bind organizations to old, and perhaps inefficient, ways of working.

ITIL 4 is encouraging us to use processes where they are appropriate, and to continually evolve and improve those processes to ensure that they at all times meet our organization’s circumstances, needs and goals. And to also understand that in today’s complex and dynamic workplace, there are some types of work where emergent practices and experimentation are more appropriate.
ITIL® is a registered trade mark of AXELOS Limited.

To learn more about ITSM Academy's ITIL 4 Courses please visit our website.


Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you. Roles and Responsibilities: Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance. Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables.  An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and th

The ITIL Maturity Model

Most organizations, especially service management organizations, strive to improve themselves. For those of us leveraging the ITIL® best practices, continual improvement is part of our DNA. We are constantly evaluating our organizations and looking for ways to improve. To aid in our improvement goals and underscore one of the major components of the ITIL Service Value System , Continual Improvement .   AXELOS has updated the ITIL Maturity Model and is offering new ITIL Assessment services. This will enable organizations to conduct evaluations and establish baselines to facilitate a continual improvement program. A while back I wrote an article on the importance of conducting an assessment . I explained the need to understand where you are before you can achieve your improvement goals. Understanding where you are deficient, how significant gaps are from your maturity objectives, and prioritizing which areas to focus on first are key to successfully improving. One method many organi

The Four Ps of Service Design - It’s not all about Technology

People ask me why I think that many designs and projects often fail. The most common answer is from a lack of preparation and management. Many IT organizations just think about the technology (product) implementation and fail to understand the risks of not planning for the effective and efficient use of the four Ps: People, Process, Products (services, technology and tools) and Partners (suppliers, manufacturers and vendors). A holistic approach should be adopted for all Service Design aspects and areas to ensure consistency and integration within all activities and processes across the entire IT environment, providing end to end business-related functionality and quality. (SD 2.4.2) People:   Have to have proper skills and possess the necessary competencies in order to get involved in the provision of IT services. The right skills, the right knowledge, the right level of experience must be kept current and aligned to the business needs. Products:   These are the technology managem