Register now or log in to join your professional community.
What is a Configuration management plan? CMP: meanings with components:
1. Scope - Do not start any plan without a scope. It is important to know your boundaries. In the case of CMP, an organization might have hundreds of services and you might be in charge of a few dozens - jot down which services come under the purview of this plan, and those that don't. It is good to put everything down in writing although many feel that it is implied.2. References - A configuration manager will obtain information from service architects, service owners, team managers and just about anybody who can throw light on the service in scope. The data is compiled, verified and is reconstructed on a configuration management database (CMDB).
To ensure the validity, and highlight the rightful owners of the data source, a section on references listing the data source against the service is necessary. This will help the configuration manager point the finger at the right source, when questions are raised. I would go one step ahead, and attach the received data and the emails in my plan.
3. CI Nomenclature - Every service asset or CI must have a unique identification. A server can have something like SRV123 or just123. Both do the job, but which one is effective? Can somebody just look at the CI name, and make a rough guess which technology it comes under with the latter? No. It makes logical sense to name CIs in a way that mere glancing can tell most of the story like what type of CI it is, location, complexity, and other attributes.
During one of my implementations, I named CIs this way -
So, a router will have something like RTR-LOC-L3-12345.
A team like the service desk which is on the least level of capability can make decisions on their own. In the example above, they could just as easily decode the CI as a router, placed at a specific location and handled by L3 support team. So, in essence, outage is minimized as the L3 team is directly involved during resolution, and a couple of functional escalations can be thankfully avoided.
A fellow consultant went one step ahead and hard coded the CIs to contain the name of the team who own it. My only argument against it was what would happen to CI names if a different team took over the ownership - let's say in an organizational rejig scenario. Would they start naming their CIs all over again?
4. Baselines - Regular baselining of CMDB must be scheduled at least one year in advance. A baseline is a benchmark drawn, for future reference to compare the deltas.
Most organizations call on two change freezes, one during Christmas and the other during Easter. I found it apt to take baselines during the change freeze period, and perform analyses if need be.
5. Change Control - Configuration management is strongly linked with the change management process. Without a valid change ticket, a CI cannot be touched - for modifying of course. In other words, change management controls the changes to CIs on the CMDB.
The CMP must specify how the change management process will interface with the configuration management process. And, at what point of the change activity will configuration management process be called upon.
6. Verifications and Audits - The accuracy of CI data is cardinal. To ensure that it stays accurate, a number of verification and audits are necessary.
Verification process is done by the configuration manager on a regular basis, and is mostly tool based. Modern tools are capable of providing reports that can help verify CI data. For example, if every CI has10 fields, the CMDB tool can pull a report of those CIs that are not fully complete. Or, if CI1 states that it is the parent of CI2, but CI2 does not state that it is the child of CI1, its noted as a discrepancy, and comes through in one of reports that the configuration manager can use.
It manages all changes related to characteristics and functions of product/service
The overall objective of the Configuration Management Plan is to document and inform project stakeholders about Configuration Management with the project, what Configuration Management tools will be used, and how they will be applied by the project to promote success.
Agree with both answers given by Mr.:Sahl & Mr.:Ali too
Configuration management is one of the few processes that overarch all other process and service lifecycle phases in ITIL V3. Wthout it, the effectiveness of the rest of your processes will be in serious jeopardy.
Here are the basic components of a CMP:
1. Scope - Do not start any plan without a scope. It is important to know your boundaries
References - A configuration manager will obtain information from service architects, service owners, team managers and just about anybody who can throw light on the service in scope. The data is compiled, verified and is reconstructed on a configuration management database (CMDB).
3. CI Nomenclature - Every service asset or CI must have a unique identification. A server can have something like SRV123 or just123. Both do the job, but which one is effective?
4. Baselines - Regular baselining of CMDB must be scheduled at least one year in advance.
5. Change Control - Configuration management is strongly linked with the change management process.
6. Verifications and Audits - The accuracy of CI data is cardinal. To ensure that it stays accurate, a number of verification and audits are necessary.
http://www.techrepublic.com/blog/tech-decision-maker/itil-what-goes-in-a-configuration-management-plan/
it depends upon manager thinking who to manage the plan
