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.
The Itil Community Forum: Forums
ITIL :: View topic - One ore several incident records?
Posted: Wed Feb 06, 2008 11:31 pm Post subject: One ore several incident records?
Hello,
I propose you the following scenario :
1) A user calls the SD because he cannot access an application page.
2) A second user calls for the same reason
3) Then a third
….
After a rapid investigation Production states that there was an issue with the DNS server, everything will be fine by 4pm.
What should be the SD behaviour in this case?
It opens an incident record, after a rapid look assigns it to a Production specialist
Then it logs each call on the same incident record
Then the production specialist resolves the incident
OR:
It opens an incident record per call
After a rapid look (the incidents are so similar) it opens a problem records and links the incidents to the problem and assigns the problem to the Production specialist
Then the Production specialist resolves the problem record and this resolves the incidents
Then SD closes the incident records one by one once sure it is fine for each user that has called the SD.
I prefer the second solution; in my view each call is a different incident even if related to the same shortage. Even if it produces an overload in Incident Management.
What’s your opinion? What would you consider the incident? Each interruption of service raised directly by a user (customer point of view) or the single Production shortage?
I'd open a master Incident record and link all the others that come in to that one.
That way Incident Management just have one incident to deal with.
However in the interim (and really quickly) I'd add a message to the Service Desk's IVR saying that if you are having this problem we are aware and dealing, no need to log a call...
In that way, Service Desk don't get floods of calls for the same thing...
Hi Skinnera,
Thanks for your answer, and what about reporting? Still referring to the same scenario do you consider you had several incidents or just one in your weekly stats?
Joined: Jan 03, 2007 Posts: 189 Location: Redmond, WA
Posted: Thu Feb 07, 2008 12:59 am Post subject: Re: One ore several incident records?
In a perfect world (ITILTopia), the way it would work would be:
-The SD receives the first call and opens an Incident record.
-The SD receives subsequent calls and opens additional records.
-The SD recognizes that there is a Problem and notifies the PM team that there is an issue that needs investigation (a SD analyst could open the Problem ticket directly, but at that point they would be performing an activity of Problem Management).
-Every subsequent call is a new Incident linked to the Problem ticket.
-Problem Management investigates the issue and discovers a Workaround (if available).
-Every subsequent Incident is resolved to the Workaround. If you have the manpower, you can look at unresolved Incidents associated with the Problem and apply the Workaround to them as well.
-When Problem Management has progressed to the Known Error phase, a Change request is opened.
-The Change is approved and Release management implements the Change.
-A successful PIR determines closes the Change, which closes the Problem, which resolves any open, linked Incidents (hopefully the tool does this auto-magically).
-Any Incidents that had Workarounds applied may need to be reviewed to see if the Workarounds need to be undone.
Hi dboylan, thanks for your detailed reply, but now, after the perfect world case, can you tell me how you’d behave in a similar situation? I ask you this question because I’d tend to act in the ideal way you described but I fear it could produce too much overload on the service desk. I discussed this topic with a colleague from production and from his point of view there is just one incident: the server shortage.
I still think that from a service point of view each disruption encountered (and notified) by a user should be considered as an incident.
Joined: Aug 11, 2006 Posts: 262 Location: Netherlands
Posted: Thu Feb 07, 2008 4:51 am Post subject:
Hi Dam,
I think that administering all calls gives the advantage of getting insight in your workload. This will help prove to management the burden of everyday' work, justifying the number of FTE you have in operation.
At the other hand, in the case of a flood of calls (I agree with SKinnera using the IVR when possible) this might give you too much administration. What about your tooling (apart from IVT). I know that several tools have options like 'register similar call' where you can use an already registered call to (very quickly) register a new one. This way, you only have to fill in a subset of all requiered info per call. Would this be an option for you?
Joined: Jan 03, 2007 Posts: 189 Location: Redmond, WA
Posted: Thu Feb 07, 2008 10:08 am Post subject:
dam wrote:
Hi dboylan, thanks for your detailed reply, but now, after the perfect world case, can you tell me how you’d behave in a similar situation? I ask you this question because I’d tend to act in the ideal way you described but I fear it could produce too much overload on the service desk. I discussed this topic with a colleague from production and from his point of view there is just one incident: the server shortage.
I still think that from a service point of view each disruption encountered (and notified) by a user should be considered as an incident.
You opinion?
Yes, I would open a separate ticket for each reported occurrence of the issue. That way you can go back after the fact and get a feel for the disruption to the business.
A note about using the IVRU to announce an outage. I have done this in a previous position and we would add the Call Abandons to the count of Incidents reported related to the issue on the assumption that the majority of them hung up after hearing the announced message.
on the same topic, what does ITIL say should happen to all the slave calls that have been attached to the Problem record, should they go into pending or remain open with the problem record until the solution or workaround is identified.
or would you say thats more of a business decision.
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Sat Mar 15, 2008 4:36 am Post subject:
Hi ITILbit,
ITIL is not that prescriptive. If you keep them open, what will you do with them? If you close them, will you lose anything?
On the other hand, I'm not sure I would open a problem that quickly in the scenario described. It is really an incident with effect on more than one user. you can tie yourself up in to much management if you jump too soon.
If it happened again and then again within a few days or weeks, then it could go to Problem status to find why it was happening.
My slant on the original question is this:
1. It might be important to be able to contact each affected user
2. It might be important to know haw many have been affected
3. If it does eventually need PM then it might be useful to know which users were affected each time.
So
record this information. If that is easiest to do by opening individual incident records, then make sure you document the link between them.
Of course this is a bit simple. For example, if you get hundreds of calls the information on each is less usable and less useful and the effort of recording them all is excessive. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
As I understand this, if we had an ongoing Problem that for some reason there was no fix, until Problem management completed their RCA, then any further calls logged by the users, should be linked to the Problem in order to monitor impact, however these calls should be placed either in pending or should closed as repeat calls simply because the issue still remains one issue (ie Server down) and for analysis one could count the linked calls or/and call back the pending calls to ensure that they were related to the original fault, before individual closure.
However the account I support argues that, "fine, there maybe only one issue as the root cause, but for each person reporting the fault they are all individually experiancing a separate incdent".
Though I cant get to grips fully with this concept of that thought, I was hoping to find something in ITIL to refer back to.
Hi Skinnera,
Thanks for your answer, and what about reporting? Still referring to the same scenario do you consider you had several incidents or just one in your weekly stats?
To me this is one incident, reported X times therefore impact is Y (can be easily calculated) and duration was N.
A Mail server is constantly slow,
-Reported to Service desk and Incident process followed, which turns into a MASTER with additional slave calls linked to it. The Server was Identified as slow but no luck in finding out why.
- So because no fault could be identified. Problem Management process and the PM team were brought in to identify the underlyning issues of this server.
- PM investigation finaly makes recomendation to add an additiional server to share the load balance, for this RFC is raised, change, release and implentation being carried out.
- however until this is completed the users will continue to see the delays in sending and recieving.
Now would you agree that irrespective of the PM team getting involved this is still an outstanding incident (that would easily breach SLA) and additional calls logged should be linked to the MASTER Incident. Or would you argue that service is slow but not stopped hence not a direct impact of service but more an adverse affect and should be Part of a Problem investigation and not part of any Incident SLA, if the latter, then should the new calls be linked to the Problem Record directly.
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