Home �   ITIL�  Index

Building an IT Service Catalog

Jun 27, 2007

Mike Drapeau

An IT service item, however, is more akin to a specific offering. It is literally what the customer actually orders. For instance, under the IT service category of Telecommunications and the sub-category of Voice, one might find the following IT service items:

  • Set Up Phone
  • Set Up Remote Voice Mail
  • Report Phone Problems
  • Record Conversations
  • Move Phone
  • Connect Land line and Cell Phone
  • The critical distinction between the IT service item and the overall IT service is end users interact and, more importantly, only think of the former. The category labels of the latter are usually too abstract for the user and sometimes they become so confusingly non-descriptive, that users are unable to find the item or service they want to order.

    That is the reason that savvy service catalog implementation teams ensure the labels they derive for each service name are worded in the lingua franca of the user, not in IT-speak.

    Successful Implementations

    Despite the challenge, the stories of successful service catalog deployments are starting to accumulate. Robert Hilsdon, IT Service manager for Rohm and Haas, a Philadelphia-based maker of chemicals, adhesives, and sealants, conceived, managed, and oversaw successful implementation of his company’s IT service catalog.

    Rohm deployed RequestCenter software from Foster City, California-based newScale. Since going live in May of 2006, the catalog has grown to over 220 service items rolled out to 8,000 end users in 35 countries processing more than 200,000 requests over the past year. Each service item is described in plain English from with no IT jargon, and presented to IT customers via a Web browser in an easy-to-use interface.

    It wasn’t always easy going, though. Hilsdon states that initially Rohm tried different approaches to constructing their IT service catalog, including modifying pre-existing IT service document templates, collecting info using a service-specific questionnaire, and assembling IT services from an asset database. Each of these approaches failed.

    So they went back to the existing incident ticketing software to examine all possible routings for the fulfillment of individual service items and used this as the basis of their existing, de-facto service design. From this reservoir of data, they developed service level requirements from a set of rationalized activities.

    In addition to the service items specific to their end users, Rohm and Haas also satisfied the services needs of their own IT organization with 15 more technical IT service items such as "UNIX Build," which describes an end-to-end solution for services requested by IT staff.

    Hilsdon noted that, “these services include high-level containers for bundles of other, even more technical services. For instance, the service item ‘Application Development’ incorporates desktop rollout of a new version to a full-blown deployment of a custom-coded application and all the accompanying data center modifications and changes, which might involve as many as five separate technical services.”

    One key aspect of Rohm's deployment was the integration of the service catalog into the corporate LDAP (lightweight directory access protocol) server. This enables their newScale service catalog to use authentication groups to assigned visibility to ensure that each end user only sees the IT services that they are entitled to. It also provides information about the user (e.g. routing, approvals, geography) that directly impacts the workflow for the requested IT service item.

    Enabling Strategy

    Ron Williams, manager of Data Services, of CompuCredit Corporation in Atlanta knew that he needed to improve IT’s marketability. Williams notes that, “when you try to run IT like a business you need a marketing function to help educate prospects and customers, shape demand, and publicize successes.”