5 фатальных ошибок при миграции с SAP PI/PO на новую интеграционную шину - и как их избежать

От эксперта «Севен Груп» Юрия Иванова - ведущего разработчика продукта класса ESB «Интегра»

За десять лет работы с корпоративными интеграциями наблюдал десятки проектов по замене SAP PI, SAP PO и SAP CPI. Некоторые завершались чисто и по плану. Многие - превращались в затяжные кризисы, которые стоили компаниям месяцев простоя, перерасхода бюджета и репутационных потерь.

Каждый раз причина лежала не в сложности технологий, а в одних и тех же управленческих и архитектурных просчетах.

Интеграционная шина данных - это нервная система предприятия. SAP Process Integration и SAP Process Orchestration связывают ERP, CRM, WMS, производственные системы и внешних контрагентов в единую экосистему. Через нее проходят данные / сообщения по заказам, накладным, финансовым проводкам, складским остаткам, производственным заданиям.

Когда SAP в 2022 году ушел с российского рынка, перед тысячами компаний встал выбор: продолжать работать на системе без вендорской поддержки или перейти на российский аналог SAP PI. Многие выбрали второй путь. И многие столкнулись с одними и теми же ошибками - дорогостоящими, а порой разрушительными для операционной деятельности компании.

Срок поддержки SAP PI и PO официально истекает в 2030 году. Это означает, что окно для спокойной, методичной миграции пока существует, но оно скоро закроется. Указ Президента РФ №309 от 07.05.2024 ускорил этот процесс для объектов критической информационной инфраструктуры (КИИ). Давление регулятора порождает спешку - главный катализатор всех пяти ошибок, о которых расскажу ниже.

Самая распространенная и самая дорогая ошибка при переходе с SAP PI - приступать к работе без полной карты существующих интеграций.

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

Проблема усугубляется тем, что SAP PI/PO за годы эксплуатации накапливает значительный технический долг. Интеграции создавались разными командами, в разные периоды, без единых стандартов. ICO (Integration Configuration Objects) расплодились хаотично. Часть из них никто не трогал годами - но отключить страшно, потому что неизвестно, что за процесс за ними стоит.

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

Совет: Документации по интеграциям лучше не верить - она всегда отстает от реальности. Единственный надежный источник истины - живые данные из самой системы SAP PI/PO: статистика вызовов по каждому каналу за последние 12 месяцев. Потоки с нулевым трафиком за год - кандидаты на отключение, но только после подтверждения у бизнес-владельца.

Давление сроков толкает команды к соблазнительному, но опасному решению: перенести весь интеграционный слой за один этап, переключить трафик в дату X и закрыть вопрос. На бумаге это выглядит эффектно. На практике - превращается в катастрофу.

Один крупный производственный холдинг попытался перенести 150 интеграционных потоков за три месяца без периода параллельной работы. В день переключения обнаружилось, что 23 потока некорректно обрабатывают формат IDoc - специфичный для SAP формат электронных документов. Склад перестал получать подтверждения отгрузок, финансовая система потеряла синхронизацию с ERP. Производство встало на 11 часов. Стоимость простоя превысила весь бюджет проекта миграции.

Корень проблемы - в архитектурной несовместимости: SAP PI и ESB-системы устроены по-разному, и одинаковые с виду сценарии ведут себя принципиально иначе под нагрузкой. Понять это без реальной эксплуатационной нагрузки невозможно.

Что делать вместо этого. Единственная рабочая стратегия - поэтапная миграция с обязательным периодом параллельной эксплуатации. Российский аналог SAP PI должен работать рядом с существующей системой, принимая нарастающую долю трафика. Первым этапом переносятся некритичные потоки - это позволяет команде освоить новую платформу в безопасных условиях. «Активные и критичные» потоки переключаются последними, когда команда уже накопила опыт и уверенность.

Интеграционная платформа «Интегра» спроектирована с расчетом на такой сценарий: она штатно работает в гибридном режиме рядом с SAP PI/PO, принимая трафик по мере готовности отдельных потоков, без принудительного переключения всего ИТ-ландшафта единовременно.

