Joined: Sep 16, 2006 Posts: 3582 Location: London, UK
Posted: Fri Apr 27, 2007 8:18 pm Post subject:
You sure about this... The lesssons learnt would fill 2 or 3 books
I will give a try
The first lesson to be learnt - Data Collection and data entry
When an physical inventory is taken of what servers, routers etc are in a data center floor area, there are several ways to collect the data and store the data
1 - have unique Company Asset tags which are bar coded. The information is collected during the arrival of the kit
1a - Then you can go around with a barcode reader and inventory the kit
2 - find the damn serial #on the device and enter it in a inventory sheet
2a - the serial # may be on the front back or the sides, top, bottom. The front and back are easy to get to in a rack cabinet but if the kit has been there for years, the s/n may _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Mar 03, 2007 Posts: 33 Location: Minneapolis
Posted: Sun Apr 29, 2007 12:12 am Post subject: Data control
Involve data professionals. The remark above about people putting in various values that mean the same thing is a data architecture question, pure and simple. Your vendor may or may not understand this - in my view, any tool that allows/encourages people to enter data in such a way is substandard, but there are far too many out there like this.
I have devoted *considerable* effort in multiple engagements to defining an official list of "applications" (as services, not software products). Such an official list has great utility across multiple ITSM processes. If you have competing/overlapping/inconsistent "application" lists, suggest you attack this hard. Doesn't necessarily cost large amounts of financial capital, but it will cost you political capital.
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Sun Apr 29, 2007 4:38 am Post subject: CMDB Implementation Lessons Learned
The list of lessons learned can be very large. However, here are some of the most critical things to keep in mind (in no particular order)...
Cost of Initial CMDB Implementation: Most enterprises that invest in CMDBs have no idea how exensive it is to implement a good CMDB. Aside from the cost to purchase and deploy the tool itself, there are all the integrations that have to get built to other systems, the work that it takes to get the data in, the work to understand how your enterprise will maximize its return on the investment, etc.
Cost of Maintaining a CMDB: Most enterprises that invest in CMDBs take no time to spell out the costs, in detail, of what it will take to maintain and grow the CMDB, year-over-year. The costs associated with doing so could be huge, when not done correctly.
Understanding the Return on Investment for Your CMDB Implementation: Most enterprises implement a CMDB without itemizing, in detail, what the return on that investment will be. Taking the time to do so and communicating that justification to get buy-in is absolutely critical. Identifying the return on investment is not always easy.
Complexity of Implementing and Maintaining a CMDB: Most enterprises have no clue as to what they're getting themselves into with the implementation of a CMDB. Of all operational systems, once an enterprise starts feeding data in or out of a CMDB, it becomes a critical dependency for all other systems. As a result, it will require a significant effort to grow and improve it, build and enhance integrations, implement useful datamining, implement useful reporting, etc. Many people think that implementing a CMDB is nothing more than building a data model. The reality is that the CMDB will become one of the most complex distributed applications that an IT organization will own and run for itself. Most enterprises that want a CMDB rarely have the resources necessary to care for it, over the long term.
Having the Wrong People Drive the Selection and Rollout of a CMDB: A CMDB is a highly distributed software application that will need some serious care and feeding to grow it and integrate it to many other systems. In most cases, CMDB implementations grow from within infrastructure teams, because of ITIL. A very big mistake is that the infrastructure teams don't hand off the effort to a firm's software architecture and process teams, who are far more experienced in such tools and technologies and who typically have responsibilities for bigger picture landscapes in IT. If your enterprise doesn't have such an enterprise architecture team, you have another problem...
Underestimating Integrations to and from a CMDB: Creating integrations to other systems that will help populate the CMDB or use data from it is an expensive and complicated task. The CMDB, as a stand-alone repository, is virtually useless to an enterprise. Done correctly, it will act as the IT data routing hub for all operational IT data/information.
Incomplete Identification and Understanding of Proper CMDB Feautures and Requirements: Unfortunately, most enterprises that implement CMDBs don't take the time to truly understand what a good CMDB is supposed to do. Instead, they only look at the requirements that fulfill what the implementation team needs. This is a sure sign of long term failure as, more often than not, the implementation team has very limted needs, when compared to the bigger picture needs of an enterprise. It is critical to understand everything a good CMDB should do, even if you don't intend to use all features, from day one, because once your CMDB is in place, it's growth will not stop there. An enterprise that is constantly maturing will want to mature and expand the functionality of their CMDB to address that enterprise maturation and expansion.
Oversimplification of CMDB Scope: Many enterprises try to narrow the scope of a CMDB, for initial implementation. In doing so, they have a tendency to leave out the proper room for growth that will be needed to address many other forms of Configuration Management that they may not be thinking of, day one. For example infrasructure people tend not to think of the needs of software people, or facilities people, or project managers, etc. As a result, the CMDB purchased or implemented is limited to the scope that the planners wanted to solve for, at the time of implementation, and more often than not leaves no real room for growth and maturity.
Poor Data Freshness/Accuracy in a CMDB: Many enterprises implement a CMDB thinking that it will become the central hub for "true" data. However, if data is being generated in other systems that feed the CMDB, the CMDB can "never" be that point of "true" data. Those systems that feed it will be (assuming that's where data is created). What this means is that the CMDB, if implemented as a stand-alone non-operational system, will always have data that is out of date, unless you can guarantee transactional synchronization between the source system and the CMDB (which is virtually impossible since most source systems are not built to facilitate transactional data pushes). This leads to the alternative, which is to select CMDBs that you work directly in, to create and manage data/information.
Choosing "Repository" CMDBs Over "Operational" CMDBs: The difference between a CMDB that is a data repository (the most common type) and one that is operational is that the data repository form is not the definitive true source of data (and can never be). The best it will ever be is a data hub. The operational CMDB is a place where people work, daily, and where data gets created from scratch. As a result, because data is created within it, an operational CMDB is the true source of data. This ensures that the CMDB will have a much higher value and provide a greater return, from day one. Also, an operational CMDB that has tools to address individual operational areas of your organization (such as Incident Management, Project Management, License Management, etc.) will act as a platform to allow that enterprise to decommission many other tools over the long term, in addition to the many integrations that might be necessary between those tools.
Inadequate Handling of the Human Factor: It's always amazing to me how many people talk about CMDBs but can't actually describe one, accurately, when pressed to do so. Too many people confuse a CMDB's features with Asset Management features, think of it as nothing more than a data model, etc. It is important to properly train people on what the tool is, how it fits into processes, how it will be integrated into other tools, why it must exist, what its impact will or won't be, etc. It becomes critical to ensure that people will know and understand how to use the CMDB and the Configuration Management processes to solve problems for themselves and others in the enterprise.
Not Treating the CMDB as a Service: Once a CMDB is in place, it will be a service that will need to be maintained with detailed SLAs/OLAs. Not doing so can have some severe impacts on an enterprise. To make a CMDB successful, an enterprise will need to put Product and Service Owners, Organizations, and expectations around it.
Not Managing the CMDB as a Product: Like any other products that an enterprise manages, the CMDB should have a clearly defined product owner and a team that will plan its upgrades through managed SW releases. This means that SW development lifecycle best practices should be applied to how it is managed, ensuring the builds, deployments, tests, etc. are all repeated "properly" in every environment (Dev, Integration, QA, Production, etc.)
Not Understanding the Future Criticality of a CMDB: If you take a CMDB and use it to feed data/information to downstream systems, those systems will become dependent on the CMDB. This means that the more systems that depend on it, the more critical the CMDB will become to the enterprise. This will slowly raise the CMDB from a Tier 3 application to a Tier 1 application, over time. Many enterprises fail to realize that this will happen and don't plan for it, from day one. Remember, if the CMDB becomes a dependency for many downstream applications, it will become critical for disaster recovery, as it will need to be one of your first systems to be recovered in IT.
Over-Glorification of the CMDB: Many people implementing a CMDB think that doing so will have a huge positive impact on their enterprise. The truth is that, while valuable, unless you're using your CMDB as an operational system that facilitates your "tool take-out" strategy, which will allow you to decommission other operational tools and directly impact your P&L, your CMDB may not have nearly the impact on your enterprise that you think it will. Also, because it takes such a long time to properly integrate it to all your systems, unless you're strategically managing a big picture plan, you may find it very difficult to gain the impact that you thought you might, at the beginning of your initiative.
Anyhow, again, please understand that there are many other valuable lessons learned. However, these are usually the most obvious and the type that most leaders will want to know about. I certainly hope they help you in your efforts.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum