The ITSM Paradox

Share twitterlinkedinmail

Paradox [par-uh-doks] noun

  1. A statement or proposition that seems self-contradictory or absurd but in reality expresses a possible truth.[1]

Example: The paradox of many IT Service Management (ITSM) implementations is they actually do not manage IT services.

Many organizations have invested time, energy, and money into establishing ITSM. But in a large number of organizations, the implementation fails to define the critical foundation for ITSM – the identification and definition of IT services.

What have these organizations done? Usually, they’ve bought a tool, deployed a self-service portal, called that portal a “service catalog”, and have listed applications, activities, procedures, and products as “services” within that portal.

Applications, activities, procedures, and products are not services. When companies have done it this way, they have neither a “service catalog” nor have they defined “services”.

What is a service?

A service essentially is a means by which the business or a customer receives value in the outcomes they receive from a service provider. The customer or business does not have to be directly concerned with the combinations of people, processes, technology, and vendors that work together to deliver those outcomes that result in value.

Think about it. For example, a smartphone without the underpinning communications network, suppliers, software, applications, and technical support is nothing more than an expensive paperweight. A password reset might allow the user to access an application or the corporate network, but then what?

By properly defining services, the IT organization demonstrates that it understands what outcomes are needed by the business. Properly defining services illustrates that IT understands what the business values and how what it does delivers those values and outcomes. But that’s not all. By properly defining its services, the IT organization also answers the question “why should the business get its IT services from us?”

Unfortunately, many IT organizations are unable to answer that question, because they’ve only included activities and products in what they are calling a “service catalog”.   While these activities and products are important, they are not services.

What is the impact?

When the IT organization does not define services that reflect business value and outcomes, but rather defines the activities, products, and tools they provide as “services”, here’s the impact:

  • IT becomes commoditized. Let’s face it- the business can get smartphones and laptop computers anywhere. If all IT does is reset passwords, develop applications, and install software, those activities can be outsourced. Define services in terms of outcomes and value and avoid becoming a commodity.
  • IT is perceived as a ‘cost center’ and not a ‘value-enabling partner’. Value is only realized when a customer feels that the benefit it receives from something outweighs the cost of getting it.   By not defining services, IT never enables or promotes the value of what it does. From the business perspective, IT just looks like cost.
  • ITSM cannot meet its potential. Defining services enables the operational aspects of ITSM. Services become the basis for categorizing incidents and requests, provide the blueprints for what CIs should appear in the CMDB, and help enable business-meaningful service level agreements. But it goes much further than that. Defining services enables the business to look at its IT service portfolio and understand its IT capability and how to leverage it. Defining services enables strategic discussions regarding how business can take advantage of advancements in technology while at the same time, ensuring that IT is delivering value now. With properly defined services, IT becomes a strategic asset of the organization.

Break the paradox

Because no two organizations are alike, identifying and defining IT services is a mix of science and art. Having said that, there are some key concepts that will help.

  • Look at the business from the perspective of its customers. What does the customer of the business get? How is value delivered to the customer? Once those two questions are answered, identify how IT contributes to or enables that delivery of value.
  • Just because your name appears on the IT organization chart doesn’t necessarily mean you’re providing a service. A frequent mistake by many organizations is using the organization chart as a guide for identifying services. The delivery and support of a service often involves multiple people from across the organization. How are the people on the organization chart working together to deliver the outcomes that are valuable to the business?
  • A service must “make sense” to the business. In my experience, IT tends to talk to itself about how the business uses IT, rather than talk to the business. Who better knows the requirements, needed outcomes, and what is valued by the business than the business? By engaging your business in the identification and definition of IT services, your service definitions make sense to the business and better partnerships between the business and IT will result.

Don’t miss my future blog posts!  Click here to subscribe to my newsletter!

[1], retrieved 6/5/2016

Share twitterlinkedinmail

Leave a Reply

Your email address will not be published. Required fields are marked *