6 steps to building a highly engaging IT service catalog

Service as a Service: IT service catalogs are services in themselves that business customers appreciate.
Written by Joe McKendrick, Contributing Writer

What's a service catalog? Is it iTunes for the enterprise? Is it an online directory? Is it a resource for developers? Is it one of the stipulations of ITIL/IT service management best practices? It's actually all of the above -- and building and making one available will greatly enhance IT's relationship with the business.

That's the word from Sharon Taylor, former chief architect for ITIL and president of the Aspect Group. In an informative white paper just published on the subject, Taylor states that a service catalog, a critical part of IT service management, serves as "the means by which we, as IT service providers, articulate what we can do for our business customers. It seems a simple enough concept yet so many of us get it wrong over and over again."

Taylor points out that there are three types of service catalogs: the business service catalog, which is tied to specific business lines; the user request catalog, which is a self-service venue; and the technical services catalog, which addresses service level agreements, configuration information, and security and access information.

There are several steps that need to be taken to developing a well-functioning IT service catalog, Taylor explains:

Get feedback from business users. This is the first step -- find out exactly what kinds of services or apps the business wants. "Understand how your customers use the service," Taylor writes. "Too often, IT specialists believe they have all the answers only to find out they did, but not to the right questions!"

Agree on the definition of a "service." IT pros have been working with "services" for years, and understand how they relate to systems and infrastructure. However, business users may have different concepts -- to them, Google may be a "service." Taylor urges putting forth plain, straightforward definitions that can set the standard going forward. No discussions of REST versus SOAP. Instead, something like a "purchase order system" or "zip code directory" may suffice.

List the existing services you have. What's already out there? This is a perfect and easy way to start building the service catalog, Taylor observes. In addition, she advises not to go overboard in the first release of the catalog -- stick to just a few key processes.

List the dependencies of each service. Such dependencies may include third party suppliers, service levels, IT components, and processes, Taylor states.

Decide usage parameters. Who will have access? Who can authorize and make changes?

Understand requirements before investing in automation tools. Let things shape up before deciding how to automate processes. This will encourage innovative thinking as adoption of the catalog progresses, Taylor states.

Editorial standards