We decided to share experience from the implementation of this complex methodology within our company and plan to write a series of articles on how to implement ITSM, what difficulties we overcome, and what solutions we have. We hope that the articles will be of interest to IT-management.

A little background. We work in a large holding whose main activity is the sale of medicines in retail. Most IT-products for the management of the holding are developed in him. A holding rarely buys software on the side (when it comes to automating the company's core business processes)

We have a large IT department, which consists of several development groups, system administrators, architects, Service desk, security guards, etc.

At some point, the IT department began to receive a huge number of complaints about the work of IT services, and after long discussions we decided to implement ITSM approaches within the company. We analyzed the complaints of internal customers of the IT department and identified the main ones. That's what happened.
')

Ping pong

This problem has a number of titles: “Shifting responsibility”, “The problem is not on my side”, etc.

Suppose there is an automated workplace cashier (ON "Cashier"). Software for this workplace is developed within the company. At one fine moment, some kind of malfunction occurs with the “Cashier” software, an incident is started up, which is sent to the Service Desk.

Since the Cashier software is developed by the relevant department and the Service Desk staff cannot solve the problem on their own, the Service Desk sends the incident to the cash register development department.

ON "Cashier" works on a personal computer for which the department of system administrators is responsible. Having seen the “problem in hardware”, a specialist from the Cashier’s development department sends the incident to the system administration department.

But not for long, the system administrator sees no problems in the hardware and returns the incident back to the development department. A vicious circle is formed, which leads to a delay in solving the incident and financial losses for the business. At this point, the cashier can not sell.



Ping Pong is a very frequent phenomenon in the service sector. Worse, often Ping Pong leads to interpersonal conflicts.

Bad information

Another problem we faced is poor information of the IT department's client. Information may not be at all, it may be untimely, may not inform all of whom you need, etc.

The lack of proactive information about the elimination of the incident, it almost always causes the anger of the internal customers of the IT department.

For example, there is a massive incident with PO Cashier, which affects all points of sale (pharmacies in our case). In one of the pharmacies, the incident was noticed earlier and reported to the Service Desk. The Service Desk understood the mass character of the incident, but forgot to report it to all interested parties. As a minimal consequence - a flurry of calls to the 1st line of support.

Having to explain problems twice

Almost any client is wildly annoyed when they have to explain problems twice. How this problem manifested itself:

1. An internal IT department client reports a problem to the Service Desk.
2. Service Desk employee accepts the problem and begins to deal with it.
3. The internal client starts to get nervous, because it does not receive information about the progress of the incident.
4. Internal client re-calls the Service Desk and gets on another employee who is not aware of the problem.
5. Follows the question "What is your problem?"
6. An internal client of the IT department in a rage.

Incorrect incident prioritization

Improper prioritization is another common problem that has to be solved as part of project implementation.

Two identical incidents come from different outlets. At the outlet on the street. Russian trade turnover exceeds the point of sale in Wrangel. The Wrangel incident comes earlier and will be done earlier, because the employee of the Service Desk is stupidly not aware of the financial performance of the outlets. As a consequence, there is a turn to eliminate incidents that do not meet the interests of the business.

Decision

What we have implemented to solve these problems.

The first, most important and banal - made a catalog of IT-services. We have unraveled a lump of incomprehensible IT-service, making it more transparent for the customer and for ourselves.



So in what cruel discussions this stage took place - the topic of a separate article. I can only say that it took about a month of time and in addition to the separation of services, we threw out some of them, and also learned a lot about how and what services we provide to business.

Ping pong. Decision

The decision was made administratively-technical, it with a creak and resistance gives the result.

For each service secured a single responsible. Even if the service is composite. For example, the software "Cashier" depends on the data network, workstation, etc.



The single responsibility excludes ping-pong by itself, but causes discontent and internal resistance: “Why should I be responsible for the work of the admins.”



In fact, everything is very simple here. Someone provides a service, someone consumes it. Consumer services do not care about the reasons for which the service is not provided. The consumer wants a service for which he paid virtual money.

Employees of the majority of departments that serve internal customers (users) do not understand that the difference between internal and external customers in terms of service is small.

Technically, the person responsible for the service can monitor incidents for his service, which are not decided in his department, and also has the right to redirect incidents going to the test through him.

Bad information. Decision

Administratively, we assigned responsibility for informing the service unit of the line, which will eliminate the incident.

We also consolidated the principles of informing (how often and who should) in a single document regulating the principles of servicing internal customers. We called it “Domostroy 1st and 2nd line of support” (I plan to tell about this document in other articles)

The employee must inform the customer in the context of the incident. To do this, we have implemented the “Inform” button, which can send messages through several channels at once and logs the sent messages in the incident.



The message log can analyze and analyze information problems, punish the innocent and reward those not involved.

Need to explain problems twice. Decision

The decision came up, but not yet implemented.

The solution is banal, which is that until the service desk employee picks up the phone, the system should identify the author of the call and prepare open incidents the author can call.
And of course to attach the audio recording of the first call to the incident.

We are waiting for the introduction of new ip-telephony and we will immediately do the integration with our Service Desk.

Incorrect incident prioritization. Decision

We implemented the ability to create influence scripts in our system. The script is a tree of questions to which the employee of the Service Desk should answer, classifying the incident.

Each script is attached to the service.

Scripts are developed and administered by the staff of the 2nd support line. It is these employees who possess the necessary competencies and greater interest in the proper prioritization of incidents.

Here is an example script:



The employee of the 1st line, classifying the incident, clicks the script.



The script helps to determine the impact of the incident on a particular service. The priority of the incident is determined from the combination of influence and urgency (in the best traditions of ITSM).



Urgency in our system is constant for the service value. The stronger the service is on the company's main business process, the higher its urgency.

Afterword

All these solutions give their results. Most of all difficulties in the organization of implementation, the adoption of approaches by the employees themselves.

In the following articles, I plan to more deeply immerse myself in the ITSM approach and its implementation in our software. There are several topics I would like to describe. I would be glad if you tell me what would be more interesting for you. Here are the topics:

• Interaction problems of support lines and their solution.
• Service Catalog.
• Organizational changes in the implementation of ITSM.
• Interface incident.
• Motivation employee 1st line of support.
• The life cycle of the incident.

Presents

Presentation

Before the start of ITSM implementation, we gathered all the customers and gave them a small presentation of the project. The presentation turned out gorgeous, all at the time found themselves in a happy future. Perhaps it will be useful to those who are going to implement ITSM in their company. Therefore, keep a link to the slides:

docs.google.com/presentation/d/18m_SzZ7C8Dbkypncp7-sKZLQeGYkZ9PuKbxEp2QIVU0/edit?usp=sharing

A discount

We have been selling our solutions for a long time and successfully. They are famous for low cost and flexibility of customization. The 30% discount will be valid until November 21.

» Get the demo version of the Service Desk plugin

Thanks to all!