The Forum - 05/08/2008  (Plain Text Version)

Strategic question to ask yourself about each service that your organization provides: Do your customers feel like they are directly exposed to the cost and risk? Do your customers understand what they are getting from the service and the cost of the service? Note: an overhead charge or an IT budget breakdown in terms of labor, software and hardware depreciation, does not explain the specific cost of each service.

The Value of a Service

The first part of the definition of a service speaks about value.  There are two dimensions to value: utility and warranty.

Utility refers to how effectively the service facilitates the desired outcome, i.e. help the customer achieve its business objectives.  Let us continue with our Sales Force Automation theme.  Some examples of objectives for the SFA service are: ensure sales reps are following an effective standardized sales process to result in more sales, provide management with a greater visibility in the sales forecast, etc.  The ability of the SFA service to affect these outcomes is a measure of its utility.  When you think of utility, ask the question, “what” is the service trying to achieve and is the service “fit for purpose.”

Warranty refers to the ability of consistently delivering the service when it is required.  Here, concepts like availability, performance, security, etc., are important.  In our SFA example, sales reps may need access to the SFA system in the office and on the road.  They may have meetings during the day (hopefully a good indication that they are productively selling) so they may only be able to update their SFA information after-hours.  Hence, when you think of warranty, ask the question, “how” is the service being delivered and is the service “fit for use.”

Both utility and warranty must exist in order for the customer to perceive value in the service.

Categorizing Services

When identifying the services that your organization provides, it is useful to consider the following categories of services:

• End-user services:  As the name suggests, these are services provided to an end-user, e.g., a new hire would typically get most of these services automatically.  Many organizations consider them “basic” or “utility” services.  Examples include: desktop/laptop service, email services, collaboration services, etc.
  
• Technical services:  These services are provided by one IT team to another IT team.  They are important to identify and define because they will be governed by Operational Level Agreements (OLAs).  Examples include: network support, server support, database administration, etc.
  
• Business services:  These services are provided to departments and business units.  Generic examples include Enterprise Resource Planning (ERP), Supply Chain Management (SCM), Customer Relationship Management (CRM), etc., but each industry vertical may have their own unique services, e.g., higher-education has Learning Management Systems (LMS), hospitals have Clinical IT services, and hotels have room reservation IT services.
  

Defining Services

So how do you identify the services that should go into your Service Portfolio?  In order to identify the services, think about what the customer perceives as a coherent whole, an end-to-end capability, which supports one or more business processes.  The idea of a “coherent whole” is best understood by reviewing specific examples in the “real world.” 

We will also distinguish between the “service” and “service requests” – something that is frequently confused when creating a Service Portfolio or Service Catalog.

Desktop/Laptop Support	Customers consider the hardware, operating system and software as a coherent whole.  As far as the customer is concerned, if the hardware is broken, or if there is a problem with the software, there is a disruption with the desktop/laptop service.  Customers also expect their desktops/laptops to have malware protection and be covered by patch management (some organizations have been identifying these as separate services). Regardless of whether the device is a desktop or a laptop, customers expect similar service.  However, laptops are typically more expensive than desktops and have different accessories such as docking stations.  Hence, laptops can be modeled as a different service level option or service level package. One thing to note is that “requesting a new desktop” or “requesting a move” is not a service.  These are “requests.”  A service can have many different types of requests; however, these requests are not modeled in the Service Portfolio.
Email	Most IT organizations realize that the email service is more than just keeping the email server(s) up and running.  However, customers expect their email to be spam filtered and virus protected.  To understand what constitutes a “coherent whole” for the email service, it may be useful to compare how your organization defines the email service relative to other third-party options, e.g., gmail, hotmail, etc. Requests that an organization may want to provide in the Service Request Catalog, but not in their Service Portfolio, include: request a new inbox, request a public folder, request a new distribution list, etc.
Business Services	Some organizations separate the delivery of the service from application development for that service.  However, think of the outcome that the customer wants.  Using the housing industry as an example, does the customer want a builder or a home?  Similarly, the end results the customer is looking for is not “application development” but greater service utility.  Hence, from a service definition perspective, do not separate application development from service delivery. This means that if the service owner comes from the application development perspective, they need to understand that they are responsible for the warranty of the service, i.e., does it demonstrate good response time, does it satisfy the availability requirements, etc.  Too often, application-based service owners push this responsibility to the infrastructure or operations team.  However, from the customer’s perspective, they expect the service owner to be responsible for both the utility and warranty.

This article started by asking whether a service portfolio or a service catalog should have less than thirty services or hundreds of services.  I have found from experience that when organizations think strategically about services, they typically can realistically identify 80 to 120 services.  Getting to the right level of detail, the detail that the customer needs to understand what IT provides to their business operation, can be challenging.  I hope that this article has provided some concrete examples of how to think about services and help you get to that right level.

About the Author:
Reginald Lo is a Vice President of Third Sky.  Third Sky is a privately held services company, dedicated to providing Service Management solutions “in the Real World” to a broad range of clients in all market segments. In the past 4 years, Reg Lo has educated over 30 clients about ITIL^®, guided them through process improvement initiatives and helped them select and implement a variety of ITIL^®-based tools. He is a frequent speaker at itSMF and HDI LIGs, at corporate IT Senior Management meetings, and at education institutes.