Построение службы Service Desk: как сделать все правильно

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

Это так, но лишь отчасти. Несмотря на свои достоинства, Service Desk — это всего лишь инструмент, который не работает сам по себе. Чтобы он был полезен, его нужно правильно выбрать, настроить и применить. В этой статье расскажем, что требуется, чтобы знакомство с Service Desk прошло без разочарований и бессмысленных трат.

Как выбрать Service Desk

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

Практика Naumen показывает, что значительная часть проектов по внедрению Service Desk сталкивается с трудностями еще до старта. Как этого избежать, разберем подробнее.

Этап 1. Проведите внутренний аудит процессов

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

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

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

Экономическое обоснование. Если объем входящих обращений превышает пропускную способностью службы поддержки, Service Desk необходим. Если в компании работает десять человек, инвестиции в многофункциональную ИТ-систему не оправдаются.

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

Этап 2. Выберите способ развертывания

Обычно выбирают между двумя вариантами:

1. SaaS. Оптимально для компаний, не располагающих избыточными ИТ-мощностями. Компании не понадобится дополнительное серверное оборудование. Облачная архитектура упрощает процедуры резервного копирования и получения обновлений.
2. On-premise. Развертывание во внутреннем контуре обязательно для организаций, деятельность которых регулируется требованиями о локализации данных и использования серверов внутри периметра компании.

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

Этап 3. Определитесь с функциональностью

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

Система должна предоставлять готовый набор процессов, чтобы бизнес мог сразу начать работу. К нему относятся:

• управление инцидентами и сервисными запросами с контролем соблюдения SLA;
• каталог услуг с разными правилами маршрутизации;
• база знаний для ускорения сценариев самообслуживания и снижения нагрузки на поддержку.

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

Оцените расширенные функции, которые понадобятся по мере роста потребностей бизнеса: управление изменениями, управление конфигурациями и активами (CMDB).

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

Если Service Desk базируется на low-code платформе, кастомизировать функции получится без привлечения вендора. Это существенно снизит стоимость доработок и сократит время внедрения изменений.

Этап 4. Запустите пилотный проект

Перед окончательным выбором попробуйте протестировать решение на рабочих задачах.

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

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

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

Этап 5. Оцените окупаемость инвестиций в Service Desk

При оценке затрат следует принимать во внимание не только стоимость лицензий, но и сопутствующие расходы:

• стоимость внедрения;
• оплату дополнительных модулей;
• техническую поддержку и обновление версий;
• обучение персонала.

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

Как внедрить Service Desk в процессы

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

Грамотное внедрение строится на последовательности и постепенном наращивании сложности.

1. Разработать каталог услуг

Еще до подключения Service Desk нужно разработать прототип каталога услуг, на основе которого будут создаваться и распределяться заявки.

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

Первый этап для внутренней и внешней поддержки может отличаться. Внутренние ИТ-отделы заботятся обо всех сотрудниках компании без исключения, поэтому им не нужно разрабатывать правила по ограничениям в обслуживании. Внешним же, помимо каталога услуг, нужно проработать и гарантийные договоры. Их условия подскажут операторам, когда задачи выходят за рамки оговоренных объемов обслуживания.

2. Сохранить опыт и пополнять базу знаний

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

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

3. Обучить сотрудников

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

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

4. Подобрать метрики

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

Хорошо, когда процессы техподдержки относительно зрелые и время выполнения задач уже зафиксированы. Существующие правила можно перенести в систему вместе с каталогом услуг. Но некоторые SLA всегда можно улучшить.

На этапе внедрения Service Desk основными метриками для аналитики работы поддержки являются среднее время обработки заявки и удовлетворенность пользователей (индекс лояльности, или NPS). Время обработки можно оценить с помощью дашбордов или таймеров внутри запросов, а удовлетворенность — через проведение опросов при закрытии заявки.

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

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

4. Подумать о дальнейшем масштабировании

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

К последующим этапам также относится настройка сквозных взаимодействий. Системы класса Service Desk обладают достаточной функциональностью, чтобы в каталог добавить услуги других сервисных подразделений, например, бухгалтерии или АХО. В перспективе на базе связанных между собой процессов систему можно будет переработать в полноценный Центр обслуживания.

Как избежать ошибок при использовании Service Desk

Иногда к снижению эффективности от внедрения системы может привести неправильная эксплуатация. Например, специалисты продолжают обрабатывать заявки, как привыкли, не классифицируя их и не выявляя закономерности в запросах пользователей. Чтобы Service Desk был и оставался полезным инструментом, нужно:

Структурировать каталог — отсутствие структуры лишит Service Desk таких функций, как накопление и анализ данных, потому что разбирать кучу заявок без единой логики сложно и занимает много времени. Без проработанного каталога Service Desk превратится в еще один канал по приему заявок, но никак не облегчит работу техподдержки. Это будет таблица в Excel только в другом интерфейсе.

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

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

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

Главное

1. Выбор Service Desk начинается с внутреннего аудита. Оцените процессную зрелость и экономическую целесообразность автоматизации. Затем определите модель развертывания, необходимый минимум функциональных требований и потенциал масштабирования. Запустите пилотный проект на реальных задачах. Это позволит проверить удобство системы и качество поддержки вендора.
2. Запуск Service Desk начинается с разработки каталога услуг, развития базы знаний, обучения сотрудников и настройки метрик для контроля SLA. После того, как накопится достаточно данных, можно подключать ИИ. Впоследствии полученный опыт внедрения масштабируется на все сервисные подразделения компании.
3. Система приносит пользу только при структурированном каталоге услуг, регулярном развитии функциональности. При возникновении сложностей с доработками можно обратиться к вендору за консультацией. Ответственный за развитие системы со стороны команды поможет преодолеть сопротивление сотрудников при освоении новых инструментов.

Хотите узнать, как Service Desk улучшит вашу службы поддержки? Оставьте заявку на демо. Эксперты Naumen ответят на вопросы, помогут оценить текущие процессы и провести пилотный проект.