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: Casas
New Today: 50
New Yesterday: 68
Overall: 131810

People Online:
Visitors: 49
Members: 4
Total: 53 .

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 - Incident --> change
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Incident --> change

 
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk
View previous topic :: View next topic  
Author Message
Json
Newbie
Newbie


Joined: Oct 01, 2009
Posts: 4

PostPosted: Thu Jan 07, 2010 7:06 am    Post subject: Incident --> change Reply with quote

Hi

if a incident is created which demands a change to be created and let say this change will take time to resolve, till then should this incident be open

I guess answer would be yes.

If this is kind of routine thing which happens , what would be the better way to handle this without increasing aging time of tickets
Back to top
View user's profile
Timo
Senior Itiler


Joined: Oct 26, 2007
Posts: 295
Location: Calgary, Canada

PostPosted: Thu Jan 07, 2010 8:40 am    Post subject: Reply with quote

I don't think there is black and white answer. If you were able to mitigate immediate impact of the incident by providing a plausible workaround, you could potentially suspend the ticket, which would stop the SLA time on resolution, but won't stop the ticket from "aging". This is not always a preferred practice in cases where the user(s) is still experiencing the impact and don't have full access to the service.

I've seen organizations that actually close incident tickets that do have pending changes associated with them. From practical stand point, they will still resolve the issue, but it will make it harder to contact end users to validate resolution, and to track issue resolution in general in case as you state change takes too long to prepare and implement.

If anything, you should link incident tickets to change ticket to ensure that kind of traceability.

See what your policy says and most importantly investigate and think what makes most sense for the organization.
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Thu Jan 07, 2010 8:33 pm    Post subject: Reply with quote

The only way to stop an incident ageing is to resolve it. The only other way is for its importance to the customer to drop to about zero so that the customer will accept closure without resolution. The only other way is to buy the customer off.

Suspending or stopping the clock is a means of having your management system disagree with reality. The more you do this the more difficult it is to determine whether you actually have a viable management system.

Resolving an incident is a matter of restoring the interrupted or impaired functionality to the customer's satisfaction. This can be by means of a fix or a workaround.

If the incident threatens an SLA on its own, then it is either an incident with severe impact (in which case you are not going to be wasting time worrying about SLA's because you will be too busy getting it fixed) or your SLA's are too tied to individual incidents and the SLAs should be repaired.

If the incident is going to be open so long that it impacts an SLA based on rolling averages, then that is what the SLA is for (and if that is your primary concern, the incident cannot be having much impact).

The message in all the above is that if you have got rules, stick to them and always discuss to the point of agreement with the customer exactly what you are going to do about a recalcitrant incident.

You can always propose that your SLAs have a clause under which incidents are excluded from counting towards penalty clauses (or adverse review findings) with the customer's agreement. You can always ask! Twisted Evil
_________________
"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
Back to top
View user's profile Send e-mail
AgentJay
Newbie
Newbie


Joined: Sep 03, 2007
Posts: 19

PostPosted: Sat Jan 30, 2010 9:12 am    Post subject: Reply with quote

Hey there,

Not sure what IM tool you are using. But, Remedy and the family has the option to stop the incident ageing by changing its status to 'Pending'--> 'Monitoring the Incident'. This actually stops the incident clock until the status is changed.
Back to top
View user's profile MSN Messenger
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Sat Jan 30, 2010 9:34 pm    Post subject: Reply with quote

And does it report that the clock was stopped in the incident record?

Are you able to discover and analyse incidents that had their clock stopped to determine if it was appropriate to stop it. are you still readily able to determine how long the service was unavailable/interrupted in real time?

Let's say the clock was stopped for a very good reason and with full agreement from the customer (not user). Is the fact sufficiently flagged to be picked up in review so that it can be considered whether the underlying reason for stopping the clock needs to be addressed.

Stopping the clock is such a dangerous idea that it should only be done if it is a subordinate clock because you should never lose track of how long an incident has been in an open state.

It might be better to take the heat over the SLA breach initially and negotiate it out at service review with the customer if there was good cause.
_________________
"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
Back to top
View user's profile Send e-mail
viv121
Senior Itiler


Joined: Dec 15, 2007
Posts: 112

PostPosted: Sun Jan 31, 2010 4:36 am    Post subject: Incident --> change Reply with quote

Json,


You asked " Hi

if a incident is created which demands a change to be created and let say this change will take time to resolve, till then should this incident be open

I guess answer would be yes.
If this is kind of routine thing which happens , what would be the better way to handle this without increasing aging time of tickets"

You are right in stating that the incident should be kept opened till the change cycle is completed. You further mentioned that this kind of routine things which happens. For me, the incidents would have a saving grace if you actually mean routine things. In case of routine issues, it would be safe to shift the focus to the problem management. For routine incidents, problem record should be created and RCA should be done. The change or no change would depend upon the RCA. It would be wise not to have such issues become a routine and get them fixed for good. The by-product is that is an incident is linked with the problem record lose its significance of aging. In such cases the age of problems matter and incidents take a back seat.
Back to top
View user's profile Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk All times are GMT + 10 Hours
Page 1 of 1

 
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.