Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
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.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
Posted: Mon May 05, 2008 10:20 pm Post subject: CHG vs. INC
Hi Forum,
I have seen many times the KPI: "#of INCs resulting from RfCs" in order to assess and to steer the CHG process performance.
Valid point in theory but right now I'm asking myself how do other companies get a clear picture of the incidents which come from lets say inproper implemented RfCs?
In our company we have different tools for CHG and INC and I find it pretty hard to bring INC and changes together in one picuture. Maybe there is a good and easy way to figure out which incidents belong to certain change requests.
Joined: Oct 07, 2007 Posts: 441 Location: Jakarta, INA
Posted: Tue May 06, 2008 12:44 am Post subject:
Hi,
I guess an incident could not be associated directly at first level with a particular RFC. It needs investigation and cannot be done automatically.
In my office, an incident that after investigation was found out as a result of improper change will be informed to Change Management, and Change Management will bring it to the PIR Meeting, Change Manager will add one to the related KPI manually.
If it caused a medium and high severity level, an emergency RFC would be raised to fall back.
Joined: Sep 16, 2006 Posts: 3590 Location: London, UK
Posted: Tue May 06, 2008 8:37 pm Post subject:
It will as asrilrm has said... a manual process
What usually happens is that a change gets down - usually on the weekend
lo an behold come monday - despite whatever testing was done.. soemthng does not work right for some team
this gets fixed udner the incident process
then comes the big pointing finger of mgmt... depending on how bad the incident was
if it is small finger.. return the favor with the finger of chasnge mgmt and update the KPIs
if it is big finger, then it is likely Problem mgmt and self analysis and other actions arise .....and update the KPIs _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Tue May 06, 2008 8:58 pm Post subject:
Hi,
of course it is not only poor implementations that lead to incidents. The change could have been implemented perfectly, but it then unmasked an unforeseen consequence for example. In that case it is the analysis and specification for the change that leads to issues. _________________ "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
Within my org it's a manual process but our tool allows us to link CCRs to the Incidents they have caused, and we can therefore report on 'CCR generated Incidents' straight out of the system.
Only as good as the people making the links of course, but better than nothing...
You can therefore have (as we did earlier this year) a chain of events that goes;
Incident -> CCR to fix it -> generated Incident -> CCR to fix it -> generated Incident -> CCR to fix it... _________________ When I say 'CCR', please read 'RFC'.
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