Стратегия импортозамещения Service Desk: что учесть при миграции

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

Какие причины дополнительно мотивируют компании к переходу на новую ITSM-систему

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

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

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

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

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

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

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

Что важно оценить до старта проекта миграции

Компании подходят к процессу миграции по-разному. Например, переносят данные вручную, импортируют через API или сторонние приложения. Прежде чем приступить к переносу накопленной информации в новый инструмент, потребуется оценить, какой вариант больше подходит под задачи конкретной организации. Обычно учитываются два фактора: объем и ценность данных.

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

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

Как организовать миграцию данных в ITSM-систему без потерь

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

Универсального алгоритма не существует. При этом миграция в новую систему службы поддержки обычно выполняется по следующему сценарию.

Разберем каждый этап подробнее.

Этап 1. Планирование

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

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

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

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

Этап 2. Подготовка

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

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

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

Этап 3. Проведение

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

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

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

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

Этап 4. Завершение

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

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

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

Подводя итоги

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