Several Changes

[ITILAddict]

In charge of implementing ITIL in my Company (Dev & hosting). Many questions arose when i check the change management process and the release management process.
Is one RFC means 1 change ?
What if one change implies several modification ?
ie : Remove application A from Server A
Does it have to go through the release management pipe eventhough there is no dev involved ?

My concern is the update of the CMDB. In such a case how do i update it ?

After reading all the materiel i could i m even more confused

Hope somebody can help Does anyone have concret exemple and a step by step that could help

[Ed]

Hi Itiladdict

As a Change Manager, I want ALL changes covered, on ALL items.

One Change means an RFC is required, unless the change is occuring in an area that is outside the scope of Change Management as defined by your company. For example in my company desk top pcs are not generally covered by Change Management. Any changes here do not come within my remit.

Elsewhere, I need to know what the business case is for the Change (is it a nice to have, an emergency fix, or what).

If the change is to be safe then the Change builder needs to demonstrate that it has been built correctly, that the regression has been tested and works etc.

For this you need a release document to cover all of the above.

Potentially you could have more than one release document for a single RFC - depends what you are capturing.

Installing 32 servers in a number of small doses could require several releases against a single RFC.

Equally, you could have several RFCs on one release - again it depends on what is happening.

A Release document allows the Change into the 'live' environment

Update of the CMDB will depend on what software tools you have, if any.

Some will do it for you automatically(or so their vendors claim). Some will need you to run discovery tools to pick up the 'new' configuration, and some will need you to do it manually.

I hope this sheds some light

Regards

Ed

[ITILAddict]

Thanks Ed, your message is very helpfull.
Am I right if i say change and release go through the same pipe and there is no need to distinguish the 2 processes. Cause they both request at some point a RFC ? The difference would be RM involved softwares dev and 3 different environments (by the way is it necessary to ask for a RFC when it is time to change from dev environment to integration, then to pre-production )?

Do you recommand any particular dicovery tool...i was thinking of updating the CMDB manually but i don't know why people around me disagree

ITILAddict

[Ed]

Hi ITILaddict

Release and Change and Configuration work extemely closely together, but thay are separate processes, and will, in a large company, have different managers, with different agendas etc. It is also true to say that in smaller companies (like ours) the Change, Release and Config form part of the same team.

I cannot possibly recommend a specific discovery tool as I have only very limited experience with the ones we have.

I would never attempt to update a CMDB manually, unless there was NO other solution. It just blows my mind to think of it. any reasonable sized environment will have thousands of CIs of all varieties - mind boggling.

Regards

Ed

[outager]

Hmm. In my experience I did update the CMDB manually.

It all depends on the goal of configurationmanagement.

Disadvantages of auto-update:
- You cannot detect unauthorised changes. With a CMDB plus a dicovery tool you can look for differences. Those are likely unauthorised changes.
- With a manual CMDB, you can detect differences between the "current" situation and the "should be" situation. In case of an incident where for example a CI is changed by a hacker, you can use the CMDB to have information how the CI should be.

But again, the goal is different in different situations.

In a month we will be implementing HP Openview Servicedesk. That tool has a nice way of dealing with changes to the CMDB.
In a workorder you can relate a CI, and then you can register the new values for that CI after the change. So for example the requester can relate the CI with hostname oldserver, and he can register the new name in the workorder newserver.
This info is then very "synoptic" (is this the good word?) for CAB members. Plus you can have the CMDB updated "automaticly" after the workorder is closed.

I am very curious how this will function in real life! ?

Paul.

[RP]

Hi,

We do update our CMDB manually - despite having a large one. I feel if we do it automatically - we will loose control.

However to make life simpler asset discovery tools can track close to 100 attributes of each asset and populate it in a db - not CMDB. A separate db.

You can look at this asset info in one part of the window and CMDB asset info in another to help u compare. If the chnges to the asset done are appoved then you might want to import them (decision made by a human) you can do so with click of a button with a reference to the approved RFC.

This is R11 integration of CA Unicentre Asset Management and Unicentre ServicePlus Service Desk. This feature is a useful one - the description is not meant to be a positive review about this tool. I am sure you see the point.

Cheers!
Ravi