Incident Classification in Service-Now

[gvanroy]

We are working on putting together our Incident Classification and we were wondering how others are doing it. We were thinking about using Service>System>Component/Function>Incident Type. For example:
Email Service>OWA>Send/Receive>Issue or
Desktop Service>Laptop>Memory>Issue
What have others done? Have you found any issues with reporting doing it the way you do?

[#2]

I'm not aware of any reporting issues based on how deep your heirarchy is.

The main downside to having that deep a categorization heirarchy is that it slows down call collection. Technicians have to fill in 4 levels of category, which takes appreciably longer than two.

Likweise the more granular you make your categories, the harder it is to find the right one. If the user calls, for example and says:

every time I launch exchange, it crashes, where is that in the heirarchy?

Is it:

Email -> Exchange -> Client -> Crash

or

Desktop -> Application -> Exchange -> Crash

The shallower your heirarchy is, the more "discoverable" things are.

If technicians can't find the right categorization quickly, their temptation is to either A) pick "misc" for everything or B) pick something at random.

Point being, we usually recommend balancing the needs of the technicans with the reporting needs of the system. Since these types of apps usually get developed by the same people who report off of them, the temptation is to put in place lots of granular reporting fields, and then you end up with an incident form which is slow and/or hard to use for your technicians.

[Chris York]

While this topic might be seemingly simple, in my experience this is quite a complex problem to solve at most organizations and often requires weeks of debate amongst interested parties.

My recommendation is to focus on three things.

[*]The ability for clear and accurate trend reporting
[*]avoiding redundant data collection
[*]Simple and intuitive Reporting
Don't be tempted to cram everything into your categorizations to gather all the information about this incident. Keep in mind that some of the data will come from other areas (CI, Close Code, Resolution Code, etc.).

You want to be able to have like minded data in the same column. Don't mix values across columns. For example, here are 2 examples of the wrong way to categorize:

Example 1
-----------
Level 1 - Software
Level 2 - Peoplesoft
Level 3 - Payroll Module
Level 4 - Data Problem

Example 2
-----------
Level 1 - Hardware
Level 2 - Server
Level 3 - Windows Server
Level 4 - Hard Drive Failure

Notice that in Level 2 in the above examples, you have different types of data. Example 1 has a specific application where Example 2 is more general.

Redundant Data
I think Categorization should only describe the "Symptom" of the Incident. You can derive other pieces of data if you have referenced the Configuration Item. For example, If you include the application name as part of your categorization structure, things like hardware or software, etc are all things that are also known as soon as you reference a CI. Therefore this is not needed in the Categorization.

Notice that in the 2 examples above, the symptom is really just the 4th level. The 1st 3 levels can be derived from the CI.

When you come up with a model, take 100 tickets from your existing system. Plug them into the model and look at the type of reports that will come out if you group the data on the category levels

Simple and Intuitive
If you stay at 2 levels of categorization, it is obviously simpler and more intuitive. If you leave your categories as purely symptom based, then you should be able to easily fit them into 2 levels. This of course requires to to select a Configuration Item seperate from the Category so that you can derive additional information like whether it was a hardware or a software problem.


So to summarize:

CI = What is impacted
Category/Subcategory = How is it impacted

[gvanroy]

Thanks for all the feedback

We definately want things as simple as possible for the Service Desk to use for logging tickets.
After several meetings today we made some modifications to what we were thinking. All along we were going to capture the exact details of what caused an issue (at least from a high level).

It would look somthing like this:
Level 1 = System (Generic CIs)
Level 2 = Component/Function
Level 3 = Type

example
Level 1 = Email
Level 2 = Inbound Mail
Level 3 = Issue

At closure we would then capture the CI and the Closure Code.
It would look somthing like this:
Cause CI (Configuration Item)
Closure Code

example
Cause CI: Exchange Server 12345
Closure Code: Hardware Failure

Any thoughts?

[michelregueiro]

I would tend to agree with Chris, the objective of categorization in incident management is to identify the type of incident, not what is impacted. What is impacted is identified with the configuration items, either with a simple field "configuration item" or with a combination of a "Business Service" field + "Configuration Item" field.

Another way of identifying what is impacted is to use the Related list "Affected CIs" when it is required to identify several CIs (typically, when a server is down, this might affect several business services").

With regards to the classification of an incident, we regularly propose this structure to our customers:
Type (1st level of category):
Failure
Service Request
+ any other type required

Category (dependant on the type):
Failure > Hardware
Failure > Software
Failure > Data
Failure > Hosting

SR > User Admin
SR > System Admin
SR > Coaching
+ any other category required based on your business.

The good test we like to use to make sure that our categorization is correct is to check that the types and categories are valid no matter the CI selected. When I select Peoplesoft as a CI, I can categorize it with "Failure" or "Service Request" and I can categorize it as hardware, software, etc... Of course, it does not fit with 100% CIs, but globally this should cover the categorization needs.

Michel
www.aspediens.com