So now the proverbial “rubber hits the road”.  You’ve purchased a service desk tool, and you want it to support your ITIL process initiative.  So how do you get there?

This is part 3 of a three part series (Part 1, Part 2) discussing how to “Bridge the Gap” between Service Desks, IT Processes, and Workflow.  Part 3 offers some practical advice on how to get from what the ITIL Processes describe, and really getting the benefit through automation tools.

In the two parts that preceded this article, I discussed the value of ITIL Processes and Workflow.  ITIL Process provides value in the Governance of IT, in their ability to Measure, Control and Enable the IT Service Organization.  Workflow brings business context to the activities associated with completing the process.

So how do we build the bridge between Process and Workflow?  The answer lies in the example described in Part 2, you need to understand the overlap between the activities from multiple processes that may need to be integrated into a homogeneous workflow.

To illustrate this, I’ll take the example of Request Fulfillment, and the Access Management Processes.  The objectives of the two processes are (from, “Service Operations”, 2007):

Request Fulfillment – to provide a channel for users to request and receive standard services; to provide information to users and customers about the availability of services and the procedure for obtaining them; to source and deliver the components of standard services; and to assist with general information, complaints or comments

Access Management – to provide the right for users to be able to use a service or group of services; executes policies and actions defined in Information Security Management and Availability Management

Both these services are clearly separate with differentiated goals and objectives.  The activities for each process have separate roles assigned in a RACI matrix.  However, in practical application, how do our end users typically access both Request Fulfillment Processes, and Access Management Processes?  The answer is, they both are Requests from the customer point of view, and for our business are typically managed in a combined workflow.   The activities encompassed within the work instructions that underlie that workflow will clearly be different; however, the workflow will typically hold many of the same elements.

The next question is how do we define the correct workflow?  Unfortunately, this one comes in part to the standard consultant’s answer of “it depends”.    However, this isn’t as bad as it seems.  It depends on the CMS (Configuration Management System) Tool or Tool-Set you are using.    CMS Tools which encompass workflow management (usually in the form of “Ticketing”), come in two basic flavors:

Status Based – These tools govern the workflow through the agent changing the status of tickets, and having the ability to transfer tickets to other groups or agents.  They have the advantage of flexibility, as the workflow is usually based on some simple statuses.  However, these tools can be difficult to measure, and rely heavily on each individual agent doing things according to policy/procedure/work-instructions exactly the right way, every time, manually to ensure accurate measurements on the performance of that workflow.

Action Based – These tools do not allow the agent to manipulate statuses directly.  Instead, they require agents to take actions, which are made available based on the status of the tickets.  This allows the process owner(s) to essentially encode the process steps, much more thoroughly into the workflow, and provides better governance of the workflow steps for the organization.  Modern service desk systems are moving toward action based models.  They are differentiated by the level of work required to model workflow.  The better systems are entirely driven by configuration data, and require a minimum of programming/scripting of the workflow.

So the implementation of the workflow becomes highly dependent on the tools you choose to make up your CMS.   Choosing an Action Based system will maximize your ability to control the workflow, and accurately measure the effectiveness of your workflow process.     In its simplest form, an action based system will flow much the same way as a status based system.   However, the action based system has much more capability to provide both control of the workflow, in the form of work-rules based on status, and measurement of the specific steps in the workflow.

Returning to our example, modeling the activities to perform the Access Management and Request Fulfillment processes, it is likely that a unified workflow will be developed.  The start of the workflow will be the common request mechanism for the service desk.  From there, based on the request being made, it will branch into workflow that captures the activities of either Access Management or Request Fulfillment.  Furthermore, a frequently implemented request model is for new employees, which will encompass workflow elements from both workflows to fulfill the same root request.

So… to bridge the divide between Process, Workflow, and Tools, one must understand the definition of each.  Once we understand that Workflow reflects our business requirements in how to approach the Activities defined in the ITIL Processes (watch all those key words, its important), we discover that workflow design is the bridge between good Process and the Tools we need to automate them.  The tools will act to define the constraints of our workflow, and our workflow requirements may in turn help define our requirements for tools.

In summary, focus on designing your workflow to suit the tools appropriate to your organization.  Every organization does not need an “enterprise” service desk, but all organizations looking to automate their workflow need to consider designing their workflow to meet their real business needs.  Keep it simple when you start, and allow yourself room for Continual Improvement.  Most of all, focus on good design; the CMS is the ERP system for IT, and as such it is the tool to manage IT’s business, and look for tools that will enable your organizations ability to manage workflow, don’t let your tool manage you!

Guest blogger, Vernon Palango is the Principle Consultant for InteQ Corporation’s Service Management Consulting and Training organization.  In addition, he acts as the primary advisor for implementation of ITIL Best Practices within InfraDesk™, InteQ’s On-Demand Service Desk product.  www.inteqnet.com

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

