Change ,Release & Configuration Mgmt

[Kathy]

Hi, everyone!
I just begin to do a Configuration Mgmt project for a company,now my task is to design the details of the process.Of course it's not solitude,as it's connected to release and change mgmt, I should also concern how it coordinate with the two processes.
As I'm a new in ITIL, I only have a little knowledge of theory about it. So,is any one of you would give me some suggestions or examples you have experienced(better) or something like this? I really need your help.

Thank you in advance!

Kathy

[Guerino1]

Hi Kathy,

What's the scope of what is "in" or "out" for your project? For example, are configurations of Servers, Desktops, Custom Built Software, etc. in or out?

Regards,
_________________
[Edited by Admin to remove link]

[Kathy]

Thanks for your reply first,Guerino.
My project firstly deals with applications/infrastuctures,which includes some subclass,such as server,database,schema and so on.I don't know if I have made me understood?

Kathy

[Guerino1]

Hi Kathy,

So, what I gather from your response is that your scope is rather large. Let me ask you some questions that may help you get to your answers.

1) Have you already purchased a CMDB or do you have plans to build one? This will impact your process as you'll need to store all the information in a centralized place that everyone else can leverage.

2) How many assets does your organization manage? (Tens? Hundreds? Thousands?...) This will dictate what you can or cannot use to store your data. Small quantities mean you can get away with spreadsheets before you start to grow. Large quantities will require something larger, like a formal CMDB.

3) Do you have automated solutions in place to collect data from each of the assets or will your enterprise be collecting and managing such information, manually?

4) Are all of the data owners on board with the work required to provide you with the data and to help manage it, going forward? For example, are all of the Hardware Server owners on board with providing and managing their data? Are all of the development teams on board with providing and managing their data? Etc.

5) What is your enterprise trying to get out of the "Configuration Management" process? Is it visibility for quicker Incident resolution? Is it visibility for quicker development debug time? Is it centralized inventories? Etc.

If you can answer these, they will help to start you on your way. Let me know what you believe the answers are and we can go from there.

Regards,
_________________
[Edited by Admin to remove link]

[rjp]

Hi Kathy,

I'd like to augment Frank's response...

He is spot on with his questions - it's all about scope. With special attention to quest 5 above....

What is the primary focus of the people sponsoring your project: Service Management of Infrastructure Management?

The two things are related, but the differences have a direct bearing on how the obejctives of a CMDB will be perceived. Moreover, in many organisations there in insufficient differerntiation of these two managment layers, and no real understanding of Service Management's position 'higher' up the management pyramid. Infrastructure Management is focused primarily on the technology - it's health, efficiency, cost, etc. Service Management is focused on how that infrastructure is delivering capability to the business. The key is that a perfectly running infrastructure may be delivering crap service. This is the core 'business alignement' principle of ITIL.

CMDBs support Service Management. A CMDB is an information architecture that lets you see how all the various components of your infrastructure work together as production factors of your Services. This is commonly referred to as an end-to-end view of your services.

Secondly the Configuration Management process is primarly an information managmenet process: Concerned only with collecting organising and maintaining the information that will give you that end to end view. That information will be then used by other management processes.

Service Management configuration information is considerably simpler (and leaner) than the information Infrastructure Management requires.

Generally technologies and tools that automatically aquire, organise, and present infrastructure information (eg, Open View agents, SNMP reporting tools, etc) collect far more information than a CMDB requires.

A good CMDB stays in scope by identifying what is relevant and appropriately filtering infrastructure information so that management controls can be implemented.

I like to think of it as a map and terrain metaphor. Maps are very powerful tools because they abstract and filter information about the terrain in a way that is aligned to the purposes of the user. If a map is too detailed, then it becomes as difficult to negotiate as the terrain itself and offers no real advantages.

So I would be very overt about negotiating the terms of reference with the sponsors - if they really want a highly functional infrastructure management system then get them to drop the term CMDB. If they do have a number of Service Management process in place (change release, etc) then get the infrastructure and service management objectives into two separate 'columns' and ensure that the priority and resource requirements of each are identified and agreed to.

Start by asking what management controls are required. If there is no answer, or just a lot of vague ideas, then the focus is actually on the technology itself and you are being asked to provide a centralised infrastrcuture management system.

IMHO - because of the complexity, heterogeneity, and volatility of technology there can be no uber-system for its management, and a CMDB implemented to that end in on shakey foundations.

[Kathy]

Thank you Guerino1 and rjp.
The questions Gue asked me are what I didn't think about, but now I can answer part of them at least.Our comapny haven't get a CMDB and just plans it. So I guess the other processes such as automation collection of data are still unavalible.
Our focus of project is Service Mgmt not Infrastructure Mgmt,as stressed by my manager.It will be mainly about the control of applications ,and of course these applications are resident on some special hardware and software and the things like that.So I guess we will need a CMDB.
As so far, we are just in a zero stage, and thus I will start from here.I am supposed to give a draft of the config mgmt by the end of this month,which makes me feel a bit stressed.
Thank you for your help!

Kathy

[Guerino1]

Hello Kathy,

Some follow-up information and questions, below...

[Kathy]

Hi,Guerino
By saying"Our comapny haven't get a CMDB and just plans it."
I mean that our company just want to start Configuration Management,and didn't have a CMDB before.So ,I think we will need it.
What you have said is really what we need to consider, then what I need to do is just to analysize the requirements and then design the detailed process of CM.

Now ,I have made a simple paln(I don't know if it can be called a plan), which includes the purpose,scope ,objectives and requirement .I am planning to collect the information of the company's detail, I want to know if what I have done is right .
Thanks for all your relpies!

Kathy