Мы решили поделиться опытом от внедрения этой непростой методологии внутри нашей компании и планируем написать ряд статей о том, как внедряем ITSM, какие сложности преодолеваем, и какие решения у нас есть. Надеемся, что статьи будут интересны IT-менеджменту.

Немного предыстории. Мы работаем в большом холдинге, основная деятельность которого: продажа медикаментов в рознице. Большинство IT-продуктов для управления холдингом разрабатываются в нем самом. Холдинг редко покупает программные продукты на стороне (если речь идет об автоматизации основных бизнес процессов компании)

У нас большой IT-департамент, который состоит из нескольких групп разработки, системных администраторов, архитекторов, Service desk, безопасников и т.д.

В определенный момент IT-департамент стал получать просто гигантское количество жалоб на работу ИТ-служб и после долгих обсуждений мы решили внедрять ITSM-подходы внутри компании. Мы провели анализ жалоб внутренних клиентов IT-департамента и выделили основные. Вот что получилось.

Пинг-Понг

У этой проблемы есть целый ряд названий: «Перекладывание ответственности», «Проблема не на моей стороне» и т.д.

Допустим, есть автоматизированное рабочее место кассира (ПО «Касса»). Программное обеспечение для данного рабочего места разработано внутри компании. В один прекрасный момент с ПО «Касса» происходит какой-то сбой, заводится инцидент, который отправляется в Service Desk.

Поскольку ПО «Касса» разрабатывается соответствующим отделом и сотрудники Service Desk не могут самостоятельно решить проблему, то Service Desk направляет инцидент в отдел разработки кассы.

ПО «Касса» работает на персональном компьютере, за который отвечает отдел системных администраторов. Увидев «проблему в железе» специалист из отдела разработки Кассы направляет инцидент в отдел системного администрирования.

Но не надолго, системный администратор не видит проблем в железе и возвращает инцидент обратно в отдел разработки. Образуется порочный круг, который приводит к затягиванию времени решения инцидента и финансовым потерям для бизнеса. В этот момент кассир не может продавать.



Пинг-Понг очень частое явление в сфере обслуживания. Хуже того часто Пинг-Понг приводит к межличностным конфликтам.

Плохое информирование

Другая проблема, с которой мы столкнулись — плохое информирование клиента ИТ департамента. Информирования может не быть совсем, оно может быть несвоевременным, могут информировать не всех кого нужно и т.д.

Отсутствие проактивного информирования об устранении инцидента, то это почти всегда вызывает гнев внутренних клиентов IT-департамента.

Например, происходит массовый инцидент с ПО «Касса», который затрагивает все точки продаж (аптеки в нашем случае). В одной из аптек инцидент заметили раньше и сообщили об этом в Service Desk. Service Desk понял массовость инцидента, но забыл сообщить об этом всем заинтересованным лицам. Как минимальное последствие — шквал звонков на 1-ую линию поддержки.

Необходимость объяснять проблемы дважды

Почти любого клиента дико бесит, когда приходится объяснять проблемы дважды. Как данная проблема проявлялась:

1. Внутренний клиент ИТ департамента сообщает о проблеме в Service Desk.
2. Сотрудник Service Desk принимает проблему и начинает заниматься ее устранением.
3. Внутренний клиент начинает нервничать, поскольку не получает информации о ходе решения инцидента.
4. Внутренний клиент повторно звонит в Service Desk и попадает на другого сотрудника, который не в курсе проблемы.
5. Следует вопрос «А в чем у вас проблема?»
6. Внутренний клиент IT-департамента в гневе.

Неправильная приоритезация инцидентов

Неправильная приоритезация — это еще одна банальная проблема, которую приходится решать в рамках внедрения проекта.

Два одинаковых инцидента поступают с разных торговых точек. У торговой точки по ул. Русская товарооборот в разы превышает торговую точку в п. Врангель. Инцидент из Врангеля поступает раньше и делаться будет раньше, поскольку сотрудник Service Desk тупо не в курсе финансовых показателей торговых точек. Как следствие, появляется очередь устранения инцидентов, не отвечающая интересам бизнеса.

Решение

Что мы реализовали, чтобы решить эти проблемы.

Первое, самое важное и банальное — сделали каталог IT-услуг. Мы распутали комок непонятного IT-сервиса, сделав его прозрачнее для заказчика и для себя.



То в каких жестоких обсуждениях проходил этот этап — тема отдельной статьи. Скажу только, что на это ушло около месяца времени и помимо разделения услуг, мы выкинули часть из них, а также узнали много нового о том, как и какие услуги мы оказываем бизнесу.

Пинг-Понг. Решение

Решение приняли административно-техническое, оно со скрипом и сопротивлением дает свой результат.

За каждой услугой закрепили единого ответственного. Даже если услуга составная. Например, ПО «Касса» зависит от сети передачи данных, рабочей станции и т.д.



Единая ответственность сама по себе исключает пинг-понг, но порождает недовольство и внутреннее сопротивление: «Почему я должен отвечать за работу админов».



На самом деле здесь все очень просто. Кто-то предоставляет услугу, кто-то ее потребляет. Потребителю услуги наплевать на то, по каким причинам услуга не предоставляется. Потребитель хочет услугу, за которую заплатил виртуальные деньги.

Сотрудники большинства отделов, которые обслуживают внутренних клиентов (пользователей) не понимают, что разница между внутренним и внешним клиентом с точки зрения обслуживания невелика.

Технически, ответственный за услугу может контролировать инциденты по его услуге, которые решаются не в его отделе, а также имеет право перенаправить инциденты, идущие на проверку, через себя.

Плохое информирование. Решение

Административно мы закрепили ответственность за информирование на обслуживающем подразделении линии, которая устранят инцидент.

Также мы закрепили принципы информирования (как часто и кто должен) в едином документе, регламентирующем принципы обслуживания внутренних клиентов. Мы назвали его “Домострой 1-ой и 2-ой линии поддержки” (про этот документ я планирую рассказать в других статьях)

Сотрудник должен информировать клиента в рамках инцидента. Для этого мы реализовали кнопку «Информировать», которая может отправлять сообщения сразу по нескольким каналам и логирует отправленные сообщения в инциденте.



По логу сообщений можно анализировать и разбирать проблемы информирования, наказывать невиновных и награждать не участвующих.

Необходимость объяснять проблемы дважды. Решение

Решение придумали, но пока не реализовали.

Решение банальное, которое заключается в том, что до момента взятия трубки сотрудником Service Desk, система должна выявлять автора звонка и подготавливать открытые инциденты, по которым может звонить автор.
Ну и конечно прикреплять аудио запись первого звонка к инциденту.

Ждем внедрения новой ip-телефонии и сразу будем делать интеграцию с нашим Service Desk.

Неправильная приоритезация инцидентов. Решение

Мы реализовали возможность создавать скрипты влияния в нашей системе. Скрипт представляет собою дерево вопросов, на которые должен ответить сотрудник Service Desk, классифицируя инцидент.

Каждый скрипт прикрепляется к услуге.

Скрипты разрабатывают и администрируют сотрудники 2-ой линии поддержки. Именно эти сотрудники обладают нужными компетенциями и большей заинтересованностью в правильной приоритезации инцидентов.

Вот пример скрипта:



Сотрудник 1-ой линии, классифицируя инцидент, прощелкивает скрипт.



Скрипт помогает определить влияние инцидента на конкретную услугу. Приоритет инцидента определяется из сочетания влияния и срочности (в лучших традициях ITSM).



Срочность в нашей системе является постоянной для услуги величиной. Чем сильнее услуга лежит на основном продающем бизнес процессе компании, тем выше у нее срочность.

Послесловие

Все эти решения дают свой результат. Больше всего трудностей в организации внедрения, принятии подходов самими сотрудниками.

В следующих статьях я планирую более глубоко погрузится в ITSM подход и в его реализацию в нашем программном обеспечении. Есть несколько тем, которые я хотел бы описать. Буду рад, если вы подскажите мне, что бы было вам более интересно. Вот темы:

• Проблемы взаимодействия линий поддержки и их решение.
• Каталог услуг.
• Организационные изменения при внедрении ITSM.
• Интерфейс инцидента.
• Мотивация сотрудника 1-ой линии поддержки.
• Жизненный цикл инцидента.

Подарки

Презентация

Перед началом внедрения ITSM мы собрали всех заказчиков и устроили им небольшую презентацию проекта. Презентация получилась шикарная, все на момент очутились в счастливом будущем. Возможно она будет полезна тем, кто собирается внедрять ITSM у себя в компании. Поэтому держите ссылку на слайды:

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

Скидка

Мы довольно давно и успешно продаем наши решения. Они славятся низкой стоимостью и гибкостью настройки. Скидка в 30% будет действовать до 21 ноября.

» Взять demo-версию плагина Service Desk

Всем спасибо!