| Author | Post |
|---|
djcannon
Registered GP5
| Joined: | Tue Nov 25th, 2008 |
| Location: | Allen, Texas USA |
| Posts: | 5 |
| itSMF Chapter: | U.S.A. |
| Status: |
Offline
|
|
Posted: Thu Oct 22nd, 2009 14:45 |
|
Andrej,
The theoretical discussion around this can go on forever and every answer you receive will be "correct" in some ways and "incorrect" in others. Bottom line, this is not a theoretical argument, it is about how you decide to manage disruptions to service.
There are two main thing to think about here: "what are you trying to do?" and "From whose perspective are you measuring?".
"What are you trying to do?" If it is an incident you should be trying to restore service. In this case, what logging method is going to help you most? I would argue that the more you know about which users / customers are affected the better you understand the impact and scope of the incident. How you log these will depend on which tool you use and how you measure service quality. There are several options ranging from "log it once and indicate the impact by checking the database to see how many users use that system" (not very good, because the database doesn't tell you whether those users are experiencing any disruption) - to "log it once and then just increment the count in the first incident record" - to log a separate incident for every person that calls. The question you should ask is - what is going to give you the level of information that you need to resolve this incident in the agreed time.
Also, always remember that your primary goal is to deliver services that meet the business objectives - defining the incident simply in terms of the device or application that fails is not adequate to meet this goal. The way you log incidents should always represent how it (or potentially will) impacts the business.
"From whose perspective are you measuring?" When dealing with service disruptions and service quality, it is always best to measure from the point of view of the person receiving the service. Hence the word "customer" was used instead of "user". Without getting into a debate, it may have been clearer if both "customer" and "user" were included in the definition, because in this particular case it applies to both. Following this train of thought, my opinion is that the way you log incidents should represent the way it is being experienced by the person calling the service desk. When defining the incident from the user / customer point of view it is clear that every person impacted by the disruption will view it as an incident - and most of them will not care about who else is impacted, as long as they can carry on working. So I lean towards finding some way of recognizing each call as an incident - either by logging each separately or finding some way of representing how many calls were related and who they came to.
There is one major caution, however. Failures don't always happen singly, they are often combined. If you assume that because the email server is down that every person who calls with similar symptoms is experiencing the same incident, then you could be headed toward disaster. Let's just say that two major systems went down together and you assumed they were the same thing and stopped recording individual incident records. How long before you detect the second failure and fix it? I have been in way too many situations where I was denied service because someone had fixed the incident, and told me I couldn't possible experiencing any outages - only to find out some time later that there was actually another incident that they had been ignoring because nobody had been logging the subsequent calls as incidents.
The answer for your organization will depend on a number of factors, but I think it will end up being a balance of these two factors (combined with the size of your organization, call volume, resources available to take calls, log incidents, etc.). Whatever you do, implement what makes sense for you.
|
ivor
Registered GP18
| Joined: | Thu Nov 29th, 2007 |
| Location: | Swindon, United Kingdom |
| Posts: | 67 |
| itSMF Chapter: | U.K. |
| Status: |
Offline
|
|
Posted: Thu Oct 22nd, 2009 15:02 |
|
I agree totally with David - it is never simply about definitions, it is always about service - that's why this called 'service management' - because it is about service and because it needs 'managing' - not just following rules.
A key point in all this is that, just because 100 users are affected, it does not mean the impact is the same in every case, nor even in any two of them. It could be 99 part-time occasional users are affected, and then #100 is business critical - at that point the nature changes, so recording - to the required degree - is necessary for each instance. If you know for sure that your workforce is totally homogeneous, then you need less separation. But - as David says - the nature of incident recording is dependent on the type of service actually or potentially affected - not the infrastructure component.
|
andrejs
Approved Member
| Joined: | Wed Oct 21st, 2009 |
| Location: | Latvia |
| Posts: | 7 |
| itSMF Chapter: | Latvia |
| Status: |
Offline
|
|
Posted: Thu Oct 22nd, 2009 15:32 |
|
Thanks Ivor and djcannon for your feedback.
My consern is to report correctly to "Customer" who is paying money for service being consumed by his "Users".
So, whether it is to report 1 Incident as one case of "service disruption" which was noticed by 100 "Users" or to report 100 Incidents ?
If you, as experts judge that all Incidents should be recorded and treated as separate "service disruption" (I have the same opinion) why not just to amend Incident definition and to add only one word "User" ?
This discussion will be settled for good. 
|
djcannon
Registered GP5
| Joined: | Tue Nov 25th, 2008 |
| Location: | Allen, Texas USA |
| Posts: | 5 |
| itSMF Chapter: | U.S.A. |
| Status: |
Offline
|
|
Posted: Thu Oct 22nd, 2009 21:45 |
|
| Good suggestion, I will request the change
|
Current time is 18:13 | Page:   1 2 |
|
|
|