We are implementing ITSM. Our group is struggling with the difference between network software and desktop software and what should be in what category. Examples, apps like power point, client server apps, web apps, infrastructure apps.
Has anyone tackled this that could share what they did?

If there was a list of 'balck arts' in ITIL, incident classification would be on it.

First let me say, I think the question you're asking is too specific to your situation to answer direclty, I suspect there are other factors in play. And there is no hard and fast rule to distinguish applications in the manner you suggest. A purely desktop application is rapidly becoming a thing of the past. And I think you will find applications that straddle all the categories you suggested.

One of the characteristics of a good schema is that is doesn't generate 'monsters' i.e., beasts with the head of a web app and the body of an infrastructure app

Consider what you are classifying and the work you expect that classification to do where it is being applied. In most cases it is simply to assign the incident.

Where classification often goes astray is when people stray into trying to classify their infrastructure rather than their incidents.

So with regard to your question -- do you really need to explicitly break these 'types' of application down according to a specific rule.

Perhaps something like:

SOE Desktop -> MS Word -> Application Error

is sufficient, while another category might be

SOE Desktop -> CD Rom -> Inoperable

In this case, each level embodies one rule implicitly, and those rules can be expressed as

Service -> Component -> Nature of Incident

Note that when you look at this example you see nouns - common usage names of things and events that people are used to using. You don't see 'adjectival qualifier nouns' like hardware / software. Once you link the report to the correct CIs and have the activity codes in place, you will be able to report on incidents against these type of categories.

So with regard to your initial question do you really need to flag the differences you are talking about. For example how quickly can you 'recognise' the items in the following list:

Where
Service is a business activity, as defined in your service catalog
System is an identified application (which must be used by the service) including client and server side
Component is the functional area that the incident is about (for example 'reports' but could equally be a hardware item)
Incident type would be generic eg Access, Availability, Slow Performance, Install, Advice, Request.

The rationale is to identify WHERE the incident is occurring and WHAT symptoms the user is experiencing. The Closure cause can categorise what the fault was.

And you should have an option of 'unknown' at each level so that, in event of the list being incomplete or the service desk staff not aware, they dont classify incorrectly.

I am finding this classification scheme extremely interesting because it offers an easy way to report back on incidents based on customer-facing services (level1 of the classification) and it allows to spread reporting for the IT organization based on functional IT services (level 2 & 3). If you implement this using n-n relationships between the lists (so that "WAN" can be used both under "Business Systems" or "E-Mail" services), then you have a pretty complete framework.

Is it something that you created yourself or it was advised to you by someone, or you read it somewhere? I'd like to get access to your source if you don't mind....

Yes, that's exactly the idea. We can immediately see what area of the business is affected and negotiate the loss of service with them. Equally we can go to the technical side and focus on the changes that are needed to correct the problem. and of course the system and service defines the CAB.

