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

За последние два года с российского рынка ушли десятки иностранных вендоров. Одновременно с этим обновилось законодательство – теперь субъектам критической информационной инфраструктуры и компаниям с государственным участием предписано полностью перейти на отечественное ПО к 2025 году. О том, как пережить миграцию и избежать ошибок в процессе, рассказывает Юрий Мацыгин, руководитель производственного блока ООО "Т1 Инновации" (входит в Холдинг Т1).

Ошибается тот, кто ничего не делает

Одна из главных ошибок – отказ от импортозамещения. По итогам 2023 года, 68% отечественных компаний уже приступили к миграции на российские решения, однако полностью замещены от 10% до 50% программных продуктов. Отчасти такие показатели объясняются тем, что в некоторых отраслях ситуация с предложением сложная: разработчики делают только первые подходы к узкоспециализированному софту, из-за чего он не обладает необходимыми функционалом. Однако не стоит ждать момента, когда поставщик ПО "угадает" конкретные потребности компании. Потери, которые компания понесет за время ожидания, будут выше мнимой экономии на переходе. Более того, своей обратной связью бизнес может подтолкнуть разработчиков в правильную сторону, и постепенно за счет взаимодействия вендоров, интеграторов и заказчиков цифровая зрелость решений будет расти.

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

Все везде и сразу

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

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

Снизу вверх или сверху вниз

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

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

Класть все задачи в одну корзину

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

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

Работа над ошибками

Чтобы избежать этих ошибок, нужно не так много. Главное – не оттягивать импортозамещение. Не стоит дожидаться отзыва лицензии или расширения требований государства, из-за которых пользоваться привычным продуктом станет невозможно. Если два года назад переход на российский софт был настоящим вызовом, то сегодня ситуация изменилась. Число решений в Реестре отечественного ПО по сравнению с 2021 годом увеличилось в два раза. Для того, чтобы достичь отметки в 10 тысяч продуктов, потребовалось пять лет, в 20 тысяч – уже два года. Более того, вендоры открыты к предложениям и обратной связи – получить необходимые функциональные возможности можно в короткие сроки, достаточно сформулировать соответствующий запрос.

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

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

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

Когда впервые зашла речь об импортозамещении ПО, цель казалась чересчур амбициозной и даже невероятной. Однако за последние два года количество продуктов в Реестре отечественного ПО выросло на 60%. И это только начало, зрелость российских решений неизбежно будет расти. Вендоры уже сталкиваются с вызовами следующего уровня: как выстроить взаимодействие с партнерами, осуществлять поддержку разных версий, организовать параллельную работу с несколькими ОС. Мигрировать с иностранных продуктов становится все проще. Главное – не допускать типичных ошибок и грамотно подойти к планированию.