Configuration Management, Without The AgonyGroups working on Configuration Management need to start simple and learn in order to be successful.
One group I worked with simply identified classes of configuration items (server, network device, operating system, application, etc.). For each configuration item they only recorded the unique identifier and the necessary parent-child data that is so very important for mapping out relationships. That was it. They got up and running very quickly, at a low cost and learned a lot along the way. Their objective was to understand dependencies as they often had problems planning changes and responding to incidents because they didnt have an enterprise view to how the various component configuration items in a given IT service related.
Scope of systems
The next critical element is to decide where to start. A big bang approach can be a nightmare. Instead, start with a class of systems that is relatively controllable in a central location. This is really a pilot approach wherein the initial process and data model are developed and tested. The scope is slowly increased and corrections made if needed.
One area I tend to actively recommend against are desktops. They tend to be the least controlled and most political. Furthermore, if something is going to be in Configuration Management, it really needs to be governed by Change Management. The volume of the desktop changes could derail efforts.
As just alluded to, there is another important element when determining scope and that is politics. There are groups that will be more willing to work with a nascent Configuration Management process and the team working on it than others. It is wise to determine the scope based on this as well.
When determining what data is needed, it is critical to understand what management information is needed at a bare minimum for each process to be successful and what senior management needs to understand how IT is performing.
This means holding process design meetings and actively identifying what is needed at the time of initial launch and then over time as updates to the process are released into production. Again, design for what is needed versus everything that is technically possible.