Incidents & Changes

Discuss and debate ITIL Change Management issues
Post Reply
User avatar
franko123
Itiler
Itiler
Posts: 9
Joined: Sun Mar 02, 2008 7:00 pm

Tue Aug 02, 2011 5:10 am

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!


User avatar
ITIL101
Itiler
Itiler
Posts: 7
Joined: Fri Jul 22, 2011 8:00 pm
Contact:

Tue Aug 02, 2011 6:23 am

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.
User avatar
Dutch
Newbie
Newbie
Posts: 1
Joined: Thu Jan 12, 2012 7:00 pm
Location: Netherlands

Fri Jan 13, 2012 6:37 am

I know this is an old post but my solution might help others aswell.
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]
User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Fri Jan 13, 2012 10:45 am

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
Post Reply