When is a process not a process? This is a question I have been trying to find an answer for lately.
When you live in a world where IT Service Management and its processes seem like a given, it is perturbing to see that there are organizations where documented processes are the exception rather than the rule.
However, does a lack of defined process mean there is no process?
Initially, I thought that it did, but I have now discovered the phenomenon that is the ‘phantom process.’ It is very unlikely that even the most dysfunctional IT Service Desk can run with absolutely no process. It may not be written down, or process-flowed, but you can just about guarantee that there is some repeatable flow to what they are doing. It may not be right, or productive, but it will be there.
Where do you start when you discover a phantom process in the wild?
First, do not rush in to create a new process. You need to take the time to understand the way the current process is, or perhaps isn’t, working. It is entirely possible that the process has some positives that need to be retained. You must document the existing process before you start any work on designing a new one.
Phantom processes have grown organically, and they are probably serving the organization adequately, but finding one is a great indication that there is real room for improvement and optimization of the service desk.
The first step must be to study the process; track a variety of incidents and service requests from the start and get a clear understanding of how they are managed through to resolution. You may need to monitor this flow from the viewpoints of multiple service desk agents to make sure that the same phantom is haunting the entire service desk!
Mapping and documenting the current way of working gives you a head start on designing any new process that may be needed. Once you have worked out just how the service desk is handling calls, then go out and talk to the business and see how it is working from their point of view. How do they currently log their calls, how do they track them through to resolution? How do they know they have been resolved? Also, most importantly, how happy are they with the way things are currently working?
With all this information to hand, you can start to plan how to document and improve the way the service desk is working.
Read the next part of this story to see where to go next. (coming soon)