For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone
Note: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
Posted: Fri Sep 28, 2007 7:55 pm Post subject: Service Catalogue & CMDB
Please advice on which of the 2 “Service Catalogue & CMDB” takes preference when implementing Service Management and how would one go about it to make sure that the project becomes a success?? Is there a relationship between the 2 or are they separate entities??
Joined: Oct 13, 2006 Posts: 116 Location: South Africa
Posted: Thu Oct 04, 2007 9:58 pm Post subject:
Normally a Service Catalogue is the recommended place to start. Most beginner organisations don't have one, and the value even from a basic one can be quite significant.
Most organisations do have config data, just not in an integrated consistent form. Getting all the data integrated and accurate, and linking change and release processes to it for control, are major long-term tasks (so long term that I do not believe any company anywhere in the world has finished ).
So you can deliver a valuable Catalogue more quickly than you can deliver a valuable CMDB.
They are definitely related. But ITIL seems to have changed the terminology from V2 to V3. In V2, the CMDB contained all information - including the catalogue - whereas in V3, the (or multiple) CMDBs are part of a larger service knowledge management system (SKMS) and the service portfolio and service catalogue are outside the CMDB. I could be wrong on this, or I could be wrong in thinking that this change was done for bad reasons.
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Wed Oct 10, 2007 9:41 am Post subject:
Hello sbhikha,
Whether or not the Service Catalog is a part of or decoupled from the CMDB is an implementation detail that has tradeoffs to your enterprise. You will have to evaluate the tradeoffs of having a single, unified solution versus a decoupled, multi-system solution. Part of this evaluation will be the understanding of a detailed ROI analysis.
From our own experience, I can tell you that the world and our customers and prospects seem to be leaning, more and more, towards a unified solution. Typically, the Total Cost of Ownership is lower, there's less to manage, it requires fewer people to manage, there's far less training, it eliminates integration costs, etc.
In this day and age, consolidation of platforms seems to be a good thing for most leaders. However, please understand that you will still need to come to your own conclusions.
If you want to discuss it all, in more detail, please feel free to reach out to me, offline, and I'll gladly share whatever experiences I can on the subject. My email address is Frank.Guerino<@>TraverseIT.com.
I hope this helps.
My Best,
Frank Guerino, CEO
TraverseIT
On-Demand ITIL Platform
Hi, regardless of V2 or V3, the Service Catalogue and CMDB are two very different entities.
A Service Catalogue may live within your CMDB as a CI, as you want to mange any changes to the Catalogue to ensure everyone within your organization is aware of these changes at the same time.
I feel these are two separate initiatives. There have been looks of discussion around CMDBs and looks of good information you can gleam from them. Search through the thread.
As with anything, you need to find the right business requirements, the right CI depth, etc. Start small and allow the CMDB to grow. Work in the production environment and you can effectively tie Change Management into the management of the CIs. Remember the CMDB is not everything to everybody. You need to define some boundaries to start.
As for the Service Catalogue, this requires greater understanding of the Business and what IT wishes to provide in terms of Services. What one company may think of an IT Service may not be in the larger sense. Do we have Email as a service, or is the service Collaboration which includes products like Email, Video conference, etc. The reason you are putting in place a Service Catalogue is to eventually get to a point where you can show the cost of the services to the business to help IT justify its existence. This is a good thing as many IT organizations are unsure of their costs.
One other thing I would suggest you consider, is not to allow the tool to direct what you need. A tool will limit where you may want to go within your organization as you will have to work within the tools constraints, but be cognisant of the fact that ultimately you will need to use a tool and you will then be able to decide what is important to the business and what can be changed to adapt to a tool.
Cheers, _________________ Azard Omardeen
ITSM Service Manager Certified
Consultant and Trainer
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Mon Oct 15, 2007 1:40 pm Post subject:
Hello Azard,
I think you may have missed my point.
Yes, I agree that the Service Catalog and the CMDB are two very separate entities. However, they do "not" need to be two separate tools. They can both be provided to your enterprise as part of one common tool, such as our own On-Demand ITIL Platform, which incorporates many ITIL tools, all as part of one master, transparent platform. In such a case, there is no independent Service Catalog and/or CMDB. They are one in the same piece of software.
As for the implementation of a Service Catalog, it is actually very simple to do, if done correctly. There are two types of Service concepts that have to be addressed:
1. The V2.0 Service Catalog addresses Services in the form of systems and applications (e.g. Email, the Network, your business applications, your finance applications, etc.). In this case, at a minimum, the Service Catalog is nothing more than a catalog/inventory of all such 'dialtone-like' Services.
2. The V3.0 Service Catalog addresses the old IBM type of Service, which correlates to a Service Request. So, for example, you can go to the catalog, scan the inventory of all Services that are performed by any and all Service Groups and invoke a Service Request to have a particular Service executed, which will yield a very specific and repeatable deliverable.
If you understand the difference between both of these Service types, then setting up your Service Catalog should be pretty easy, especially if you're using one that's an enterprise class application.
On your last paragraph, I would have to agree. However, I would throw in one other critical suggestion. Don't let people with limited ITIL experience define what you do or don't need to properly implement any piece of ITIL. We're finding, more and more, that people with limited experience, who implement ITIL, typically do more long term damage to their enterprise than they do good. Be cognizant of the fact that very few people with ITIL credentials have any real ITIL design and implementation experience. I recommend that you find those people who do. Having people who have a great deal of design and implementation experience will be the difference between a long, expensive, complicated, and incomplete rollout, versus a short, cost effective, simple, and thorough rollout.
Anyhow, I hope this helps.
My Best,
Frank Guerino, CEO
TraverseIT
On-Demand ITIL Platform
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
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
).
