We are in the middle of a CFG & CHG planning. We are now discussing how we will deal with changes to the CMDB.

For now, the CMDB will only contain desktop (hw and sw) CIs. So, it is a consensus that we should use standard changes for modifying a CI.

But there is a disagreement if this standard change should be submitted via an RFC or simply executed. I mean, the technical guy has just changed the hard disk from a desktop. He must now modify the corresponding CI. He must use the standard change (with the corresponding change model), which is pre-approved.

The fact that it is pre-approved means that he does not need to raise a RFC? Could he simply do it? Some guys here are complaining about raising a RFC for every single minor desktop change in their day-to-day work...

I understand this always depends. But I would like to hear from you what you do at your companies...

Do you mean that changing the disk does not need change management but changing the CI does? I don't like that at all. These are aspects of one change.

My general view is that standard changes should be explicitly defined and there should be formal process wrapped around them that ensures proper change management. Whether that requires a rfc depends on how else you can get the change log and other documentation maintained, including identifying the parties involved in authorizing and performing the the change.

Consequently, I cannot envisage a blanket "standard change" for all desktop h/w and s/w change activity.

Pre-approval should not be full authorization; someone still has to decide that this instance comes within the approval scope.

Nor does it imply avoiding considerations of cost and impact on users (including the resources allocated being unavailable for other tasks).

Finally, "standard change" activities require scrutiny and review._________________"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

This confusion started when someone pointed out that ITIL V3 states in its glossary that a standard change is:

"(Service Transition) A pre-approved Change that is low Risk, relatively common and follows a Procedure or Work Instruction. For example, password reset or provision of standard equipment to a new employee. RFCs are not required to implement a Standard Change, and they are logged and tracked using a different mechanism, such as a Service Request. See also Change Model."

So... RFCs are not required... That is in the official book!

I thought we should always have a RFC, even for standard changes. But it seems we can go without it, as long as we can register the change...

So, for a desktop change for instance we would have a standard change that would start at the service desk, would go through all the steps necessary for the physical change, and would end up with updating the CMDB. And all this without a RFC!

RFCs are not required to implement a Standard Change, and they are logged and tracked using a different mechanism, such as a Service Request. See also Change Model."

A rose by any other name...

Regardless of how the swap of a hard drive is documented (Standard Change - RFC in V2, Service Request in V3, or NewThing in V4), the updating of the CI is one of the tasks within that procedure, not a separate RFC or Service Request.

Is a disk swap or a software upgrade a Service Request and not an RFC? I'm not sure those actions are quite as low risk as the examples given -- password resets and provisioning new equipment.

Furthermore, in V2, preapproved Standard Change means that the change is too trivial for the CAB but it doesn't mean that the Change Manager's hands are tied. If the planned disk swap conflicts with something else (say a scheduled security scan), the Change Manager can require that it is rescheduled.

ITIL sometimes says you must have a RFC, and sometimes it says you must not...

I don't have access to the texts for v3, but I hope you are misreading this. "Must" is a strong word in a set of guidance material.

I'm 100% with rpmason on this. A password reset can plausibly be considered a service request, but it strikes me as disingenuous to start labelling change activities as such, when the motive seems to be more about cutting corners than ensuring proper management.

Standard change and service request are different things, although it is conceivable that a service request could involve a standard change (in which case the procedure that delivers the service has to manage the change as well).

When people start saying with reference to ITIL "look, if we call this a blankety blank instead of a doofer, we can avoid such and such actions" then they are thinking more about rules and loopholes than appropriate management practices.

Always start with meeting the requirements of good service provision and never with the formulae._________________"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

Why does your technical guy need to update the CMDB having replaced a disk in a pc.?
Presumably the disk is simply a replacement,like for like following a hard disk failure in which a service desk ticket has been generated in order to assign an engineer to repair the PC.

Last edited by UKIT on Tue Oct 27, 2009 6:42 am; edited 1 time in total

Must is a strong word as Diarmid mentioned, ITIL is not a standard its a guidance best practices which should be tailored.

Chasing,

why don't you consider changing that to a basic minor change, make a template for it and modify they key factors that might change in the RFC ex: impact lets say that desktop has an important shared folder that everyone uses or a local shared printer that colleagues uses.

In my opinion this the best solution for your scenario, modifying the RFC wont take minutes and its treated as a minor change which will be approved from the change manager only. Its going to be the same proceedure of testing and implementation except that there might be some small differences.

Try to google: "hank marquis standard change" to get a better understanding of how to deal with standard changes

Replacing a hd disk or whatever is an activity that is however minor can have unpleasant implications. Whether a formal approval required or not, there needs to be a record that the activity took place. It has to identify what CI was affected, who was the customer, when it happened, why, etc. The record needs to be created and it has to be "findable" and accessible by reporting tools.

It is up to your organization to assess risks associated with such activity and determine whether a request for disk to be changed (or whatever else) needs to be formally approved.

Replacing a hd disk or whatever is an activity that is however minor can have unpleasant implications. Whether a formal approval required or not, there needs to be a record that the activity took place

Timo please clarify your understanding of a minor change. It is classified,recorded and logged. An RFC is raised and treated like any other basic change except that its authorized by a change manager not by the CAB or Senior Managenet.

Last edited by thechosenone69 on Tue Oct 27, 2009 5:56 am; edited 1 time in total

I never said minor change... in my sentence 'minor' referred to size or effort required. It does not mean that such activity would not necessarily be required to go through a bunch of approval and planning exercises.

The point i was trying to make (obviously not well) is that no matter what your change is, no matter what you call specific activity, it has to be documented. So whether there is an RFC process in place or not, it is important that even the most trivial and lowest risk change is documented.

I've flicked through the sections V3 Service Transition book for Change and Configuration management.
There is a diagram called Figure 4.6 Request for Change Workflow and key interfaces to Configuration Management.
There is a 2 way arrow between Approve/reject change in the Change management flow and Update records in the Configuration management flow.
Now call me a stupid Aussie if you like, but that sounds to me like the CIs are updated before the change. I'm assuming the records referred to in the Config Mgt flow are CIs_________________DYbeach
ITIL V3 Release, Control & Validation,
ITIL V3 Operation SUpport & Analysis
PMI CAPM (R)

"In times of universal deceit, telling the truth will be a revolutionary act." George Orwell