The popular choice for incident classification is definately the 4 tiered model:

Service >> System >> Component >> Incident Type

Service is a business activity, as defined in the service definitions
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.

Service >> System >> Incident Type
Service is a business activity, as defined in the ALD’s
System is an identified application (which must be used by the service) including client and server side
-Omitted- (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.

Our new model currently looks like this (and is problematic!):
Service >> System (or Component) >> Incident Type

Each of the 3 tiered models seem to be lacking. In the first example there is a leap between Exchange Email and Advice. In the second example, there is a leap between the Email Service and the Outlook Client.
Our current model has components spilling out into system and also into incident.

Looking at the above, the 4 tiered model looks more favourable and would resolve this problem. ???

Does anyone else have any insight in to this?
I think we have hit the nail on the head here...

Kind regards,
Paul._________________Paul R Baxter
IT Support Analyst/DBA
University of Leeds, UK

the right track definitely, but I suspect you are going to take a hit at call logging, incident matching, utilising known workarounds and reporting by having a four-tier classification.

Consider what your classification needs to do: Which is only to decide further action - to whom it must be sent, what process must be followed.

Also consider what information needs to be collected as the incident resolution unfolds, but does not really further the aims of classification. That information can be relegated to other fields, so you can still report and analyse.

If you align your service definitions to support requirements by making sure you collect and document the various types of ownership - technology, business process, documentation, service request deliverables, etc., then that will meet the core requirements with a 3 or even 2 tier schema - Incidents can be assigned on the basis of known ownership for services, managed at that level and monitored from the Service Desk. Then put the component data for break-fix incidents recorded elsewhere on the record.

Such a separation of schemas will allow for easier and more relevant reporting. A 'principal' I use all the time, and which has been very helpful is - don't use one process to achieve the objectives of another. CI classification belongs to configuration management - your Incident Management schema should not compensate for a lack of configuration management by classifying your CIs.

Besides judging from your posts, I would say ownership is really decided at what you are calling the "System" level - which means removing the "Component" information to another field isn't going to change the ability to initiate the correct action. (Or collect and report on break-fix data)

CI = Configuration Item. Not quite the same as 'asset' or 'component' though these can certainly be CIs. A CI is effectively whatever it is in your infrastructure that you decide to record, track and otherwise manage (ideally through your Configuration Management Database). So a CI may be records of components, documentation, software instances, etc. It may also be aggregate collections of other CIs that have a relevant 'identity' in terms of your management requirements - for example you may record a 'system' as a single CI, made up of other CIs. The primary addition to the CI (and the CMDB) is that it should encapsulate relationships that show how things are 'configured', eg, depends on, requires, is a component of, etc. I would argue that recording the relationships a CI has to other CIs is more important than recording the attributes of any individual item.

Your 'CI' clasifications will categorise you infrastructure. My point is that while it is important to classify infrastructure, and to be able to report on it according to its classes, doing so is not a function of incident management. Rather it is mostly the responsibility of Configuration Management processes, (but should also be integral to a broader service development and improvement cycle).

Incident management objectives suffer, when due to a lack of supporting processes, incident classifications are used to compensate. So you do not actually need classes in you IM schema that look like 'software' 'hardware' 'Microsoft Office', 'printer' etc etc.

NB: Having said that, I do acknowledge that we live in the 'real world'. If you have to use component schemas to decide how to act on an incident then you have to.

i think the idea isn't bad. but what you are trying to do is to built a service modell in a categorization. this is in my opinion really dangerous, because i doubt that anyone can do a proper categorization of an incident like this. you always have to know the impactet service for each client for each incident which in fact isn't possible to find out. in addition there could be several services which are impacted by one incident... how will you do the classification of a such incident?

my opinion is that we should do the classification of a incident only to the impacted ci an the symptom of the incident. in a service desk you can't say more about it. the ci should be included in a service model that you can find out the impacted service or the impacted services.

However, what I'm really struggling with is because my users (not just Service Desk Technicians) can raise their own incidents and choose the classification, I have to keep away from terms live "Active Directory" or "Exchange Server" as they simply won't understand these. I do however need it to be able direct the incident, should it need escalating, to the relevant area of responsibiliy. As well as report on incidents etc.

Being an Remedy Professional, I would suggest the method that Remedy prefer's and which has worked well with most of our customers. Make use of a summary field, which inturn is tied up with the Categorization. This categorization could be 3 or 4 tiered.

With the latest version, Remedy has come up with multiple classifications.
Operational and system classification. The operational classicifation is used from the service perspective (for normal end users). The system classification is used from the Hardware identification perspective (moreso from support and highend users).

We can have a list like this: {service} -> {component} -> {action/issue}
When the issue is something like reporting or monitoring, it comes up that we can turn it around to become reporting or monitoring itself in a service, this way: monitoring -> {system/application} - {action/issue}

So, almost all services can have a third level category named, in this example, monitoring. But monitoring can be seen itself as a service which inside has the "services".

Which should we use? why?
We've discussed it from the reporting point of view, as well as from the assigning point of view, and can't find yet a strong reason to use one better than the other.

Now, we plan to take away some extra classification and tie it in to the above model:
Service Category (how it's funded) - will be based on 'Service' selected.
Service Type (incident/service req/etc...) - will be based on 'Incident'.

The problem we are facing now is that the 'Incident' is very incident specific, so how would we go about classifying an information request on an incident type?

For example:

Imagine someone having a query about a finance system client package, but not an incident...

A way round this is to have 'Info Request' as an 'Incident' for every 'System', but is this not duplication of the 'Service Type' and hence not the correct place for it. ???

Is the answer to make 'Incident' not too specific to incident types, but to make it more like a 'component' of system - then leading way to whether it is a service request, incident, change req, etc... I have reasons why this is not preferable however.

I know this is a complicated business but any thoughts on this would be muchly appreciated.

Many thanks,
Paul Baxter._________________Paul R Baxter
IT Support Analyst/DBA
University of Leeds, UK

I think we are on the right track. We have a 3 tier classification structure based on services offered. We have also duplicated the sub systems and incident types across the services (where needed) as the customer (or service desker) will not necessarily know which service is being problematic (this is especially true with systems that cross over).

My main angle on this, is: If it's simple enough for the customer to use (through a self service portal) then it should be simple for the Service Desk also.

All we need from this fundamentally is for the service desk to be able to accurately classify incidents/requests. This will either aid resolution at first point, or assist in a rapid referral to second line (without bouncing an incident round every support team before it reaches the correct one).

I also have 5 years experience of service desk and service desk development so i am fully aware of the problems this may cause. Keep it simple it my advice.

We are approaching the suck it and see point, so I will report back on our progress. As long as the structure is right, then we can change the data at any time.

Many thanks,
Paul._________________Paul R Baxter
IT Support Analyst/DBA
University of Leeds, UK

In our Peregrine SC system we had a standard 4 tier classification, then we developed our own system and for a brief time implemented a 5-tier:

Business Service/Service/System/Component/Type

Then we realised that it was difficult to fix the categorization depth for different levels of ServiceDesk expertise.

So we developed a categorisation tree with free depth (customizable). We are MS experts, and don't do much NW support, so the depth on MS infrastructure subtree is deep 5 nodes, and on NW we have depth of 3.

I think the general concensus is that the classification structure does indeed depend on the expertise of the service desk.

Our service desk (like many others) has a pretty steady turnover, and hence skills and knowledge are variable. Our intention is to provide a classification structure that is easy enough for a customer to navigate (for our self service site). If this is the case, then it should be simple also for the service desk to use.

It would also appear that the depth required depends on the environment. We support a very wide range of products, services and systems hence our 3 tier system. We had a 2 tier system and the structure just wasnt good enough. We will be implementing the new structure within the next 6 weeks so i will let you all know how we get on with it.

Bax_________________Paul R Baxter
IT Support Analyst/DBA
University of Leeds, UK