ITSM. What we understand about services

As was clear from the previous article “Four defects of service”, we are actively implementing ITSM approaches in our company. Today, I would like to talk about how the introduction of ITSM in a company usually begins - about the service catalog.



Distinguishing services was not an easy task and we faced a lot of difficulties:

• Can I take a software package for an IT service or not?
• How to single out a single person if the service is composite and supported by two software packages?
• How to determine by what service to register the incident, if the IT infrastructure as a whole collapsed and almost all services are not provided.

Here are the principles we follow when allocating any service:

• Any service must have a single person in charge who is fully responsible for its quality (timely elimination of incidents, availability, etc.)
• The name and description of the service must be understandable to the end user (internal client) and the service must provide clear value.
• A valid service must support at least one business process.

Let's analyze these principles in a little more detail and understand how they will help us to properly allocate services. Yes! I just want to warn you that these are our principles and we do not insist on their applicability in all organizations. I personally saw several catalogs of services that are not subject to these principles.

')

Any service must have a single person in charge who is fully responsible for its quality.

Logically everything seems to be clear. If there is no one responsible, then the problem of loss of responsibility and the subsequent ping-pong in eliminating incidents, about which I wrote in the last article, are not excluded.



But how to determine the responsible for the composite service. For example, there is a service U1, the essence of which is to provide an interface to a specific set of data. There is software P1, which is developed by the department O1. Software P1 only displays the data provided within the framework of the U1 service for all company employees. All data for software P1 is provided by software P2, which is developed by the O2 department.



Who is the one responsible for the service U1?



We decided for ourselves that we have an interface principle of determining responsibility.



What does it mean?

Interface principle of determining responsibility

Responsible for the service = responsible for the application in which the internal client consumes the service.



Why? Because the client should not understand the internal architecture of the service. The client consumes the U1 service using the P1 program interface and if something is wrong with the service, the image of the employee responsible for the P1 program will suffer (the image of the P1 program). And here it does not matter that 80% of the problems with the data in the P1 program are related to the fact that the P2 program does not properly upload data.



Responsibility for the service is on who is responsible for the final presentation of the data and its task to interact with the person responsible for the application P2 so that the perceived quality of its service does not suffer.

The name of the service should be clear to the end user and reflect the value that the client understands.

With the first part, everything should be clear. You need to communicate with the client in a language that he understands, in general. And in particular, to call the services as they will be clear to the client.



Do not use data transfer protocol names and similar technical terms in service names.



For example, instead of the “Message transfer via XMPP” service, it is better to use the “Instant messaging service”



Once I discovered a manual on physical practice and in the second paragraph I read the following:



“The holes injected into the base must diffuse towards the collector”



It should be easier and then it will be clearer.



From the name of the service to the client should be clear value. For example, the service “Automation of cash transactions” carries a value that the client understands. And the service “Data Network” is not. It is not clear what the value of such a service is for an ordinary ordinary user. Why should he send data!? What value will he get!?



ITIL rather strictly defines the concept of value:





The service “Automation of cash transactions” provides performance, the service “Receive applications on the website” eliminates restrictions (the need to physically be present at a point of sale). The “Data Network” service is not understandable to an ordinary user and therefore does not carry value for it. But it carries value for an IT professional who understands this value.



This principle saves us from listing the services of what should not be there: internal services (such as LANs, virtual servers, etc.)



I recently visited nalog.ru and saw that in order to get a tax deduction, you need to consume the “Fill in the 3NDFL certificate” service, this service does not carry value. Firstly, the term 3NDFL is accounting and incomprehensible, and secondly it is completely unclear what the value of the service is. But the service “Return 13% of the amount of medical expenses” would be valuable.

A valid service must support at least one business process.

Again, everything is logical. If the service does not support the business process, then the business does not need it. And in the service catalog it does not belong.



It is this principle that led us to the idea that, in the most general case, the software package cannot be mistaken for an IT service. The software package can be replaced by another software package, while the service remains unchanged. For example, the “Telephony” service supports business processes in a call center. When replacing one hardware-software complex of ip-telephony with another, the service should not change. Therefore, we have no “Oktell IP telephony” service.



The same principle helps us understand when different IT services should be distinguished in the same software.



If different logical modules of the same application support different business processes, then the services should be different.



For example, there is an RM + application that implements various aspects of a company management: Efficiency calculation and payroll accrual, Planning, Service Desk, etc.



Different modules of the RM + application support different business processes of the company. Therefore, the services are different.





On the other hand, there is an e-mail service that also supports the most diverse business processes of a company, but at the same time, it is impossible to select logical modules in the service that would support various business processes. The whole business process needs the same email functionality.





Therefore, in this case, we have one service - “E-mail”.



There is one more 4th principle, about which I clearly did not write at the beginning of the article.

If a piece of infrastructure has collapsed, then incidents need to start for those services that the client can not consume at the moment.

Let us take an example of what this means.



Suppose a client consumes three services: Service 1, Service 2, Service 3. All three services directly depend on the internal service: “Network data transfer” (this service is not in the user's services catalog).



Let's say something happens to the root switch. The internal service “Data Network” is no longer available. Following it, services from the service catalog are no longer provided: Service 1, Service 2, Service 3.



End customers do not know anything about the “Data Network” Service. All three services from the service catalog currently do not work. On which service should the Service Desk get an incident from the end customer, on which service should the SLA rules for incident resolution, etc., be applied?





Our answer: According to the one that he wants right now, but the client cannot consume even internally, about which the client does not know anything. In this case, the services: "Service 3" and the internal service "Data Network". If the rest of the client’s services do not work, but he does not try to use them, then incidents can be avoided.



This is all that I would like to share in this article. Hope you enjoyed it. Thank!

Some gifts

A 20% discount on the Service Desk plugin, which will help to provide services according to the ITSM approach in your company, and also implements many other useful things.



The discount is valid for 3 weeks.



Our Redmine plugins are used worldwide and are renowned for their flexibility and low cost.