In our ITSM Consulting Practice, we regularly work with customers on the implementation of service desk tools.  One of the common misconceived requests we receive is…  “Can you implement the ITIL (name one) process in our service desk tool?”   What follows is that we need to educate the customer that you can’t implement a process in a tool; we can only implement a workflow, and documentation.  The process is larger than that.

Last week, we saw “Bridging the Gap – Part 1: Process and the Service Desk“. This is part 2 of the three part series discussing how to “Bridge the Gap” between Service Desks, IT Processes, and Workflow.  Part 2 describes the role of defining workflow for the Service Desk, and the other “actors” in the service management processes.

Workflow is how we document and automate the day-to-day activities and decision points to achieve the aims of a process.  One way to view it is, that the goal of a process is to achieve specific set of outputs for the process stakeholders, while the goal of workflow is to ensure a set of activities, that may span multiple processes are executed in a specific order.

An illustrative example is in the relationship between Change Management and Release Management.    Change Management is responsible for approving the work to implement a change, and Release Management is responsible for approving a release into production.  These are separate processes, but in practice, they are frequently implemented in a common workflow.   This is part of where the confusion frequently originates, as the workflow in our tools associated with both of these processes is frequently associated with “Change Tickets”.

Structured workflow design has the benefit of developing consistent, repeatable steps for approaching the activities associated with any process.  This is particularly helpful in a process like Incident Management, where the Level 1 personnel may not have deep technical understanding of the services in the organization, but can rely on a well defined workflow to guide them in solving the issue.

ITIL identifies a set of activities to accomplish processes in the form of a RACI Matrix, which stands for:

Responsible – A person or role that performs the activity
Accountable – The one and only one person that ensures the activity occurs
Consulted – A person or role that gives advice for an activity
Informed – A person or role who is given information about an activity, but has no other role

Each process should define all the activities to accomplish it, and the roles that will perform those activities.  This becomes a guide to workflow, but again, is not itself the workflow…  For this we can take the example of incident management.  The standard activities at the beginning of the incident management process are… Incident Identification, Incident Logging, Incident Categorization, Incident Prioritization.  These are the process activities, the workflow associated with this might be Log Incident, Assign to Level 1, and Accept Level 1 Assignment with the underlying work instructions for the Level 1 Staff ensuring that the appropriate process activities are performed.

Put another way, workflow identifies the business steps being taken by personnel acting in a process.  The process defines activities, and the workflow must ensure (usually through work instructions) that all activities are performed by the appropriate roles.

In summary, the workflow puts the activities associated with one or more processes into the context of the business in which it occurs.  The workflow for incident management at a large bank will be much different than that for a small internet hosting company, but the underlying activities to resolve the incident will be very similar, with a very different RACI matrix associated.

Part 3 of this series will give a practical example of how to bridge process, workflow, and the tools we use to automate the processes.   We will describe a common case of the relationship between Request Fulfillment and Access Management as defined by ITIL V3, and show how you would approach mapping the process activities, workflow, and considerations you need to make when applying that to a tool.

Guest blogger, Vernon Palango is the Principle Consultant for InteQ’s On Demand Service Management Consulting and Training organization.  In addition, he acts as the primary advisor for InfraDesk, InteQ’s On Demand Service Desk, clients during the implementation stage. www.inteqnet.com