By Jason Stevenson
A service involves two parties: 1) a customer and 2) a service provider.
A service fulfills a customer’s need. Though there may be many components to a service, those technology, process, and people components are combined to form a single service. The customer should not need to understand all the subcomponents of the service to benefit from the service. Nor should any service-specific knowledge be required for the customer to solicit the service. In other words, the service should be expressed in cohesive layman’s terms.
Water Service Example
- Customer Needs: Water services fulfill multiple needs: life/thirst, personal/environmental sanitation, etc. If you put in a well, you have your own water and there’s no need for water service. However, if you do not have a well, you will need to engage the county water service provider.
- Service Provider: To engage water services, you expect simple contract language and simple commodity pricing. The customer should not need to be a plumber or hydro-engineer to engage the service.
- Customer Expectations: Once engaged, the customer doesn’t care how the water gets to them, what must be maintained, or who maintains it. After procuring the water service, they never want to talk to the water service provider again unless their needs change. If water service is interrupted, it’s the service provider’s problem. Customers don’t care what service provider people, tools, or expenses are needed to fix the problem, they just expect it to be rapidly resolved by any means.
How does this example relate to IT services?
First, let’s lay out the key players:
- CEO, CFO, and stakeholders = Mom and Dad paying for the water service
- IT Users = the family drinking the water and bathing in it
- IT department = water service provider
- IT services = water
- Data, applications, networks, servers, storage = water treatment plants, water towers, mainlines, pipes, trucks, wrenches
- IT staff = plumbers and hydro-engineers
Every time a customer experiences interruptions and contacts a water service center, the support call is not considered a “service” but is ancillary to the water service they are already payed for. The customer would rather not engage the service center at all. This is the same with an IT service desk.
Though a water plant monitors water flow and quality, it is not a service. The customer assumes the water is available with adequate water pressure when they purchase the service. This is the same with an IT operations center.
Though hydro-engineers and plumbers may be needed, for example in a large mall complex, they’re assistance would not be a service, rather a project to support the delivery of water services to the tenants and patrons of the mall. This is the same with IT engineers, developers, and project teams.
We assume the water is safe, maintained, and appropriate precautions are taken to ensure ongoing water quality and availability. This is the same with IT security, IT service management, and disaster recovery.
How do CIOs apply this to running as an IT as a Service Provider?
Think of what a water provider service catalog website looks like. It’s pretty simple… Water. Everything needed to supply the water is moot. You may be thinking “Sure this is true of a water commodity but IT is not a commodity.” No it is not… not yet.
So let’s take it up a notch and talk about utilities like telephone and energy services. Their service catalog websites contain utility services. Telephone companies for example list things like local and long-distance, Internet, call waiting, caller ID, conferencing, etc. on their service catalog website. They may also segregate their services by enterprise, small business, and individual customers.
Cable companies are even more similar to IT in some respects. They list things like VoIP communications, Internet, television/entertainment packages, etc. You can draw a parallel between each station offered by a cable company to each application offered by IT.
Regardless of commodities or utilities, service providers of water, power, telephone, cable, etc. have very simple service catalogs considering their extremely complex infrastructure and organizations. This is because the service provider has matured their services to focus on the customer/users and highly refined their services to meet specific customer/user needs, to remain relevant, competitive, and accessible.
To become a true service-provider, IT must take a similar approach to interaction with customers and users. To be successful, CIOs become CEOs by defining a usable service catalog with:
- A clear business-focus addressing specific needs
- Inclusive pricing and options
- Seamless delivery
- Transparent fulfillment
Jason Stevenson is a Transformation Consultant based in Michigan.
