One ore several incident records?

[dam]

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?

Thanks in advance

[Skinnera]

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

[dam]

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?

[dboylan]

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.

[dam]

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?

[m_croon]

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?

Hope this helps,

Michiel Croon
Getronics Pinkroccade

[dboylan]

[dam]

thanks for the answers

[ITILbit]

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.

[Diarmid]

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

[ITILbit]

Thanks Dam,

The problem we have is that:

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.

[UKVIKING]

ITILbit

The PM process works independantly from the IM process. The IM process is to restore service as soon as possible if there is a service impact

What the SD can say is that if there is a PM record which is based on several incidents that are linked to gether

Your incident # is blank. As you are (ar not) suffering service impact, we will escalate the incident to restore service to the appropriate group

In additon, because several incidents about this issue has been raised, a PM record has been created in parallel to find why it is happening.

Their next update is .....
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[Skinnera]

[ITILbit]

Thanks UKVIKING,

so the scenario is as such;

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.

Thanks

[ITILbit]

Q: does ITIL say any detail about "SLAVE/MASTER" or "CHILD/PARENT" relationship or how linking is best carried out?