Documentation can serve a variety of purposes, of course, but one of its key applications is defining process. The word process seems so uninspiring in itself, but in the world of support, process is a cornerstone of providing top notch service. Or perhaps I should say good process is a cornerstone of top notch service; ineffective or poorly developed process is often worse than having no process at all. Although experienced support personnel have the instincts to know what the next step is in most situations, process is what gets everyone pulling in the same direction; if implemented and adhered to religiously, process ensures that the customer will receive exactly the same experience every time they call for support. And once you have the baseline of a single process, you can then refine it over time, with contributions from the team. Refining a process this way allows the entire support team to immediately benefit from each team member’s input. The issue of process adherence is a complicated one, and something I will discuss in future posts. We need to move beyond creating fancy flow charts and page after page of descriptive text. This is a starting point, but will result in overall poor adherence to process, regardless of how good the team’s intentions are.
Before we get to adherence, it is important to think about how to create killer processes to work from. One approach that has been widely accepted and has performed well for many organizations is the OGC IT Infrastructure Library (ITIL). As described on the ITIL website:
“ITIL® provides a cohesive set of best practice, drawn from the public and private sectors internationally. It is supported by a comprehensive qualifications scheme, accredited training organisations, and implementation and assessment tools.”
Whether you are looking to create a whole new set of processes, or refine the ones you have today, ITIL provides a solid framework and foundation to work from. Because ITIL is a framework, you cannot simply post the ITIL documentation to your intranet as process; you will need to write your own process documentation, but can rely on ITIL for guidance and structure.
The ITIL documentation fill several books, but the two central works are Service Support and Service Delivery. The Service Support book is a good place to start in terms of process for providing technical support, and it is divided into the following main sections:
- Service Desk
- Incident Management
- Problem Management
- Configuration Management
- Change Management
- Release Management
Following a defined process for delivering technical support may seem contrary to allowing the brightest team members to shine and show their creativity. If the processes are designed properly, this need not be the case. Well-defined processes provide structure to the routine and required activities necessary to getting the job done well, but do not restrict team members from coming up with new ways to complete those tasks. Further, when team members have good ideas that fall outside the existing process, they should always be considered, discussed with the greater team, and incorporated into the process if there is agreement to do so. The challenge is to see process as a means to allowing creativity to flourish and have a wider benefit than it otherwise would, not as a rigid mechanism for turning the support team into an assembly line.
This post has been a summary of the overall benefit of process, and has touched on some of the key aspects and challenges of its design and implementation. Clearly process is a large and important topic, and I look forward to expanding on each of its aspects. I also welcome your feedback: what state is your current process in? How well is it working for you, and what are your plans to improving it? Have you considered ITIL, or other frameworks?
Comment Preview