Join Mark Thomas for an in-depth discussion in this video Processes, part of Cert Prep: ITIL Foundations.
- Now, we move in to module four and talk about some key principles, models and concepts. The first thing we want to talk about is a process. What processes are? Before we start jumping in to the specific ITIL processes in the phases of the life cycle, we're going to make sure we get a foundation on what these things actually are. Let's take a look here at the next slide. A process. Process is a set of structured activities designed to accomplish a specific objective. It is what the organization does in terms of those activities. Process is defined the organization as well as products and services.
Process takes a lot of inputs. It could be one input. It could be more than one input coming into the process and in terms of the defined outputs. I really like how the slide really describes some of the pieces of this process. First of all, data enters the process. It comes in terms of inputs. That could from another process. That could come from a customer, and so on, but we need data to trigger and kick off this process. Once we hit the process, we had things called activities, procedures, and working structures. Now oftentimes, processes, activities, procedures are oftentimes, you see them use kind of the same terms but there clearly is a difference between these things.
I want to point one of these things out to you. The term process and procedure are often used interchangeably. But within service management, they are distinctly different. For clarity, a process focuses on the what of an activity. A procedure focuses on the who and how an activity is completed. It describes a set of logically related activities. You can see a kind of attacks on before a process, activities, base we process procedures and activities in the working structures. Now, we have another part of the process.
Process metrics. How we're measuring and controlling that process by looking at metrics and measurements for that. We have process roles. A lot of roles identified. We talked earlier about service management roles but there are owners. There are managers. There are practitioners. For roles, it has to be clearly defined as a part of that overall process structure. We have process improvements. As we are looking at metrics, and we're looking at the activities and working instructions, these things all input into how we are improving those processes.
Now, before we hit outputs, there are some things that can control that process. We're talking about control. We go full screen here. Look at some of the key things that are on the control side. One, every process has to have this thing right here. It's called the Process Owner. A Process Owner is basically responsible for ensuring that the process is performing as documented. We'll talk a little bit more about those things. That's clearly a role. We have documentation. We have the policies.
We have the procedures that are well-known across the organization on how the process behaves. Process Feedback, one of the things this is... A process is considered what we call a closed loop system because results of the process typically provide for change or transformation of an event into a specific goal. It's closed loop. That's coming back in to the feedback piece of this. We have policies. We have objectives in the process, okay? We have a neighbors. You might remember these when we were talking about service management.
Enabler is an ingredient. Something that will help us determine whether or not this process is going to succeed. Those are resources and capabilities. You might remember those from that slide. Now, things coming out. There are outputs. We have to determine whether that process has to achieve its objective because those outputs could be going directly to customers or those outputs could be going to another process. It's very important to really understand that. This is really good at breaking down what pieces are really involved on the process side.
Now, the next slide is very important for you to remember. Some of the basic things around the characteristics of every process. Basically, four characteristics. I'll tell you how I remember these. It might help you out here as well. But first of all, every process has to be measurable. I underline the M there. We have to be able to measure the process. For example, we have incident management. How do we measure the process? There are all types of different metrics you might look at. Backlog of incidents, incident closure, meantime resolve, different types of key performance and measurements that we use on that.
What they're doing is helping us manage the performance of that process so that we can improve it, so that we know the outcomes of that. They help us look at costs, quality, other variables of that. Practitioners, well, I actually backed up a little bit. One of the things here is managers. That's a role. Managers are measuring the costs. Practitioners, which is a more detailed role on that, measure the duration and productivity. That's the measurable piece of that. The second characteristic is what I call specific results. Every process has to have a specific result.
It exists to deliver this. Let's use incident management again. Remember incident management that we'll talk later. The goal of incident management is to restore services quickly as possible. Specific result of incident management would be restore of service within the service level, within the agreed metrics that we're looking at there. Results may be individually identifiable and controllable coming out of that process. So specific result. The third we might have is what we call customers.
Every process has to have a customer, internal or external customer. Let's use incident management again. It's like customer calling me for that specific incident. We also may have a group or a role or a part of the organization that which we provide incident support services for. Those customers, internal or external, and we have to meet their expectation. Again, it goes back to that closed loop. We have an owner. We're ensuring that we're monitoring our metrics and measurements. Then the outcome of this process are meeting those expectations. Then the last one is that a response to a specific event.
Now, the way I see this, this is a process sits until something says "go". Remember, that's a set of activities. It takes inputs and turns into the outputs. Now, in this process, an advanced specific, we have to have a trigger that kicks it off. Let's go to incident management. One is the specific event that kicks off incident management. There's a couple of ways that could happen. One is we have some type of monitoring tool and event management. We have monitoring tool that catches a trucial being breached that might automatically trigger that incident process.
Let's say a customer calls a service desk. That might be a trigger that kicks off the incident management process. Again, it could be ongoing or it could be interactive but usually what happen is some specific event kicks that process off. Remember, some of the things we talked about in the previous slide. Every process has to have an order. We're measuring it and those types of things involved there. MSCR, Mary Sells Customer Ring is how I remember this. Every process must be measurable. It has to have specific results. It has customers and response to a specific event.
It means it's triggered by something that says "go". Those are the characteristics of every process.
ITIL® is a registered trade mark of AXELOS Limited. This ITIL Foundations course is offered by Interface Technical Training, ATO of EXIN.