|Stuart D. Galup|
So, what connects the incident management process to the service desk function and problem management process? In Incident management made easier with Microsoft Service Desk, I talked about the incident management process, which is a sequence of actions that seeks to resolve any incident that is not part of standard operations and may or does cause a disruption in normal service levels. For example, several drivers are known to cause stability problems with Windows XP, and problems with those drivers can stall your users' workstations.
Unfortunately, in an incident like that, an IT organization often sees those activities as standalone activities that don't cross into other IT areas of responsibility, such as network support or database support.
You know what I mean. Yes, we pass information from the service desk to another IT technology team for action, but a true team approach between that technology team and the service desk function does not always exist. I often hear from service desk employees that the technology teams run off to address the incident and do not keep them in the loop. Not all IT organizations operate this way -- but many do.
To appreciate what connects the incident management process to the service desk function and problem management process, you have to understand the relationships between an incident or group of incidents, a problem, a known error and a request for change.
Making sense of the incident management process
In the event that 1-line support is unable to restore the IT service to normal operating levels, the incident is escalated either functionally or hierarchically or both. Functional escalation is the transfer of the incident to a higher level of technical skill organized into groups called lines of support. If the incident is not resolved at a specific line of support, the incident transfers to the next line of support. The lines of support are 2-line (usually part of the service desk function), 3-line (such as technology teams responsible for network management) and n-line (vendor technical support). If incident management at any of these escalation points finds a workaround solution, it is recorded in the knowledge base for future reference. If a permanent solution is found, a request for change is submitted to the change management process.
For example, the 1-line support at the service desk receives a call from a user who says a program on his workstation keeps crashing. The service desk determines that the incident occurs when Windows XP cannot access a file because of a problem with the hard disk.
In the event that 1-line support does not find a workaround for the Windows XP file access, escalation is needed. At this point, the 1-line support would bring 2-line support into the process. Because this is a known Microsoft error and 2-line support would have access to the Microsoft knowledge base, the driver workaround would be downloaded by the user -- if he is skilled enough to attempt the fix. If not, the service desk would pass the incident information with the workaround to the desktop support group for action. A successful resolution at this stage requires a cross-functional team consisting of the service desk and the desktop support group.
It is critical for IT managers responsible for all aspects of incident management to reach out to and encourage the sharing of information across the IT organization in order to achieve an efficient responses to incidents.
Dr. Stuart D. Galup (D.B.A., Nova Southeastern University) is an associate professor of computer information systems at Florida Atlantic University. He is a Certified Computing Professional and is certified in ITIL. He has held a number of senior information technology positions and holds a U.S. patent. Galup has authored more than 45 academic publications and two books.
This was first published in July 2007