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

Жизнь российского ИТ-специалиста никак не назовешь простой и безоблачной. Ему постоянно приходится решать задачи, каждая из которых сложнее предыдущей. Не успел миновать пик пандемии ковида (кто-то о ней еще помнит?), как грянули беспрецедентные международные санкции. Большая часть зарубежных вендоров прекратила работу на российском рынке и покинула нашу страну. Российским заказчикам в срочном порядке пришлось искать замену и готовиться к импортозамещению и миграции на отечественные или Open Source-решения. Год назад миграция носила экстренный, пожарный характер. Это было больше похоже на затыкание дыр и прилаживание «костылей», чтобы бизнес не остановился, не прекратил свою работу.

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

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

Стратегическое импортозамещение

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

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

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

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

Ильдар Закиев («ЛАНИТ-Интеграция» (ГК «ЛАНИТ»)): Если у предприятия большая и распределенная ИТ-инфраструктура, заменить все разом не получится. Обычно выделяется сегмент ИТ-инфраструктуры, информационная система или набор информационных систем, который в своих границах либо больше не интегрируются с другими системами, либо может интегрироваться с любым решением — как с импортным, так и с импортозамещенным.

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

Запуск пилота

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

Дмитрий Алифатов (Step Logic): Одновременная замена сразу нескольких смежных информационных систем может кратно увеличить сложность миграции. Поэтому ее следует рассматривать только в случае, если обеспечение надежной интеграции с новой платформой становится не менее сложной задачей.

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

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

Альберт Мухутдинов (ICL Services): Главные факторы для успешной миграции ИТ-платформы — грамотно проведенное обследование, правильное ТЗ, четкое согласование сроков и следование им, расстановка приоритетов плюс пилотный проект с активным участием бизнеса на всех этапах.

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

Пересадка с одной платформы на другую

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

«Чисто формальный подход, при котором можно заменить фрагмент ИТ-ландшафта на систему с такой же функциональностью и таким же набором плагинов, работает только в отношении «каноничных» решений (с четкими границами функциональности, одинаково трактуемыми рынком), типа CRM- или HRM-систем. Здесь возможна поузловая замена с интеграцией с сопредельными решениями, но не во всех случаях. В других ситуациях, например, при замене системы управления задачами, которая может быть сильно изменена по отношению к «коробочному» решению, мы сталкиваемся с необходимостью кластерной замены со сложной интеграцией», — предупреждает Юрий Дручинин («Сфера.Задачи»).

Юрий Дручинин (владелец продукта «Сфера.Задачи»): Если «коробочное» ПО предоставляет возможности для доработки и конфигурирования под бизнес-задачи конкретной компании, то нужно выбирать его.

«Зачастую переезд с одной платформы на другую сопряжен с большим количеством сложностей, — комментирует Роман Воробьев, директор департамента производства программного обеспечения и сервисной поддержки компании Bercut. — Часто даже смена отдельных релизов приводит к тому, что совместимость реализованных сервисов теряется. В связи с этим компании вынуждены переписать до 90% ранее созданных продуктов. Поэтому организации стараются избегать обновления релизов, не говоря уже о полноценном переходе на новую платформу». Эксперт советует сделать переход на новую платформу более плавным, что минимизирует количество необдуманных шагов. «Во-первых, для начала стоит запустить на платформе несколько новых кейсов, это поможет ознакомиться с принципами ее работы. Во-вторых, можно приступать к проведению интеграций с Open Source-системами и внутренними наработками компании. В-третьих, после приобретения опыта, создания необходимых коннекторов и более близкого знакомства с системой компания сможет постепенно отказываться от существующих компонентов или Open Source в ключевых продуктах», — говорит он.

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

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

Сначала опыт, затем документы

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

В целом, эксперты сходятся во мнении, что ситуация с описанием удачных кейсов действительно оставляет желать лучшего, однако со временем и накоплением опыта положение исправится. «Задачи миграций, которые стоят сейчас перед российскими организациями, — ситуация вынужденная и достаточно уникальная. Ведь ПО развивается эволюционно, осуществляя переход на более технологичное, современное, высокопроизводительное ПО с хорошей поддержкой. Никто не переходит, например, с одной СУБД на другую просто так. Это всегда высокозатратные истории. Поэтому и у российских вендоров, и у зарубежных не так уж много контента про удачные миграции, хотя, безусловно, в силу глобального распространения у зарубежных вендоров его больше. Но и у наших компаний быстро копится такой опыт, и, соответственно, появляется документация и кейсы по успешной миграции, поскольку запрос на такие работы сейчас необычайно высок», — считает Андрей Инюшин (ITentika).

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

Юрий Дручинин («Сфера.Задачи») обозначает вполне ясные сроки появления кейсов, посвященных удачным проектам по миграции. Ждать осталось не так долго. «Сроки документирования зависят от времени пилотирования отдельных процессов и отчасти — от тендерных процедур. Для отдельных систем обоснованные кейсы качественного внедрения мы увидим на горизонте полутора лет. В случае импортозамещения продуктов, которые закрывают не растянутые по времени процессы, — к концу этого года», — заключает он.

Источник: IT World.