Логика «перенесем все как есть, разберемся потом» кажется разумной экономией времени. Результат - технический долг, который не исчезает, а удваивается.

SAP PI/PO и современные ESB-платформы реализуют интеграционные паттерны по-разному. Кастомные Java-маппинги, ccBPM (сложные бизнес-процессы в SAP PI), нестандартные адаптеры и Function Libraries не переносятся механически - они требуют переработки. Команда, которая пытается воспроизвести старую архитектуру один в один на новой платформе, получает худшее из двух миров: ни гибкости новой системы, ни стабильности старой.

Характерный пример из практики: компания из сектора розничной торговли перенесла 60 потоков «как есть», включая ccBPM-процессы обработки заказов. Через полгода выяснилось, что производительность новой системы под пиковой нагрузкой (период распродаж) оказалась хуже, чем у SAP PO. Причина - архитектурный антипаттерн, унаследованный из старой системы и воспроизведенный в новой.

Что делать вместо этого. Миграция с SAP Process Orchestration - это не копирование, а рефакторинг. Каждый поток при переносе нужно оценивать заново: соответствует ли его архитектура возможностям целевой платформы? Есть ли более эффективный способ реализовать ту же бизнес-логику?

Платформа «Интегра» предоставляет готовые шаблоны для типовых интеграционных паттернов, встроенный инструмент графического маппинга Mapping Data как функциональный аналог SAP Message Mapping. «Интегра» обладает всеми необходимыми коннекторами для перехода с SAP, исключая взаимодействие по SAP протоколам. Это позволяет не изобретать велосипед для каждого SAP-специфичного сценария, а использовать готовые, проверенные шаблоны.

Совет: Перед переносом каждого ccBPM-процесса задайте один вопрос: зачем здесь нужна оркестрация? Часто выясняется, что исходный ccBPM был написан как обходное решение для ограничений старой версии SAP PI - и в новой интеграционной платформе (ESB) та же задача решается прямолинейно, без сложной логики.

Технические руководители фокусируются на переносе потоков и упускают из виду факт: после переключения на новую платформу команда теряет значительную часть накопленной экспертизы.

SAP PI/PO - специализированная система с глубокой экосистемой знаний. Специалист, который за пять лет научился уверенно работать с SAP Integration Builder, ccBPM и всеми нюансами адаптеров, оказывается на новой платформе практически новичком. По опыту проектов, команда восстанавливает прежнюю производительность через 6-9 месяцев после полного переключения - если переобучение было правильно организовано. Если нет - через 12-18 месяцев.

Параллельно обострился дефицит SAP-консультантов на рынке: после ухода вендора многие специалисты переквалифицировались или ушли в смежные области. Найти сильного SAP PI/PO-архитектора для поддержки переходного периода становится дороже с каждым годом.

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

Важный критерий выбора российского аналога SAP PI - порог входа для действующих специалистов. Платформы с low-code средой разработки позволяют SAP-консультантам освоить новый инструментарий без глубокого погружения в программирование. Например, «Интегра» предоставляет визуальную среду разработки интеграционных потоков, русскоязычную документацию и программу сертифицированного обучения с лекциями, заданиями, видео и реализованного на платформе обучения. Помогает быстро освоиться, что существенно сокращает время.

Если стоит задача не просто закрыть риски кадрового дефицита, но и выстроить устойчивую интеграционную архитектуру на годы вперед, имеет смысл познакомиться с подходом к корпоративной интеграции на платформе «Интегра» подробнее.

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

Часть компаний при выборе отечественного аналога SAP PI/PO ориентировалась исключительно на функциональность и цену. Вопрос о соответствии регуляторным требованиям откладывался на потом. «Потом» наступало в виде предписания от регулятора, срыва тендера или невозможности подключить государственного заказчика.

Для объектов критической информационной инфраструктуры (КИИ) - промышленности, энергетики, транспорта, финансового сектора - требования однозначны: интеграционная платформа должна входить в Реестр российского ПО Минцифры, а для ряда категорий - иметь сертификацию ФСТЭК. Open-source решения, формально адаптированные под российский рынок, зачастую не проходят аудит безопасности, так как содержат иностранные компоненты с неизвестным происхождением кода.

