The Thee Natures & Customers of the IT Service Catalog

Three Natures of the Service Catalog:

  1. Constitutive: First and foremost the service catalog is constitutive, in that it defines what IT does and does not do, and on what terms. As the constitution of a country lays down the guiding principles of how the society will operate the Service Catalog clearly articulates for both IT and its customers the guiding principles as well as the details of what, how and to who services are delivered.
    By its constitutive nature the Service Catalog is used as a starting point in support of open discussion and dialog on how IT can support the needs of its business customers.

  2. Actionable: In order for the Service Catalog to be of use on an ongoing basis to the customer community it must do more than provide a platform for publishing information about IT Services. Research shows that unless the IT Service Catalog enables and automates the IT request and order fulfillment processes the chances of its ongoing adoption as a useful and meaningful tool is less then 4%. In short the service catalog is best understood as an online tool for browsing and ordering IT Services.

  3. Governing: Service Catalog documents the details of how and when IT services are delivered based on business requirements established by Service Level Management. By the nature of these documented service attributes the Service Catalog provides a governing function that ensures IT services are designed, delivered and audited against the key terms, conditions and controls that are agreed upon. e.g. entitlement, support, authorization, control, costing and charging


  4.  

Just as there are three natures of the service catalog it is also important to understand that it is a tool used by three separate roles, each with a separate objective and perhaps view of the data presented in the catalog. Three Customers of The Service Catalog

  1. Business Customer: For the business customer the Service Catalog represents a tool to assist with annual planning and budgeting activities. Information is presented to this role at a level that supports the estimation of how IT services are used as it relates to a business customer's subscription to a collection of service offerings. This bundling of service offerings into a portfolio view provides a clear understanding of the planned IT spend.

  2. End User: Based on agreements made at the Business Customer level of the catalog, the user is presented with a set of day to day transactional IT services that support ongoing business operations. The information that is presented out of the catalog for the user is filtered based on established agreements and role based entitlements. For the user the service catalog is a shopping cart and a key entry point to the organizations Request Management Processes.

  3. Service Level Manager: From an IT perspective The Service Catalog is also a tool to clearly document the detailed technical attributes of service delivery such as Availability, Security, IT Service Continuity, etc.. It is this detailed information that is used for governing the delivery of IT services and is a primary source of information of how services are delivered. The Service Level Manager working with a customer contact and an IT service owner agree upon the levels of services documented in the catalog and how they are referenced in the customer facing service level agreements as well as the IT facing operational level agreements and underpinning contracts.

  4. In summary to fully comprehend the importance and scope of a Service Catalog it is important to understand its three natures and three key customer groups. Additional blog posts on the Service Catalog:  (Service Level Management) Service Owner — The Missing ITSM Role Troy's thoughts what are yours? “To give real service you must add something which cannot be bought or measured with money, and that is sincerity and integrity.” ~Douglas Adams

Like this article? Like

View Comments (8)

Comments

“Research shows that unless the IT Service Catalog enables and automates the IT request and order fulfillment processes the chances of its ongoing adoption as a useful and meaningful tool is less then 4%.”  Chokey the Chimp wants to know what research?

Adoption by who and “useful and meaningful” to who?  To the business customer?  To the Service Level Manager?  they need automation?  Many service catalogues are implemented to serve other than the end user, at least in early phases.  Automation is - as -usual - an add-on nice to have.  A service desk can process provisioning requests quite adequately.  if a tool makes them lower cost and/or more efficient then great, but it is not essential.  Only the vendors think so.

The IT Skeptic | December 18, 2009 at 8:31pm

Ok Skep

You have a point and after reading the Halo Effect I too wonder about much of the so called research.

To answer your questions fairly. The research I am referring to is 2nd hand from our friend Rodrigo at NewScale so i will have to defer to him on that one.

As to adoption I have my own experience to hang on as well. What I / we have observed is that when an IT group puts up a fancy web page describing all the great things they offer and expect the world to come and read their marketing materials they are sadly disappointed.

In reality the customer (Business, user , IT) does not care about the Service Catalog unless they can browse and order by placing things into their digital shopping cart and then monitor the progress of their request.)

So if you want to make an investment in a Service Catalog and have it actually be looked at and used then make sure it supports an online shopping experience.

Troy

Troy DuMoulin, VP Research & Development | December 18, 2009 at 9:13pm

We might be talking about different types of customers.  Most of my experience is with in-house IT departments, not commodity service providers. 

Ordering is not the priority for (business) customers; negotiating and monitoring the service levels is.  Business relationship managers meet with the customers regularly.  The most useful tool for BRMs is an nice brochure, a customer-facing document.

Users might like an online ordering system but they are not paying for it.  As I said above, by all means put one in if TCO is cheaper than the service desk doing it.  I haven’t heard of digital shopping carts being widespread in the industry: most I have heard of are at best online forms or emails.  Sounds like bells and whistles to me smile

Within IT, WTF do they need with digital shopping carts?  They want some way to look up configuration information for service impact but that’s not the same thing.

The IT Skeptic | December 18, 2009 at 9:47pm

Hello Skep

When you consider a Government Website where you can fill out a form to get your address changes across multiple agencies. Or an IT portal where you get you can get a password reset or hit a button that open’s an email form to request consulting support for an application enhancement.

Whether you are ordering up a new laptop and filling out a form for on-boarding a new employee which quicks off a series or sequential and parallel tasks.

All of these actions are what I am referring to as a digital shopping cart. I was not necessarily being literal.

The key message is that your online Service Catalog has to be more than static text. It has to be a place where you interact with an IT Service Organization.

Troy

Troy DuMoulin, VP Research & Development | December 20, 2009 at 9:29pm

“The key message is that your online Service Catalog has to be more than
static text. It has to be a place where you interact with an IT Service
Organization.”  I challenge “has to be”.  No it doesn’t. 

For the customer and internal IT contexts anything more than static text is irrelevant.

For the user context, it is useful only if the cost of implementing and maintaining it is less than the cost of the service desk taking request calls.  True in some orgs, not in others.

Rob England (IT Skeptic) | December 20, 2009 at 10:42pm

Hello Rob

This may be another area we will have to agree to disagree. In the IT Context you will rarely get an application service owner calling a service desk for a service request, and when you get to the Business Customer they are more interested in seeing the financial information about the services they are currently subscribed to (although admittedly there are very few organizations that could provide this today.)

My believe is that if your Service Catalog is simply a web brochure of all the good things IT does for the money it receives every year as part of the budget process they would be better off investing in a glossy tri-fold handout than investing in the web infrastructures and resources to put up a service catalog.

Troy

Troy DuMoulin, VP Research & Development | December 21, 2009 at 9:45am

I’m becoming skeptical of the IT Skeptic.

It is evident why ‘actionable’ items are required as part of the service catalog; many units of work that occur between users and support, I.T. and support, etc cannot be classified as one of the major types of items.  In addition, many of these units of work should bypass the helpdesk completely and be routed automatically to the person who is to perform the unit of work.

indio | February 17, 2012 at 3:08pm

Wow this thread came back from the grave smile

A service catalogue is a virtual thing.  Whether it is implemented as a spreadsheet, a trifold glossy, a webpage, or an expensive piece of request automation, its a service catalogue.  Whether it lists nothing but the high level service definitions or all the detail of the configuration, or all the actionable requests per service, it is a service catalogue.

If it is just a list of requests without associating them with a service, I think I dispute that it is a service catalogue.  ITIL went to a lot of trouble to define what a service is and what a request is.  Let’s not confuse them.

There is a maturity model of catalogue starting with a simple text list and ending with whizzy automated workflows for the associated requests, and all levels of solution between.  We should stat with the simplest case: define what we do.  The rest comes later as we manage to build a business case for the higher levels of sophistication… until we can’t.

the it skeptic | February 18, 2012 at 5:23pm

Post a comment