There is only one customer

The concept of internal customer is an idea to increase quality by motivating people to serve other internal teams as they were their customers. In the model the various units form a chain or network of service providers who serve each other. The internal service model allows all employees to have some direct customers. Companies or organizations usually have a customer for their services or products. They work for the customer who pays the costs. Some of the work is indirectly related to the customer and in some cases the link is complicated.

IT used to have a distant connection to business. Data was entered via punched cards and input from IT to business or customers was via printouts, reports, invoices etc.  It was natural to see IT as an internal service unit. In ITSM the concept of internal customers has been adopted very thoroughly. Instead of just using the internal service model for motivating staff, the ITIL books suggest that one needs to have a service strategy for creating and managing a service portfolio, as if the internal customers were real. An IT unit which follows the ITIL model acts like it is an independent business which can decide its own strategy. If that is right, then the corporation should check whether the IT service unit is competitive. If it isn’t, the corporation can switch to an outside vendor, if it is then the corporation can spin off the IT part as an independent business.

Most large corporations have several internal support functions: finance, human resources, legal, marketing and IT. It is common that directors of finance and legal are board members and it is relatively easy to become a CEO from those positions. CIO’s are much less likely to be included in the top management team. The reason for this is that finance and legal are involved in the business while IT can be seen as just a technical service.

Stephen Mann wrote a blog about how one should not limit ITSM models just to IT. http://allthingsitsm.com/enterprise-service-management-not-just-itsm/. I agree up to a point. The concept of internal customer is not harmful if applied with sense. It is a good idea that for example the service desk staff treat the people who ask for help as customers. It is a natural model in that situation. And the service desk model can be applied to many other situations. The ITSM tools can be applied to many other business processes. I disagree with the idea that the whole internal service model should be copied to other services. It is a better idea to move to the opposite direction.

It has become quite common that outside customers have a direct connection to the IT systems. A customer may check current information about availability, delivery times etc., they can enter their orders and update their information. The role of IT has changed or should change from internal service provider to a partner of the business.

There is only one real customer and there is only one real strategy. This means that a lot of the elements of the internal customer service model are unnecessary. There is no need for a comprehensive service catalog, service strategy, service level agreements for example. Instead of IT services to the business there are business services to the customer. This means that there is very little need for IT centered best practice models, instead IT needs to apply the business models.

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.

%d bloggers like this: