View previous topic :: View next topic |
Author |
Message |
stu62 Newbie


Joined: Aug 22, 2007 Posts: 3
|
Posted: Thu Aug 23, 2007 5:47 pm Post subject: Is a Work-around a Resolution? |
|
|
Should an incident be closed if a work-around is found and an associated Problem record has been created, or should the Incident remain open until the Problem is closed?
What consistutes an Incident resolution? |
|
Back to top |
|
 |
dboylan Senior Itiler

Joined: Jan 03, 2007 Posts: 189 Location: Redmond, WA
|
Posted: Thu Aug 23, 2007 10:10 pm Post subject: Re: Is a Work-around a Resolution? |
|
|
stu62 wrote: | Should an incident be closed if a work-around is found and an associated Problem record has been created, or should the Incident remain open until the Problem is closed?
What consistutes an Incident resolution? |
According to the strict definition of ITIL (at least according to the way I have interpreted the books), yes. An Incident is defined as interruption or (degradation in quality) in a Service. A Workaround is defined as a means of restoring Service by no longer being reliant on the failed component.
I would say that there needs to be some procedure in place to return the user to a pre-Workaround state (in cases where that is desirable) once the Incident has been closed. This might include a flag on the Incident record that the Workaround results in a less then desirable state, or a report that shows the Incidents resolved to the Workaround that would then need new Service Requests opened for follow up work.
Don
Last edited by dboylan on Tue Aug 28, 2007 10:26 pm; edited 1 time in total |
|
Back to top |
|
 |
Guerino1 Senior Itiler

Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
|
Posted: Mon Aug 27, 2007 5:14 am Post subject: |
|
|
Hello Stu62,
Don is correct. Incident Management is about putting out the fire and restoring service, even if it is held together by bandaids, while a greater problem might be in resolution. For this reason, once service is restored to the customer(s) and all appropriate data/information is captured for that Incident, it is a good idea to close it. Creating a related Problem to track and manage opens up a completely different process.
I hope this helps.
My Best,
Frank Guerino, CEO
TraverseIT
On-Demand ITIL |
|
Back to top |
|
 |
stu62 Newbie


Joined: Aug 22, 2007 Posts: 3
|
Posted: Tue Aug 28, 2007 5:07 pm Post subject: |
|
|
Thanks for the advice guys but I still have my doubts.
Perhaps it's a question of semantics but if we have to change business processes in order to work-around an incident does this really constitute service restoration?
Let me try an example:
An accounts system has a reporting module which stops working but the accountant is shown how to export the data into a spreadsheet and produce an identical report.
The IT team have provided a work-around but has Service been restored?
Shouldn't the incident stay open until a proper fix is found?
It may sound like a hair-splitting exercise but many SLAs stand or fall on this question.
Stu |
|
Back to top |
|
 |
UKVIKING Senior Itiler

Joined: Sep 16, 2006 Posts: 3590 Location: London, UK
|
Posted: Tue Aug 28, 2007 6:11 pm Post subject: |
|
|
Answer the question this way.
You take the train from Suburb to Town every morning.
This week there is no train services.
Instead there is a smelly bus that takes 3x as long to get you the three stops
You can still get from Suburb to Town. but it is not the same level of service (how fast, the comfortable seats, the coffee on the train) vice the smelly bus and uncomfortable seats.
In this case, I think the IT team is sloppy shouldering the issue.
Yes, you can export data from any accounting package a text file and import the file in Excel, Access word etc.
How long does it take the user to do this the manual way vice the accountung reporting module
Did the incident meet the criteria for getting a problem created about the module issue ?
The incident should be closed - he can run the report manually and more time consuming.
The (A) problem should stay open and a solution should be found. _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter |
|
Back to top |
|
 |
jpgilles Senior Itiler

Joined: Mar 29, 2007 Posts: 123 Location: FRance
|
Posted: Tue Aug 28, 2007 7:10 pm Post subject: |
|
|
To adress that specific issue, I have seen one implementation of Incident management where a specific incident status was created "worked around" which means:
a workaround was found to provide the required function , however it is not efficient/performing/satisfactory enough to be considered as a valuable resolution. Hence the incident is not closed, just gets lower priority and problem is automatically created to find a sustainable solution.
That's not 100% ITIL (in theory) but worked fine for that organization (dealing with about 30.000 help desk calls per month) : that's real life ITIL implementation...
best regards
JP _________________ JP Gilles |
|
Back to top |
|
 |
dboylan Senior Itiler

Joined: Jan 03, 2007 Posts: 189 Location: Redmond, WA
|
Posted: Tue Aug 28, 2007 10:18 pm Post subject: |
|
|
I would also like to say that IT doesn't get the final word on whether an Incident is Closed. The IT groups can Resolve an Incident, but it is up to the user to indicate that the issue is fixed to their satisfaction so it can be set to a Closed state. In the case of the reporting function not working, IT can Resolve the issue to the Workaround, but the user can then refuse to accept the Resolution and deny it to going to a Closed state. |
|
Back to top |
|
 |
stu62 Newbie


Joined: Aug 22, 2007 Posts: 3
|
Posted: Tue Aug 28, 2007 10:52 pm Post subject: |
|
|
So, to quote John's metaphor, if the customer isn't happy that the "smelly bus" is an acceptable alternative the incident stays open even if the non-functioning commuter train has been raised as a 'Problem' ??? |
|
Back to top |
|
 |
dboylan Senior Itiler

