IT Service Management (ITSM) - What is a Service?

Posted by Dedra Cenciarelli  I  August 27, 12

In my college economics class, we were taught that a service is an intangible commodity. Wikipedia tells us that... "Service provision is often an economic activity where the buyer does not generally, except by exclusive contract, obtain exclusive ownership of the thing purchased. The benefits of such a service, if priced, are held to be self-evident in the buyer's willingness to pay for it."

ITIL v3 tells us that “A service is a means of delivering value to customers by facilitating outcomes customers want to achieve, but without the ownership of specific costs and risks.”

So, basically, a service is a means of delivering customer value by providing them with what they want or need without the headache of keeping up with all the costs and risks. So, with all that in mind, for a business to effectively operate and manage the services provided to their customers, those services must be identified and documented. The services must, in essence, somehow have tangibility.

In my opinion, ITIL methodology does a good job of explaining how to facilitate, manage, and measure a service. It provides a detailed description of important IT practices and what types of questions to ask when establishing procedures, guidelines, and responsibilities. But, in my years of experience, the toughest challenge for actually applying those fundamentals of ITIL is being able to define the services themselves. And, not only do we need to define our services adequately, but we should be able to classify them and identify what types of service requests we have in order to establish the basis for keeping our customers satisfied... which will consequently help us “measure” our success in doing so.

Sooo, in a nutshell, there’s your definition of a service. But, where do we start? How do you make a service quantifiable so that it can be effectively managed and measured and more importantly, how do you structure those services so that one can adequately facilitate the processes surrounding them? How do you make a service “tangible”? Sigh.

Techport Thirteen employs ITILv3-certified consultants

Nick King, a Senior Software Consultant at Techport Thirteen, has done an amazing job at shedding some light on this topic for me. A critical step in identifying an IT Service is to distinguish the service from the technology. A service provides a desired outcome for the consumer of that service, while a technology is simply a tool used to deliver a service. It is important to keep this in mind when you start building a service catalog for your organization.

Identification of a service may be accomplished through an evaluation process. The process entails answering a series of questions about the items that compose the service. Each answer provides information that distinguishes that service from its component make-up and categorizes a service as either a Business Service or an IT Service. The evaluation process is complete when a desired outcome is defined and matched with the functions and technologies used to deliver that outcome. That combination of technology components, functions, and a desired outcome identify an “IT Service”. Operating Level Agreements (OLA’s) evolve from this type of services. A “Business Service” is a category of IT Services that directly support a business process and provide customers with a desired outcome. Service Level Agreements (SLA’s) evolve from this type of services. Both business and IT services may exist in a service catalogue, but various IT services may be used to make up the business service, and the IT services will be made of various configuration items that work together to maintain overall service continuity.

So where do we start? Do we immediately “dig into the details” or do we “step back and look at the big picture”? I believe it is a little of both. Start from the top and go down, but as details that make up a service surface, take note and circle back. This is important.

You must view the business as a whole, not just from an IT perspective. However, that IT perspective is key in helping you drill down into the details. When a customer has a request or reports an issue, what components are necessary to fulfill that request or troubleshoot that issue?

You also need to think as though you are a customer. You are on the “receiving end” of the services being provided for the business. When you have a request or an issue, how do you report that need to the business? And at the end of the day, how do you know whether or not you are satisfied with the services provided?

Ultimately, service definition starts with understanding your business processes. Drill down into each aspect of that process and identify the types of requests and issues being reported by your customers. Then, identify how your resources are currently handling them. Remember the four P’s of Service Design: Perspectives, Positioning, Planning, and Patterns. Service definition will evolve if each of these aspects are carefully analyzed.

You must also consider the infrastructure necessary to provide a service. A service is made of multiple configuration items. Define the service from a customer perspective. Then, relate that service to all of the “pieces” that come together to ultimately deliver that service. If the configuration items for the service are effectively implemented, it can provide information about the following subjects [Published by TSO (The Stationary Office), Introduction to ITIL (English edition Van Haren Pulishing; Dutch edition ITSMF Netherlands, 2005), p. 57]:

  • Product Policy
    • Which IT components are we currently using, how many of each model (version), and how long have we had them?
    • What are the trends in the various product groups?
    • Which IT components can be phased out and which require upgrading?
    • What licenses do we have and are they adequate?
    • Which maintenance contracts should be reviewed?
    • How standardized is our IT infrastructure?
  • Troubleshooting information and impact Assessment
    • Which IT components will we need for a disaster recovery procedure?
    • Will the disaster recovery plan still be effective if the configurations are modified?
    • Which IT components are affected by a rollout?
    • Which network is equipment connected to?
    • Which software modules are included in each suite?
    • Which IT components are affected by a change?
    • Which [change requests] are under consideration for specific IT components?
    • Which incidents and problems have occurred in the past and are currently relevant?
    • What IT components are responsible for known errors?
  • Provision of Services and Charging
    • Which IT component configurations are essential for certain services?
    • Which IT components are in use at a site and who are they used by?
    • What are the standard IT components that users can order that are supported?

This gets us into Configuration Management which, in my mind, is a beast of its own. But, it is a critical juncture in the overall service definition journey.

In general, think of it as building a portfolio for each service. Then, once you have these service portfolios, you now have the makings of a service catalogue. You have:

  • Service definition
  • Service classification (IT or Business)
  • Service types (incident, change, and service request categorization)
  • Service infrastructure

Let’s briefly look at an example such as “email”. A simple name used to refer to something may mean different things to different people based upon their point of view. Therefore, evaluating a certain technology based on its name alone can yield inaccurate results. For example, the term email could mean different things based upon who is asked to describe the term. Which of the following descriptions are correct for the term email?

  • The capability of a person to send and receive electronic messages to and from another person
  • The collection of servers and software used to deliver electronic messages
  • The act of delivering an electronic message
  • The server that delivers electronic messages
  • The software used to compose, send, receive, and read electronic messages
  • The act of sending an electronic message
  • An individual electronic message

The fact is that all of these descriptions are potentially valid descriptions of email. Therefore it is not possible to accurately evaluate an item called email without clearly describing what is meant by the term. In general, the items to be evaluated will fall into one of three main categories: Outcomes, Functions, or Components

Using the examples above, they fall into the categories listed below:

  • Outcome
    • The capability of a person to send and receive electronic messages to and from another person
  • Function
    • The act of delivering an electronic message
    • The act of sending an electronic message
  • Component
    • The collection of servers and software used to deliver electronic messages
    • The software used to compose, send, receive, and read electronic messages
    • An individual electronic message
    • The repository used for housing all the emails

In conclusion, service definition is a pain-staking process. It is the roadmap for service delivery. The quality of a service weighs heavily on the customer’s interaction with the provider. That roadmap is crucial because it will allow you to navigate changes that provide for continual service improvement... yet another module in the ITIL lifecycle.

Editor's note: Dedra Cenciarelli is a Senior Service Consultant at Techport Thirteen, Inc. She has worked in the ITSM tools industry for over 15 years, and has worked hands-on with the ITIL methodology, and its many variations, during her experienced career.

Have a comment for Dedra, or want to add to the discussion? Post your comment below for her and others to review.

If you are interested in talking more with Techport Thirteen about your firm's ITSM processes, and how utilizing ITIL could improve your firm's performance, please call or click us:


Tags:  xMatters, HP Service Manager, Bomgar, ServiceNow