Отдельный риск - выбор платформы, которая является надстройкой над иностранной open-source ESB. Такой продукт технически зависим от зарубежного upstream-проекта, и его соответствие требованиям реестра может быть оспорено при углубленной проверке.

Что делать вместо этого. Еще до функционального тестирования сформируйте список обязательных критериев: включение в Реестр российского ПО, наличие или дорожная карта получения сертификата ФСТЭК, поддержка российских операционных систем (Astra Linux, Альт, РЕД ОС), возможность размещения на собственной инфраструктуре без зависимости от зарубежных облаков.

Платформа «Интегра» (7TECH INTEGRA 2.0) включена в Реестр российского ПО Минцифры, является собственной разработкой «Севентек» без иностранных open-source компонентов в ядре, поддерживает российские ОС и поддерживает российские средства контейнеризации.
В каталоге совместимости АРПП платформа официально указана как замена SAP PI/PO, WSO2, IBM Integration Bus и Microsoft BizTalk.

Миграция с SAP PI, SAP PO или SAP CPI - не технический проект, а управление рисками масштаба всего предприятия. Пять ошибок, которые превращают такой проект в кризис, всегда одни и те же: старт без инвентаризации, перенос одним этапом, архитектурный lift-and-shift, игнорирование кадрового вопроса и выбор платформы без проверки регуляторных требований.

Каждая из них предотвратима - при условии, что решение принимается методично, а не под давлением дедлайна. Российский рынок интеграционных платформ за последние три года прошел путь от «есть что-то похожее» до зрелых продуктов, которые закрывают весь функциональный объем SAP PI/PO и добавляют то, чего в SAP никогда не было: полную регуляторную прозрачность, русскоязычную поддержку и понятный путь развития без зависимости от зарубежного вендора.

Хотите понять, как выглядит ваш интеграционный ландшафт с точки зрения готовности к миграции? Эксперты «Интегры» проводят бесплатный аудит существующих интеграционных сценариев и готовят оценку трудозатрат для перехода.

Чем SAP PI отличается от SAP PO и SAP CPI - и это важно для выбора аналога?

SAP PI (Process Integration) - исходное название интеграционной платформы SAP для on-premise развертывания. SAP PO (Process Orchestration) - расширенная версия с добавлением BPM и BRM-функциональности, тоже on-premise. SAP CPI (Cloud Platform Integration, сейчас - SAP Integration Suite) - облачная версия. Для российского рынка это различие принципиально: большинство крупных предприятий работают именно на SAP PI/PO (on-premise), и российские аналоги SAP PI должны поддерживать прямую миграцию с on-premise архитектуры - без принудительного перехода в облако.

Сколько времени реально занимает полная миграция с SAP PI/PO?

Для ландшафта из 50-100 потоков при правильной организации - от 6 до 9 месяцев с учетом аудита, переноса и периода параллельной эксплуатации. Ландшафты от 200 потоков требуют 12-18 месяцев. Попытки уложиться быстрее, как правило, заканчиваются ошибкой №2 из этой статьи.

Можно ли использовать open-source ESB как замену SAP PI, не переплачивая за коммерческий продукт?

Технически - да, функционально open-source решения (Apache Camel, MuleSoft Community и другие) покрывают базовые интеграционные сценарии. Но для предприятий с требованиями КИИ, госконтрактами или аудитами безопасности open-source путь создает регуляторные риски: такие продукты не входят в Реестр Минцифры и не имеют сертификации ФСТЭК. Помимо этого, скрытые затраты на поддержку и доработку open-source нередко превышают стоимость коммерческой лицензии уже на третий год эксплуатации.

Нужно ли полностью переобучать SAP-специалистов для работы с российским аналогом?

Полное переобучение с нуля не требуется. Базовые концепции корпоративной интеграции - паттерны обмена сообщениями, маппинг, адаптеры, мониторинг - универсальны. Специалист с опытом в SAP PI/PO осваивает новую платформу за 4-8 недель при наличии качественной программы обучения. Ключевое отличие - не глубина переобучения, а его своевременность: программу нужно запускать в самом начале проекта, а не после переключения.