ITIL Foundation: Introduction to ITIL Processes

ITIL started out being process centric when it was conceived, and up until 2007 when version 3 was introduced. And then, ITIL V3 flipped the whole service management and started working its way from the services point of view. However, the process of a definition and what it stood for hasn’t changed – except for some improvements over the years.

The official definition of an ITIL process goes like this:

“A structured set of Activities designed to accomplish a specific Objective. A Process takes one or more defined inputs and turns them into defined outputs. A Process may include any of the Roles, responsibilities, tools and management Controls required to reliably deliver the outputs. A Process may define Policies, Standards, Guidelines, Activities, and Work Instructions if they are needed.”

In layman terms, for a process to be developed, you need to have an input, a trigger and the expected output. What happens between the input and the output is your process.

Read my past post on the explanation of a process in general. I have also written a non-IT example to explain the essence of the process in this post.

In the figure above, any process will have three parts to it. The first is process control which provides the governance and hierarchy for the process to be effective and efficient in meeting its objectives.

The middle layer is the actual process steps, and also the step downs such as work instructions and standard operating procedures. A good process will also define KPIs against the process and define how the process needs to be measured and weighed.

The final block is where you have resources and capabilities. Resources and capabilities are the essential elements that are needed to run the process. Examples are people, service management knowledge and the financials among others.

The process has an input and a trigger feeding it. Any process starts moving once it has both an input and a trigger. An input could be the data needed to process and a trigger could be as simple as a request from a manager.

Every process must have an output. It takes the input, which goes through a series of hoops and comes out as something else – like an industrial output. In the example I gave you earlier, the data gets transformed and comes out as a usable report. Remember that the output is always as defined by the process developer. There can be no surprises during the output stages.

Another non-IT example is a manufacturing industry. The inputs are the raw materials. The trigger could be fresh demand from distributors. The industrial inputs get processed through a number of steps and out comes a finished product that is well defined and is as expected.

If you observe closely, an arrow from the output goes right back to the process control. This is the most important part of any process. This is the feedback mechanism. Based on the output achieved, the process control measures the process to check if it is meeting its objectives and provides inputs that are needed for process improvements.