Миграция на отечественное решение управления ИТ-услугами (IT Service Management, ITSM) — не просто замена одной системы на другую, а куда более сложный и трудоемкий процесс. Опрошенные CNews Analytics разработчики сходятся во мнении, что потенциальный успех миграции определяется не сколько широкой функциональностью самого продукта, столько готовностью заказчика к изменениям и четкостью выстроенных сервисных процессов внутри организации.
1. Выбор решения в пользу платформы
Один из ключевых этапов любого проекта по переходу с одного решения на другое — как раз-таки выбор этого решения. При изучении предложений на рынке стоит обращать внимание на ряд критериев.
Лидеры отрасли отмечают, что смотреть нужно, в первую очередь, на архитектуру и экономику изменений, которые должны произойти после внедрения ITSM-системы. У решения должна быть единая модель данных, открытые API, понятные механизмы интеграции с другими системами и несколько уровней кастомизации — от настройки силами администратора до разработки сложной логики. Что касается разработчика ИТ-решений, то здесь ключевое — наличие обширной базы кейсов, в особенности для крупных корпоративных заказчиков.
«Не менее важна прозрачность лицензирования: заказчик должен понимать стоимость не только первого контура ITSM, но и подключения ESM-процессов, новых пользователей, интеграций и развития в горизонте нескольких лет. Импортозамещение в этом смысле — редкая возможность пересобрать сервисную модель на более устойчивой основе», — отмечает Андрей Вишняков, директор по бизнес-продуктам компании SimpleOne.
Топ-10 российских поставщиков ITSM-систем
Агентство CNews Analytics сравнило выручку крупнейших игроков отечественного рынка решений по управлению ИТ-услугами предприятия
Выбор ITSM-системы также начинается с понимания того, куда движется бизнес, и какую роль в этой траектории играет ИТ-подразделение. Важно четко понимать, нужна ли платформа только для ИТ-процессов или планируется перевод на сервисную модель и других бизнес-функций. В таком случае система становится не просто инструментом поддержки, а сквозным механизмом операционного контроля, который объединяет все внутренние службы вокруг клиентоориентированной модели.
«В текущих реалиях лучше рассматривать платформенные решения, либо продукты с высоким интеграционным потенциалом — то, что не используется сегодня, наверняка понадобится завтра, ведь процессы в организации развиваются, а потребности растут. Использование единого или тесно интегрированного решения позволяет усилить эффекты от внедрения — данные из одних процессов (например, управления инфраструктурой и инвентаризации) усиливают другие (например, управление проектами), создавая сквозной конвейер данных и площадку для взаимодействия различных подразделений ИТ-службы», — уверен Никита Кардашин, руководитель практики комплексной цифровизации процессов, Naumen.
2. Кибербезопасность: универсального набора мер не существует
При выборе платформы аспект, требующий отдельного внимания, — обеспечение информационной безопасности. Об этом стоит позаботиться еще до старта проекта миграции.
Вопрос информационной безопасности не решается установкой одного дополнительного средства защиты. Ряд инструментов уже должны быть вшиты в сам продукт. Речь идет о системе контроля версий, ролевой модели, разграничении доступа, аудите действий, безопасной работе с API, интеграции с корпоративными механизмами идентификации.
Если выходить за рамки базового списка, то набор ИБ-мер определяется потребностями конкретной организации. На это влияет критичность данных, требования к развертыванию, число внешних систем и характер обрабатываемой информации.
«Необходимо оценивать соответствие требованиям внутренней политики безопасности, возможности разграничения доступа, аудита действий пользователей, защиты корпоративных данных, безопасной интеграции с корпоративным ИТ-ландшафтом, маскирования коммерческой информации в заявках и обезличивания данных при использовании на разных контурах. Универсального набора не существует: для одних организаций будет достаточно встроенных механизмов платформы, для других потребуется комплекс специализированных решений. Главное, чтобы безопасность была встроена в архитектуру системы и не мешала развитию процессов, не блокировала, а поддерживала и усиливала их», — полагает Наталья Буйлина, лидер ITSM-стрима платформы «Сфера» ИТ-холдинга «Т1».
3. Подготовка к пилоту: реинжиниринг процессов
Перед внедрением любого цифрового инструмента в контур необходимо пройти несколько этапов подготовки. Во многом именно они в будущем определяют эффективность проекта. Опрошенные CNews Analytics эксперты выделяют следующие:
- Аудит текущих процессов
- Определение ответственных как в технологической (архитектурной), так и в процессной части
- Проектирование целевой модели процессов
- Оценка и «инвентаризация» доработок, выполненных в существующей системе
- Инвентаризация интеграций. Оценка интеграционных потоков, их сложности, необходимости корректировки при переходе на новую систему
- Определение объема, источников и качества данных, подлежащих миграции
- Подготовка инфраструктуры
«Важный шаг при подготовке пилота, о котором часто не думают, — реинжиниринг процессов. При переходе на новое ITSM-решение у компании появляется уникальная возможность пересобрать процессы, убрав «исторически сложившиеся» схемы, которые уже не приносят результат, и наперед продумать будущие изменения. Главнейший шаг для формирования ядра сервисного подхода — каталог услуг. Для его создания надо идентифицировать и описать услуги, которые предоставляет ИТ-департамент, и определить, кто отвечает за их качество», — добавляет Елена Колбей, руководитель практик ITAM и ITSM компании «К2Тех».
4. Пилот: проверка не решения, а контура заказчика
Ключевой этап перед непосредственным внедрением решения — пилотный запуск. Большинство разработчиков ITSM-систем полагают, что без тестового периода переходить сразу к миграции на новой продукт чревато. При этом они обращают внимание на то, что пилот — это проверка не работы платформы, а самого заказчика, его готовности перестроиться и работать с уже новой системой.
«По нашим проектам внедрения мы видим, что при возникновении проблем во время пилота в 90% случаях виноват не инструмент, а неправильные ожидания и плохо спроектированные процессы. Основные сложности миграции связаны не с самой системой, а с особенностями процессов, интеграций и данных. Именно поэтому пилот позволяет выявить большинство организационных и технических рисков до промышленного запуска, существенно снижая вероятность простоев после масштабирования решения на всю компанию», — обращает внимание Наталья Буйлина, лидер ITSM-стрима платформы «Сфера», ИТ-холдинга «Т1».
Пилотный запуск лучше строить на ограниченном, но содержательном контуре. Проще всего оценить сервисный подход и автоматизацию на распространенных типовых услугах, таких как выдача доступа, справок от отдела кадров, оплата счета. Постепенный запуск поможет выявить проблемы до тиражирования, уточнить архитектурные решения и подготовить пользователей к переходу без резкого отключения прежней системы.
«Мы всегда рекомендуем начинать с нескольких процессов, где «болит» сильнее всего. Когда сотрудники видят быстрый и осязаемый результат — например, заявка стала обрабатываться быстрее, исчезли дубли или появился понятный статус, — они начинают доверять системе. Это доверие становится фундаментом для следующего этапа. Постепенно вовлекаются другие подразделения, и шаг за шагом компания переходит к полноценной сервисной модели управления», — уверен Лев Ройзенберг, директор по управлению продуктами ИТ-экосистемы «Лукоморье».
При этом многие, но не все ИТ-поставщики считают, что при интеграции ITSM требуется пилотный запуск. В некоторых ситуациях можно обойтись и без него, ограничиваясь классической предпроектной подготовкой.
«Пилотирование имеет смысл в случаях, когда нет уверенности, что предлагаемая технология, обычно инновационная, решит задачу, имеющуюся у бизнеса, и позволит достичь целевого результата. ITSM — технология не новая, золотой стандарт внедрения подобных систем давно выработан индустрией, и на рынке есть достаточно зрелых прикладных решений. Пилотировать зрелые продукты, имеющие большой список успешных внедрений, смысла нет — это пустой перерасход ресурсов внутренней команды и затягивание сроков проекта», — считает Никита Кардашин, руководитель практики комплексной цифровизации процессов компании Naumen.
5. Ввод в эксплуатацию: почему на этом все не заканчивается
Как только во время пилота удалось «удалить» все ошибки, новая система стартует в контуре заказчика. При этом сам факт миграции не означает завершение проекта. Чаще всего после того, как система показала свою эффективность и интегрировалась в ИТ-ландшафт, заказчик начинает строить планы по масштабированию решения.
Стратегию развития стоит строить не вокруг внедрения новых модулей, а вокруг бизнес-приоритетов. К примеру, если аналитические сведения говорят о том, что основная сложность — длительное восстановление сервисов, то логично развивать процессы управления проблемами и авариями.
Чтобы ITSM-платформа не превратилась в статичный справочник заявок, а стала ядром цифровой экосистемы компании, стратегию масштабирования необходимо выстраивать на основе объективных данных, архитектурных возможностей платформы и бизнес-целей, считает Николай Панов, директор по развитию бизнеса ГК «ИТ Эксперт».
Опираться следует на следующие ключевые направления:
Данные о реальном использовании системы
- Анализ обратной связи от пользователей
- Метрики качества процессов
- Тепловые карты сервисов
Модель внутреннего взаимодействия
- Управление бэклогом
- Быстрая обратная связь как драйвер обновлений
- Моделирование и тестирование гипотез
Организационная зрелость
- Постоянная оценка модели зрелости процессов, имплементированная непосредственно в повседневные практики
- Непрерывный контроль и совершенствование сервисных процессов
Выбор российской ITSM-системы — это стратегическое решение, которое не сводится к сравнению функциональных модулей, а требует оценки архитектурной гибкости, экономики изменений и встроенных механизмов безопасности. Успех миграции во многом зависит не от самого инструмента, а от качества предпроектной подготовки, реинжиниринга процессов и готовности команды работать по-новому. В итоге правильно выбранная и выстроенная ITSM-платформа превращается в сквозное цифровое ядро, объединяющее внутренние службы.
Поделиться
