Hello,
We are looking to take baby steps onto ITIL implementation. We would like to start with and complete implementation of configuration management this year. However i am very new to this so i had a few questions:

It is said that do not implement a CMDB unless you have ITIL recommended CM processes in place. I am open to implementing new processes in our organization. Is there a link where i can get a list of all CM related processes, roles and some best practices on implementing them.

Think of a restaurant - consider each meal to be a "service". If you don't have a menu (service catalogue) defined which lists the meals you serve, and if you don't have a recipe (configuration baseline for the service) then how will you know what ingredients (CIs) you need? Once you know the ingredients, then you know how much of each to maintain (capacity), when to thaw out the frozen ingredients (availability - although Gordan Ramsey might disagree). It all starts with the Menu, which is dictated by the chef (Service Delivery manager I guess) according to the business needs the restaurant owner (business customer).

It is said that do not implement a CMDB unless you have ITIL recommended CM processes in place.

I would say it is pretty hard to manage anything unless you have strong change management in place. How else can you ensure that attempted changes won't do untold damage?

As far as "ITIL recommended CM processes" go, it could be hard to implement these if you are not already sure of your way forward with ITIL.

I would suggest that you extract the underlying principles of ITIL Change Management and build a change process from this. Your emphasis needs to be on managing not simply recording changes, although if you do not record changes to the CMDB you will be in trouble soon enough._________________"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

Well to add to the previous posts. Change Management and Configuration management are best implemented concurrently, as the configuration management facilitates Change Management by identifying areas/items impacted. Not to forget to mention that controlling the IT infrastructure without those 2 processes in place will be very hard.

As Ed mentioned earlier if you have an Asset registrar then your half way there. If not then I would recommend to start from there and then you can progress your way to Configuration Management.

I think it's dangerous to implement both Change and Configuration concurrently if you haven't got a clear idea of your services and the supporting systems in your Service Catalogue - otherwise how do you know what you're managing in your CMDB? Your CMDB should be a representation of your services with a value focus - you should only store data in the CMDB if you can prove the value of keeping it from a value point of view.

I'm struggling to contain a CMDB at the moment - it's been populated with every possible fact and figure about every component of a service. No-one uses the CMDB, because it's easier and more trustworthy for the support teams to just go look at the components directly than to go to the CMDB. I think that when you decide to capture an attribute type, you should also capture who will use it and why. That way everyone knows how the data is going to be used.

Personally, I'm sick of seeing CMDBs that are full of lots of data, but no-one can say what the reason for capturing the data is. I think there's value in taking a knife to the CMDB and leaving just the bare bones as long as it is used appropriately.