Joined: Jan 03, 2007 Posts: 189 Location: Redmond, WA
|
Posted: Wed Aug 29, 2007 12:01 am Post subject: |
|
|
Yes, that is correct. And hopefully your Incident/Problem management tool can link the records together so that any users with Incidents open to the Problem will be notified that the Incidents are ready for Closure when the Problem record is Closed.
It seems like there needs to be a status of "Resolved but waiting on Problem for Closure". |
|
Back to top |
|
 |
Guerino1 Senior Itiler

Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
|
Posted: Wed Sep 05, 2007 10:24 pm Post subject: |
|
|
Hello All,
I'd like to interject one last piece to this. Closing the Incident is not always about whether or not the customer is happy. Sometimes, you'll have customers that are never happy. Closing the Incident is about ensuring that the Service has been restored to acceptable levels within the SLA. It's nice to have the customer be happy, when the Service is restored. However, you may have to simply close the ticket when you've restored the Service to work within it's defined SLA and move on to the next ticket. This is why SLAs are put in place. They manage "expectations" and those expectations have ranges of acceptability. Sometimes, restoring a Service to be "just good enough" has to happen so that you can deal with bigger fires.
Anyhow, I hope this helps.
My Best,
Frank Guerino, CEO
TraverseIT
On-Demand ITIL Platform |
|
Back to top |
|
 |
dam Senior Itiler

Joined: Sep 05, 2007 Posts: 57
|
Posted: Wed Sep 05, 2007 11:45 pm Post subject: |
|
|
Hello,
In my opinion there is no one solution that fits all the cases. It strongly depends on the nature of the incident (on a punctual action, on a recurring action) and on the efficiency of the workaround (it fully/partially answers to the request).
For example
1)
I have a data integration that runs daily and it starts to fail,
The workaround is to charge the file manually in the application.
I’d open an incident on each integration fail, I’d resolve and close the incident ticket after each manual integration. Because the task has been completely accomplished even if it will fail the next time till the underlying problem is unresolved.
2)
I have a functionality that permits to add a comment to a form, every time the comment contains a question mark it produces an error page after you click on save.
I open an incident, the workaround is to say to the user “don’t put question mark in the comments”, after having communicated this to the customer I’d set the incident to “resolved” but I’d wait the underlying problem to be resolved to set the incident to “closed”.
What do you think?
Regards,
DAM |
|
Back to top |
|
 |
tolman101 Itiler

Joined: Sep 26, 2005 Posts: 44 Location: Sweden
|
Posted: Thu Sep 06, 2007 1:19 am Post subject: |
|
|
Hi,
This is a common issue similar to that of incidents v service requests. ITIL is not going to give us the minute details, rather it gives some guidlines and then we have to find the real life solution that works for our own organisations.
What works for us is to set problem record criteria. When one of the criteria is met a problem record is registered and linked to any related incidents. A couple of criteria for registering a problem record is if there is an unsustainable workaround or the end user/customer is not satisfied with the supplied workaround.
The incident is closed using the unsustainable workaround (service restored), and a problem record is opened and remains open to identify a sustainable resolution to the incident/s. |
|
Back to top |
|
 |
itsmer Itiler

Joined: Oct 11, 2006 Posts: 21
|
Posted: Tue Oct 30, 2007 7:58 pm Post subject: |
|
|
Some thoughts of mine..
1. I sometimes recomend to open a problem ticket and close the incident stating workaround is done. Why problem ticket? otherwise the guys might forget that they handled a workaround and something is not normal.
2. Service levels are given on calls to be closed. Workaround SLA not done.. IT has to get back to the user later and keep him informed on progress of resolving it completly. All this would not happen if there was no ticket of incident or problem. And if this does not happen then there has to be a complaint process designed to handle such situations. |
|
Back to top |
|
 |
Mark-OLoughlin Senior Itiler

Joined: Oct 12, 2007 Posts: 306 Location: Ireland
|
Posted: Tue Oct 30, 2007 11:21 pm Post subject: |
|
|
Hi,
The incident should be closed when a workaround has been provided or at least set to a status that stops the SLA counter even if the actual cause of the problem has not been fixed. If you have a tool that can relate incident and problems make the relationship. Also if you have the capability - you could set up say a status for problem called "workaround in place" and once that is selected it updates all the related incidents to the status mentioned earlier.
if the tool supports it at this point have an email sent to everyone that reported an incident to inform that that a workaround has been put in place - this would be an automated message if possible and at this point that SLA on incidents stops.
The problem record is still in a non closed status and has to be progressed through an RCA and actual solution if possible.
In the case of your accounts example one the user can get the report the incident for him is resolved, however the problem should remain open and assigned to a problem manager until RCA is identified and if possible a solution identified and put in place.
Sometimes you just have to close problems too as the business wont agree to fund the cost of the solution and only when you have a large number of problem records for the same thing can you get then to listen.
I hope this helps. |
|
Back to top |
|
 |
Kyoanna Newbie


Joined: Oct 15, 2007 Posts: 4 Location: Kraków, Poland
|
Posted: Wed Oct 31, 2007 8:24 pm Post subject: |
|
|
Hello:)
Maybe I will also write about my ideas in this topic.
Lately, I've been defining some scenarios and diagrams of Incident and Problem processes for telecom IT systems.
And I think that the best way is to define few possible paths after the Incident analysis and investigation. You wrote about the path, when there is a problem...
If there is a root problem, you create a problem record and you have to wait until you get the report information that it has been fixed (in a specified state e.g. Problem process running or sth...) otherwise you will not have a report info, test results etc. in the Incident record.
But maybe it can look differently in other industries - everything depends of the complexity of the system and related functionalities.
Also you can define some steps concerning tests/verification/validation in a different place...then maybe you don't have wait until Problem closure..
P.S. Sorry for my English, I haven't used this language for a long time... |
|
Back to top |
|
 |
|