Миграция на российское ПО: сложности переезда

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

Проект проекту рознь

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

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

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

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

Заменить сложно, но можно

Проблема поиска замены для зарубежных продуктов также остается очень актуальной. Аналоги большинства продуктов «мейнстрима», таких как операционные системы для серверов и рабочих станций, офисные пакеты, антивирусное ПО и межсетевые экраны, легко найти на рынке. Более того, здесь есть даже выбор и конкуренция. С другими категориями ПО ситуация сложнее. «Пока существуют некоторые трудности с замещением программно-аппаратных комплексов для инженерного проектирования сложных изделий, с ERP-системами, с ПО, разработанным по заказу организаций. Сегодня доля отечественного инженерного ПО составляет примерно 30% российского рынка. Импортные ERP-системы прочно вросли в деловые процессы крупных российских холдингов ТЭК и металлургии, их замена требует очень большой и кропотливой работы», — комментирует Григорий Сизоненко, генеральный директор компании «ИВК».

«В России всегда было сильное направление информационной безопасности, с этими решениями меньше всего проблем, — считает Сергей Таранов (WIAT). — Основная проблема — инфраструктурные решения, как программное обеспечение, так и вычислительные комплексы и комплексы хранения. Российские системы виртуализации, системы резервного копирования довольно сильно уступают по функциональности зарубежным аналогам».

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

Не весь Open Source одинаково полезен

Мы уже поднимали тему выбора программных продуктов с открытым кодом (Open Source) в качестве альтернативы зарубежным коммерческим продуктам. Да, в большинстве случаев свободное ПО — это не российская разработка. Чаще всего крупные проекты поддерживаются международным сообществом, в составе которого есть, разумеется, и отечественные программисты, аналитики, тестировщики и другие специалисты. Ситуация усугубляется тем, что нередко одну из ключевых ролей в таких проектах играют крупные ИТ-корпорации, которые привносят в них не только финансы, но и код, технологии, ноу-хау. Руководствуясь санкционной политикой, они могут ограничить доступ к этим компонентам российским пользователям. Неслучайно же в Минцифры РФ собираются создать аналог крупнейшего репозитория Github, который, как известно, принадлежит корпорации Microsoft.

«Необходимо окончательно осознать, что Open Source в его изначальном смысле закончился, — комментирует Кирилл Федулов (Okdesk). — Многие решения уже давно коммерциализированы, но остаются доступными для всех на бесплатной основе в очень старой версии или без какой-либо техподдержки. Яркий пример — система обработки заявок OTRS. Буквально на днях ИТ-сообщество взбудоражила новость про Gitlab и про удаление неактивных проектов. Компания уже опровергла эту активность, но мы все знаем, что нет дыма без огня. При этом еще полгода назад никто и подумать не мог, что коммерческие компании будут блокировать аккаунты или не продлевать использование своего ПО по какому-то надуманному, совсем не рыночному предлогу. Мир и отношения в нем изменились. Верить в то, что еще вчера было невозможным, сегодня может позволить себе только очень наивный человек. С Open Source — аналогичная история, но взвешивать риски и принимать решение необходимо каждому. Важно перестать верить в мифы про российское ПО. Мы давно даем фору зарубежным решениям по целому ряду направлений».

«На первый взгляд ответ очевиден: у отечественного ПО есть разработчик, поставщик, обеспечена поддержка. В развитие Open Source продуктов вкладываются огромные ресурсы, в том числе и крупнейшими мировыми корпорациями. Использование Open Source может значительно ускорить процесс получения «готового продукта», однако вопрос требует очень обширного детального рассмотрения, поскольку Open Source и его использование имеет множество нюансов. Поэтому важно, чтобы открытое ПО имело российские ветки, потому что у продукта должен быть поставщик, отвечающий за его работоспособность и поддержку. Использовать Open Source можно, когда речь идет о российских продуктах, разработанных на базе проектов с открытым исходным кодом, а не самих проектах со сложной и подчас непонятной моделью управления. А это уже практически отечественное ПО. Ярким примером является продукт Postgres и локализация его на российском рынке СУБД Postgre SQL», — предостерегает Сергей Хахамов («Фирма «АС»).

По мнению Александра Молодцова (iFellow), принимать решение нужно, исходя из бизнес-потребности, распространенности продукта и его пула клиентов на рынке. «Очень важно понимать, как тот или иной программный продукт далее будет развиваться и сопровождаться. Отсутствие зрелости у вендора, как компании-создателя программного продукта, или комьюнити у Open Source-решения, означает отсутствие достаточной экспертизы и специалистов, способных развивать и сопровождать решение. В будущем это может загнать компанию в тупик. Также очень важно понимать, кто владеет OpenSource решением. Как правило, решения базируются в рамках некоммерческих партнерств, но не стоит забывать о том, что это юридические лица, подверженные влиянию законодательства страны, в которой они были созданы», — отмечает эксперт.

Миграция начинается с аудита

Любой серьезный ИТ-проект должен сопровождаться аудитом ИТ-инфраструктуры и имеющегося программного обеспечения. Миграция на отечественное ПО не исключение. Все эксперты сходятся в оценке важности данного этапа. «Да, необходимо провести аудит не только существующей ИТ-инфраструктуры, но и бизнес-процессов. Это необходимо для того, чтобы не искать замену зарубежным продуктам один в один, а наиболее точно подобрать российское ПО, которое послужит инструментом решения задач организации», — советует Григорий Сизоненко («ИВК»).

«Стратегию миграции ПО предлагается рассматривать как инвестиционный проект, считая, что он сопряжен с неопределенностью в части производимых затрат и получаемых в будущем результатов. Соответственно, на предынвестиционном этапе необходимо обосновать целесообразность, исследовать рынок предлагаемых решений на основе отечественных продуктов и разработать бизнес-план, в котором оценить возможность возврата вложенных средств с учетом текущих расходов, связанных с эксплуатацией. Аудит является неотъемлемой частью такого подхода. Можно добавить, что если активно не двигаться в направлении импортонезависимости, то зависимость от импортных решений становится естественным результатом, который мы и наблюдаем в настоящий момент», — утверждает Сергей Хахамов («Фирма «АС»).

Александр Молодцов (iFellow) перечислил этапы, которые должны быть предусмотрены в проекте по миграции на отечественную платформу. На первом месте он назвал аудит. «Аудит — один из важнейших этапов проекта по переходу на новое программное обеспечение, это касается не только миграции данных. На старте проекта необходимо изучить бизнес-потребности клиента, технические ограничения и возможности, интеграционное окружение новой системы и другие нюансы», — говорит он. Стратегию миграции эксперт разделяет на несколько этапов: аудит — изучение текущего используемого функционала и окружения ПО; разработка детальной дорожной карты миграции; интеграция с окружением; пилотирование решения на фокус-группе; развертывание на всех пользователей. В заключение Александр напоминает о такой обязательной процедуре, как резервное копирование.

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