Sample ITIL Service Catalogue documents
FWIW, here are some sample ITIL service catalogue documents. They may not be flash but they are better than what you get in the ITIL V3 Service Design book. I have used these a couple of times with success but they are not extensively road tested: they are provided on an as is basis with no warranty or support.
From my book Owning ITIL®:
The ITIL2 books don’t make much of Service Catalogue but it is the central, pivotal, fairly-static object in the ITIL world. (The central dynamic, transactional object is the Service Desk ticketing system, and the asset database). ITIL3 makes more of Service Catalogue, but still does not place it as centrally as the IT Skeptic and others would.
Service Catalogue drives your people. It is a key mechanism in cultural change, the foundation of customer relationship, and a pivotal tool for organising effort.
Service Catalogue informs your processes. It is only once the services are defined that all the ITIL processes know what is required of them, and how to prioritise.
In the IT Skeptic’s model, there are four levels of catalogue, which represent levels of maturity. Because ITIL2 and ITIL3 use “catalogue” slightly differently I thought about using another name, but “catalogue” exactly describes what people expect to find in such a document.
• Current Catalogue: an “as-is” snapshot that defines the current set of services being delivered. This includes legacy services which we have no intention of offering to any more users. It forms an essential artefact to focus staff on the service-oriented mindset - a touchstone - and it defines the “as-is” state. Target audience: IT.
• Brochure Catalogue: a high-level document written in business terms that defines what is on offer to the business. It is used by Relationship Managers to provide a basis for discussions. It is used by staff as a point of reference. In ITIL3 terminology, this is the Service Pipeline, plus those parts of the Current Catalogue that we want to continue to offer . It provides a definition of the “to-be” objective. Target audience: Customers, Users.
• Technical Catalogue: a union of Current and Brochure catalogues to describe all services actual and potential, with extensive supplementary information. It is used in the ITIL processes. The SLAs - once you have them - form a part of it, and there is much else: critical components, related services, escalation paths, available training etc. Target audience: IT.
• Automated Catalogue: an interactive tool that allows customers to browse and order services. Almost always, the real-world instances of this are not for customers, they are for users to make requests associated with services (customers pay, users consume). In the most advanced manifestation, services are provisioned in response to user ordering. To be clear, this is a request catalogue not a service catalogue . This idea is all the rage, although the technology has been available for a decade – think ASP. As with all of these things the technology is the easy part. The business model, the means and terms of chargeback, and most of all organisational acceptance and uptake are the real issues. And the automated tool still needs to be backed up with the three documents above. These levels complement each other, not replace each other. Target audience: Users.
The early outcome to look for is the Current Catalogue. The Brochure Catalogue and the Technical Catalogue grow over time. Many organisations will never reach the level of Automated Catalogue.
| The geeks amongst may enjoy a diagram relating this catalogue structure to ITIL’s Service Portfolio Management. This sample can be used as a Current Catalogue. At a pinch it could be used as basis for a Brochure Catalogue too though I have always wanted to do a template specific to that to show the level to write at (one day!). It will work as a template for ITIL V3 Business Service Catalogue. This sample can be used as a Technical Catalogue (much the same as an ITIL V3 Technical Service Catalogue). This spreadsheet sample can be used for those who'd like to present the Service Catalogue in spreadsheet format with addendum text descriptions for each service. The spreadsheet includes a list of generic services. It is also a very useful worksheet when compiling a list of services for any format of catalogue. The catalogue should see IT from outside, as a black box. Technology on its own is not a service. it is a thing. the services we provide are (a) to host and nurture that technology on behalf of the organisation, or (b) to steward the underlying corporate data (in which case the technology is just a tool we use) or (c) to facilitate organisational activities which use the technology and data. Which one depends on your organisation's role for IT as a service provider. Note that
The "service-to-customer relationship" is the SLA. This can be one or many at either end of the link depending on your business model: one SLA per customer-service pair; one SLA per customer for many services; one SLA per service for many customers; or other variants.
I know these documents are a bit raw - you get what you pay for - and I'm sure they will stimulate plenty of debate and criticism, but at least I'm putting my IP out there without hiding it behind subscription fees. These samples have not been updated to ITIL V3 compliance (I'm allowed to use the "compliance" word now that OGC say ITIL is a standard). I'm expecting there will be little diffference. If you ask me nicely I will do it. I looked at using Google Docs to host these but I've used too many useful features of MS-Office (hurry UP Google!!). The Service Catalogue Community used to provide a lot of this stuff online but they seem to have retreated into the gated community of LinkedIn which won't suit everyone, so I posted these here. Let's have some links to other good online Service Catalogue resouces... |
READ the comments below: more important information there
More about catalogue here
If you found this post useful, and you are a Facebook user, Please Like the IT Skeptic on facebook
You might also like Introduction To Real ITSM
Made in New Zealand 
Comments
iso 20000 policy statemet
hi all
I'm IT management student, I've been interested in iso 20000 and reading about it.
i need some examples for ITSM policy statement
is there anyone help me and give some sample of iso 20000 policy statement?
thanks
ITIL Service Catalogue
Hello, I am a fresh graduate who has started working for a large company and has been tasked to implement a service catalogue for one of their departments. So far, very good. It is definitely needed here and I have a lot of support from management. The problem is, I really want to do this right. Are there any ITIL compliant books you can recommend me to purchase so I really know what I am talking about.
Thanks heaps for all the resources you have provided.
Service catalogue books
If you really want to know what you are talking about I recommend experience. If you don't have it, buy some. Get a reputable consultant with a genuine track record. Check references: are their clients still getting value from their service catalogue?
Writing a catalogue is easy. Buying an expensive tool and implementing it is just as easy. Getting the customers and providers to agree on what the services actually are so that you can populate it is harder. Putting systems and ownership in place so the catalogue remains accurate and widely used is even harder still.
You don't get that from a book, sorry.
if you just want to bluff long enough to move on to another project then my preferred book is Defining IT Success Through The Service Catalog: A Practical Guide, Second Edition
Forget the ITIL books, they don't say enough about catalogue. And I don't like Randy Steinberg's book Servicing ITIL - it is too geeky and treats technical systems as services. (Review coming one of these days). The Van Haren Best Practice book The Service Catalog
is a better book but is still makes the same distinctions between business services and IT services and is a bit theoretical for me. (Another review coming one of these days). It still has good content - you might consider it as a second book.
P.S. ITIL spells "catalogue" as intended by God and Queen - I wish everyone would standardise. We spelled it first, America.
ITIL, NIST, PMI, DOD, and UDDI
Skep - Thanks for a great post!
I've been scarfing all I can on ITIL - what a great thing finally to be doing! From a service delivery / management view, ITIL has a well thought out and robust model. As part of MSIA work, I've been doing quite a bit of reading between NIST (FIPS 199/200, SP 800-53, 800-39, 800-60, 800-53a and friends) and DOD pubs (5000.2, 8570, 4245.7M, Risk Management Guide, 5200.1M) and it's interesting to relate them to ITIL service management. The key always comes back to risk management, that's true in ITIL as in PMI approach. (Interesting: both PMBOK and ITIL define risk as positive and negative; DoD / NIST use a negative connotation only.) I'm hoping to be V3 Foundations certified within a few weeks; in going through the ITIL literature it's like meeting old friends but with slightly different names.
Enjoyed the post; reading through Service Design I was intrigued by the multi-level (hierarchical) Service Catalog aspect, especially since it ties so closely to NIST concept of enterprise, hybrid, and system-specific controls. I wanted to find out who had implemented a UDDI using ITIL guidelines so I could get tips on service discovery. I'm thinking that my next SOA is going to look a lot more ITIL-ish.
For those that care, check out the Army Data Services Layer at http://data.army.mil/ADSL.html. It has a lot of good information on service management / governance that ties into ITIL and some downloadable toolkits (Java and C#). I can even claim a tiny bit of credit for it (I was part of the overall Army SOA Foundation back a few years ago and worked with the Data Services group closely standing up proofs-of-concept).
Back to reading...
UDDI
Thanks Andy, interesting remarks, esp the view of risk. One thing though: perhaps I'm missing something but it always seems to me that the only things SOA and Service Catalogue have in common is that they have the word "service" in their names. An application programmer's callable service has little to do with a business service. As i understand it the relationship is many-to-many. SOA services are ITIL configuration items. So you wouldn't define catalogue-able services in a UDDI.
SOA and service catalog
SOA and service catalog (sorry, I'm too lazy to use anything but the American spelling)... this may be a topic worth exploring a little further. I've been uncomfortable with the relationship between SOA services and (I guess we'll call them) ITIL services too, but my current thinking is that the differences are mainly in granularity, audience, and intent. I want to say that these are either two sides of the same coin, or nearly identical approaches to he same problem in two different contexts.
SOA is an architectural concept, so the focus is on how to decompose, build, and assemble system level services in the most efficient and flexible way to allow re-usability. At it's best, it's tightly tied to Business Process management practices and provides traceability between SOA elements and specific business processes or process steps. There's no question that a lot of value can be driven from this, but I don't know that the audience for this work extends beyond hard-core process folks and IT architects and developers who build stuff. Users only encounter the results of this work indirectly through UI systems that invoke these services.
That said, there's a section in TOGAF that discusses the difference between "Developer Led" vs "Business Led" SOA that seems to provide a bridge into more traditional ITIL territory:
http://www.opengroup.org/architecture/togaf9-doc/arch/chap22.html#tag_22_03
Like the "business led" SOA described, ITIL is more management focused... there is less of a focus on the mechanics of building services, and more focus on customer and provider management concerns like the cost and quality of services, and how well they are serving their intended purposes. Said another way ITIL services exist more at the level of marketing and relationship management practices--as products, really--and "developer led" SOA services exist more at the level of engineering practices, as functional components, and are more akin to the ITIL Service Request concept. I'm sure I'm generalizing here...
Here's the part that I think gets interesting... If you build a service catalog from the ground up (as Ian would want us to) by starting with requests (orderable services/requestable services/or whatever term you want to use here)... your goal is the same as the goals of SOA: service requests that are reusable in different contexts. They should be able to stand alone as atomic requests ("deploy laptop", "provision LAN ID", "establish e-mail account") or be possible to string together into composite requests ("onboard new employee", which might bundle a dozen on more atomic request together) that handle common patterns of activity. It's still a mater of decomposing and assembling services in a way that the allows for flexibility and reuse. The main difference seems to be that SOA services typically exist in the application or systems realm and don't really concern themselves with services based on human effort (although the Amazon "Mechanical Turk" is kind of an interesting counterpoint here).
However, consider a fully automated service request in a user catalog: if a prototypical service request like "Reset my password" is entirely automated, isn't that automation accomplished behind the scenes via SOA style services? And similarly, isn't a user-facing application that invokes back-end SOA services pretty much just a specialized service catalog that is specific to a single process or domain? I'm probably not articulating this as well I'd like to, but I'd love to hear other's thoughts.
SOA, Service Catalogue, Business Service
Skep, thanks for the response. You are, of course, correct. As I have been enlightened in last night's chapter on Service Design, the Service Catalogue is broken down into Business Service Catalogue (customer view, non-geeky, relationships to business units) and Technical Service Catalogue (geeky, non-customer focused, relationships to other services).
Coming from a SOA background (but not from its Service Offerings and Agreements meaning), I was intrigued by the multi-level hierarchy and immediately thought of UDDI. I can possibly envision using UDDI as an advertising support service (delivered itself using ITIL) for some commercial business services delivered using ITIL (example: providing a new Geospatial Service, UDDI would provide a searchable way for "customers" to find this service and get information on it). Such a view fails on at least two levels. First, as you point out, Business Services are designed for "real" customers to read; not programmers doing a search. Second, UDDI isn't a valid way to advertise services in any case; there are really no public UDDI servers left (see http://uddi.xml.org/public-uddi-registry for the entry I found back in 2007).
In my defense, I think that UDDI could possibly be a reasonable database for storing service information to enable automated cross-referencing and to prevent service duplication or overlap within the portfolio. However, when I wrote the post I was simply excited to think about how to apply ITIL to a concrete programming-oriented use case.
It's quite interesting to see the role of Information Security Management (ISM) within Service Design. The ISM section in the ITIL book I'm reading included the CIA Triad (and even included the Authenticity element, but left out Utility, Possession, and Non-Repudiation) so I thought "Ah, IA!" Being an IA-type, I think of IA as encompassing, well, everything. However, the ITIL book definitely sees the role of IT security as being smaller; for example, Risk Management (RM) is a separate process from ISM while I would consider RM to be an aspect of overall IA. Then again, I probably just don't understand (that would be situation-normal for me in any case).
In deference to your request, I have forced my fingers to type the "ue" and I feel myself growing into a finer person as a result. Cheers!
catalog community still has the templates, Skep
Hey Skep,
The templates, samples, discussions are all still available
through my blog at http://www.servicecatalogs.com
or
directly to the LinkedIn group at:
http://www.linkedin.com/groups?home=&gid=134909&trk=anet_ug_hm
We had to move from the old site when my SAAS provider got bought by Google who then ... pretty much canceled the service. So it was a bit of a forced migration, really.
Yet, the new community is doing really great with good discussions and no trolling. It turns out that real identities are important for professional discussions - new learning for me. And having a bit of control over who joins helps a lot to reduce spam and trolls. It's a professional community, so if you sign in as "kissmebooty" --- you are not getting in.
LinkedIn doesn't yet have good document sharing and other stuff but it's serviceable. And yes, it's not everyone's cup of tea
I'm glad to see you adding to the knowledgesphere. Feel free to add to the news section there. It's totally relevant and welcome.