| Author | Post |
|---|
andrejs
Approved Member
| Joined: | Wed Oct 21st, 2009 |
| Location: | Latvia |
| Posts: | 7 |
| itSMF Chapter: | Latvia |
| Status: |
Offline
|
|
Posted: Wed Oct 21st, 2009 16:36 |
|
I face one question - how to count incidents in the following situation.
Something has happened with e-mail server and Service Desk receive calls stating that "e-mail is not working". First Incident was transfered to appropriate group for resolution but Incident are still approaching. New Incidents about this topic are being linked as "child" Incidents to the first "Parent" Incident.
Lets assume we received 100 complains about this before Incident was resolved and it was not a "Major Incident".
Qustion: Whether it was only ONE incident or there were 100 Incidents ?
I rise this question because in accordance to official ITIl v3 glossary and opposite to Service Requests Incidents are nothing to do with "Users".
Here it is:
Incident - (Service Operation) An unplanned interruption to an IT Service or reduction in the Quality of an IT Service. Failure of a Configuration Item that has not yet affected Service is also an Incident. For example, Failure of one disk from a mirror set.
IT Service - A Service provided to one or more Customers by an IT Service provider. An IT Service is based on the use of Information Technology and supports the Customer’s Business Processes. An IT Service is made up from a combination of people, Processes and technology and should be defined in a Service Level Agreement.
Customer - Someone who buys goods or Services. The Customer of an IT Service provider is the person or group that defines and agrees the Service level targets. The term Customers is also sometimes informally used to mean Users, for example ‘this is a Customer-focused Organization’.
As you can see no relation to "User" at all !
Was it made intentionally and for "Customer" it was only one Incident or though where were 100 Incidents ?
Regards and appreciate any help,
|
Robert Falkowitz
Registered GP21
| Joined: | Sat Nov 24th, 2007 |
| Location: | Switzerland |
| Posts: | 210 |
| itSMF Chapter: | |
| Status: |
Offline
|
|
Posted: Wed Oct 21st, 2009 16:54 |
|
Andrej,
You have two separate issues here - one is the theory of what an incident is; the other is the practice of logging and managing incidents using a specific tool.
The theory is clear, and you have said it yourself - there is only one "unplanned interruption to a service", hence only one incident. All of the other events are requests to the Service Center for support - service calls, if you will.
The practice depends entirely on your tools. Many tools distinguish between incident objects (or tickets) and service call objects (or tickets) (the latter are also called "contacts" by certain vendors). You should be able to link those calls to the incident, and often can automate the processing of the calls, based on the processing of the incident.
Other tools, especially those that continue to follow ITIL V2 in a literal way, only have incident objects (tickets). Since there is clearly a difference between the event of a technical component or a service failing, and the event of a user calling the Service Desk because of the disruption caused by that first event, we need to distinguish amongst types of incidents, so it is typical to create different categories of incidents in these tools. One category corresponds to the types of disruptions that ITIL V3 calls an "incident"; another category corresponds to the calls to the Service Desk. Again, it is often possible in the tools to link many "incidents" to a single, master incident, and do some automated processing based on those links.
The difficulty is that when you do reporting for the second case, you should break down your incident counts by category, and the official count of "incidents" (in the ITIL V3 sense) should be the count of the incident tickets of only a certain category, not the count of all the incident tickets of any category.
By the way, I would avoid naming the tickets corresponding to calls to the Service Desk as "complaints". I would reserve a "complaint" as a category of call to the service desk in which the user complains about the quality of the IT services (as opposed to reporting a failure).
Good luck,
Robert
|
IT Skeptic
Approved Member
| Joined: | Thu Jan 31st, 2008 |
| Location: | Porirua, New Zealand |
| Posts: | 38 |
| itSMF Chapter: | N Zealand |
| Status: |
Offline
|
|
Posted: Thu Oct 22nd, 2009 05:14 |
|
100 people call because they can't get to email. The calls are linked to an incident ticket. An issue is found with one email process which is restarted and 99 of those 100 users have their email back, but one of them is left waiting for days wondering when someone is going to fix his email, which isn't working because his desktop is misconfigured...
I beg to differ: there are 100 incidents. there is one problem.
|
Diarmid
Approved Member
| Joined: | Thu Mar 13th, 2008 |
| Location: | |
| Posts: | 37 |
| itSMF Chapter: | - Not Applicable - |
| Status: |
Offline
|
|
Posted: Thu Oct 22nd, 2009 08:10 |
|
IT Skeptic,
You have just invented an intermediate category between Incident and Problem, namely problem.
We have to talk a common language at least to the extent that a single discussion maintains a consistent meaning for the terms it uses.
We started out here with a concept of an incident as an event, not as a report of an event. The event was a failure of service. Let's not confuse things by changing that in the middle.
Therefore your description is of a situation where two, not 100, Incidents have occurred. The single person whose service does not recover in line with the rest has a different situation. whether that was from a pre-existing condition or from some action that person took when they lost the service or for some coincident event needs to be determined and dealt with. That is why it is useful to track, as far as practical, all those who appear to suffer from the same incident. You cannot be sure.
|
andrejs
Approved Member
| Joined: | Wed Oct 21st, 2009 |
| Location: | Latvia |
| Posts: | 7 |
| itSMF Chapter: | Latvia |
| Status: |
Offline
|
|
Posted: Thu Oct 22nd, 2009 08:53 |
|
Thanks for your quick feedback.
In simple cases it is obvious that there is only one "unplanned interruption to a service" (Incident) and all the rest is related to this event.
But how in this case to treat the 99 "requests for support" from ITIL v3 perspective ?
They are neither pure "incidents" nor pure "requests for service".
From "User" perspective who act on behalt of "Customer" these events are "Incidents" besause for each particular "User" service is not delivered and from "Customer" perspective there is only one "unplanned interruption to a service" which was noticed by 99 "Users".
What would be the best way to reflect these 99 events in reporting to "Customer" from ITIL v3 point of view?
Regards,
|
Diarmid
Approved Member
| Joined: | Thu Mar 13th, 2008 |
| Location: | |
| Posts: | 37 |
| itSMF Chapter: | - Not Applicable - |
| Status: |
Offline
|
|
Posted: Thu Oct 22nd, 2009 09:15 |
|
andrejs,
my perspective on this is that the calls are neither incidents , nor requests for service. They are simply reports of lack of service which typically indicate an incident.
The 99 calls report something indicative of an incident which you then diagnose and determine that they are, or are very likely to be consequent on the incident that you identified after one or a few calls. From user perspective each one is aware of an incident, but they don't go around saying "oh! you've got an incident too" but more likely "hey! that has happened here too" In other words they don't think collectively of 99 incidents, they just think something is wrong and they want it fixed.
|
andrejs
Approved Member
| Joined: | Wed Oct 21st, 2009 |
| Location: | Latvia |
| Posts: | 7 |
| itSMF Chapter: | Latvia |
| Status: |
Offline
|
|
Posted: Thu Oct 22nd, 2009 09:41 |
|
Thanks Dearmid!
I agree completely but what to do with these 99 calls (events, cases, whatever) ?
Should I just ignore them or record somehow and if the latter what are they from ITIL v3 perspective ?
Regards,
|
Beno
Registered GP3
| Joined: | Fri Dec 7th, 2007 |
| Location: | Slovenia |
| Posts: | 5 |
| itSMF Chapter: | |
| Status: |
Offline
|
|
Posted: Thu Oct 22nd, 2009 09:41 |
|
Hello to all.
Let’s have a look at services from End to End perspective.
Let’s take an example. If I go to the restaurant I would expect a solid service. If my dinner is burned out I am not satisfied with the service and I would make complain (I would report an Incident). Interestingly the other Guests would also get dinners burned out, but I don’t care about them. It is Me that is important and I got an unplanned interruption of service.
Though the cause might be the same (failure at kitchen-range), but again, the Menu (service catalog) said the dinner will be tasty and I received disruption in service.
IT service is not something that sits in IT Datacenter. The service exists when it serves someone, while it is Consumed by someone, when it is bringing value to someone. If I am not getting value that we can talk about bad service, IT service. And again when we talk about unplanned disruption I talk about incident. In case of 100 users they all are receiving disruption in service so 100 incidents. They might be related or joined but still there is 100 incidents.
Service Strategy page 129.
Service production cannot occur without the concurrent presence
of demand that consumes the output. It is a pull-system in
which consumption cycles stimulate production cycles.
Benjamin Orazem
|
IT Skeptic
Approved Member
| Joined: | Thu Jan 31st, 2008 |
| Location: | Porirua, New Zealand |
| Posts: | 38 |
| itSMF Chapter: | N Zealand |
| Status: |
Offline
|
|
Posted: Thu Oct 22nd, 2009 09:59 |
|
You are right Diarmid, that i should not have used a Problem as the collective object. One generally accepted practice is a Master Incident to which the others are linked, though that does not appear in ITIL V3.
I'm not saying you guys are wrong. I like your model. The concept of a single incident for many users is a nice one, but I don't think you can say it is a universally accepted one.
A call should probably be a separate entity from an incident. But in ITIL V3 it is not. Service Operation says an incoming call is categorised as an incident or a request (e.g. 6.2.2). Actually it doesn't say very clearly - it is vague about many important things. The fact that the book cannot be used to unambiguously answer a question as fundamental as this reflects badly on it. (The book doesn't say how best to record a followup call for an open incident either)
ITIL V3 certainly does not recognise any entity called a Call or a Contact distinct from an Incident and nowhere does it talk about associating a Call with an Incident let alone linking multiple Calls with a single Incident. Nowhere does it mention logging a call then attempting to match the call to a known incident. (So some products that have been certified by OGC as Incident-process-compliant will not have a distinct call entity record in them or will require the incident record to be created first and then the call associated with it.) And ITIL only talks about an Incident as being associated with a single user.
As I say, I like the model. It would be great if it was in ITIL so we could all settle on it.
|
Diarmid
Approved Member
| Joined: | Thu Mar 13th, 2008 |
| Location: | |
| Posts: | 37 |
| itSMF Chapter: | - Not Applicable - |
| Status: |
Offline
|
|
Posted: Thu Oct 22nd, 2009 10:00 |
|
andrejs,
there is a thread live on the itilcommunity forum on this topic right now. You will find more ideas there that complement what is being said here.
Beno,
(sorry to do two in one, but I'm trying to jump in the car and drive to kirriemuir which will take all day)
If you manage these as one hundred incidents then you have to go through one hundred resolutions. Apart from the logistical problems, you will also have to draw up some unorthodox measuring systems, the only good side of which is likely to be that you never have to maintain data about how many people are affected by an incident since it will always be one.
I am inclined to think you still have problems because not everyone affected will make a call. Especially those who share a workspace are likely to let just one call suffice. and so you don't have a record of every incident. How many people suffer when the stock market crashes? how many incidents is a stock market crash?
It seems to me that a simple combination of basic definitions and practical common sense is all that is needed.
Incidents are events that lead to loss or damage to service or threaten to do so. Whatever the event has been the resolution of the incident is to restore, recover, or make good the service. One of the steps is to make sure that all who were affected by it are once again experiencing the service as required.
The link between the quote on service dynamics is hardly to the point in this context. It is a wholly abstract description when the issues are tangible and practical.
If you need to define incidents in terms of experience rather than event, how do you manage deleterious events which have a delayed impact? you need a new category for them if they are not to be incidents.
Is all this hoo ha not more to do with the nature of tools rather than the management of services?
|
andrejs
Approved Member
| Joined: | Wed Oct 21st, 2009 |
| Location: | Latvia |
| Posts: | 7 |
| itSMF Chapter: | Latvia |
| Status: |
Offline
|
|
Posted: Thu Oct 22nd, 2009 10:02 |
|
Good example, but why ITIL v3 do not directly stating that Incidents are seen from "Users" point of view not "Customers" ?
For example "Service Request" definition is stating clearly that it is "A request from a User for information or advice, or for a Standard Change or for Access to an IT Service. For example to reset a password, or to provide standard IT Services for a new User. Service requests are usually handled by a Service Desk, and do not require an RFC to be submitted. See also Request Fulfilment."
Key word is "User".
|
Diarmid
Approved Member
| Joined: | Thu Mar 13th, 2008 |
| Location: | |
| Posts: | 37 |
| itSMF Chapter: | - Not Applicable - |
| Status: |
Offline
|
|
Posted: Thu Oct 22nd, 2009 10:11 |
|
ITSkeptic,
I'm not going to defend V3, partly because I have never seen it and partly because I keep hearing bad things about it.
What I am arguing is pure ITIL and emanates from long years. however there is no such thing as "pure ITIL" because ITIL started out as guidance on best practice. As such it did not intend to be very specific about the fine details of how you behave operationally because it recognized that there is a wide range of circumstances in IT services. For me this is still true and I am much more concerned with identifying what kind of processes and what classes of information and what kinds of issues have to be resolved to deliver service because they are more generally applicable. The fine detail goes in to the development of any particular organization and does not rest well as a generality.
I'm gaining the impression that ITIL three is trying to do more and perhaps ITIL 2 did to some extent, although I always regarded it as advice rather than prescription and took the detail as example rather than rule. whether this is a fair interpretation or not, it seems clear that many very people are treating it this way and constantly asking what ITIL says about brushing their teeth in the night shift. I guess this is so because mangers are always looking for quick and simple answers to complex problems and would rather buy a book than engage their brain.
|
andrejs
Approved Member
| Joined: | Wed Oct 21st, 2009 |
| Location: | Latvia |
| Posts: | 7 |
| itSMF Chapter: | Latvia |
| Status: |
Offline
|
|
Posted: Thu Oct 22nd, 2009 10:16 |
|
My concern is SLA and reporting because it is two big differences whether to show 1 Incident in report or 100 Incidents.
From technical point of view there is absolutely no problem because for sure there will be one "Master" Incident and all the rest "Slave".
|
Robert Falkowitz
Registered GP21
| Joined: | Sat Nov 24th, 2007 |
| Location: | Switzerland |
| Posts: | 210 |
| itSMF Chapter: | |
| Status: |
Offline
|
|
Posted: Thu Oct 22nd, 2009 10:19 |
|
Andrej,
In your organization, you ought to clearly define your terms. There is no point is discussing here those definitions. ITIL has provided some. Use them, or not, as it suits your organization.
The key to understanding how to treat these contacts from users, be it by telephone, by email, by a web site, or whatever, is to understand that these are moments of truth for the users. Their satisfaction with IT depends largely on how you treat those contacts. Typically, they are concerned that you:- are available to give support when the user needs support
- respond as quickly as you agreed to respond
- are courteous, helpful, kind, ernest, cheerful, etc.
- give genuine help in an efficient way
- keep them informed of what is happening
These are all measurable, although some may depend on asking the users their subjective opinions of your service, whereas others, such as the Abandoned Call Rate, or the Mean Time to Respond, etc., can be measured by technical means.
All of this is distinct from, albeit related to, the business of resolving the incident. You can do a fantastic job of resolving incidents, but be terrible in your user relations - what do you think the users' opinions of IT will in that case?
This is just the long way of saying that these contacts with users are important, and you probably need to manage them. What should you report to the users?
- How many times do users ask for any type of support (I do not care what you ultimately decide to call this, although I am perfectly happy with "Service Request" - the service being end user support) - this shows how much you are working to support your users
- How often do you fail to respond in a reasonable time - this is a relative indicator of how much productivity the users are losing
- How satisfied do the users say they are with your support service - this is an indicator of how well you are listening to your users and making attempts to improve your service
In addition, you will probably want to measure and manage these contacts for internal purposes:- What is the abandoned call rate? - this is used to manage the capacity of your service desk
- How are the support requests distributed amongst your agents - this supports workload management
- How accurately do the agents log the support request information?
- How long does it take the agents to resolve the support requests, independently of the resolution time of any related incidents (this one might be complicated to measure) - this helps you to understand and manage the efficiency of your support.
One last bit - you ask if you should be recording the support requests. This opens up a lot of issues. Recording this information is overhead. If you measure your service desk agents on the number of calls they manage, or on the mean time to resolve a call, they will NOT want to log what they do, because it slows them down and makes their statistics look worse. So you need to have balanced measurements. If your service desk is like most service desks, it will be very hard for the agents to remember the details of the open requests, and very hard to remember what is resolved and what is not, unless they log this information. And if you do an active job of managing the support service (which is probably a very good idea), it will be hard to identify trends, priorities for improvement, etc., unless these support requests are logged.
Keep the faith,
Robert
|
IT Skeptic
Approved Member
| Joined: | Thu Jan 31st, 2008 |
| Location: | Porirua, New Zealand |
| Posts: | 38 |
| itSMF Chapter: | N Zealand |
| Status: |
Offline
|
|
Posted: Thu Oct 22nd, 2009 11:04 |
|
Diarmid
It is not an easy question. Are we to have a separate entity called a Contact or Call? If so, do we need to record a call and then create a Service Request associated with it, or is the request a category of call? If it is a category, then what category do we call the calls that relate to an incident? Maybe the category of call is called an Incident, and the new entity we are introducing that isn't in ITIL should be an Interruption? That would make more sense and it would help resolve the confusion introduced by ITIL V3 deciding that an Incident is not just an interruption to service but also a potential interruption to service.
If we had an Interruption entity then that would make service level reporting much easier wouldn't it?
Why is it that twenty years into ITIL's history we are still debating this stuff and the book holds no unambiguous answers as to what is best practice in ITIL's core heartland process? I agree that there are some things sites can work out for themselves. There are other things where there is a best way and/or a generally accepted way, and I thought ITIL was about saving folk the grief of having to re-invent that stuff for themselves, not to mention getting some standarisation in the industry.
For fun, I'm running a poll on the blog: one incident or 100? http://www.itskeptic.org/hundred-users-call-and-say-they-cant-get-emails-on
Last edited on Thu Oct 22nd, 2009 11:05 by IT Skeptic
|
Current time is 03:53 | Page: 1 2   |
|
|
|