Creating a Configuration MGT Procedure and Policy

[jeffburns75]

Has anybody implemented an Configuration MGT Procedure and policy?

We are currently using INFRA as our CMDB tool and updating it with our CI's as well as using the CMDB for all Incident, Service Request and change requests. We have been using this tool for several years but we are lacking a procedure and policy on Configuration Management in our enviroment.

One of ther questions i have is, has anybody created a procedure on how to do configuration management? Or has this been included into another procedure?

The other question i have is, has anybody create a company policy on configuration management? or has this also been combined with another policy?

If you have how did you go about this and what were the major topics you covered in each area?

Any help would be great..

Thanks

[mnsmith]

Jeff

I've had a go at writing one numerous times over the years and have come to the conclusion that you need to use the KISS method - keep it simple stupid.

Your policy could probably fit on one piece of A4 and should states things like:
- who's in charge of config mgmt
- roles/responsiblities
- the type of CIs that will be recorded (desktops, monitors, etc)
- the CI attributes
- the relationships between the types
- the process for managing CI type (i.e. who to approve a new type)

And that's about it.

The important bit and the thing I think you need, is an asset management process for each CI type. This process will then state who owns the CI type, the point at which they added to the CMDB (purchase/installation etc), the review/audit procedures.

By separating the config and asset policies users won't get drowned in information. For example, if I only deal with servers, which should I wade through a 100 page document to find the section relating to me? The odds are I won't bother, ending up with inconsistencies which will spiral out of control.

You have to remember that config mgmt is the best thing since sliced bread to all config managers but is dull as dishwater to everyone else. Therefore, keep config lightweight and beef us asset management, which people understand more. As long as you've got solid links between the two, it works fine.

Hope that helps

Mick

P.S. We also use Infra....
_________________
Mick Smith
Change, Configuration and Release Manager

[Azard]

Hi, I have helped designed several Configuration Mgmt processes for various clients. Let me add to some of the points mnsmith has already provided.

A couple questions I would ask myself are:
- What is the scope of Configuration Mgmt? How large do you want to start this initative? Am I am just working to design a process for one group, am I going to try to design a corporate process, or is it a combination of both?
- Do I have the key stakeholders involved to help design the process
- While not all assets are CIs, you need to decide what are going to be assets vs CIs.
- Who has authority to manage the CIs?
- What types of configuration relationships/configuration models are you trying to design?

I would take some time to plan what I want the process to look like, and then work towards the goal. Think about what types of reports you would like to see, what types of relationships. Having an understanding of who is going to use this information and why, goes a long way when design the process.

Good luck with the efforts.

Cheers,
_________________
Azard Omardeen
ITIL Expert / Accredited Trainer / ITSM Consultant

[jpgilles]

Hi,

I am currently reviewing our Configuration Management process.
THe process itself is quite simple (creating and managing the CMDB structure, Updating the CMDB, Auditing and Controling the CMDB are the main sub-processes).
The complexity comes with the implementation.
The first choice of the company was to have every actor of a change to update the CMDB with information pertinent to that change...ending up with more than 100 people that are supposed to deal with CMDB information (CIs and relationships) the exact way you want them to: this is a real nightmare.
What we are trying to do now is to setup a central team that will deal with updating the CMDB , based on information provided by the various people that do perform changes (validation of information provided to Config Management is being part of the Authorization to proceed with the impementation of the Change): this is just another nightmare. For information to be consistent , we need to provide people with a template , which should basically show the CIs and relationships as they are BEFORE the change and as they should be AFTER. We are currently on this and dealing with some technical issues (how to build a suitable template from a ralational database is part of the issue).

I am not sure if that helps, but that is where we are.

regards
JP
_________________
JP Gilles

[Diarmid]

JP,

I suspect it is partly a matter of scale. In a smaller organization where there may only be, say, a couple of dozen people involved, it might well be best that they are all sufficiently trained to perform update activities within their clearly defined sphere and following clear procedures. It would be a judgement call based on the maturity and culture of the Service Management organization and on the complexity and diversity of the CMDB.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718