New view on service catalogs

I have been thinking about the practical implications of breaking down the concept of service. One obvious case is the re-thinking of the service catalog. Writing a good service catalog is not easy. There are books and training about it but good examples are rare. I have come to the conclusion that talking about service in general in ITSM is actually a waste of time.

A service promise or proposal is about the outcomes the customer want. These may be specific or general, all depends on the customer needs. There is a major difference between internal IT and external IT. External IT must sell its services and there is usually competition. It is not easy to make good service proposal, it is a business skill and I will not cover it in detail. Internal IT is in a different position; it has a monopoly position which it should use wisely or it will lose it. It needs to be able to deliver the IT services the business wants. The business owns it and can decide what the IT does. Internal IT needs to make and keep a service promise which satisfies the customer.

A service system is a combination of people, processes, hardware, software etc. Usually there is a collection of service systems to fulfill the service promise. Typical service systems are: an application, network, servers, service desk etc. Service systems can be outsourced or internal. Some service systems are visible and recognizable to the customer; other systems are hidden or uninteresting from the customer’s point of view.

When service systems operate, they may perform service acts. Service acts are touch points between the service system and the customer and the service promise is fulfilled by the service acts.

This model leads to three different ”service catalogs”, which are much easier to design than the current model:

  • A list of service promises contains the promises IT has made to the customer. They need not be very detailed but the customer may require exact details of some important service systems.
  • A list of service systems describes all the components of the whole service system. This is just a breakdown of the whole machinery to smaller components. The customer may be interested in some elements of it but not at all interested in some other elements. The list would be identical with the list of higher level configuration items.
  • A list of service acts describes in detail what the customer can get from the service provider.

The discussions with the customers should concentrate on the list of promises and the list of acts. It is possible that the customer is interested in the details of some specific service system but hardly ever interested in all of them.

Consider an amusement park. It has a simple service proposal: you and your family will have fun. It may add information about the number of rides, restaurants etc. It may describe some technical details about selected rides like maximum speeds but there will not be exact details of all rides. The service proposal will contain exact information of the available price options and their benefits.

 All the rides and restaurants are service systems, but there are other systems like security, cleaning, maintenance etc.

 There will be a detailed list and map of all the rides and other service facilities and that is the most interesting list for the users.

 There are usually no SLAs.

A service promise might ideally look like this:

The IT departments supports business units by providing the business with up to date tools and ensuring that the IT systems work well. The goal is to have no events that cause business losses and to make sure that the staff will lose very little time due to IT technical problems.

The list of available services would be on the support portal and would include things like:

  • order a computer
  • order an application
  • new employee
  • etc.

Stuart Rance wrote recently a blog about why one should not define applications as services. I agree with that, but you could have customers who want to specify some important IT application and require an SLA for it. The problem with this is that the IT and the customer won’t mean the same thing. The application can be outsourced from vendor A and it runs on platforms provided by vendor B. It needs data from other applications. In worst case different business units own the contracts or the applications. The application might be running 100 % ok but some other system might not be providing the necessary data.

The solution this would to make a service promise about the application. This can be a problem if there is no overall responsibility for it. Then there are two options: 1) the customer negotiates SLAs with each vendor via the business unit which owns the contract. 2) some party takes the role of a service integrator.

The second option is most likely much better for all parties, which explains the current popularity of SIAM.


Täytä tietosi alle tai klikkaa kuvaketta kirjautuaksesi sisään:

Olet kommentoimassa -tilin nimissä. Log Out /  Muuta )

Google+ photo

Olet kommentoimassa Google+ -tilin nimissä. Log Out /  Muuta )


Olet kommentoimassa Twitter -tilin nimissä. Log Out /  Muuta )


Olet kommentoimassa Facebook -tilin nimissä. Log Out /  Muuta )

Muodostetaan yhteyttä palveluun %s

%d bloggers like this: