Гайд: как подготовиться к замене сервис деск, чтобы мигрировать спокойно и без хаоса

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

Шаг 1. Определите объем ресурсов для запуска новой системы 

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

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

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

Шаг 2. Выделите процессы и исполнителей

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

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

Шаг 3. Проанализируйте плюсы и минусы текущего сценария применения системы

Здесь потребуется оценить все текущие кейсы использования системы и ее связь с другими ИТ-сервисами и ПО в компании. После оценки степени критичности таких взаимосвязей в новый инструмент автоматизации лучше переносить только актуальное.

Шаг 4. Отберите шорт-лист требований

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

К основным отнести:

• ПО российского разработчика;
• внедрение по модели SaaS;
• безопасность данных;
• удобный UX/UI для пользователя.

Среди функциональных:

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

Шаг 5. Проведите аналитику рынка разработчиков ПО соответствующего класса систем

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

Затем переходите к формированию шорт-листа. Базой для этого может стать:

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

Шаг 6. «Пощупайте» продукты на практике

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

Также лучше уточнить, сколько можно бесплатно тестировать ПО. Сам процесс оптимально построить так:

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

Далее составьте сводную таблицу, где распишите по вертикали основные требования к  системе, по горизонтали — список разработчиков ПО, на пересечении — оценку по пятибалльной шкале. Далее выберите 2-3 системы, которые наберут максимальный балл.

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

Шаг 7. Набросайте оптимальный сценарий миграции данных

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

Помимо этого, обеспечьте работоспособность старой ITSM-системы, пока не мигрировали. Бывает, что не все данные получается перенести сразу, а значит какое-то время саппорту придется работать в текущем заменяемом инструменте.

Шаг 8. Организуйте постепенный переезд

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