From Cookies to Castles

About 10 years ago I had a Neiman Marcus credit card.  I eventually cancelled my card because I wasn't shopping there as much as I used to.  The thing I miss the most about my almost five year relationship with Neiman's is the annual Christmas catalog.  If you've never seen the Neiman Marcus Christmas Catalog, you've missed something quite spectacular!  On those pages, you can find almost anything your heart desires from denim to diamonds and from cookies to castles. The annual unveiling is truly an event.

Every year, someone (or a group of people I suspect) get together and decide what items to offer in the catalog.  I've always wondered how they decide what makes it into the catalog and what doesn't.

I bring up Neiman's catalog because lately there seems to be a lot of buzz around another type of catalog - the Service Catalog.  I frequently run into IT folks asking a lot of good questions about it.  Do I need one?  What exactly is it?  How will it help?  Can I get Fries with it?

Origins of the Service Catalog

I once heard a CIO say, "My job is to convert cash to value".  I love that phrase because it really does capture what should be the service-oriented nature of IT.  An IT professional's job is to provide a service that adds value to the business in exchange for funds.  The challenge that many IT organizations face, however, is how to best communicate that value to the business.

The simplest approach is to write it down.  Come up with a list of the services that IT provides and share that with the business.  Thus the Service Catalog was born.  In its earliest incarnations, the Service Catalog was simply a list of what IT did for the business that the business valued.  If the CEO ever confronted the CIO with "what have you done for me lately?" the CIO could produce the service catalog to demonstrate his/her value.  The service catalog was aptly named because it was intended to be a catalog of the "services" that IT provided and not just products.  For example, a laptop is a product.  However, providing that same laptop to a new employee within one day of their start date could be considered a service - more on this later.

As time went on, many CIOs - pressured by the need to be more cost effective  - were faced with the need to not only passively meet demand for service, but rather to try and shape the very demand for those services.  One way to do this was to charge for the service.  According to ITIL, one reason to implement a chargeback system is to influence customer behavior.  If the business now has to pay for service, they will most likely start to think about how they consume it.  To facilitate this process, cost information (as well as what would be delivered for that cost) was added to the service catalog.

Now, IT could use the service catalog to not only communicate the things it did for the business but also to communicate how much it would charge to do those things.  The business, in turn, could use the catalog to decide whether or not to acquire that service.

It Depends!

At this point, many IT organizations start asking the question, "what should I put in my service catalog?"  Before we answer that question, let's take a quick look at the definition of a service.  Consider the following definitions:

From the Oxford English Dictionary:
"...work done for; benefit conferred on another; maintenance and repair work; provision or supply of what is necessary (e.g. supply of gas, water etc). Yes there are goods involved, but one is not ordering or purchasing the good, one is ordering or purchasing the service, which may incorporate the good in some way"

From the ITIL v3 Glossary:
Providing something of value to a customer that is not goods (i.e. physical things with material value).

From Wikipedia:
A process that creates benefits by facilitating a change in customers, a change in their physical possessions, or a change in their intangible assets.

I think most people would agree that the common thread here is that a service is something done by someone for someone else that is valued by the receiving party.  It's really that simple so let's leave it there!  Translating that to IT terms, a service is something IT does that the business values.  Once again, let's keep it that simple.

So now, let's go back to the question of what to put in the service catalog.  If I want to use my service catalog to communicate with the business, then I'm going to include the key things that I do for the business that they value.  These "key things" are commonly referred to as "business services".  Thus I could include services in my catalog such as:

* Sales Force Automation Service
* Patient Care Service
* Order Entry Service

For each of these services, I would add cost and corresponding service level information to the catalog to aid the business in their decision on whether to acquire the services.  Thus, the Sales Force Automation service may cost the Sales Department $1,000 per user per year for "Platinum Level" service, $750 for "Gold" service and "$500" for "Silver" service.  The sales department could then manage its expenditure by figuring out which sales reps needed which level of service.

Beware the Duck!

At this point, I've cataloged my services to communicate value as well as the costs and corresponding service levels.  That's a great start.  But what happens when the number of "key things" (i.e. business services) that I can provide is being impacted by all of the "minor" things my staff is doing.  I once heard this referred to as "getting pecked to death by ducks".  One ornery duck might be considered a nuisance.  Enough of them, however, can be lethal!

In the same way, a small number of "minor" requests for service may not impact the overall business service delivery capability.  Enough of them, however, most assuredly will.  Accordingly, IT must shape and manage the demand for these "minor" services as well as fulfill them in a more cost effective manner.

One way of doing that is to use the service catalog to also document the "minor" things that IT can do for the business.  Some people refer to these as "supporting" services.  Others call them "requestable" services.  Examples of these types of services include:

* Setting up email distribution lists
* Resetting passwords
* Provisioning laptops

Regardless of the qualifying term used, however, the key point here is that these are all services just as Sales Force Automation is a service.  Clearly, they are different in terms of scale, scope, delivery method, etc. but the fact is that they are all services offered by IT and thus should all be listed in the service catalog.

Enter BMC Service Request Management (SRM)

In practice, however, you would potentially want to present different "views" of the catalog to different audiences.  The business customer (i.e. the person writing the check) is probably most interested in the business service view of the catalog.  On the other hand, the end users in the business are focused on the "supporting" or "reqeustable" services in the catalog.  As I pointed out earlier, if not properly managed, these are the things that can overwhelm an IT organization and impact its ability to deliver the business services at the required service levels.

To address this issue, BMC is introducing the BMC Service Request Management (SRM) solution.  This solution allows IT organizations to catalog all of their "requestable" services and then automate much of the submission, tracking and fulfillment of end-user's requests for those services.  To the extent that routine requests can be handled in an automated fashion, IT support personnel are freed up to focus on the provision and operation of the more strategic business services.

How much is that Castle in the Window?

In the end - just like Neiman-Marcus - IT organizations need a place to capture and publish all of the "things" they provide to their customers regardless of scale (e.g. the $3.8M membership to The Club At Castiglion Del Bosco in Italy vs. the $50 tin of cookies - both found in the N-M catalog).  The service catalog is that place.  SRM represents a first step in the development and leveraging of the service catalog that IT organizations need.  Stay tuned as the story unfolds!  Anyone want to go in on the castle?!