Incident Classifications - Clarification

[BAX]

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.

For example:

Email (Service) >> Exchange Email (System) >> Outlook Client (Component) >> Advice (Incident)

We have been toying with a 3 tier model:

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.

For example:
Email (Service) >> Exchange Email (System) >> Advice (Incident)

Or alternatively:
Email (Service) >> Outlook Client (Component) >> Advice (Incident)


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

[rjp]

Paul,

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)

[BAX]

Many thanks for your replies RJP. You are definately an asset to this forum.

Just one quick question...

Could you please clarify what a CI is? That was the only thing i didnt understand from your previous post.

Thanks again.
Paul.
_________________
Paul R Baxter
IT Support Analyst/DBA
University of Leeds, UK

[rjp]

Thanks Paul - de nada,

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.

[scis_chris]

hy there

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.

[DeanoB]

Quick question rjp, by using a 2 or 3 tiered of :

Service >> System >> Incident Type

That works fine for things such as :

Printing >> Network Printing >> Error
Printing >> Local Printing >> Paperjam
eMail >> Outlook >> Logon
eMail >> WebMail >> Calendar

etc etc.

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.

What I've started to do is this :-

Printing >> Apple Network Printer >> Error
Printing >> Windows Network Printer >> Paperjam
Printing >> Windows Local Printer >> Cartridge
Logon >> Apple Mac >> Password
Logon >> Windows PC >> Account Locked

This allows me to direct these types of incidents as well as report on them, but my second tier then becomes multi purpose and I'm not sure it'll work.

Any thoughts ?

[itilimp]

In our case we've got classification for ourselves and a separate classification for the users who log calls via the intranet.

In the background, we have mapped their classification to our 4 level classification.

e.g. User logs a call and picks Logon > Forgot Password

This maps automatically to Security > User > Logon > Password

You may want to see whether your system will allow you to do something similar, or use call templates which prefill in the classification based on the template name to make it easy for your users.

Hope that helps.

[Nikhil]

HI,

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.

e.g. Summary - Cannot logon to People Soft.
Categorization:
Service - HR System
System - Peoplesoft
issue - Logon

This would make it easier for the end users to log call's.

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).

This new method is not tested yet, but on the whole should work.

Hope this helps.
_________________
Regards,
Nikhil Kulkarni.
Application Analyst
cMango.. The Services Management Company

The taste of low quality lingers long after the satisfaction of low price.

[alejosure]

Hi

We're facing this dilemma with the categories:

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.

[BAX]

OK, sorry to bring this one back in to existence, but we have been working on this for months now. And here is our latest dilemma...


Our new design for classification now looks like this:

Service >> System >> Incident >> Root Cause

e.g.
Network/Telephony >> Campus network >> Connection Issue >> Equipment

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...

Service = Finance + Payroll Services
System = SAP - Finance
Incident = Client Issue
(inherently, Service Cat = 'Covered' and Service Type = '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

[Globis]

Don't lose sight of what you're trying to achieve with all of this, namely the swiftest possible restoration of service to the user.

So does having 4 or 3 or even 2 tiers make it any quicker to fix the problem from the user's perspective?

Go talk to our helpdesk (sorry Service Desk) and see how they solve problems today. Even better go work there doing incident intake for a week.

Remember that if you radically change how the SD works today, whatever you choose will be irrelevant as it will not work. IT is easy to change, people are not.

Finally stop worrying about it and go implement. Practical experence is way more useful than academic debate - and if you get it wrong it is not a train smash, just go back and try something else.

Dave

[BAX]

Thanks for the reply Dave,

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

[doc]

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.

For reporting purposes we use Incident-CMDB relations and we are fine.
_________________
doc
http://itservicemngmt.blogspot.com/

[BAX]

Thanks Doc.

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