I want to put all our IT services onto one chart for purpose of viewing end-to-end KPIs such as Resolution Time (across multiple support groups) Ė so will incorporate OLAís and UCís and be mapped to corresponding SLAís.

Whatís this chart called and are any examples or templates available for this?

Need to define all dependencies on other services, OLAs, UCs etc. Want to know best wording for this kind of matrix.

When I read this, I think of a "dependency tree or map", where for a given service you can see a breakdown of everything that depends on it or it depends on. This usually comes directly from the CMDB. For government contractors, we've labeled such a document as a "Configuration Spec".

What I think I'm still confused with is how you will map KPIs into the document, as there are "many" different KPIs that you could possibly use. I'm sure if you're going to limit it down to something specific like "Up-Time" or "Availability" you might make the whole view homogenous. However, when you start mixing in multiple KPIs that have nothing to do with each other, it might get out of hand, quickly.

Quote:

Also, when documenting service dependency on critical function, for example Network, how can I refer to it (as Network connectivity is not a service by itself?

A "Service", in the sense of how one is defined by ITIL, is really a wrapper around a Product. For example, "Email" is really a product that is rolled out to an enterprise and it is wrapped in a "Service" that dictates operational/behavioral expectations for it's end users/customers. As a result, you really are not dependent on other "Services" so much as you are other "Products", which have services wrapped around them. When you create your dependency tree/map, I would recommend you simply show all "Products" that your key "Product" is dependent on. What you can do is color any/and all Products that are important enough to have dedicated "Services" wrapped around them in a different collor. So, for example, if your Product depends on a build tool that doesn't have a dedicated Service wrapped around it, then leave that build tool black. If it also depends on a "Queuing/Messaging" tool that does havea dedicated Service (complete with SLAs, etc.) around it, then make the Queuing tool Green or some other color.

ITIL poorly mixes the concept of "Services" with "Products", with no clear delineation. In ITIL, a Service is merely a Product that is important enough to be tagged with things like SLAs/OLAs/etc. However, if you're running a top quality enterprise, you will have these things for "every" product in your environment, because all will need some level of support if something goes wrong. The problem is that ITIL "only" focuses on the production environment and leaves out everything in all previous environments, such as development and testing/verification tools. If a development tool goes down, a developer and, quite possibly a development team, is not working. You would have to address getting that tool working again and the process is also formal Incident Management. So, realistically, there is a need for a Service definition for all Products in your environment. ITIL, in its incompleteness, leaves this out.

Quote:

Any good examples or templates would help in shedding light.

Sorry, I don't. This is the first I've heard of mixing things like KPIs into Configuration Map. Not that I don't think it's a good idea... I simply just have not seen such a thing, before. My initial reaction is that you may find it very difficult to maintain, since there will be a great deal of information on it and collecting all that information for each and every Service/Product dependency could get ugly.

Quote:

Consider that providing Email relies on UCs with a number of internal support groups and vendors too. And it relies on a network connection, the ISPís email connection (eg SMTP) etc.)

Looking for a nice way to model all of this information & show relationships between them and the service provided.

The minute you start using words like "relies" & "relationships" or "depends" & "dependencies" I instantly think Configuration Map, where the map consists of dependencies that are only one degree of separation, away. If you maintain your CMDB properly, this map will be very easy to pull from your CMDB. If not, I'm afraid that you may have a very hard time managing it and keeping it up to date.