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: CMulley
New Today: 1
New Yesterday: 73
Overall: 142293

People Online:
Visitors: 64
Members: 3
Total: 67 .

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

Incidents & Changes

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


Joined: Mar 03, 2008
Posts: 9

PostPosted: Tue Aug 02, 2011 7:10 pm    Post subject: Incidents & Changes Reply with quote

Dear All,
Was wondering what your thoughts are on this as I'm sure it's a common one. Daily, we face situations where incidents occur in a production environment with applications, hardware, network configurations etc.
In order to troubleshoot these issues, the analyst/engineer working on the case, will have to change something or touch a production environment. Inevitably, if he has the access or privileges to fix the issue, he will make the changes to resolve the issue and restore the services impacted without thinking about raising RFC's.

Per the CM process, no changes should be made in a production environment without an RFC.

I have a couple of questions just to understand this:
1. Don't all incidents require some sort of change to fix them and hence should always have RFC's?
2. Is this practical that while a user or set of user(s) are suffering, we are raising RFC's and waiting for approvals when we can easily fix such things.
Even if we can classify them as pre-approved standard changes, it could make two processes cumbersome and bureaucratic and be difficult to adopt.
3. What's the best approach?

Thanks!
Back to top
View user's profile
ITIL101
Newbie
Newbie


Joined: Jul 23, 2011
Posts: 7

PostPosted: Tue Aug 02, 2011 8:23 pm    Post subject: Re: Incidents & Changes Reply with quote

franko123 wrote:

I have a couple of questions just to understand this:
1. Don't all incidents require some sort of change to fix them and hence should always have RFC's?
2. Is this practical that while a user or set of user(s) are suffering, we are raising RFC's and waiting for approvals when we can easily fix such things.
Even if we can classify them as pre-approved standard changes, it could make two processes cumbersome and bureaucratic and be difficult to adopt.
3. What's the best approach?


1. Not neccessarily. The typical flow would be where a Problem Record is raised for one or more Incidents, and the output of the Problem Management process is that errors are resolved in the environment via a Change.

2. The practical solution is to ensure your tool supports standard changes to make it a 2 click process. The alternative is to raise an Emergency Change - although this may have unwanted repercussions in terms of SLAs and KPIs so it is often not an adopted approach for simple resolutions.

3. Your best approach would be to blueprint your changes and make them Standard Changes.

In the absence of a supporting tool or adopting the Standard Change approach, you may want to look at creating knowledge articles that essentially do the same thing a standard change would, and detail the steps required for resolution, but ensure your Incident log reflects the usage of that particular knowledge article (so if something really bad happens, you have an idea how to roll back).

Through it existing as a knowledge article the resolution can be effected under the guise of Incident Management. <-- I dont necessarily recommend this approach, but it is a practical approach, and possibly better than nothing.

Regards.
Back to top
View user's profile Visit poster's website
Dutch
Newbie
Newbie


Joined: Jan 13, 2012
Posts: 1
Location: Netherlands

PostPosted: Fri Jan 13, 2012 9:37 pm    Post subject: but... Reply with quote

I know this is an old post but my solution might help others aswell.

Quote:
we face situations where incidents occur in a production environment with applications, hardware, network configurations etc.
In order to troubleshoot these issues, the analyst/engineer working on the case, will have to change something or touch a production environment. Inevitably, if he has the access or privileges to fix the issue, he will make the changes to resolve the issue and restore the services impacted without thinking about raising RFC's.


I was faced with the same situation.
The problems i faced:

When i (engineer) have to register everything i change? If so i need a PA just for registering.
Do i (engineer) need to get approval for every single change? If so I might as well call it a day.

All legitimate questions and expectable answers.
In fact, the way we defined our change procedures would result in a Yes on both questions.

That got me thinking. How can we make them to register without making it a cumbersome and bureaucratic process for them.
Luckily our tool lets me create change templates and allows me to monitor every record that’s created. The thing holding me back is the change procedure. So I made dissension to ad a 3d change procedure. Before introducing the procedure to the IT staff I got approval and commitment (backing) by the staff team leader. (responsible for daily operations)

The 3d procedure states:
The engineer is responsible and accountable for completing the entire change procedure. (From assessing the impact of the change to updating documentation etc.) However this only applies to changes by IT staff for IT (Pro-active) that have a low impact AND a low risk. If either one is higher then low the “normal” change procedure applies. Triggering CAB etc.

Making sure the IT staff use the procedure correctly is for the most part done by auditing every change they register. (Blind copy e-mail with details is sent do my address)

Since the introduction June Last year (2011) i found they registered 80+ changes that otherwise would have never be known.
[/quote]
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Sat Jan 14, 2012 1:45 am    Post subject: Reply with quote

Dutch,

I think you have addressed the real issue, but perhaps it needs shouting louder.

Many people, including the earlier posts, focus on the need for records and/or the authority to act, both of which are of course very important. But the essence of change management is to ensure that changes are delivered correctly and with minimum impact and this involves assessing impact and risk, scheduling and planning (even if "immediate"), and communicating appropriately among other things.

If you authorize your engineers to proceed (whether alone or in conjuction with others) and fully manage the change they identify as within their scope, and ensure they are trained to understand this, and maintain suitable monitoring and review. then you have the makings of a workable system.
_________________
"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.