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

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

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

Как выбрать подходящий инструмент

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

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

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

Определиться со способом размещения. Обычно рассматривают два варианта размещения системы — в облаке или внутреннем контуре компании. Для небольших предприятий облако будет лучшим решением, так как не потребует привлечения дополнительных ресурсов команды и средств для развертывания ИТ-инфраструктуры.

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

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

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

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

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

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

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

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

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

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

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

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

Разработать каталог услуг. Перед тем, как запускать Service Desk в свой «огород», в нем необходимо прибраться. Если команда сама не знает, кто за какие задачи отвечает, внедрение нового инструмента не решит их проблем. Еще до подключения Service Desk нужно разработать прототип каталога услуг, на основе которого будут создаваться и распределяться заявки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

К выводам

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

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

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