Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: ASiddins
New Today: 30
New Yesterday: 44
Overall: 146540

People Online:
Visitors: 38
Members: 2
Total: 40 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

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.


The Itil Community Forum: Forums

ITIL :: View topic - Is a Work-around a Resolution?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Is a Work-around a Resolution?
Goto page 1, 2  Next
 
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk
View previous topic :: View next topic  
Author Message
stu62
Newbie
Newbie


Joined: Aug 22, 2007
Posts: 3

PostPosted: Thu Aug 23, 2007 5:47 pm    Post subject: Is a Work-around a Resolution? Reply with quote

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
View user's profile
dboylan
Senior Itiler


Joined: Jan 03, 2007
Posts: 189
Location: Redmond, WA

PostPosted: Thu Aug 23, 2007 10:10 pm    Post subject: Re: Is a Work-around a Resolution? Reply with quote

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
View user's profile
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Mon Aug 27, 2007 5:14 am    Post subject: Reply with quote

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
View user's profile Send e-mail Visit poster's website
stu62
Newbie
Newbie


Joined: Aug 22, 2007
Posts: 3

PostPosted: Tue Aug 28, 2007 5:07 pm    Post subject: Reply with quote

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
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3315
Location: London, UK

PostPosted: Tue Aug 28, 2007 6:11 pm    Post subject: Reply with quote

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
View user's profile
jpgilles
Senior Itiler


Joined: Mar 29, 2007
Posts: 123
Location: FRance

PostPosted: Tue Aug 28, 2007 7:10 pm    Post subject: Reply with quote

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
View user's profile Send e-mail
dboylan
Senior Itiler


Joined: Jan 03, 2007
Posts: 189
Location: Redmond, WA

PostPosted: Tue Aug 28, 2007 10:18 pm    Post subject: Reply with quote

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
View user's profile
stu62
Newbie
Newbie


Joined: Aug 22, 2007
Posts: 3

PostPosted: Tue Aug 28, 2007 10:52 pm    Post subject: Reply with quote

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
View user's profile
dboylan
Senior Itiler


Joined: Jan 03, 2007
Posts: 189
Location: Redmond, WA

PostPosted: Wed Aug 29, 2007 12:01 am    Post subject: Reply with quote

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
View user's profile
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Wed Sep 05, 2007 10:24 pm    Post subject: Reply with quote

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
View user's profile Send e-mail Visit poster's website
dam
Senior Itiler


Joined: Sep 05, 2007
Posts: 57

PostPosted: Wed Sep 05, 2007 11:45 pm    Post subject: Reply with quote

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
View user's profile
tolman101
Itiler


Joined: Sep 26, 2005
Posts: 44
Location: Sweden

PostPosted: Thu Sep 06, 2007 1:19 am    Post subject: Reply with quote

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
View user's profile
itsmer
Itiler


Joined: Oct 11, 2006
Posts: 21

PostPosted: Tue Oct 30, 2007 7:58 pm    Post subject: Reply with quote

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
View user's profile
Mark-OLoughlin
Senior Itiler


Joined: Oct 12, 2007
Posts: 306
Location: Ireland

PostPosted: Tue Oct 30, 2007 11:21 pm    Post subject: Reply with quote

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
View user's profile
Kyoanna
Newbie
Newbie


Joined: Oct 15, 2007
Posts: 4
Location: Kraków, Poland

PostPosted: Wed Oct 31, 2007 8:24 pm    Post subject: Reply with quote

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...Smile
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk All times are GMT + 10 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops © 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest © 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.