It is Friday. And I am a fan of Dilbert toons. Today’s Dilbert reminded me of the often situation some of us find ourselves, when we take a project or a thought or an action plan to our bosses. Well, the good ones would be jubilant (maybe an exaggeration!) and the bad ones would beat the idea down because they feel insecure that someone else thought of something better than them.

Anyways, the toon also reminded me of the how we approach the help desk or ITIL. Documentation, even though a very boring thing to do, can sometimes be a life saver. It can definitely be a time saver for future projects, where teams can rely on wisdom gained from past projects.

It also reminds me of RCA or Root Cause Analysis – it is something that is used in Problem Management. The advantage of RCA gives you all the data you need to find out the actual reason for the problem. Problem management helps in deciding what to do to eliminate that problem completely. The goal being – never let that problem occur again.

Have a great weekend, everybody!

I teach the ITIL V3 Foundations Course at least monthly, and without fail a student will ask me a question like “So… How exactly do I set up the incident management process in my help desk system?” at which point I have a discussion with the class about the difference between process and workflow.

This is part 1 of a three part series discussing how to “Bridge the Gap” between Service Desks, IT Processes, and Workflow.  In Part 1, I will describe the role IT Processes have, as defined by ITIL, in relation to the service desk.

Processes, or better stated Business Processes, are the entire set of activities, people, tools, etc… that contributes to a specific business outcome.  ITIL describes a process as “…a set of coordinated activities combining and implementing resources and capabilities in order to produce an outcome, which directly or indirectly creates value for an external customer or stakeholder” (Service Strategy, 2007).

The processes that the Service Desk has the most frequent interaction with include Incident Management, Request Fulfillment, Problem Management, Change Management and others.  The confusion comes in when the people working within the process lose track of what a process really is; a set of inputs which are processed into outputs based on defined triggers.

So what’s the importance of designing & implementing a good process in that case?

To answer that question, I ask another, is it important for the rest of the organization to define the business processes that deliver products and services to your organization’s customers?  Of course it is, and IT Processes are the business processes of the IT Service Organization, providing the measureable outcomes whereby success of the IT Business can be understood.

Put another way… Processes identify the outcomes you need to measure to be successful in delivering the value of IT Services to the business.  Without a clear definition of success, the likelihood that you will define your work, policies, and procedures correctly is chancy at best.

Processes, as defined by ITIL have three factors that must be considered.

The Process Itself which is defined by the activities, procedures, work instructions, roles, and most importantly the measureable metrics for the process.  The activities are what we usually are discussing when talking about the workflow automation done in service desk tools, but those activities, do not make up the process.

More important than the activities are the process measures, for without a way to objectively measure success, any process is ultimately doomed.  Without measures, there is no way to reliably show the value in managing a process and, without value, IT enters the familiar death spiral of declining trust with the business; becoming viewed as overhead to be cut instead of a provider of valuable services.

The Process Controls “are the activities of planning and regulating a process, with the objective of performing a process in an efficient and consistent manner” (Service Design, 2007).   Processes need owners to be accountable for the success of the process, and to insure that the process is improved over time according to the results of the measures.  Policies also need to be in place to ensure that the process goals are achieved within an appropriate set of business rules.

Process Enablers are the resources (primarily people and technology), as well as process capabilities (Knowledge & Skills in the organization as an example) which define the constraints under which the process can be executed.  All processes should be designed with an understanding of the capabilities of the organization in terms of process enablers.

Bringing this all together, processes give definition to how the IT Organization in general and the Service Desk organization specifically can measure success.  So, as we consider the value of tools for our processes, their importance is in the ability to:

MEASURE the effectiveness of the process through the reporting of key metrics
CONTROL the process through the implementation of business rules
and
ENABLE the process through workflow automation

Remember, Processes are not the tools, and the tools are not the process.  But, a full understanding of the relationship between the processes in the organizations, and the tools that enable, measure, and control the processes is required to successfully manage the modern IT Service Organization effectively.

In Part 2 of this series, I will go into the value of workflow to the service desk, and how it differs from process.  Part 3 will bring it all together, and give some advice on how to bring process together with workflow, and increase the maturity and value delivered by Service Desks in the IT Organization.

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

It really is an old question. But then why are people still asking or pondering this? IT managers seem to be in a dilemma of sorts. Some of them know that ITILv2 is sufficient but the market seems to have moved on. After all, when there is a new version in the market, why would anyone want to go to the old version? – it does not seem to be the right thing to do.

But then the real question would be – what is wrong with ITIL v2 anyways? My point being, if you have never dabbled with ITIL before, you should start with v2. As Rob England (more popularly known as the IT Skeptic) puts it, “If v2 taught us how to walk, v3 teaches us how to run. The trouble is many organisations are still sitting down.”

I have always believed in ITIL. It helps define and set up the processes in any organization. I believe it is easier to get the ball rolling with v2, than v3.

So what is your experience? Have you taken the ITIL plunge? What did you do? V2 or v3? Share your experience here.