Service Catalogs and Remedy IT Service Management Applications

Theme:  Apps in Action
 

Service Catalogs and Remedy IT Service Management Applications

With more and more companies and organizations adopting the ITIL® Framework as a standard for their Service Management efforts, Service Catalogs have become a hot topic. This article will look at what a Service Catalog is, how it is important, and steps that can be taken to leverage Service Catalogs in the Remedy IT Service Management applications.

 

What is a Service Catalog?

There is a configuration option in the LDAP SDK that allows you to set the timeout used when establishing a connection to a directory service. We have added an option for the AREA LDAP plug-in that allows this timeout to be configured. This option is described below:

As with many items inside the ITIL framework, Service Catalogs seem to have different definitions depending on a number of environmental factors. Before we can implement an effective set of Service Catalogs, we have to understand what this means to the enterprise. Here are some possible definitions, as found in ITIL material and on the Internet:

From the Official ITIL Glossary:

"Written statement of IT services, default levels and options" 1

From the Internet:

"How do we know what services we provide and hence what needs an SLA in place? This is the one of the jobs of the Service Catalogue. The Service Catalogue is often overlooked in its importance. The best way to approach the population of a Service Catalogue is to understand what services the customers perceive. It is not uncommon for a customer to have a single service that is made up from three or four separate applications where at least one of these is invisible to the business.

By asking customers (i.e. SLRs) you can begin to document what goes in to the Service Catalogue, where the complete set of ITIL processes are in use it will be possible to get some of this information from the Service Desk who receive comments directly from customers on the services provided. Any Service Management tools should also be audited as services forgotten about by IT may still be active and have had incidents, problems and changes logged against them. The Configuration Management Database will also outline services, but the key is always to understand the customers perception.

A Service Catalogue can appear in many different formats such as word documents, spreadsheets etc. and ITIL does offer guidance on the sort of information captured in the Service Catalogue, however expanding on this to make a catalogue a worthwhile within an IT Support Organization I personally feel the following items should be considered;

  • Service Name Basic
  • Service Description
  • Key Business Users
  • Importance of Service
  • Key Support areas
  • Planned Maintenance/Outage data
  • SLA (in place and where it is located)

By providing slightly more information it is possible to use this resource within a Service Desk to support the allocation of priority to faults and direct Incidents to the relevant area alongside the Configuration Management Database. This will also aid in the general support Service Desk staff can give to improve Customer satisfaction through system knowledge, understanding Customer usage etc. The Service Catalogue should also facilitate the ability for organizations to 'speak the same language'." 2

So the first question that many people familiar with Remedy's IT Service Management solution ask is: how does Remedy's use of Categorizations differ from a Service Catalog and can Categorizations of tickets be developed to match to Services? The table below will help to answer this question, for although there is a relationship between Categorizations and Service Catalogs, each has a different goal and place within the application:

CategorizationsService Catalogs
IT-focused—could be transparent to the RequesterBusiness-focused—how the customer identifies the issue
Used for detailed reports and OLAs and some SLAsUsed for higher-level reporting to the business and for SLAs
Managed by IT for IT; somewhat fluid based on new technologyManaged by IT and the business; should be fairly static
IT stakeholders will drive the definition of the categorizationsBusiness stakeholders will drive the definition of the Service Catalog

Simply put, a Service Catalog enables end users to see in simple terms the "items" for which they expect to have support from IT.

 

Best Practices in Developing Service Catalogs

Because of their value to the business, Service Catalogs will get a great deal of focus, but how do we develop a Service Catalog and get it implemented?

Since a Service Catalog is most effective when developed jointly between IT and the business, there is a needed cooperation between both groups. Here are some tips to consider:

  • Start with putting together a list of proposed services and estimated response time metrics.
  • Call for a good old-fashioned "sit-down" with business stakeholders (your customers). This is truly the first step in the way the business will view IT Services, and as such, IT has to be prepared for the change:
  • Validate your proposed list of IT Services
  • Confirm the Service Level Agreement contracts
  • Establish how compliance to these contracts will be measured and reported to the business.

Once you complete the process of defining your Service Catalog and validating it with the business, you must "sell and market" your various services to the Enterprise. To do this, you should consider the use of the Web, color brochures, and posters to advertise to the business just what you will deliver to them and what level of service they should expect.

 

Implementation of Service Catalogs in Remedy's IT Service Management Applications

The final step in the effort to implement Service Catalogs is to modify Remedy IT Service Management applications to help you in the tracking and management of your Service Catalog. Since Remedy IT Service Management applications are built on the highly flexible AR System® platform, this effort will be much easier to accomplish and to integrate into processes, such as service level agreements and reporting.

What follows are some concepts around how to build out the needed workflow, leaving the actual workflow objects for you to develop and implement. Note: There are many ways to adapt the application to manage your Service Catalog. Only a few are offered here to help get you started in that direction.

So what do we need at a high level to make Service Catalogs happen?

  • Add a set of forms to identify your Service Catalog items and link the associated Configuration Items (CI) and Category/Type/Items that will map to the overall service. This form should contain some of the following data about each Service:
  • What you will call the service and a description of the service and its value to the business
  • Who owns the service and who should be notified through things like service level agreements and escalations
  • Target metrics, such as "time to resolve" or "lead time needed to set up"
  • Workflow and a Table Field to link CIs from the Remedy Asset Management application and Categorizations in the other ITSM applications
  • A permissions model that defines who has access to the service inside the Enterprise (for example, limiting access to a Service in your Catalog that only allows Accounting to subscribe to it and open tickets on it)

Once you complete this form, you can create a public view that you leverage on the Mid-Tier to display for reference to your end users the services that they can access from IT.

  • Integrate your Service Catalog into the Remedy ITSM applications:
  • Requester View. If you have your end users opening tickets over the Web, you will want to link your Service Catalog into the submission process to help streamline the overall user experience. One way would be to use Service Catalogs to filter the different problems and requests that a Requester sees when accessing the application.
  • Support and Management Views in Remedy Help Desk and Remedy Change Management. Capturing the Service is a critical metric for things such as service level agreements, reporting, and tracking issues and changes back to CIs in a greater degree.
  • Asset Management. The link between Services and CIs that are kept in the Remedy Asset Management application is critical for the success of this extension of the current ITSM suite.
  • Service Level Agreements. Adding the ability to filter and design SLAs against a Service Catalog will be key in tracking and reporting on more robust and meaningful metrics.

Summary

The first steps in adopting a Service Catalog internal to your company starts with adopting the understanding that publishing a Service Catalog changes the way IT is viewed by the business. There are numerous ways to go about the implementation of a Service Catalog and the AR System platform opens up a number of ways to implement this extension to the IT Service Management applications. After getting the go ahead to proceed, using known best practices for Remedy Application Development will lead you to a sound and useful set of forms and workflows to meet this growing need around adopting a Service Catalog.

~John
Senior Business Development Manager - RAC Certified
Western Area Professional Services
Joined Remedy in 1999
"Red Sox WIN!"

 

Footnotes

  1. Planning to Implement Service Management
    by Vernon Lloyd and et. al.
    © Crown Copyright 2002
    HMSO, Licensing Division, St Clements House, 2-16 Colegate, Norwich, NR3 1BQ
    Appendix A.2 Glossary
  2. www.itilpeople.com/articles
    The Key to Quality Service Level Management
    by Karsten Smet
    © 2003, Karsten Smet