The Art of ITSM Process Design, Part 1

I’ve been wrestling for some time with how to articulate the magic juju that makes LANDesk Service Desk so special. Because there is something special there – and certainly it’s something that few, and possibly none of the other ITSM toolsets are able to do. And yet it’s strangely hard to describe. In meetings with potential customers it can take about 30 minutes to an hour of background explanation and demonstration before you reach the tipping point where the light bulb comes on, and they start telling me what LANDesk Service Desk (LDSD) can do.

It’s harder to communicate that magic when the potential customer has used or seen other ITSM toolsets. They focus on ‘surface’ behavior, checking off on a checklist that a product can do A, B, or C—guided often by those huge ITIL books and Pink Verification type questions: Can it categorize? Can it assign? Does it have dashboards? Of course it does. All ITSM toolsets do.

But when the customer starts the meeting (or sends beforehand) a process diagram that describes how they need to work—not how the product works, but how their staff work—then we see an opportunity to really help someone. It’s when the prospective customer has a clear vision of what their change processes must do, and how they need to progress a request in their business then we’re heading in the right direction.

In order to tackle this and avoid confusion and conflict with assumptions and beliefs and passionate views, let’s move beyond ITSM and ITIL. I don’t want to argue about the right order to do things.  If we are happy that ITSM requires us to take the right steps, quickly and efficiently in a defined sequence, then that concept can be better seen in a non-ITSM example . . . like writing a blog article.

To write a blog post, there’s a standard set of steps one has to go through.

  1. I come up with an idea, write uncontrolled words to articulate the idea, leave it alone for a bit, come back to it, try and adjust and cut down and turn the mass of ugly sentences into something readable. If I can produce something meaningful and makes the point I want to make, I pass it to a colleague to review (usually the most impressive @melkarunaratne since she is a harsh and brutal critic).
  2. She passes back her corrections.
  3. I apply those changes, re-read again, if it still makes sense I email it to our blog editor. (Hi, Abel.)
  4. He reviews it and tweaks and edits it into slightly more acceptable global version of English.
  5. Then – if it’s good – he publishes it on the blog site and sends out emails telling people it’s live.

So, do all those steps add up to? It’s—here it comes—a  process! Just like a Problem Management process, or a Change request, or a Service Request or an Incident. It’s a series of steps, with choices.

So, let’s take that ‘How I Write A Blog’ sequence of steps and draw that out. Funnily thing – I started to do this in Visio and then realized that its actually quicker to use LDSD itself than anything else. It guides you through the right steps so building a process is super-simple. This took me 15 minutes to build. It’s a real usable process—not just a diagram.

How I Write a Blog Process

Let me repeat: This is not a just a picture. Its a screenshot from what you use as you work with LDSD. It’s interactive. You can change it. It’s a real flow of the process. Change the lines and you change the sequence of events and the work people do.

Now the magic juju inside LDSD is the core ability to take a process like the above and bring it to life. It’s passed automatically to a person (or group or role), with the steps (actions) they have to take. When they choose and perform the action, the process moves on to the next status.

Performing an action usually means completing a bunch of fields in a window that need to be captured to complete that action. It’s not click here to move on; it’s complete the following fields, and it will only move on if and when you can complete those fields. Typically it’s assigned automatically to the next person. That’s the arrows you see above.  And of course the next person can only see and perform the actions presented to them at that status.  Each process is moved around the business like tossing a ball from one person to another, and everyone—staff, management, employees, third parties, customers and so on—all take the right steps when the process is in their hands.

Has the light bulb come on in your head?  You do things. With LDSD you draw the steps and decisions that need to be followed. You give them life and people follow them. Whether its a change request, a service request, a knowledge article, incident, problem, service lifecycle, facilities management, human resources, a blog, social discussion, idea generation, risk register, or a chat conversation. Every step audited.

You might find some other ITSM Vendors that say, “It’s not about the process because process makes things complicated.” What they are really saying is that they don’t have a solution that lets you literally draw out the way you want to work. That way is called Process. Processes can be complicated or very, very simple. How it works is up to you.

Now it’s often said that we need People, Process and Technology(or tools). I find it frustrating when I hear talk of ‘our tool does or doesn’t let us follow our process’. That’s just weird to me. The Tool is the Process and the Process is the Tool. If your process is wrong, change it. That’s what the Tool is for. The tool brings your process to life, and the tool doesn’t live without your process.

And, yes, some vendors will say they can do process too. That’s fine. Many can in their own way. When considering a suitable tool you can grow with rather than having to live with, perhaps ask every sales/vendor to show you how they can deliver one of your own processes. And ask to see it being built in front of you. If you’re happy with code and if you’re happy with status that can be changed at random with no controls, then go for it. If you are happy keeping your support processes separate from a tool that doesn’t follow your process, then fine. Everyone does ITSM differently. What I’ve described is how LANDesk does it and I’ve seen enough of those ‘light bulb’ moments to know we do something special.

Just ask our customers.

In Part Two I’d like to take the aforementioned example further and show you how all the standard concepts of Categories, Assignments, Groups, Service Levels, Dashboards, Emails, iPads, and Integration all wrap around this process, and how this process integrates with all the ‘core’ ITSM/ITIL processes. It’s a lovely subject, but just too big to put in one blog article.