IT Business Fundamentals Part 3a


ITIL’s Process Confusion

NOTE: As promised in an earlier post, the confusion with the terms process and function will be cleared up in IT Business Fundamentals Part 3. However, due to the multiple points of confusion with these terms and my goal to publish a new and useful article each week, part three will be split into multiple sub-parts starting with “part 3a.”

One of the most confusing and misleading concepts in ITIL is the two definitions it provides for process. Way back when ITIL was first written it was decided that having a process based organization was a best-practice and ITIL processes were born. They identified a number of processes that must take place in IT management whether they are performed by design or simply by default; they wrote about these processes; and they named chapters after these processes. So far so good right? Unfortunately not, as this is where the problems began.

Before ITIL, a process was simply a set of activities required to produce a specified output organized in the sequence required to produce that output; a recipe of activities if you will. This is the type of process written about by many management authors of the time. The idea behind the best practice is to start with the business output and trace all of the activities required to produce that output and make business decisions based on producing that output. In other words make production of the desired output the primary concern of management. This was recommended as a method for overcoming the silo mentality generated by functional organization of business resources.

There are frameworks and collections of symbols designed to visually document process flows in what is commonly called process maps. Many people when first introduced to ITIL try to use these tools to map the ITIL processes. Very few people are ever successful because the “ITIL processes” are not processes at all. They are chapters in the ITIL books that introduce an assortment of ideas all related to what is sometimes a process and sometimes is not. Remember, a process before ITIL was always simply a set of activities required to produce a specific output structured in the order necessary to produce that output. Processes receive inputs and transform them into outputs through a series of activities. Resources exist outside of the process and perform the activities.

With the growing popularity of swim lane diagrams people often wrongly believe that resources are part of the process and are mapped in the process. This is simply not the case. Swim lane diagrams are a combination of two types of diagrams that when combined provide a very powerful visual tool. Think of the swim lane diagram and the process diagram as two different diagrams drawn on transparent film. First the swim lane diagram identifying resources is laid on the paper. On top of this goes the process diagram identifying activities. When combined we can easily see the activities that must be performed identified with the resources that actually perform them providing even more insight than either or both diagrams viewed separately.

One way to better understand what is going on with ITIL and processes is to realize that processes are systems. They are a very precisely defined system of activities that produce a specific output. Activities required to produce the output are inside the system and all other activities are outside the system. Nothing else exists within the process system. Policies are not inside the system. Tools are not inside the system. Certainly best practice guidance is not inside the system.

It is unfortunate that ITIL labeled its chapters as processes. Much confusion has ensued through well meaning people redefining processes in an effort to make sense of the ITIL labels. It would have been much better if ITIL had labeled their chapters as systems instead. Not the precisely defined system that is a process but a business system of tools that support a specific process. Thinking of the ITIL chapters as describing systems organized around a core process helps me keep the concepts straight. Instead of the ITIL Incident Management Process, I think of the Incident Management System that contains a process and much more.

There is a process that is rightly labeled “Manage Incident”; most mapping frameworks suggest placing the action “manage” before the object “incident.” There are also policies that may guide the management of a process and provide acceptable boundaries within which it can operate. There are resources that perform the activities within the process “Manage Incident” but they do not exist within the process system itself. They exist within a larger less precisely defined system that supports the “Manage Incident” process. This concept of systems is powerful. It allows us to examine things from many different perspectives. It helps us group and categorize things in ways that are useful and that provide a profit.

Systems can exist within systems. They can be highly specialized like processes or they can be generic and all encompassing such as the IT system. Systems can be defined to suit our need for focus on a particular topic. Focusing tightly on the process system allows us to map processes visually which provides for significant improvements in efficiency, effectiveness, communication, and other business needs. Likewise, creating a loose grouping of business tools that support a process allows us to maintain all of the previous benefits while organizing everything related to the process in a useful way.

So if you want to better understand ITIL processes think of the chapters of the ITIL books as collections of business tools related to the core process that the chapter is named for. Maintain for yourself the traditional definition of process and learn to use process mapping tools to codify your knowledge of what the process is and what it does. A well mapped business process is an example of organizational knowledge that is useful and valuable. Think of all the other information in the chapter as tools both logical and physical that help you better manage the process.

Also keep in mind that there are supporting systems for the core processes. Manage Incident and other processes such as “manage problem” require common processes for prioritization and categorization. Processes such as these can be organized within the “ITIL system” as supporting processes for multiple core processes. In this way the ITIL Library can be viewed as a system of systems supporting core processes.

Thinking of ITIL processes in this way maintains the power and usefulness of process and swim lane diagramming while preserving the excellent best practice guidance of ITIL. Keep separate in your mind the idea of processes from the supporting guidance for using IT core processes and your life as an ITIL practitioner will be simpler and more fruitful.

Author’s Note: I am an avid supporter of ITIL. It is by far the best available and most far reaching body of knowledge on IT management available. I have spent the better part of a decade studying its three sets of books and have struggled with some issues and concepts. Many of my struggles were resolved as I learned more and came to better understand what ITIL was saying. Some of my struggles, however, have been the result of ITIL mixing metaphors if you will; taking concepts from different business disciplines and combining them awkwardly.
Where I have identified these issues and sorted them out, at least in my own mind, I seek to share my experiences with others; hoping that my advice is useful to others; and hoping that those who read my writing achieve the tremendous benefit to be found in adopting ITIL best practices a little bit faster than they otherwise might. To the ITIL authors, many of whom I’ve come to know over the years, my intent is not to criticize but to contribute in some small way to an excellent body of work.