5 советов бизнесу: как импортозаместить ITSM-систему

Импортозамещение ITSM-систем – не только вынужденная мера в ответ на внешние вызовы, но и возможность для бизнеса провести глубокую и осмысленную трансформацию ИТ-процессов. Успех перехода стоит оценивать не по скорости замены одного решения на другое, а по гармоничному сочетанию в проекте различных составляющих, считает Елена Березина, руководитель проекта в компании GreenData. На примере реального кейса эксперт рассказала IT Speaker, как получить максимум пользы от миграции, и дала пять ключевых рекомендаций.

Совет 1. Начните с вопроса «Зачем?» – определите истинные драйверы перехода и критические риски

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

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

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

• моральное и технологическое устаревание. Унаследованные системы не соответствуют современным стандартам и архитектуре, что тормозит развитие;

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

• оптимизация стоимости владения (TCO). Поддержка устаревших систем и поиск редких специалистов для их обслуживания обходятся дорого, а развитие становится практически невозможным.

Поэтому, прежде чем изучать рынок отечественных решений, проведите внутренний аудит. Честно ответьте на вопрос: «Что случится, если завтра наша текущая система откажет?» Ответ на него станет главным ориентиром в проекте миграции.

Совет 2. Выбирайте зрелость, а не просто набор функций

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

На что же обращать внимание, оценивая реальную зрелость платформы?

• глубина реализации процессов. Недостаточно просто иметь модуль «Управление инцидентами». Важно, как он реализован: есть ли четкое разделение ролей, понятные метрики, сквозные интеграции с другими процессами (например, с базой знаний или CMDB). Поверхностная автоматизация создает лишь иллюзию порядка;

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

• «коробочная» готовность ключевых функций. Базовые процессы – управление запросами, инцидентами, проблемами, изменениями, CMDB – должны работать сразу, без дорогостоящих доработок «под базовые нужды».

  Вас может заинтересовать: 

  Объем ИТ-рынка в России оценили в 3,9 трлн рублей
  

Совет 3. Адаптируйте процессы под бизнес, а не наоборот

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

Миграция – редкий шанс взглянуть на ИТ-сервисы как на часть операционного контура, а не вспомогательную функцию. В этот момент важно не переносить «как есть», а задать вопрос: «Зачем мы делаем это именно так?» Часто именно здесь рождаются новые регламенты, исчезают дубли, а метрики начинают отражать реальную ценность.

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

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

• минимализм форм. Оставляйте только те поля, которые необходимы конкретной роли на конкретном этапе. Остальное – по условию или автоматически;

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

• автоматизация рутины. Там, где возможно, заменяйте ручные переходы и проверки автоматическими действиями и валидациями.

Совет 4. Не откладывайте интеграцию на потом, ведь это фундамент проекта

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

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

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

• приоритизация. Не пытайтесь интегрировать все и сразу. Выберите 3-5 критически важных сервисов для запуска MVP, например, корпоративный портал для приема заявок и система кадрового учета для синхронизации данных о сотрудниках;

• четкая цель. Для каждой интеграции ответьте на вопросы: зачем она нужна? Кто будет ее пользователем? Какие данные и как часто будут передаваться? Поверхностное требование «интегрируйтесь с мониторингом» – это путь в никуда;

• MVP-подход к каждой интеграции. Начните с минимально необходимого функционала. Например, сначала настройте только автоматическое создание инцидента по событию из системы мониторинга. Более сложные сценарии можно добавить на следующих этапах;

• техническая проверка совместимости. Заранее изучите технические детали: версии API, протоколы, требования к аутентификации. Это убережет от неприятных сюрпризов в середине проекта.

Совет 5. Управляйте изменениями: вовлекайте команду и говорите с ней на одном языке

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

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

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

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

• старт с «быстрых побед». Начните внедрение с минимального набора самых востребованных процессов, которые дадут результат в короткий срок;

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

• сбор и учет обратной связи. Создайте понятный канал для сбора предложений и оперативно реагируйте на них.

Выводы

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