A Service Desk Management Model
On December 1 2009 Peter Baskette and I presented a management model for the Service Desk for a Northeast Regional Computing Program (NERCOMP) event. On April 16, 2010 I reprised a slightly more expanded version of the model for the Help Desk Institute Symposium.
Titled 'Process and the Service Desk: Driving Consistency and Quality through Process Management', this model builds on the concepts of the IT Value Chain and Services and Processes that are outlined on this site.
The presentation as given to NERCOMP is available for download here.
The presentation as give to HDI is available for download here.
A more complete model, that incorporates Knowledge Management and a more complete coverage of Problem Management, is available for download here.
The presentations are in PowerPoint 2003 format. They also have extensive speaker’s notes below the slides which should serve to clarify the points on the slides.
The Model in Short
Service Desk Defined
- The Single Point of Contact between the Service Provider and the Users.
- Manages Incidents and Service Requests.
- Handles communication with users.
- The Service Desk performs the first line support for IT Services
In the pure specification the Service Desk is the only point of contact for end-users. All end-user interactions, including communications, go through the Service Desk. These can occur through a variety of mechanisms- Calls, Emails, Chats, Walk-Ins. Whatever technology a given Desk uses.
In the v2 ITIL framework, the Service Desk is the only function (organizational unit) defined.
Service Desk tasks include:
- Act as a single point of contact for users
- “Own” inquiry from start (recording, status reports) to finish (close-out, monitoring satisfaction)
- Monitor adherence to the service level agreements and take appropriate measures if there is a danger of failure to meet an agreement
- Coordinate second level support and third-party support units
- Provide management information to improve the service quality
Self-Service
The Self-Service bubble is an indication that it is beneficial to present an interface into the Knowledge Base and other self-service applications. This follows the principle of driving work to the most efficient level. If an acceptable interface can be presented such that users can find the answers to their own questions, or process their own Service Requests, that frees up scarce support resources to focus on higher value added work.
Interaction Management
Interaction Management is a process that is NOT a part of the ITIL standard. It is a useful process to consider nonetheless. It is most clearly described in Rob Addy's excellent 'Effective IT Service Management: To ITIL and Beyond.'
In the pure ITL standard the activities and objectives of Interaction Management are subsumed in the Incident Management process. Treating Interaction Management as a stand-alone process has the advantage of separating the communications steps into a distinct process, where they can be measured and managed separately from the efforts to troubleshoot and apply break-fix solutions. A second advantage of distinguishing the Interaction process is that upon first contact to the Service Desk it cannot be assumed the client communication is about an Incident; the contact may ultimately be a Change Request, a Request for Information or another request that does not involve an error. Therefore the Interaction process becomes a routing process to correctly diagnose the nature of the client contact and then to route to the proper process.
If you use Interaction Management, all end-user intitiated interaction begins in Interaction Management. Requests for Information that are known to the intiail agent are closed there, other Interactions are then routed to the appropriate process. This sounds more complex than it is in practice.
To my knowledge only HP Service Manager of the major tools vendors specifically has a separate Interaction Management module. However, any standard ITSM software can be configured to enable this process.
Building the Model- The Support and Restore Processes
The ITIL v2 specification, represented in the pyramid above, defined 10 processes and 1 function.
They were presented in two volumes, Service Support ('the blue book') and Service Delivery ('the red book').
The 5 Service Support processes (and 1 function) can be further broken down into two triads. Notice how they are positioned on the pyramid. This is significant.
The first triad is the Service Desk, Incident Mgt. and Problem Management. This triad is called Support and Restore.
The Problem process is the controlling process for the Support and Restore triad.
Incident and Problem Management are processes. When learning processes it is helpful to keep the goals of the processes in mind:
- The goal of Incident Management is to restore service as quickly as possible, even if root cause is not known.
- The goal of Problem Management is to seek and determine root cause.
And, just for good measure- the Service Desk is the single point of contact for end-users.
So- the Service Desk is the face of Incident Management to the end-users. When something goes wrong- the end users deal with the Service Desk.
It is important to understand that this does NOT mean that the Service Desk is the only organizational unit that deals with Incidents. Incident Management is the process that seeks to restore service as quickly as possible. A quick review:
- An Incident is an interruption or degradation of service.
- Incident Management seeks to restore service as quickly as possible, even if root cause is unknown.
- Therefore, there are some Incidents that may be resolved without the Service Desk ever being aware of them.
One of the principle benefits of separating incidents and problems. It is possible to close incidents for which workarounds can be applied, while creating separate tickets to track progress to finding the underlying root cause of the Problem.
As the controlling process of the Support and Restore triad - Problem Management is the ‘big brother’ or the ‘mentor’ to the Incident Management process. What this means is that all workarounds (key ITIL term) made available to or implemented by or discovered by Incident Management are subject to review of the Problem Management process.
Principally this accomplishes:
- It ensures consistency by ensuring all methods to apply a fix/workaround are reviewed and the most effective are approved for use.
- It ensures that knowledge is shared among support staff, saving duplicate effort
- It allows Problem Management to be proactive in testing workarounds to ensure they fix the issue without causing further, perhaps more serioius, Incidents. (sometimes the cure is worse than the disease...).
In the v2 standard Knowledge Management was a sub-process of Problem Management (yes, you have to read the lines VERY carefully in the blue book- but they are there). So, among other things- the Knowledge Base contains approved workarounds.
In the truly pure version of the model, a near practical impossibility, all Incidents must be closed with an approved closure code for a workaround stored in the Knowledge Base.
In real life- it makes sense to document as many of these closure codes as possible.
Service Requests
Service Requests are a subset of the pre-approved class of Changes. These are requests to do such things as change passwords, create accounts, install purchased software and the like. They are Changes that provide or allow access to a Service for which the process is known (and documented) and approvals are clearly defined and easily applied.
ITIL v2 treated this class of Changes as a part of the Incident Management process. It makes more sense to treat them as a separate process; another benefit of using Interaction Management to perform process triage.
An important point to remember about Service Requests is that each one is a separate process or procedure in its own right. As such, they should be reviewed and documented and stored in the Knowledge Base. All executions of respective Service Requests should follow the approved and documented procedures.
Request Fulfillment
Closely related to Service Requests, ITIL v3 breaks Request Fulfillment into its own separate process.
This is the process that is responsible for setting up access to the organization's computer systems.
As a separate dedicated process, separated from Service Requests, it allows streamlined procedures for account creation and levels of access and authority.
It also allows for a distinct on-boarding process. This is often a process that crosses functional boundaries beyond IT- linking with HR, Payroll, ID Centers, Parking, etc. As such, in many organizations it can be an ideal first Business Process Management initiative.
Conclusion - What's the Process Point?
Why create distinct processes at your Service Desk?
One answer is more consistent and meaningful management metrics. Separating Interactions and Requests for Information from true break/fix Incidents and filtering out how much work is performed carrying out Service Requests leads to more informed decisions about:
- Organizational decisions, e.g. would it be cost-effective to tier your Desk?
- Investment decisions, e.g. do we need more staff, or invest in a knowledge base?
- Procedures and work flow. As mentioned elsewhere, what we don't define we cannot manage and improve.
Reflective Questions
- Do you distinguish between incidents and requests? Handle them differently?
- Do you collect metrics? Do they drive your decisions? Your Vision?
- Do RFIs compromise your data?
- Do you have consistent Interaction Management? Scripts? Standard greetings?