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

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

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

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

---

Содержание

Что подготовить до внедрения Service Desk
Оцените зрелость сервисных процессов
Определите цели и метрики успеха
Выберите модель развертывания: облако или on-premise

Этапы внедрения Service Desk
Назначьте владельца системы и сформируйте команду проекта
Разработайте каталог услуг
Настройте SLA и приоритизацию заявок
Подключите каналы приема заявок
Запустите пилот на одной команде
Обучите сотрудников и пользователей
Наполните базу знаний

Первые 30 дней после запуска

Как масштабировать Service Desk

Service Desk для внутренней и внешней поддержки: в чём разница

Типичные ошибки при внедрении Service Desk

Главное

Частые вопросы

---

Что подготовить до внедрения Service Desk

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

Оцените зрелость сервисных процессов

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

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

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

Определите цели и метрики успеха

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

1. Обозначить метрики, по которым оценивается техподдержка.
2. Собрать их до запуска решения, даже если придется делать это вручную.
3. Задать периодичность их замера для отслеживания динамики.

Чаще всего сервисные процессы оцениваются по четырем ключевым метрикам.

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

Среднее время решения (Mean Time to Resolve — MTTR) — промежуток от регистрации обращения до его закрытия. Демонстрирует скорость работы сервисного подразделения. После автоматизации обычно уменьшается.

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

Индекс удовлетворенности пользователей (Customer Satisfaction — CSAT) — оценки, которые пользователи ставят сервисным сотрудникам после выполнения заявки. Способствует более разносторонней картине, так как скорость работы не всегда означает качество. И CSAT поможет это выявить. Запуск Service Desk обычно влечет за собой рост оценок получателей услуг.

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

Выберите модель развертывания: облако или on-premise

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

SaaS. Оптимально для компаний, не располагающих достаточными ИТ-мощностями. Им не понадобится дополнительное серверное оборудование. Облачная архитектура упрощает процедуры резервного копирования и обновлений. Выбирая этот вариант, важно убедиться, что серверы провайдера физически находятся на территории РФ, а сама платформа соответствует 152-ФЗ «О персональных данных» (в частности, требованиям к уровню защищенности ИСПДн).

On-premise. Развертывание во внутреннем контуре обязательно для организаций, деятельность которых регулируется требованиями о локализации данных и использования серверов внутри периметра компании. Субъекты критической информационной инфраструктуры (КИИ согласно 187-ФЗ), государственные органы, оборонные и стратегические предприятия могут выбрать только этот вариант. Локальное размещение позволяет полностью изолировать систему от внешних сетей и выполнить требования регуляторов (ФСТЭК, ФСБ) по защите информации.

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

Этапы внедрения Service Desk

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

Назначьте владельца системы и сформируйте команду проекта

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

Владелец продукта — это специалист, который понимает внутренние процессы техподдержки, отвечает за них и обладает полномочиями на изменения. В его интересах, чтобы Service Desk отвечал потребностям сервисной команды и делал ее работу эффективнее как в текущем моменте, так и в перспективе. Также в его ответственности взаимодействие со специалистами поддержки: обучение, профилактика сопротивления и саботажа перемен. Кроме того, именно владелец впоследствии развивает решение под новые потребности бизнеса.

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

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

Владельца продукта важно определить до старта проекта, так как он и специалисты поддержки выступают экспертами при внедрении и настройки системы.

Разработайте каталог услуг

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

Настройте приоритизацию заявок и SLA

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

Например, могут быть группы «Топ-менеджмент» и «Сотрудники офиса». Для каждой из них определяются графики поддержки различных услуг и ключевые метрики. Финансовому директору услуга «Удаленный доступ» будет доступна круглосуточно, а заявка на нее должна быть решена, допустим, за 10 минут. Тогда как сотрудник HR-подразделения может обратиться за ней только в рабочее время — с 9:00 до 18:00, и на выполнение его заявки по SLA дается два часа.

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

Чаще всего ключевыми показателями, которыми оперирует SLA, становятся:

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

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

Подключите каналы приема заявок

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

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

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

Запустите пилот на одной команде

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

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

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

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

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

