+358 50 5066 806
This is a discussion between Aale Roos and Aki Lähteenmäki. We met some time ago and we discussed ITSM matters. We got to know each other many years ago when Aki attended ITIL Service Manager course where Aale was the a trainer. Aki has worked previously in his career in tool & process consultancy roles in various companies. In 2014 Aki started a consulting company www.justin.fi with his colleagues. Aale is internationally recognized expert on ITSM and Service Desks. Aale has his own consultancy company pohjoisviitta.fi.
We share a common view that ITSM is yet quite immature and there is a lot of work ahead in improving models and practices. Our different backgrounds give us different viewpoints on possible solutions.
We decided to have a written dialog about some areas where we see major problems in current practices but are not quite sure what would be the right approach. We do this in English in the hope that other people might find this approach useful.
The subject of this first blog discussion is the Service Catalog for the internal IT. It is a key concept in ITIL and in IT service management but there is silly problem in it. ITIL books state that service is A means of delivering value to customers by facilitating outcomes customers want to achieve, but without the ownership of specific costs and risks.
That is obviously not true for most IT organizations. A typical corporate IT is part of the corporation which is the customer, so it definitely does not free the customer of the ownership of the risks and costs of the IT infrastructure it owns.
So this leaves us with two choices:
• either the concept of service is right and then internal IT is not a service provider
• or the definition is wrong
The first choice is quite interesting but not very useful for our discussion. I have come to the conclusion that it would be better to stop talking about service and assuming that everybody understands it the same way. It is a better idea to split the term in three parts: promise, act and system.
• Service promise is what we promise to do, it is not necessary very detailed
• Service systems are all the systems we operate or buy on behalf of the customer. Service systems may contain hardware, software, processes, people, resources etc.
• Service acts are what the customer gets. They fulfill the promises and they are the results of the service system working.
What do you think about this model, Aki?
I agree with you that ITIL definition is applicable only for certain cases and therefore it is not good way to describe what generic term “service” means. I have used to understand term “service” as generic term for something which brings value for service consumer. In this context consumer can be service end user, other company, service provider’s organization or even service organization itself.
Depending on the case, service can be “pure” service like IT Service desk which provides support for service users or it can be combination of services and products. For example “Workspace service” can contain certain set of available/orderable products like workstations, mobile devices or software. Same service can contain services like service desk, control desk (monitoring), etc.
So therefore there is different kind of services and maybe we should make definitions for those instead of trying to resolve service definition problem?
For example: We could have definition for:
What comes to your idea about those three dimensions; promise, act and system, I like it. But what does it mean in practice, from service definition point of view?
Writing a service definition is hard. The problem is that all the different service definitions you described still contain the word service. It is difficult to avoid it.
The split in three elements makes it a bit easier. For example, I would say that a Service Desk is three things:
• a promise to help in all kinds of problems and questions regarding the IT infrastructure
• a system with people, processes and tools
• an act of responding to a customer and finding a solution to the customer’s problem
I think the benefits come when you create service catalogs. While there would be three of them, they should be easier to create. Could you try this approach just as a thought experiment, Aki?
I think I understand what you mean by this “PSA” model. If I try to combine your approach and portfolio thinking I used to, I can find at least two options to mix those:
PSA service model:
Or PSA model as service modelling matrix:
For me that is the perfect match! What do you think Aale?
Aki, I think we are pretty close. But remember that all customer facing services are based on service systems too. The difference is that some service systems are visible to the customer and some become visible only if they fail. There are usually many service systems behind one promise. There can be also many acts.
Well in my mind service system is system of people, processes, tools and knowledge which will produce and deliver tasks, activities and service assets like business applications, servers, workstations, workstation software, etc. But I think tools & technology used as a part of service systems should be part of the supporting services (service system).
How does that sound, Aale?
I also started to wonder where in this picture external vendor’s are? For example software/hardware vendors or outsourcing partners? Can supporting service describe external actor’s service as well?
I like your picture Aki. I had never thought that an asset like a laptop would be a service act but of course it is.
Let’s take an example. The IT provides workstations including laptops, tablets etc. to the corporate customers. This service has a price list and a promises of service quality. For example, customers are guaranteed that if their device is broken, it will be replaced within two hours.
IT outsources the procurement, installation, delivery and maintenance of all devices to vendor ZZZ. The IT provides service desk, network, email, backups etc.
Now there are several customer facing service systems within one promise. The service desk and the device delivery are service systems under the service promise. Then there are also many supporting service systems like network, backup servers, device and software procurement which are not usually visible to the customer.
Good! So it looks like that it is possible to mix your PSA model and service portfolio modelling thinking successfully. PSA model provides nice framework to identify service type and purpose in service ecosystem. Service portfolio modelling enables concrete understanding how services can be defined in support tool as a configuration items or other service records.