Service catalogue and service request catalogue

Both service catalogue and service request catalogue matter - the order in which you address them and the relative priority you give them depends on the circumstances. Don't fall for the hype around service request catalogue right now. Click to tweet this.

First some terminology:

A service catalogue (SC) defines what your services are. It can be as simple or complex as business requirements dictate. A piece of paper with a list of the names of your services is a service catalogue.

A service request catalogue (SRC) lists what requests can be made against your services (I identify thirteen types including incidents). It can be as simple or complex as business requirements dictate. In the simplest case this can be a drop-down box of request types on a service desk tool, or a list of request types on a piece of paper. The simplest request types are to provision or de-provision a service to a user or group of users. Ideally, request can be thought of as the user front-end to changes. there will be standard (routine) requests that link to standard changes or work orders that don't need to go through change control; and unfamiliar requests that lead to non-standard (normal) changes. See Standard+Case.

For every service there is a one-to-many relationship to the associated requests for that service.

You can have requests without knowing what your services are - many organisations do. Just as you can have requests without even knowing what your requests are. That happens often enough too - all requests are handled ad-hoc. But with increasing sophistication all organisations will need both a list of services (SC) and a list of requests (SRC) at some point - more of this below.

I wish IT people would stop leaping to technology solutions for these artifacts. Sure SC and SRC can be deployed on expensive tools. Sure they can be "actionable". Sure the workflow can be automated. Show me the business case in each instance. Automation is sometimes a good idea. Other times automation is tech people getting their rocks off on complex technology or misanthropically delighting in driving people out of process. Click to tweet this The appropriateness of SC and SRC solutions for each organisation exist on a spectrum from paper to iPad apps.

Recently it was implied in a twitter debate that I was guilty of "old" ITSM thinking for working on a service catalogue for a client instead of a request catalogue. I think the real old thinking is thinking which dismisses the catalogue as something peripheral, marginalising it as an after thought. ITIL has always done this, even in ITIL 2011.

Service catalogue is the centre of the IT world:

SC is central, fundamental, a mission statement for a service provider. A definition of your services provides the root taxonomy for everything. For example:

• If you need to improve IT's service reporting, you need to start by defining the services to report against, to get that external customer perspective.
• If you are implementing synthetic transactions to monitor service availability from the desktop (the only true measure of online availability), then you will want to know the online services to test (and report) against.
• When you report availability, your customers may want to know availability of requests("was I able to order a desktop MAC"?), but more likely they want to know when the financial information service was or wasn't available.
• Service desk responsiveness will likely be reported against each request type, although in some cases the customer may just want the report consolidated for the overall service
• When you do service portfolio management, you balance your priorities, plans and resources across your proposed and existing services. That's pretty hard if you don't know what those services are.
• Doing availability, capacity or continuity planning is also hard without a list of your services.
• and of course impact assessment for incident, problem or change becomes meaningless without a list of services to assess the impact against.
• ... and so on. Just about every practice in IT benefits from the naming of services and most practices depend on it.

SC has massive value internally, which has knock on value to the customer by improving service. SC is also an essential external tool for intelligent informed conversation with senior customers. Before you can get to the Big Table and engage with customers, you better know what you do.

Statements were made in the recent twitter debate such as "If you build a request catalogue you may never need a service catalogue" and "Service catalogue delivers no value " Bollocks.

I view the Cult of the Customer as a fad (ask Ryan Air or Microsoft where customer service rates in their priorities), along with actionable catalogue as the associated fad technology, now that CMDB has been shown to be a vendor scam. 5% of sites need a full automated CMDB. A similarly small minority of sites need a fully automated actionable request catalogue.

The whole point of ITSM is to get IT to think service-oriented, customer-centric, outside-in. That doesn't mean that

• the customer is always our first priority
• customers get whatever they want at any cost
• customer service should always be improved to infinite levels
• improving customer service is automatically profitable, automatically has a ROI in all cases
• there is nothing we should be doing internally to manage and improve our own affairs

The Cult of the Customer forgets that the customer is only one end of the value chain, not every link. Click to tweet this. They provide the anchor for that chain and the reason for its existence. To say we should only work on the last link of the chain is absurd.

Certainly when customers think "service catalogue" they are often actually thinking request catalogue. But not always. For example a current client of mine is undergoing an organisational service management transformation driven by an international consulting firm. As part of that the IT business unit needs to define its own services in terms of the organisational services provided to their external customers.

Even if customers are thinking request catalogue, that doesn't mean we should start with SRC. Sure, request catalogue is not "just another view of service catalogue", it is a fundamental extension. And it is often what customers have in mind when they say "service catalogue". And request catalogue delivers high value to a customer. I'm all for SRC.

But it is throwing the baby out with the bathwater to heap contempt on service catalogue, to assume we don't start there or - worse still - we may never have one. A service provider without a SC is rudderless. You can sail a boat without a rudder, it's just harder and less efficient. Click to tweet this. Many organisations stumble on without SC or SRC. With increasing sophistication they will need both at some point. Start with understanding business value and risk, then prioritise the corresponding outcomes, then decide what you need to fulfill. Either SC or SRC or both could be part of resulting solution design. Both SC and SRC have their place. Exactly what that place is differs from site to site depending on the business outcomes they require. To say SC has no value is nonsense unless you know what the client's needs are right now. Same with SRC.

I think this anti-service-catalogue thinking stems from the same source as anti-ITIL: bad implementations. The geeks plunge straight into building a "complete" data model for a service catalogue and populating the data, including service levels, SLAS, requests, costs, owners, impact, DR, and of course configuration decomposition. It ends in expesnive tears. That doesn't mean the concept of SC is flawed, just - often - the execution, because the implementation fails to focus on the outcomes to be supported by the SC, fails to KISS. Using these bad experiences of catalogue (or ITIL) is like using Iraq as an example of why we shouldn't have governments. Click to tweet this

I spent a lot of time on this post that I'd prefer to have spent elsewhere. I find it amazing we need to even have this debate, but that's ITSM. It is an immature discipline, rife with fads and factions, vested interests and personal agendas. Novelty is valued over sanity, and the answer to everything is a thing. Signs of maturity are emerging. I can't wait until information and service are recognised branches of engineering just like civil, mechanical and electrical. Not holding my breath.

In the meantime I hope we can build a body of common-sense knowledge over decades without trying to tear it all down every time somebody thinks they are wiser. I'm all for new ideas but preferably as evolution not revolution.

I understand the role and impact of a request catalogue. I just don't agree that SRC is always the place to start or that it is more important than the service definitions. I think if we dismiss service catalogue as having little or no value, that is harmful to the ITSM community and will mislead the many who don't think about this stuff all day long to understand the nuances. Both SC and SRC matter - the order depends on the circumstances.