Change Management without Configuration Management

[hutch]

I recently read that when Change Management is implemented without Configuration Management, Change Management solutions are much less effective. Can anyone offer me some insite on this statement?


Here is the artical where I found the comments.
[Moderator: URL removed. We delete direct links to discourage forum spamming. Thanks for understanding. ]

[H]

You are correct- if you implement change management without configuration management it becomes very difficult to track and manage your configuration baselines and there would not be a formal record such as the one that would be posted in the configuration management database. Also there would be no relationships posted. All in all one without the other defeats the purpose of doing them together.

H.

[hutch]

OK. We are in the middle of creating a change management process. Do you have any advice for implementing configuration management? I am not very fimiliar with configuration management. The ITIL definition is very wordy to me. Can you please post a brief description if configuration management and how it has benifited you? Thank you for your response!

[jpomales]

Simple. CM provides a logical model of your infrastructure which enables you to identify, control and audit what you have in there. Far more than a simple asset management system, the CM enables you to normalize and baseline what you have there and make sure that no unauthorized elements are introduced into the infrastructure. That's why Change Management must work in tandem with Configuration Management. You see then that Configuration Management will enable you to see what has been changed on a particular infrastructure element, who authorized it, when and where.

My two cents. Hope this helps!!
_________________
audentes fortuna juvat

[Guest]

OK. I think I hear you saying that Change Management is the procedure used to make changes within the infrastructure. Configuration Management is the way to document and control those changes, as well as audit them to ensure the validity of the documentation. Is this correct?

[Guest]

Correct me if I'm wrong, but Change Management would be the procudures/group that approves the changes

Release Managment is actually the group that does the implementing

Configuration Management would be the documentation of who what when where and why...

[Guest]

I would say that is correct. Thank you for all of your insight. You have been a great help!

[Aziz_BG]

Configurations management and change management are close.
In implementing Config Mgt u have to implement CMDB wich allows you to link some ITIL processes like change mgt - problems mgt - incident mgt and in this way it makes your processes more efficient.
It's my idea about that. in my company we are implementing CMDB in order to make link between our ITIL implemented processes.

ABG

[rjp]

Configuration management is probably the ITIL discipline that is most derailed by operational concerns. By operational concerns I mean building a data repository for systems management instead of service management.

This tends to...

Increase the volume and complexity of the data.
Increase costs (into the stratosphere in some cases)
Not return true vaue to your service delivery effectiveness.

The three most important things to get clear about configuration management.

1) It is a control discipline for the infrastructure - as correctly stated above it should lessen unauthorised changes and identify the ones that get through.

2) It stores the configuration - not assets, so the relationships between CIs are far more critical than the attributes attached to the records. And the most important relationship is aggregation. Even if you have every single thing in your entire infrastructure recorded you do not as a result of that automatically have a CMDB.

3) 'Semantically' it should support management first and operations second. In a nutshell it should show you how each CI functions as a production factor of your services.

This last point included a subpoint that is generally worth keeping in mind when undertaking any ITIL based process development.

ITIL processes are management processes, value to operations should come through better management and identified 'value adds' in the region of activity where operations and control naturally overlap.

The reason oh so many ITIL process implementations are hard and fail to get traction is that they try and gain the operational extras before getting the core management value.

Also as you proceed approach 'CMDB' vendors with care. These are worthy companies with some excellent products. Buy they would go bust if they did not meet customer demand. And customer demand primarily reflects many of the things I have said here - a foucs on operational concerns and systems management. Few even have an architecture for the mapping of CIs as service production inputs. (Rather they just capture the kind of stuff SNMP gets, or at best stop at some kind of delta audit and automatic failure reporting capability.)

After having said all that - if your reaction is 'Well actually my concerns are operational systems management practices', then simply don't go for the CMDB. Look instead to the Infrastructure Management chapter of the ITIL, which would cover such concerns, and consider looking at any one of the operational monitoring tools out there.

Don't try to implement the most costly process in ITIL unless you really have the ITIL objectives as your objectives.

[rjp]

[Guerino1]

Hello all,

I read through the entire thread and figured I'd add some basic info.

Based on simple experience (forget about ITIL and think bigger picture)...

Change Management is the process by which an enterprise defines and manages "Changes" through any and all environments. This includes but is not limited to the mechanisms for Defining, Creating, Editing, Versioning, Viewing, Reporting, Searching for, Promoting, Rejecting, etc. Changes. It also includes the processes and mechanism for creating and managing dependencies within and between any and all Changes.

Configuration Management is the process by which an enterprise defines and manages its "Configurations" through any and all environments. This includes but is not limited to the mechanisms for Defining, Creating, Editing, Versioning, Viewing, Reporting, Searching for, Promoting, Rejecting, etc. Configurations. It also includes the processes and mechanisms for creating and managing dependencies within and between any and all Configurations.

Configuration Management is critical to Change Management because it allows an enterprise to understand what, in any configuration, has changed, why it has changed, and what the impact of such a change will be? You can perform Change Management without Configuration Management but you will find that it will be incomplete and rather weak, as your enterprise will most likely not understand the Change if it does not have Configuration details. Also, without truly understanding the detailed Changes to any and all Configurations, you will find that the quality of your enterprise's Changes will be rather low and the risk of error will be rather high.

What you will also find is that if you have a very detailed Configuration Management solution, in place, you will be able to very accurately define the work associated with any and all Changes. This makes the Change process far more successful and reliable.

You will also find that having a detailed Configuration Management solution is key to successful rollback of Changes, from a recently modified or implemented Configuration that has problems back to a previous and more stable Configuration.

Anyhow, I hope this helps.

Regards,
_________________
[Edited by Admin to remove link]

[Ed]

Sorry folks - I came to this one late.

Having done exactly what the thread implies all I can say is DON'T DO IT.

Anyone that implements Change on it's own will suffer from a lack of control within the changes. This gives the potential for CIs to be ignored from the point of view of the Change and can cause massive side effects. We had an example whereby the implementer did not take account of the fact that a file was read at both ends of the process. He was changeing the end process and caused the early suite to crash with no-one on support. Our customer was not amused as his overnight batch processing was delayed by eight hours, this in turn kept his branch network off the air and unable to trade. Nasty stuff!

I could go on all day on this one, but don't want to bore you all to tears.

Regards

Ed