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 - Advice on how to handle this incident management scenarios
Posted: Fri Mar 01, 2013 12:53 am Post subject: Advice on how to handle this incident management scenarios
Good morning,
We are implementing standardized incident management practices in our organization. We have not implemented problem management or change management practices. As we move through the incident management implementation, we are asked questions on how to handle specific scenarios. I'm looking for some advice on how to handle the 2 scenarios below.
1. User calls the Service desk with an issue with incorrect data showing on a report. Incident gets logged at the Service Desk. Service Desk, unable to resolve the incident, escalates the issue to Tier 2. Tier 2 reviews the incident and determines that the issue is due to an error in the application that will be fixed in the next release. How do we handle this from here? Is the "incident" considered resolved because we know the solution? Should something else gets logged so as not to lose sight of this before the next release?
2. Similar scenario...
User calls the Service desk with an issue with incorrect data showing on a report. Incident gets logged at the Service Desk. Service Desk, unable to resolve the incident, escalates the issue to Tier 2. Tier 2 reviews the incident and determines what needs to be done to resolve the incident however due to other priorites, they are unable to apply the fix right now. How do we handle this from here?
Joined: Nov 03, 2012 Posts: 55 Location: Singapore
Posted: Fri Mar 01, 2013 1:35 am Post subject:
#1
You definitely need a light problem management to cover:
a) Problem Creation.
b) Problem Track.
c) Problem Close.
Since you don't have problem management process, so basically you won't have people to do the investigation and diagnosis on problems, but you can use this to track the permanent fix.
Also you need to have someone to work on the release and deployment.
#2
This is based on the priority, if you do have other priorities, what should we do? _________________ Luo, Tian-Hong (Ken)
Regional Operation Lead
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Fri Mar 01, 2013 7:55 am Post subject:
You have to be careful about being too mechanistic in your activities. What is the incident? Wrong data is a symptom. The production of the report may be the failing event or the data may be wrong in the system before that. Perhaps the report cannot be used? When and what is the business cost occurring? What is the workaround? Can a corrected version of the report be produced by some means?
Just because you have not formalised problem management doesn't stop you from dealing with problems. The people and activities exist it is the formal processes that are missing from your problem management. Correcting the report would be incident resolution; correcting the report production (or wherever the data became wrong) would be problem resolution.
1) is it acceptable to wait for the next release - or should a means of correcting the report be used until that time?
2 )is tier 2 talking about fixing the problem or the incident? _________________ "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
IMHO
Case 1:
I would mark the incident resolved, create a known error record (if you still don't have one) for tracking purposes, and notify the user about the fix coming in with the next release. Once the release gets implemented, update the known error record
Case 2: (agreed with Diarmid)
If you cannot fix the report creation, then you should be able to run an ad-hoc program to produce it right until you get your production program fixed. Depending on your customer's costs/risks of not having the report correctly and on time.
e.g. A report of historical statistic data, may not be urgent, but a check reconciliation report could require immediate attention.
Regards, _________________ Pablo Alarcón
ITIL v3 Foundation Certified
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Thu Mar 14, 2013 12:42 am Post subject:
Pablo,
it is really a problem record that will successfully track the ultimate correction. The known error record will specify the "get-round" (if any) until the problem is resolved. _________________ "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
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