Branimir Valentic Company growth is good, even desired. But usually, along with the growth of the company, the number and complexity of the services grow as well. Situations where everyone can define their own service with respective descriptions, contracts and naming nomenclature… only lead to chaos. I noticed that, looking from inside the IT organization – such chaos can exist for some time, but customers don’t react to it very well. That’s when management of services becomes essential.
Properties
I am sure that you are familiar with the situation where you have had to define properties of the application or hardware component in order to make sure that it works (as desired). It’s the same with IT services – they have to be properly defined in order to be managed and to fulfill their business targets (e.g. generate profit by being ordered by the customers). Otherwise, services will be perceived as a bunch of hardware and software, i.e. as a pure IT service.
To give you an idea of what it means to define a service, here are a few examples of service parameters:
- Naming the services – although it sounds simple, it could be quite confusing. If you are talking to the customer while trying to sell a service with a lot of IT vocabulary in the name… when you leave the customer’s office they will not even remember that someone was there. Try to use a simple name for your service that is somehow connected with the functionality that service provides (take, for example, telecommunication companies – they sell services like “Mobile Internet” and not GPRS, HSDPA… or whatever the technology in the background is).
- Describing the services – as we mention in Service Catalogue, customers speak the language of business, so such should be the description in the Business Service Catalogue (the part of the Service Catalogue which is used by customers). On the other side, the same service should have a Technical Service Catalogue that is used internally, inside the IT organization, and written in technical language.
- Establishing service hierarchy – generally, Service Catalogue will help you organize live services, i.e. services that are in use. While creating a catalogue of services I used to implement some kind of structure, i.e. hierarchy. As suggested in the Service Catalogue Management process, services can be divided into:
- Customer-facing services – these are the services that the customer sees, i.e. uses. Basically, as I was told many times, with such services the customer wants to solve some of his problems i.e. satisfy some of his needs. For example, the customer wants to be able to communicate, send messages and distribute files, and we offer – e-mail service.
- Supporting services – these are the services which support, i.e. underpin, the customer-facing services. The fact is that customer-facing services can rarely exist alone, without having services that enable their existence. Let’s go back to e-mail service. To be able to use e-mail service, the customer is using many other services that are “invisible” to him. For example, network infrastructure, server administration… etc. They are supporting services.
Figure: To be able to use e-mail service, the end-user uses many other (supporting) services.
Properties in real life
When a service is properly defined, there are a few areas where they can be of great use:
- Agreements, i.e. contracting – customer-facing services will use a Service Level Agreement (SLA) to define the service and relationship with the customer. The SLA will be written in formal business language. Supporting services will use an Underpinning Contract (UC) or Operational Level Agreement (OLA) if they have to define relationships with some (external or internal) third party. The OLA does not need to be that formal, but the UC is usually written in formal language. But, both of them will contain many technical details.
- Charging – charging is the aim of all our business activities. But, having different kinds of services, there is a logical question – how? Well, that’s more complex. Essentially, there are a few options. If you are an internal service provider, you can afford to charge for both supporting as well as customer-facing services. But, to share my lessons learned with you, if you charge for supporting services directly “as they are,” expect to get many questions and be ready to explain technical issues in non-technical language. An alternative is that you integrate supporting services into customer-facing services and charge only for the latter. That would be the case if you are providing services to external customers.
Information sources
To be honest, defining the service is not an easy job. You have to see the service through the eyes of the customer. And that is your most valuable source of information. They have different views on the services than IT itself. Talk to the customers, listen and make notes. These notes are an excellent starting point for your (Business) Service Catalogue and service description.
Download this free sample of the Service Catalogue Management process template to learn how to set up a process.
