This article provides guidance and insight into the best use of the Request Areas (to include Incident Areas and Problem Areas), Configuration Items, and Root Causes.
Misuse of Request Areas
Request Areas are probably the most misused items in Service Desk. Most companies seem to want to use the field to classify the tickets for reporting purposes. This results in a very extensive list of Request Areas but with very granular reporting potential. This is because reporting on the Request Area field is limited to the items in the Request Area list. If it's not in the list then you can't report on it. Usually this abuse of Request Areas can be attributed to the company recreating the system that Service Desk was purchased to replace. The true purpose for Request Areas are to assist in routing a ticket to the appropriate Group or Analyst for resolution.
A good rule of thumb is to start with the same number of Request Areas as their are routing potentials. Typically if there are 20 Groups, then there are 20 routing potentials. Then add new Request Areas as needed, such as when Properties are required. But do not create a Request Area for every application and every type of problem that an application can have. There are other fields that will give you this information... and do so with broader reporting potential.
Using the Fields for Their Intended Purpose
The Affected End User identifies the WHO.
- Who is the person requesting support?
- Who is the person requesting information?
The Configuration Item (aka Asset) identifies the WHAT.
- What is the item that the End User is requesting support for?
- What is the item that the End User is requesting information on?
The Root Cause identifies the WHY.
- Why is the End User requesting support?
- Why is the End User requesting information?
The Request Area simplifies the routing to the appropriate Group or Analyst equipped to handle the End User's request.
The Hidden Potential of Configuration Items
When Request Areas are misused, the listing is almost always done in a manner that categorizes the Request Areas. For example, there will be a folder for Software and another for Hardware and yet another for Network. And then maybe Software will have a sub folder of Business Apps and maybe another for IT Tools. And a concern for limiting Request Area use would be that this categorization would be lost. But this couldn't be farther from the truth. Configuration Items contain a Class and Family structure by default which exist for the sole purpose of classifying the CIs. The Family/Class structure can be designed to mimic that which has been put in place for Request Area.
Another overlooked reality with Configuration Items is their wealth of information. When you look at the details of a Request Area you get very little. Maybe a Default Group, a Service Type, Description, and a few Properties. But the details of a Configuration Item has far more potential such as Family, Class, Manufacturer, Warranty Expiration, Service Type, Priority, Organizations, Inventory Count, Parent CIs, Child CIs, etc... And all of these items can be reporting on.
Using Root Cause
The key to using Root Cause is remembering they were designed to answer the simple question of WHY?
- Why did the End User request support for there email? Because there was a network failure and Outlook was unable to connect to the Exchange Server.
- Why did the End User request assistance with their flash drive? Because a training deficiency resulted in the user's lack of understanding.
See the Root Cause article for more examples.
As stated before, if using Request Areas to classify your tickets, your reporting on Request Areas is limited to the number of items in the list. So if there are 100 Request Areas then you have 100 items to report on. You can certainly combine items, but you are still limited to the words that make up your Request Areas. But by limiting your Request Area listing and using Root Cause and Configuration Items to better classify your tickets, the reporting potential explodes.
Lets say you have configured your system with 20 Request Areas, 100 Configuration Items, and 25 Root Causes. You can now report on any combination of the three. This gives you the reporting potential that far exceeds the capabilities of the Request Area field alone. For example, 20 Request Areas X 100 Configuration Items gives you 2000 reporting possibilities (20 x 100 = 2000). Now add 25 Root Cause and you have 50,000 reporting possibilities (25 x 2000 = 50,000). And these are just the numbers when using one Request Area, one Configuration Item, and one Root Cause. The reality is that you can combine any number of each.
And finally, you also have all the attributes of the Configuration Items that you can report on.
This article was originally a wiki article created by Gityerfix in 2008 and edited by FunkDoC.