Обучите сотрудников и пользователей

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

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

Наполните базу знаний

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

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

Первые 30 дней после запуска

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

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

Как масштабировать Service Desk

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

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

Формирование из Service Desk центра управления ИТ-ландшафтом компании. Для этого потребуется сформировать базу данных управления конфигурациями (CMDB) и интегрировать систему с решениями учета ИТ-активов и мониторинга. Это позволит максимально автоматизировать управление инцидентами: формирование заявок при обнаружении сбоев в ИТ-инфраструктуре и их наполнение данными о зафиксированными аномалиях и затронутых объектах. Это в разы ускорит их устранение и повысит стабильность бизнес-процессов.

Расширение ITSM-подхода на другие подразделения компании: АХО, бухгалтерию, HR, секретариат. Это позволит выстроить их работу на базе Service Desk в соответствии с сервисным подходом: учитывать обращения, замерять скорость обработки, учитывать и анализировать трудозатраты, повышать качество взаимодействия с пользователями. Важное следствие такого масштабирования — возможность выстраивать сложные сквозные услуги. Например, при выводе нового сотрудника оформлять не несколько заявок в разные отделы, а одну, которая автоматически отправится на задействованных исполнителей. Так формируется ESM-решение  — единое цифровое окно, через которое решаются все внутренние вопросы компании.

Service Desk для внутренней поддержки и внешней: в чем разница

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

Критерий	Внутренний сервис	Внешний сервис
Пользователи	Сотрудники компании, авторизованные во внутреннем контуре	Клиенты компании: для B2C — физические лица, для В2В — представители контрагентов
Каталог услуг	Включает внутренние сервисы, необходимые сотрудникам для выполнения своей работы, а также обеспечения бизнес-процессов	Техподдержка проданного товара и услуг, гарантийное обслуживание, консультирование
Договоры и ограничения	Зависит от роли сотрудника, группы пользователей, к которой он относится, и критичности услуги	В В2В зависит от индивидуальных контрактов и SLA, нарушения влекут штрафы. В В2С — от группы пользователей, которая, в свою очередь, обычно зависит от предоставляемой услуги
Каналы приема заявок	В приоритете обычно портал самообслуживания, корпоративная почта	Сайт, телефон, мессенджеры и соцсети
Ключевые метрики	Скорость решения заявок Доля обращений, закрытых в срок Стоимость обслуживания одного сотрудника	Время реакции Скорость закрытия обращения с первого раза Индексы лояльности и удовлетворенности клиентов

Service Desk можно использовать в обоих случаях. Более того, оба направления реально реализовать в рамках одного решения. Но не всегда. Все зависит от масштаба бизнеса и специфика процессов и услуг. Например, можно использовать одну систему, если есть сервисная преемственность: компания продает сложное ПО, оборудование, оказывает услуги интегратора. В этом случае внешние заявки могут требовать эскалации на внутренних ИТ-специалистов, и единая система автоматизации станет оптимальным решением.

Типичные ошибки при внедрении Service Desk

Рассмотрим частые ошибки, которые могут снижать эффекты внедрения Service Desk.

Отсутствие аудита процессов до старта проекта

Чем грозит. Проблемы не решатся, цели не будут достигнуты, добавится путаница при рабоЗавышенные метрики в SLAте с обращениями.

Как избежать. Перед внедрением регламентировать и задокументировать процессы, зоны ответственности, механизмы эскалации/

Завышенные метрики в SLA

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

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

Стремление запустить решение на максимальную функциональность

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

Как избежать. Запускать сначала базовый функционал, затем постепенно наращивать возможности и масштабировать систему.

Игнорирование человеческого фактора

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

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

Попытки решить все своими силами, не привлекая вендора

Чем грозит. Высокие затраты на самостоятельный поиск решений и доработки, а также риск «поломать» уже сделанные настройки в пользу новых.

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

Отношение к системе как к разовому статичного проекту с фиксированными результатами

Чем грозит. Система перестанет отвечать требованиям бизнеса и возникнут вопросы к ее окупаемости и эффективности.

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

Главное

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

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

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

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

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

Частые вопросы