How we implement ITSM. Four vices of service


    We decided to share our experience from implementing this difficult 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 interesting to IT management.

    A bit of background. We work in a large holding, the main activity of which is the sale of medicines in retail. Most IT products for managing a holding are developed within it. Holding rarely buys software products 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 desks, security guards, etc.

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

    Ping pong


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

    Suppose there is an automated workplace for a cashier (PO Kassa). The software for this workplace is developed internally. At one fine moment, some kind of malfunction occurs with the Kassa software, an incident starts, which is sent to the Service Desk.

    Since the Kassa software is developed by the appropriate department and Service Desk employees cannot solve the problem on their own, Service Desk sends the incident to the cashier development department.

    Kassa software runs on a personal computer, for which the department of system administrators is responsible. Seeing a “problem in the hardware”, a specialist from the Cashier’s development department directs the incident to the system administration department.

    But not for long, the system administrator does not see problems in the hardware and returns the incident back to the development department. A vicious circle forms, which leads to a delay in solving the incident and financial losses for the business. At this moment, the cashier cannot sell.



    Ping Pong is a very common occurrence in the service industry. Even worse, Ping-Pong often leads to interpersonal conflicts.

    Poor information


    Another problem we encountered was poor informing of the IT department client. Information may not be at all, it may be untimely, may not inform everyone who needs it, etc.

    The lack of proactive reporting of the elimination of the incident, this almost always causes the anger of the internal customers of the IT department.

    For example, there is a massive incident with the Kassa software, 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. Service Desk understood the mass incident, but forgot to inform all interested parties about it. As a minimal consequence - a flurry of calls to the 1st support line.


    The need to explain problems twice


    Almost any client is furious 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. A Service Desk employee accepts the problem and begins to fix it.
    3. The internal client begins to get nervous, because he does not receive information about the progress in resolving the incident.
    4. The internal client calls the Service Desk again and gets to another employee who is not aware of the problem.
    5. The question is, “What is your problem?”
    6. The internal customer of the IT department is angry.



    Incorrect prioritization of incidents



    Improper prioritization is another commonplace problem that has to be addressed as part of the implementation of the project.

    Two identical incidents come from different outlets. At the outlet on the street. Russian commodity circulation is many times greater than the outlet in Wrangel. The Wrangel incident arrives earlier and will be done sooner, since a Service Desk employee is stupidly unaware of the financial indicators of outlets. As a result, there is a queue to eliminate incidents that does not meet the interests of the business.



    Decision



    What we have implemented to solve these problems.

    First, most important and commonplace - made a catalog of IT-services. We unraveled a clump of incomprehensible IT service, making it more transparent for the customer and for ourselves.



    That in what cruel discussions this stage took place is the topic of a separate article. I can only say that it took about a month of time, and in addition to sharing 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 by the administrative-technical, it gives a result with a creak and resistance.

    Each service has a single responsible person. Even if the service is integral. For example, Kassa software depends on a data network, workstation, etc.



    A single responsibility in itself excludes ping-pong, but it gives rise to discontent and internal resistance: "Why should I be responsible for the work of admins."



    In fact, everything is very simple. Someone provides a service, someone consumes it. The consumer of the service does not give a damn about why the service is not provided. The consumer wants the service for which he paid virtual money.

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

    Technically, the person responsible for the service can control incidents on his service that are not resolved in his department, and also has the right to redirect incidents that are being checked through himself.



    Poor information. Decision



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

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

    employee must inform the client as part of the incident. To do this, we have implemented the “Inform” button, which can send messages via several channels at once and logs sent messages in an incident.



    According to the message log, you can analyze and analyze the problems of informing, punish the innocent and reward non-participants.

    The need to explain the problem twice. Decision


    They came up with a solution, but have not yet implemented it.

    The solution is banal, which consists in the fact that prior to picking up the call by a Service Desk employee, the system must identify the call author and prepare open incidents that the author can call.
    And of course, attach the audio recording of the first call to the incident.

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

    Incorrect prioritization of incidents. Decision


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

    Each script is attached to the service.

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

    Here is an example script:



    A 1st line employee, classifying the incident, clicks on the script.



    The script helps 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 a constant value for the service. The stronger the service lies in the company's main business-selling process, the higher its urgency.



    Afterword



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

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

    • Problems of interaction of support lines and their solution.
    • Catalog of services.
    • Organizational changes in the implementation of ITSM.
    • Interface incident.
    • Motivation of the employee of the 1st support line.
    • The life cycle of an incident.


    Gifts




    Presentation


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

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

    A discount


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

    » Get a demo version of the Service Desk plugin

    Thank you all!

    Also popular now: