Service Catalogs ~ Actionable Vs. Static

By Andrew Kramer, PMG

There’s no doubt about it: the release of ITIL version 3 will create more debate, more vendor hyperbole, consulting feeding frenzies, and countless bytes of text. This paper addresses a key confusion point about Service Catalog, and why it might be the most important ITIL concept you should consider and implement. My esteemed colleague Boris Pevzner, CEO at Lontra, a Service Catalog vendor, recently wrote on his blog (http://blog.lontra.com/):

One of the main focal points of ITIL v3 is the Service Lifecycle – how services are conceptualized, defined, modeled, offered, accounted for, delivered, supported, and improved – and the Service Portfolio is the central management tool and “system of record” for the Service Lifecycle. As Troy DuMoulin of Pink Elephant mentions in his blog (http://blogs.pinkelephant.com/troy), this brings ITIL to the perspective of the CIO and executive management team and “is focused on the realization that IT Management is accountable for knowing how any given component or device supports a service which impacts or enables a business process and outcome.”

For this very reason, ITIL v3 positions the Service Portfolio as the cornerstone of IT Service Management and recommends it as the starting point for every ITIL implementation. ITIL v3 books on Service Strategy, Service Design and Continual Service Improvement lay out the best practices for building an effective Service Portfolio and its published orderable subset, the Service Catalog.

So what is an actionable service catalog versus a static one? Let us first start with a static catalog, as it is very likely the necessary first step before you can evolve to an actionable service catalog. It may be an evolution, but it need not be painful nor excessively time consuming. I have spent the past six months talking to enterprise practitioners (and admittedly vendors and consultants) and learned a lot about how they implemented their Service Catalog. It is interesting to note that most of them did not make a distinction between actionable and “static” and I think most would likely object to the term “static” altogether.

By “static” we mean a Service Catalog that simply provides detailed explanations of services, preferably in terms your business users can easily understand. Generally speaking, users are unconcerned about “configuration items,” “dependencies,” the configuration management database (CMDB), and the distinction between an incident, problem, or change. These terms are for IT providers and should be avoided when authoring your service catalog. The practitioners I spoke to all agreed that the information gathering and writing of the services was the hard and time consuming part. Agreeing on templates, the details that should be included within each service description, and the appropriate lexicon to be used also contributed to the effort.

The approach taken typically included interviews with “service owners” and the users. Once descriptions are taken from each, a reconciliation and editing process ensued to remove overly technical jargon and ensure readily understandable business descriptions of the service. The key headings for each service include (by no means a definitive list):

• Name of the service,
• Description,
• Operating hours,
• Service owner and contact info,
• Costs (fixed or recurring),
• Applicable SLAs or metrics,
• Service eligibility,
• Ordering information,
• How to request help

Clearly, this is an information gathering, data normalization, writing, editing, and publication exercise. This effort is typically, easily, and most commonly tackled using standard office applications like Microsoft Word and Excel.

Once you have assembled, written, and published this series of documents, this becomes a classic Static Service Catalog. Of course, the Service Catalog and individual service owners should and would maintain the documents and keep them up to date, thereby contradicting the term “static.” So why then, do we describe this as a Static Service Catalog. There are two key shortcomings and each has typical and common solutions. The following table illustrates these:

The good news is that the shortcomings and possible solutions are usually readily available and typically require no new hardware or software. A significant percentage of enterprises have existing intranet/extranets in place and leverage tools like Microsoft SharePoint. This said, this does not mean you will overcome the shortcomings for free and without incurring additional costs and risks. You may, after a long and arduous effort, deliver a project that will fail to deliver the ultimate goals of the Service Catalog in the first place:

• Better business alignment,
• Improved customer service,
• Improved performance, and
• Reduced costs.

Each of the possible solutions will require significant labor to accomplish. Even if that labor is considered free and available, the key question is: will the resulting catalog be usable and willingly adopted by the user base?

To illustrate, I will provide a couple of examples of what I am calling a Static Service Catalog. Please note that I point you to the following websites, without their permission. I mean neither harm nor criticism of these catalogs, merely that they are excellent examples of good catalogs and certainly better than the alternative of not having one.

To be sure, this Static Service Catalog is clean, well organized, and easy to navigate. It is online, searchable and provides relevant categories and service titles in easy to understand terminology. Once you begin to drill down into the links, however, you soon find where a Static Service Catalog’s journey ends. If you want to take action, you are provided links to forms (such as PDFs), or links to other web applications, or to email addresses and telephone numbers. This is a very crucial demarcation of where a Static Service Catalog ends and an Actionable Service Catalog can begin.

1. The Static Service Catalog provides little or no improvement to ordering, demand management, and fulfillment processes. In some cases, the fulfillment of a request is not a consideration at all. There is no connection between the Static Service Catalog and the back end service providers, either systems or people.
2. It leaves in place much, if not all, existing systems and interfaces that users may already dislike and avoid. Users are still faced with myriads of disparate forms, telephone numbers, email addresses and links to disparate web interfaces.
3. It generally provides no monitoring, metrics, or measurement capabilities for service level management and the ultimate goal of continuous process improvement.

An Improved Approach to a Static Service Catalog

If you are satisfied with the benefits of what we have described as a Static Service Catalog, there may still be a better way to achieve one. As we have said, users have unanimously reported that the long work is the document creation, collaboration, editing and publishing of the catalog. This effort specifically maps to the functionality and automation provided by document management and collaboration solutions. So, before you embark on a Static Service Catalog with mere Word or Excel as your primary weapon, I recommend seeing if you have access to document management applications or other collaboration tools. These can dramatically reduce the work required to achieve your service catalog.

I would be remiss if I didn’t mention that PMG provides an inexpensive, simple tool for a Static Service Catalog as well: PMG iComply software. Though originally designed for the creation, version control, distribution, compliance, and reporting for policies and procedures, the capabilities map quite perfectly to the creation of a Static Service Catalog.

As you can see, you can easily achieve an online, searchable Static Service Catalog, with well formatted tab-based descriptions. Using this tool, however, enables you to manage and update the catalog with full version control and permission-based content management. These features may make it worth the investment to use this approach rather than a document-only based approach.

The Actionable Service Catalog

An Actionable Service Catalog, in contrast, assumes interaction with the user by default. It transcends the basic concept of communication and explanation of services to include the ordering of those services all the way through automated fulfillment and delivery. User self-service with real-time status information should also be provided, a concept simply not possible in a Static model.

Self-Service begins with transitioning all requests to the web. Though the benefits of doing this seem obvious, the task of getting them there has always been somewhat daunting. It is common knowledge that telephone support is the most expensive means to provide service, yet call volumes continue to grow. Email support is not much better, often creating non-trackable frustrating exchanges with users. Users like the instant nature of online chat, but IT staff struggle to provide this in a cost-effective manner. A best-practice is to provide the most suitable communication method for the type of support required. While static web pages may be perfectly suited for communicating information, preventing a definitive number of inbound information request calls, email may be very ill-suited to accept a complex order that requires specific ordering information to be routed to multiple people and systems.

Many attempts at web-based customer self-service have yielded less-than-desirable results. Why is this? Before we answer that, ask yourself this question: Have you ever needed to call Amazon.com to order something? The key reason that web-based self-service projects fail is user resistance due to complicated, difficult to use web interfaces or the use of inappropriate communication methods for the specific user need. Fortunately, e-commerce giants like Amazon have spent millions to solve this problem and have made the online shopping experience easy, enjoyable, and ubiquitous. Leveraging this experience for any type of service request is simply a new use of proven technology and methodology.

From an Amazon-com-like online catalog web interface, any user can easily browse, search, find, learn about, and ultimately order or request anything. It can be a service provided by multiple people, such as “Onboard New Employee” or ordering simple items like “New BlackBerry Device.” One online catalog, same familiar shopping experience, for any request for any employee in any department. Easy to use, easily customized ordering forms should be deployed in minutes, requiring near-zero technical knowledge.

Once captured, requests should be fed to a fulfillment engine. For many, the fulfillment engine is the tried and true Service Desk application. And why not? Service Desks are well-suited to distribute tasks to individuals and workgroups, and even provide for some level of routing and workflow.

For others, order and request fulfillment is a workflow. Just like ITIL processes such as Change, Incident, Problem, and configuration, any delivery workflow should be well documented, controlled, measured and enforced. But unlike ITIL processes, request workflows may traverse multiple department boundaries and systems. To address this wider audience, modern Actionable Service Catalogs embrace the powers of Business Process Management (BPM) and Enterprise Application Integration (EAI) to transcend the IT-based delivery of service to include the fulfillment of service requests to include any and all providers.

In sum, the modern Actionable Service Catalog should combine the best features from e-Commerce, business process management (BPM), web-based portal, search, and enterprise application integration (EAI) in a dramatically easy to use, easy to deploy solution that all users will use and enjoy. Imagine trying to install and integrate these components in a custom application development effort and you can easily see why enterprises may shy away from an ambitious Actionable Service Catalog. But what if this capability is affordable, simple, and actually less expensive than Static Service Catalog Approach?

Whether you decide to start with a Static Service Catalog and evolve to an Actionable one, it is important to note that the commercially available solutions allow you to start statically and evolve into actionable with full automation.

We welcome your comments on this whitepaper. Please email the author with any comments and questions:

Andrew Kramer
akramer@pmg.net