Entering new CIs

[dsemeniuk]

We have took a stance in our CMDB that all CIs entered or updated should have a related RFC to link to the CI.

Question is, when would new software be introduced into the CMDB. What process is used to get approval to but say a new developer tool to use against a database and then get entered into the CMDB with a status of Planned/Ordered?

Right now for us it would be when the requestor wants to install the software into an environment, with an RFC, thats when we would first get exposed to the new CI and enter it into the CMDB, but I would like to have that CI in the CMDB when it is first approved to buy so we have a record of it in the CMDB before installing it but I don't see this happening through the RFC process as it doesn't quite make sense to use an RFC to buy software.

Thoughts/comments?

Thanks.

[dboylan]

dsemeniuk,

I think you might be confusing Change Management with Change Control. Change Control is a subset of the Change Management process that is focused on ensuring that releases into to the production environment don't conflict. Think of it as collision avoidance.

Change Management is a process that governs all aspects of the introduction of items into the production environment, including it's purchase. Why would a CAB have fiscal representation if the product has already been purchased?

(copy/paste from a previous post)

To think of it terms of modern IT, Change Management is what most corporations do with an Office of Project Management (PMO) department.

They are the ones who review requests in terms of its business, financial, and technical values. If they think the project has merit, then they are the group that coordinate all the activities of the project.

This is, in essence, what Change Management is all about.

Not one dollar is spent on a project until the PMO signs off of on it. Not one resource is spent developing code until the PMO signs off. Once the PMO gives its approval, then the entire project is (micro-)managed through the PMO. The PMO does no actual work on the project, but no work is done unless they authorize it.

Swap out "PMO" with "Change Management" and "project" with the word "Change" in the previous paragraph, and you have the idea of what ITIL's Change Management process is all about.

(end of copy/paste)

So Change Management is the process responsible for approving the expenditure of funds. If the RFC is raised properly, then the CI is entered into the CMDB prior to the purchase of the product.

If a RFC comes to the CAB for a product that is ready for introduction into the production environment, then you are doing Change Control, not Change Management.

Don

[alphasong]

You have accurately portrayed the scope of ITIL's Change Management concept, where most people don't get it.

My problem with this is that the language is completely inconsistent with the reality of large scale IT practice. The point is, we *don't* call it Change Management - we call it program/project portfolio management or what have you. ITIL's overly broad use of the term just confuses things.

Not sure where v3 comes down on this. I should have it in hand next week.

-Charlie
_________________
Charles T. Betz