No, I did not read it anywhere, just thought about it for a long time! Some people tend to go for fuzzier classification at level 2 like "hardware" or "admin", which leads to ambiguities (Oi agree with what rjp said about 'qualifiers' earlier. The hard fact is this: Servicedesk often do not know the cause of an incident - whether it originates in hardware or software - until the call is closed.
Creation of the service catalog requires a lot of work.

Lots of good advice above. I think the key thing to consider is what purpose will your classification scheme serve? How frequently will the results be analysed? To what purpose will those results be used?

There is no need to over-complicate things - on this I speak from experience! We are actually looking to revise our opening call category scheme so that it reflects the user needs as it is currently too closely aligned to what could be termed as problem mangement categories.

I'd second the proposal for:

Service > System > Component > Incident Type

Having said that, there does seem to be very little guidance out there or agreement regarding best practice when it comes to classification of incidents. Perhaps this is something the ITIL Refresh 3.0 will seek to address?

I still think that the System > Component part of it should not be in the categorization. This will already and better be stored as a relationship with the specific configuration item involved, which is actually that "System > Component" information.

But I have to conceed that sometimes the user calls the service by the name of the system involved. In that case, you should probably name the service as the system.

A few examples that I think match the Service > Sub Service > Incident Type approach:

Got the point? Using the System > Component as part of the categorization is annoying from a support perspective - when you get the call, it is not possible to know what the cause of the Incident is - and that keeps you from categorizing the Incident properly.

On the contrary, the approach based solely on services > sub-services > incident type is resilient to the root cause identification, resilient to the configuration item identification, etc - these two come later in the process! Also, it makes much more sense to the user. Categorization of the Incident is a chance to view things from the user perspective, not from the IS technical standpoint. Leave that to the root cause and the configuration item.

Anybody wants to argue in favor of the other approach?_________________Better have remorse than regrets

I agree to your views. But sometimes, it may be necessary to have a mix of Service and component. Here is what i have to say.

The Categorization should include some way to capture how the incident has "manifested" such as "cannot login" into an email application.

i believe that these symptoms should be part of the categorization.

In most cases, the purpose of categorization is to assign it to the relevant support group. Whenever support tools are being used (such as Remedy, Unicenter ServiceDesk or HP servicedesk), the categorization is used to auto assign to the relevant support groups for the purpose of incident diagnosis and resolution. Also, the fact the most of these tools, provide only three levels of categorization i.e Category, Type and Item for auto assignment, makes it impossible not to have the components in them because otherwise, you cannot assign to these groups.

Hence, you could also have scenarios where you may have to categorize based on service ->system - > component/service as the examples below indicates.

It is only necessary to have a mix of service and component where the site in question has no other mechanism for tracking components.

Arnoldmram, your exapmle would result in either; 1000+ incident classification types in most sites, or a large number of incident types not being classified.

However, it is worth bearing in mind that when people talk about Incident classification they are usually talking about a tree of categories and sub-categories used for what might be called 'primary' classification.

These are usually not (and should not be) the only identification fields on an Incident Recordl. It is a good idea to have fields on the record that allow you to capture CI to Incident relationships where these are a factor in the Incident Report or resoultion activity.

But ultimately primary Incident classification should classify incidents - not problems or errors (which are different things with their own records and processes). Nor should they classify your infrastructure - that is what CI classification and the CMDB is for.

The user is unable to generate any letters to students notifiying them of their results.

Service : Pupil Maintenance
System : ABC Web Console (the UI to the database)
Component: Update Address (essentially one or more db scripts although the user is not aware of them)
Incident type: Not available (eg user gets 404

(other incident types might be Data Error, display, Reset )

While the CMDB has component level detail, it is not in a useful form for operational reporting. The component category above abstracts the functions of possibly several CI's and is readily applied by Service Desk staff.
I used the term 'component' in my earlier post, alhtough perhaps it would be better referred to as 'Feature' or 'Function'; that would differentiate it better from 'CI'.
In our system (ITSM from Frontrange) we can link the incident to the relvant CI, but often that infomation is not worked out until the ticket has been escalated.

There's a lot of different information and views on this, but nothing I've ever been able to find on the web either, at least no for free. I've reviewed a lot of Gartner information, etc. and here's what I came up with for my business. I'd like to get any feedback anyone has as well on this as I'm delving more into the ITIL world. Although ITIL is just a collection of common-sense or best practice guidelines, I'd like to see what this community thinks of what I came up with.

First, the software my company is using for helpdesk/problem management only allows for 3 category fields. I was used to using Remedy and had four fields previously. So this made me have to make things a bit simpler (I think). Here's an example of a few of the categories and show how it's set up using three categories, the Type, Sub-type and Category:

The point to this is that real SOFTWARE issues like installs, errors, performance issues, etc. are separated out for reporting purposes versus issues that are ACCOUNT related like account adds, permissions within apps, etc. This counts for ENTERPRISE applications only of course. MS Office for example, doesn't have anything Account related except for Outlook/Exchange which has distribution list memberships and privileges under the Accounts heading. Make sense?

I have a Network Type as well, under which is all the network issues like folder shares, equipment, and performance issues.

So, my WHOLE type list for the Enterprise is as follows:

Hardware
Software
Accounts
Network
Services
Phone & Telecom

I USED to have Printing and Web Applications as their own Types at the insistence of the group that supported them, but I've been able to pull that back so now all printing (deals with printer issues) falls under Hardware as it should and Web apps under Software as it should and accounts where appropriate.

We use a CISCO voip phone system. CTIOS is the software that lets people log on to the phone and manage calls from their computer. I'm embroiled in consideration (argument ) right now as to whether this should fall under Phone and Telecom or software. It's software and has software like issues, but it's also an integral piece of the phone system. I feel it should fall under software for issues that require software like actions like errors, installs, etc. and go under Phone and Telecom for any issues that involve the phone system only like Agent configuration issues.
The opposing view says it should ALL be located under Phone and Telecom. Any views as to that?

Hopefully this helps give at least a view point on categories and how it's structured and working at at least one major company. Any ideas or criticisms are welcome, I'm not adverse to improvement.

I am all over this forum on this topic - and anyone who is interested can veiw my post history - so I will only make a couple of comments.

Jphuff - your schema is no doubt effective in your environment and supports your processes as you have them currently set up.

I would however, caution other readers against using as a guide to other as to how incident classification should be approached.

I think it is more an effective way of taking requests in a help desk situation where there is no real distinction between incident resolution and root cause analysis (Problem Management) - and where there is insufficient configuration managment data, and service definition to relate service disruptions to underlying CI through production mapping.

The component approach to incident classification, classifies errors, not incidents.

Aside:

ITIL is far from 'just....common sense'. And it is not simply an alternative way of describing what production IT has always done. There are some real 'mindset' challenges in it - and Incident classification involves one of those challenges where first one has to rethink basic assumptions.

There is, however, no universal imperative that says anybody, or any organisation should. Rather if you want to achieve the underlying objective of the ITIL framework - going from being an ever more profficient manager of technologies, to a partner of the business in its efforts to create value for its customers, then the mindspace challenge isn't optional.