provided by: 
Originally published at Internet.com Customers find it reassuring when airline pilots and doctors follow scripts to make sure they do not overlook anything important. Why then is IT so loath to emulate these professions?
The IT Infrastructure Library (ITIL) describes how incident matching can improve the efficiency, effectiveness, and economy of service restoration.
Incident matching is a major task described within the 2nd defined activity of the ITIL incident Management process. Basically, the idea is to collect data (hence the script) and match to a database of past issues. If you collect the right data, you can match this "knowledge base" and find a solution quickly and easily.
If you don't use scripts, it becomes hit-or-miss, and the result is often mis-classifying an incident and sending it to the wrong tech group (maybe it goes to network instead of software development). This just makes IT's work harder and causes pain for customers since the first thing the tech usually does is to call the customer and ask whatever questions they need to get the data. Plus, the incident takes longer to resolve.
While the ITIL does not provide a prescription for matching, practical experience and pragmatic thinking leads to a very effective method for matching: diagnostic scripts.
So, using scripts gets all the data up front, lets you route to the right group, and lets the right group fix the problem without bothering the customer. If the customer is happy, everybody is happy. That is incident matching in a nut shell.
Status Quo
The first reaction most inexperienced IT people have to scripts is negative. They think scripts suppress creativity. IT managers often think staff and customers will not like scripts. But customers do like effective scripts: We prefer airline pilots use a script before take off, for example. We like Doctors to follow a rigorous script to make sure they have not overlooked anything, right?
The same can be true for IT. Scripts simply make sure we collect the right data, in the right order, so as not overlook anything important.
Remember that scripts are true expert systems. They are useful anywhere variables combine in repeatable ways. Scripts let a non-expert make an expert decision. After developing several scripts, you can even allow users to diagnose their own issues if they want.
Whether paper-based or software-driven, scripts dramatically improve incident classification, diagnosis, and matching while greatly improving the accuracy of incident assignments and escalations. A script is really an expert system, which can be defined as a set of rules or a decision tree which aids an individual to make good decisions in an area where that individual is not an expert.
It is easy to think an expert system requires software, and it is true that automating scripts with a software solution will improve functionality and allow a thorough examination of a knowledge base of past incidents, problems, and known errors, perhaps even changes.
However, if you do not have a software system, you can implement and benefit from a paper system. Perhaps the most effective script I have ever seen was a manual system.
In either case, a script is just a tool for consistently gathering information, classifying, categorizing, and escalating or forwarding. As every incident using the same script gets the same handling, similar incidents get the same open code. With a consistent open code, a manager can track the scripts utility by comparing open and close codes.
If the resolution (closed code) is not what the script indicated (open code) then the script needs attention. Otherwise, the script worked to resolve or route the incident is minimal time.
This focus results in very effective and efficient handling or routing of incidents. Getting the incident resolved or routed to the right functional area quickly improves customer satisfaction while reducing IT wworkload.
Getting Started
Whether you use a paper or software driven system, you must create, tune, and tweak your scripts. It is easy to do with word processing and drawing tools. A good starting place is technical staff, and if you have it, the problem management process (ITIL assigns knowledge base/script creation to problem management).
The seven steps to scripts:
Start a script team. Start with whoever performs technical repairs, and include anyone with experience diagnosing incidents or problems. Be sure to include service desk staff, customers, and users as well.
It is vital to include users and customers because they often use different terms than IT and including them helps create a system they accept and support.
Choose script targets. Have the team identify a type of incident that "bounces" or routes back and forth between functional groups before resolutions, or Incidents the Service Desk does not handle well.
Document the script. Have the team develop questions and answers that gather enough data to accurately classify and route the incident. Be careful here-do not rely upon a technician's statements about what they do, instead watch them work and record what they do. Often, they are not conscious of what they really do.
Try out the script. Start a small test, perhaps giving the script to 25% of staff. Train them on how to use the script. Monitor its effectiveness against the original process. If the script is less effective than the existing process terminate the trial, identify what is wrong, tune it, and repeat.
Market the script. Keep management, staff, and customers aware of your activities. Describe how consistent data collection will speed and improve accuracy. If the target of your new script is a recognized "thorn" to the business, you have set yourself up for a quick win!
Roll out the script. After trialing the script and ensuring its utility, roll it out to all of service desk/incident management. You must monitor closely to ensure compliance, and there may be resistance at first, but staff will accept them if you make sure your scripts are crisp, concise, and effective.
Maintain the script. Scripts require constant maintenance and, at a minimum, require review prior to any major changes. Create reports that compare incident open code (script diagnosis) with incident close code. If you see differences-open and close code mismatches-then the script needs tuning.
This is usually for one of two reasons: the script is incorrect, or staff is not following the script. Regardless, you need to resolve the issue.
It does not matter if your scripting system is paper or software based, or whether it is in-house or out-sourced, carefully managed diagnostic scripts are your tickets to improved customer satisfaction and reduced IT workload.
Hank Marquis is a managing partner and CTO at itSM Solutions. You can contact Hank at hank.marquis@itsmsolutions.com.
Author: Hank Marquis
Read article at Internet.com site