Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: Sheldo57S
New Today: 27
New Yesterday: 97
Overall: 149973

People Online:
Visitors: 43
Members: 2
Total: 45 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - Incident Categories
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Incident Categories
Goto page 1, 2  Next
 
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk
View previous topic :: View next topic  
Author Message
ctipton
Guest





PostPosted: Thu Jul 14, 2005 2:26 pm    Post subject: Incident Categories Reply with quote

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?
Back to top
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Fri Jul 15, 2005 6:40 pm    Post subject: Reply with quote

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 Laughing

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:

MS Power Point
Outlook
SAP Financials
Exchange
Purchasing Leave Calendar

Does the following add to the usability of the list, assist with assignment rules, or capture other information that won't be captured elsewhere?

Desktop App -> MS Power Point
Desktop App -> Outlook
Enterprise App -> SAP Financials
Enterprise App -> Exchange
Web App -> Purchasing Leave Calendar
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
dailo
Newbie
Newbie


Joined: Jul 16, 2005
Posts: 7

PostPosted: Sun Jul 17, 2005 2:01 am    Post subject: Reply with quote

yeah that sounds good. at my workplace we only got 2 categories but its still need refinement

Desktop Applications - MS Office, Norton Anti-Virus, Publisher, Adobe Acrobat, Netscape...etc

Business Applications - SAP, Oracle, Citrix, i2, Siebel...etc
Back to top
View user's profile
Jules
Newbie
Newbie


Joined: Dec 22, 2005
Posts: 10
Location: South Yorkshire, UK

PostPosted: Thu Dec 22, 2005 9:09 pm    Post subject: Categories Reply with quote

My categories would be

Service > System > Component > Incident Type

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.
Back to top
View user's profile
Fabien
Senior Itiler


Joined: Sep 27, 2005
Posts: 207

PostPosted: Sat Jan 14, 2006 6:34 am    Post subject: Reply with quote

Jules,

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

Thanks!!
_________________
BR,
Fabien Papleux

Accenture
Technology Consulting | Service Excellence
Red Badge Certified

Twitter @itilgeek
Back to top
View user's profile Send e-mail Visit poster's website MSN Messenger
Jules
Newbie
Newbie


Joined: Dec 22, 2005
Posts: 10
Location: South Yorkshire, UK

PostPosted: Sat Jan 14, 2006 7:27 am    Post subject: Reply with quote

Hi Fabien

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.
Back to top
View user's profile
xitil
Newbie
Newbie


Joined: Jan 17, 2006
Posts: 13
Location: France

PostPosted: Wed Jan 25, 2006 5:37 am    Post subject: Reply with quote

rjp and Jules approach sound like the most efficient to me as well.

In our company, we did it all wrong... our categories look very much like our IS organization:

business application support -> departement a
business application support -> departement b
is application support
pc support
network
systems
etc...

What a failure!

Our categorization is useless!

We need to take it from the user perspective... it is much easier to categorize then.

We will revise our approach soon, and very liely, we'll be using something like that:

Service > Sub Service > Incident Type

We'll leave the system > component information for the configuration item.
_________________
Better have remorse than regrets Wink
Back to top
View user's profile Visit poster's website
itilimp
Senior Itiler


Joined: Jan 20, 2006
Posts: 172
Location: England

PostPosted: Wed Jan 25, 2006 7:59 am    Post subject: Reply with quote

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?
Back to top
View user's profile Visit poster's website
czr12x
Newbie
Newbie


Joined: Feb 02, 2006
Posts: 1

PostPosted: Sat Feb 04, 2006 6:32 am    Post subject: Reply with quote

Hello all - can the group please provide some examples using the following?

Service > System > Component > Incident Type

BTW - this is a geat place!! I am finding lots of VERY useful info here. Hopefully I will be able to provide some along the way.

CZ.
Back to top
View user's profile
xitil
Newbie
Newbie


Joined: Jan 17, 2006
Posts: 13
Location: France

PostPosted: Sat Feb 04, 2006 7:30 am    Post subject: Still think Service > Sub Service > Incident Type is b Reply with quote

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:

e-mail > send/receive > server unavailable error
e-mail > archiving > how to
e-mail > address book > corrupted
e-mail > other
erp > hr > payroll > reports > how to
etc

I think this is better than

e-mail > Outlook > connections > server unavailable error
e-mail > Exchange > serverx > network card > not responding
e-mail > Exchange > serverx > hard disk > out of disk space
etc

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 Wink
Back to top
View user's profile Visit poster's website
arnoldmram
Itiler


Joined: Mar 08, 2005
Posts: 36

PostPosted: Sat Feb 04, 2006 4:22 pm    Post subject: Reply with quote

xitil,

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.

Application -> Lotus notes -> Email - > cannot login
Access control - >Server geography -> server name->cannot access.
Hardware ->printer-> <printername>/Network ->cannot print

Let me know your views.
Back to top
View user's profile
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Sat Feb 04, 2006 5:11 pm    Post subject: Reply with quote

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.

And IMHO that would be the general consensus of this thread.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Jules
Newbie
Newbie


Joined: Dec 22, 2005
Posts: 10
Location: South Yorkshire, UK

PostPosted: Mon Feb 06, 2006 10:11 pm    Post subject: Reply with quote

Here is an example of Service / System / component / Incident type

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.
Back to top
View user's profile
Jphuff
Newbie
Newbie


Joined: Feb 23, 2006
Posts: 4

PostPosted: Sat Feb 25, 2006 6:33 am    Post subject: Categorization Reply with quote

Ok,

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:

Type:
Hardware
Software
Accounts
Network

So, for example, we can have:

Hardware/DesktopPC/Boot Issue


Software/ApplicationX/Error
Software/ApplicationX/Install needed
Software/ApplicationX/Unavailable
Software/applicationX/performance issue

However, ACCOUNT related issues, even with applications were sorted under the Account heading like so:

Account/Applicationx/Password reset
Account/Applicationx/account create
Account/Applicationx/modify permissions

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.

Computer account password resets for example are coded as Accounts/ADS(for Active Directory)/Password Reset

Pure software issues go under Software and where applicable, account related activities even when related to software packages go under Accounts.

Network holds infrastructure equipment issues and connectivity

Services is a small structure that holds things IT provides that are Services, like burning customer data to CD's, etc.

Phone and Telecom holds things like Phone setups, Agent and queue configurations.

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 Smile ) 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? Smile

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

Thanks!
Back to top
View user's profile
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Sat Feb 25, 2006 3:03 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk All times are GMT + 10 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.