Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
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.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
Posted: Wed Jun 14, 2006 9:59 pm Post subject: Incident Classifications - Clarification
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.
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
Joined: Mar 12, 2005 Posts: 255 Location: Melbourne, Australia
Posted: Fri Jun 16, 2006 3:40 pm Post subject:
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)
Joined: Mar 12, 2005 Posts: 255 Location: Melbourne, Australia
Posted: Tue Jun 20, 2006 12:29 am Post subject:
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.
Posted: Tue Jul 04, 2006 7:20 pm Post subject: service modelling
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.
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.
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.
Posted: Sun Sep 17, 2006 6:36 pm Post subject: Summary field can help
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.
Joined: Oct 26, 2006 Posts: 2 Location: Bogotá, Colombia
Posted: Sat Oct 28, 2006 1:28 am Post subject:
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.
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
Joined: Apr 17, 2007 Posts: 36 Location: Cape Town
Posted: Tue May 01, 2007 2:37 am Post subject:
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.
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
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