ISO/IEC 20000:1, the Information Technology Service Management (ITSM) standard, defines a service as a “means of delivering value for the customer by facilitating results the customer wants to achieve.” ISO 20000 continues by stating that a service “is generally intangible”. 
In other words, services do not sit on shelves.
Yet many ITSM vendors would have you believe that their tool provides a “service catalog”, when what is really being provided is “request fulfillment”.
Don’t misunderstand – your IT organization can realize significant efficiencies from defining and publishing request models within a centralized portal. But recognize that what you’re doing is not a service catalog. Your portal is providing access to products or activities – service requests – managed via the request fulfillment process – that provide the means to consume a service. The product or activity itself is not a ‘service’.
Why understanding ‘service’ vs. ‘service request’ is so important
Services are the critical foundation for the relationship between IT and the business it serves. When services are described in terms of business value and results, IT is able to articulate how it provides benefit in terms that the business understands. Defined services are outcomes of business strategy – the plan for how the business intends to achieve goals and objectives – and how IT will support achieving those business goals and objectives. By defining services, IT illustrates its capability and readiness to be a strategic partner to the business.
Service requests, on the other hand, are simply a means of achieving those business objectives. Strictly speaking, it really doesn’t matter what brand or type of PC that is being used to access a service. It’s the use of the service – the realization of value and outcomes – enabled by using the PC that actually provides the business value.
Why is understanding the difference between ‘service’ and ‘service request’ so critical? One answer is the difference between an IT organization that is recognized as a ‘strategic business partner’ versus an IT organization that is perceived as an ‘order taker’.
A simple example
Think about the following products: a PC, a MacBook®, an iPad®, and a Microsoft Surface® – perhaps all suitable entries in a company’s service request portal. Why would a consumer choose one of these products over another for use with his job? Perhaps it’s the form factor. Or maybe it’s personal preference. Perhaps it’s dictated by a company standard. Maybe it’s the color of the device.
Whatever the reason, can any of the devices listed above just be delivered to the consumer – out of the box – right from the shelf? Basically – no. Most companies require some sort of device protection to be installed – whether that’s simply a userid/password combination or some kind of security software. Then there’s configuring access to the corporate network, without which, none of the devices listed would be useful for the consumer for doing work for the company. Of course, the consumer will need to use corporate applications ranging from email to CRM systems.
Does the device itself deliver value by facilitating the results the consumer wants to achieve? Without the use of appropriate security measures, combined with access to the corporate network and email and CRM systems, the answer is “no”. So, is the device itself a ‘service’? No.
If this sounds like what was implemented with your ITSM tool’s “service catalog”, do you really have a service catalog?
Move from ‘Order Taker’ to ‘Strategic Partner’
To be clear, I’m not suggesting that you “turn off” your service request portal. But what I am advocating is take what you’ve defined in your request portal and look at each item from the perspective of business value and business outcomes. By doing this, you’ll be enabled to begin to move from the perception of ‘order taker’ to becoming the strategic IT partner for your business.
To start the move to ‘strategic partner’, answer the following questions for each entry in your request portal (I will use a service request for a PC as an example):
- How is the requested product or activity being used? A PC is used for multiple purposes – access email, use personal productivity tools, access to corporate systems.
- What are the technologies and activities involved with fulfilling the request? The PC requires software installation, configuration, physical installation, network connectivity, shared file system access, and other technologies and activities before it can be made usable.
- Are there any dependencies or relationships between this request model and other request models? Perhaps the PC user also needs access to corporate systems, which may be handled by other service requests.
- What is the ultimate outcome or result from the fulfillment of this request? Using the PC enables personal productivity for the consumer, which enables her to fulfill her job responsibilities.
As you get the answers to these questions, you will start to recognize similarities in outcomes or dependency patterns – indicators of the value chains that constitute services. Review these dependency patterns to identify the path that outcomes follow from the point(s) of origin to the point(s) of business value realization to complete the value chain. When you’ve done that, you have begun to identify services.
Workshops from Tedder Consulting can help you identify and define Services, develop your Service Catalog, and enable your Request Fulfillment process! Want to know how? Contact Tedder Consulting today for a free 30-minute consultation!
For more pragmatic advice and service management insight, click here to subscribe to my newsletter!
Photo credit: conrado
 ISO/IEC, (2011). ISO/IEC 20000-1:2011 Information technology – Service Management – Part 1: Service management system requirements. Geneva, Switzerland: ISO/IEC.
 MacBook® and iPad® are registered trademarks of Apple, Inc.
 Microsoft Surface® is a registered trademark of Microsoft Corporation in the United States and/or other countries.Share