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: EWaller
New Today: 0
New Yesterday: 67
Overall: 148297

People Online:
Visitors: 50
Members: 0
Total: 50

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 - Change based on an Incident/problem
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Change based on an Incident/problem

 
Post new topic   Reply to topic    ITIL Forum Index -> Change Management
View previous topic :: View next topic  
Author Message
Robbie_Van_Hoegaerden
Newbie
Newbie


Joined: Nov 23, 2009
Posts: 2
Location: Halle, Belgium

PostPosted: Tue Oct 26, 2010 7:02 pm    Post subject: Change based on an Incident/problem Reply with quote

Hi all,

In my company I've following discussion :

Person A (technical person) :

An incident has to be separate from a change, even ITIL indicates these 2 things as something different:
An change is to upgrade or to prevent further incidents, an incident is something that needs to be resolved asap (quick fix and can result later on by a change for descent fix)
Hence, the priority with an incident is to fix the issue at hand, if multiple incidents occure (or the incident is big enough) then you have a "problem" --> should be taken on and can result in a change to prevent further incidents.

I (as operational change manager) :

I don't agree with the above. A 'permanent' change to solve an incident = a change (even a quick fix has to follow the change rules). I want them to follow the change process rules in the above case.

Question :

How to convince the technical experts about the above. We can make rules and tell them to follow it. But still we'll have the same discussion over and over again. I want to convince them it's in their best interest, but they feel it's a loss of time and thus follow these rules without persuasion.

Thx in advance for the possibles examples of ways how to handle this.

Robbie Van Hoegaerden
Colruyt Group Services (>20000 employees).
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Tue Oct 26, 2010 7:56 pm    Post subject: Reply with quote

Robbie,

in one sense your protagonist is correct; you do want to restore service as soon as you can. However any proposed action to restore service must be subject to risk and cost analysis (however quickly and broad-brush). That is what change management is for.

When someone quotes "book" at you, it is often best to change the ground, go back to basics and talk about what is really required.

Incidents that can only be resolved by means of a change (whether temporary or permanent), require that change to be implemented as quickly as possible (call it an urgent change or an emergency change if you like - then you can define specific processes for that context). All changes need to be managed:

Risk
there are areas of risk to consider - the risk inherent in the change (e.g. might it overload a server?) and the risk inherent in the performing of the change (e.g. if we send our only engineer to the Outer Hebrides to do this, how will we cope with his/her absence?)

Cost
what are the costs involved; do the outweigh the benefits?

Analysis
how certain are w that this change will resolve the issue?

Testing
To what extent does our test plan ensure that the change will work?

Contingency/Backout
Are we prepared for the possibility that the change will fail

If you have a high impact incident, you want to do all this very quickly and this increases the risks. Someone needs to sign off on the risks, legitimately representing the business rather than IT Services.

I dare say that many incidents are relatively straight forward and reasonable evaluation and controls can be achieved in little more than a matter of minutes whereas others will require hours of hard work to be sure that the risks are understood and how to manage them However there are also instances where something seems simple, but in fact have hidden consequences. This is why the process needs to be rigorous so that, by involving all the interested party (e.g. CAB), there is a t least a chance that the true complexity will be discovered in good time.

I seem to be waffling. Sorry.

Another point: I'm sure it has happened a million times that a technician has rebooted a server without even bothering to check if anyone else was using it.
_________________
"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
SubbuA
Itiler


Joined: Jan 28, 2010
Posts: 33

PostPosted: Tue Nov 02, 2010 3:29 am    Post subject: Simple Answer Reply with quote

Have your policy document record the need for having an approved change request for any changes made to the CI

I rekon your issue is on because you do not have a matured change management policy document. Formulate one - get buy-in from stake holders ane use it with rigour
_________________
Regards,
Subbu A
ITIL Certified and well experienced
Back to top
View user's profile
Robbie_Van_Hoegaerden
Newbie
Newbie


Joined: Nov 23, 2009
Posts: 2
Location: Halle, Belgium

PostPosted: Tue Nov 09, 2010 3:45 am    Post subject: Reply with quote

Thx for the feedback.

I'll keep in mind the mentioned strategies/handlings and get back with some feedback.

Robbie.
Back to top
View user's profile
tstomczak
Newbie
Newbie


Joined: Nov 09, 2010
Posts: 2
Location: North Carolina

PostPosted: Wed Nov 10, 2010 3:26 am    Post subject: Reply with quote

in my shop, an incident happens, and in order to restore service, an emergency change (break/fix repair) is implemented to do so... After the fact, the "change" is documented and then the change is completed / closed and the incident is resolved...

The Incident says whats wrong
The emergency change "fixes" whats wrong in order to resolved the incident...
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Wed Nov 10, 2010 9:24 pm    Post subject: Reply with quote

tstomczak,

documenting a change is not the same thing as managing it. After-the-fact documentation may be acceptable (to some), but a lack of risk and cost analysis, planning and preparation, authorizing and communication, etc. etc. are undesirable even in an "emergency".
_________________
"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
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Change Management 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.