Жизнь после SAP: импортозамещение платформы данных

Последние пару лет не перестает сходить с первого плана вопрос импортозамещения софта ушедших вендоров. Мы занимаемся данными, поэтому и делимся опытом импортозамещения платформ данных у наших enterprise заказчиков. Если попробовать классифицировать причины импортозамещения, то это могут быть снижение вендорских рисков, требования Минцифры, сложность и стоимость закупки сертифицированного «железа» под импортные платформы и так далее. Кстати, далеко не на последнем месте запрос команд разработки и поддержки на реализацию проектов на российском и open source технологическом стеке. Российский рынок вакансий на западном проприетарном вендорском ПО постепенно сужается, так как сейчас спрос российских компаний на такой софт стремится к нулю и такие системы постепенно превращаются в Legacy. Так или иначе, российский крупный бизнес постепенно приходит к задаче импортозамещения и вместе с этим к целому спектру сложных задач, начиная от выбора подходящих целевых систем и технологий и их «допиливания», разработки,внедрения, до удовлетворения ожиданий не всегда простых бизнес-пользователей.

Разделим проблему на две части – подходящий апробированный технологический стек с формированием команды и сатисфакция бизнес-пользователей.

Здесь важно понимать, что если мы говорим про платформу данных на SAP, то это целый комплекс функциональностей: ELT механизм, инструменты моделирования, функционал для мониторинга процессов загрузки данных, даже несколько BI под разные задачи от дашбординга до self-service аналитики. Ниже я привел картинку из официальной документации SAP, которая частично визуализирует масштаб:

В парадигме SAP один консультант SAP BW (Business warehouse) настраивал всю вертикаль от экстракции данных до настройки отчетности. Также мог пользоваться low-code инструментами моделирования, мониторинга загрузок и так далее. Кстати, отсюда и выстраиваются проектные команды, в которых один консультант отвечает за свой блок, например, за экстракцию из SAP MM и одновременно за соответствующую отчетность по закупкам и остаткам, другой – за экстракцию из SAP FI и за отчетность по дебиторке и кредиторке и т.д.

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

Волей проектной судьбы мы занялись задачами импортозамещения SAP еще в 2022 году, а целевыми вендорскими системами, куда предлагаем мигрировать функционал, занимаемся уже очень давно и сейчас можем поделиться рабочим опытом. С теми или иными допущениями, в зависимости от инфраструктуры и ландшафта, мы почти всегда видим похожую блочную архитектуру (схема ниже) у различных компаний, причем даже вне зависимости от отрасли. Поставщики решений для каждого блока могут различаться, но сама архитектура уже, можно сказать, стала стандартом. Целевая платформа для миграции выделена серым прямоугольником. Слева – это любые источники.

С точки зрения вендоров самих блоков, самые большие различия в BI решениях: их на российском рынке в данный момент огромное количество. Поставщиков решений для хранения данных намного меньше, так как технологии уже более менее определены – это S3 или Hadoop для холодных данных, Greenplum – для теплых данных и Clickhouse – для горячих, а поставщики – это Arenadata для On-premise и несколько облачных провайдеров.

В самой платформе представлены серые блоки, которые покрывают собой основные компоненты платформы: загрузка, хранение, визуализация и работа с данными. На данной схеме ядром DWH для хранения данных и витрин являются продукты Arenadata DB и Arenadata QuickMarts, которые позволяют обеспечить сопоставимый или даже более высоких уровень производительности платформы и возможность дальнейшего неограниченного роста объема данных. Отсюда же строится и команда поддержки/развития платформы – команда становится больше ориентированной не на функциональные вертикали (финансы, логистика и т.д.), а скорее горизонтали по технологиям: дата инженер для работы с моделью, BI-инженер или аналитик и так далее.

Есть важный нюанс – все представленные серые блоки – это «голые» базы данных и функциональности, в которых нужно будет писать SQL, Python или Java-процедуры через специальные IDE. Это в корне меняет требования к организации и квалификации команды поддержки/разработки, трудозатратам на разработку/внедрение и time-to-market запросов на изменение от бизнес пользователей.

Синий блок ProPlum – это наш фреймворк, чем мы дополнили платформу, чтобы приблизиться к low-code подходу SAP.

Фреймворк выложен в Open source и позволяет следующее:

1. Существенно снизить трудозатраты на поддержку и доработки и увеличить скорость разработки (в компании «Комус» более 60% процедур разработки реализовано через настройки без написания SQL кода, а это в разы уменьшает трудозатраты)

2. Упростить ротацию сотрудников и включение новых проектных команд, например, подрядчиков (все работают в одной структуре и naming convention фреймоворка).

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

Кстати, касательно рисков сокращения проектной команды SAP BW – у наших клиентов они не реализовались. Все члены команд поддержки и развития смогли спокойно переучиться на новые технологии и расширить свой технологический опыт. Для этого мы проводим обучение команд наших клиентов и фреймворк ProPlum тут тоже, конечно, очень помогает для более легкого старта. Как оказалось, уходить с SAP тем, кто работал с BW и данными, намного проще, чем консультантам по классическим ERP модулям.

Другие же два синих блока – Apache Superset и Easy Report – это про сатисфакцию бизнес пользователей.

Мы довольно часто слышим от бизнес пользователей наших клиентов, что после импортозамещения должно быть «не хуже». Это очень комплексная формулировка, по сути, – минное поле, по которому нужно пройти айтишникам и инженерам данных. Мы выделили два фактора, чтобы итоговый результат, который получим после проекта миграции с SAP, был не хуже – это отсутствие блокирующих факторов для работы, то есть +/- заменители всех функциональностей, которыми пользовались пользователи, и определенные вау эффекты, которые повысят эмоциональную отдачу того «блюда», что мы в итоге принесем.

Мы дополнили стандартный Superset дополнительной функциональностью, которая позволяет получить возможности, сопоставимые с передовыми западными решениями в части фронт BI,особенно если речь идет о переходе с бизнеса с SAP BO. В ближайшее время мы выложим в Open source наши доработки в части Apache Superset.

Что мы добавили:

Разработанный нами проприетарный продукт, который позволяет максимально упростить взаимодействие с данными и делать запросы в любом мессенджере на естественном языке. Вот очень кратко возможности продукта:

Easy Report дает во-первых вау эффект и удобство работы для среднего и высшего звена, а во-вторых позволяет легко и дешево подключить большое число конечных пользователей, например, менеджеров продаж как сделал наш клиент Самолет.

Миграция с платформы данных на ПО российских вендоров – не «rocket science», но есть много нюансов и деталей, которые, к сожалению, в рамках одной статьи не расскажешь. Дать универсальные советы тоже невозможно. Выкладывая и делясь нашими разработками в Open source, мы попытались максимально облегчить жизнь российским компаниям, которые приходят к задаче импортозамещения платформы данных SAP.

Если обобщить опыт наших клиентов, то можно сказать следующее: