Is a Work-around a Resolution?

[stu62]

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?

[dboylan]

[Guerino1]

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

[stu62]

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

[UKVIKING]

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

[jpgilles]

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

[dboylan]

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.

[stu62]

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' ???

[dboylan]

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

[Guerino1]

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

[dam]

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

[tolman101]

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.

[itsmer]

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.

[Mark-OLoughlin]

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.

[Kyoanna]

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