Импортозамещение аналитических систем остаётся одной из наиболее трудоемких задач в корпоративной ИТ-среде. Особенно когда речь идёт о платформах уровня SAP BW/4 HANA: больших объемах данных, сложной архитектуре, множестве отчетов и строгих нефункциональных требованиях. В подобных проектах важны не только выбор стека и корректная миграция хранилища, но и организационные решения, планирование и работа с пользователями.

Всем привет! Меня зовут Михаил Синельников, я лидер кластера импортозамещения аналитической отчетности в ВТБ. Вместе с моим коллегой Владимиром Ведяковым, ИТ-лидером проекта со стороны компании «Сапиенс Солюшнс», мы описали в этой статье перенос системы аналитической отчетности SAP BW/4 HANA на импортонезависимый стек. В этом материале представлен наш практический опыт: ключевые решения, подходы к планированию, особенности реализации и выводы, которые могут быть полезны командам, работающим с аналогичными задачами.

Предпосылки

SAP BW/4 HANA – это единая платформа для сбора и преобразования данных из различных источников. Она легко интегрируется с другими продуктами SAP и используется для подготовки аналитической отчетности и дэшбордов. Кроме того, решение поддерживает интегрированное планирование для облегчения разработки приложений, требующих ручного ввода. Долгое время выбор этой импортной платформы в качестве технологического решения для систем аналитической отчетности был очень распространенным. Таким образом, задача импортозамещения системы аналитической отчетности, построенной на SAP BW/4 HANA сложна и амбициозна.

Тем не менее, ряд важных предпосылок потребовали решения этой задачи. Среди них:
1. Отказ от санкционного оборудования;
2. Отказ от санкционного ПО;
3. Невозможность запуска отчетов в Analysis for Office после завершения перевода рабочих мест пользователей на целевые технологии (Astra Linux, Мой Офис).

Масштаб задачи

На целевой стек требуется мигрировать систему, содержащую 293 отчета (193 аналитических отчета, 66 форм ввода и 28 дэшбордов). Данные загружаются из 14 исходных систем, при этом ключевыми исходными системами являются SAP S/4 (модули FI-FM, FI-AA, MM, RE, CO) и SAP HCM (PA, PP). Хранилище данных для отчетности состоит из ~1000 ADSO, ~1500 СV, ~1600 трансформаций и построено с применением архитектурного подхода LSA++.

LSA++ (Layered Scalable Architecture++) – расширенная версия многоуровневой масштабируемой архитектуры. Хранилища, построенные таким образом, логически делятся на уровни, среди которых можно выделить уровень сбора данных, уровень распространения, уровень отчетных витрин, уровень виртуализации и т.д. Во время загрузки данные копируются с уровня на уровень, постепенно трансформируясь к оптимальному для использования в отчетах виду.

Планирование проекта

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

Учитывая это, мы отдали предпочтение специализированным компонентам, а не универсальному платформенному решению. Итоговый стек получился таким:
1. Apache Superset в качестве BI-инструмента для визуализации дэшбордов и отчетов, а также построения форм ввода;
2. Arenadata DB для стейджинга и оперативных отчетов;
3. ClickHouse для высоконагруженной отчетности и дэшбордов;
4. Apache Ni-Fi для организации двустороннего интеграционного взаимодействия;
5. Apache AirFlow для управления интеграционными потоками и ETL-процессами.

Лайфхак: Использование специализированных (в т.ч. Open source) компонентов оправдано в том случае, если нет универсального платформенного решения, удовлетворяющего всем требованиям. Компоненты с открытым кодом м��жно самостоятельно доработать командой проекта с учетом требований к целевому решению и без оглядки на дорожную карту той или иной проприетарной платформы.

b. Планирование сроков
Самый простой для изложения пункт и самый сложный для выполнения: сроки определены верхнеуровневыми дедлайнами. Основным и самым амбициозным из таких дедлайнов являлся отказ от продуктов Microsoft (Windows и Excel).

В проекте предполагалось, что пользователи системы увидят отчеты на целевом стеке гораздо раньше окончания работ по миграции хранилища данных для этих отчетов. Абсурд и утопия или скрытая возможность сделать лучше? Разберемся далее.

c. Планирование объема работ
На фазе подготовки проекта мы сделали небольшой пилот, в рамках которого перевели несколько объектов каждого типа на целевой стек. Результатом этого пилота стали два знания:
1. На пилотном объеме мы не опровергли гипотезу о выборе целевых компонентов и приняли окончательное решение по утверждению целевого стека;
2. Мы узнали, сколько времени уходит на перевод исходных объектов того или иного типа: CV, витрина, преобразование, запрос и т.д. Таким образом мы определили коэффициенты для перевода мигрируемых объектов в человеко–дни.

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

Лайфхак: При планировании объема важно учитывать ключевую особенность проектов импортозамещения – нам уже известно то, что должно получиться в конце. Функциональные и нефункциональные бизнес-требования определены. Для системы отчетности определена требуемая структура отчетных витрин и поля отчетов. Это знание можно и нужно использовать при планировании и проведении работ.

d. Организация команды
При планировании команды мы думали о том, что:
1. Необходима команда, способная выполнить объем работ;
2. Необходимо, чтобы организованная команда могла уложиться в срок проекта;
3. Необходимо учитывать, что целевая система состоит из множества компонентов, а значит для участников проекта необходима специализация. Этот пункт новый в сравнении с внедрением системы на базе SAP BW/4 HANA – в таких внедрениях чаще всего работают специалисты, ведущие разработку от источника до отчета;
4. При реализации проекта необходимо обеспечить функционирование отчетности на целевом стеке до окончания перевода рабочих мест (отказ от Microsoft) – этот дедлайн был значительно более ранним, чем общий.

Для внедрения «с нуля» задача сделать отчеты раньше хранилища была бы нерешаемой, но в нашем случае мы знали, что должно получиться в конце. Кроме того, исходное хранилище строго разделено по слоям (LSA++). Учитывая это, мы условно разделили хранилище на две части: от источника до уровня распределения и от уровня распределения до отчета, и сконфигурировали команды проекта таким образом, что они отвечали за свою «половину» хранилища.

• Команда, названная «Технологические компоненты», дорабатывала Apache Superset, чтобы получившийся продукт удовлетворял требованиям заказчика, ранее предъявляемым к продуктам Analysis for Office и SAP Lumira;

• Команды отчетности разрабатывали хранилище, начиная с уровня распределения данных, и настраивали отчеты, формы ввода и дэшборды;

• Команды экстракции и стейджинга реализовывали целевые интеграции и настраивали хранилище и ETL до уровня распределения данных;

• При планировании команды мы также выделили отдельные функции – архитектор, скрам-мастер, ответственный за конфигурирование и настройку инфраструктуры, ответственный devops, централизующий релизную активность;

• Лидерская функция была, напротив, децентрализована – лидер кластера импортозамещения управлял скоупом и коммуникацией с заказчиком, ИТ-лидер являлся последним уровнем эскалации всех архитектурных и технических вопросов, руководитель проекта контролировал стоимость, сроки и формальное соответствие проекта всем банковским стандартам.

Такая конфигурация позволила каждой команде заниматься разработкой в рамках своих компонентов, а общая длительность проекта сократилась вдвое в сравнении с классическим внедрением от источника до отчета. Еще одним важным следствием стало то, что мы смогли уложиться в дедлайн, связанный с отказом от Excel, а пользователи системы увидели целевые отчеты задолго до окончания проекта. Это в свою очередь, обеспечило длительную стабилизацию.

Примечание: вдумчивый читатель спросит о том, как же в целевых отчетах оказались данные, если хранилище еще не готово. Ответом на этот вопрос стала временная архитектура системы. В промежуточном решении все интеграции были настроены в SAP BW/4 HANA, там же остались все преобразования от источника до уровня распределения, связанные с очисткой и гомогенизацией. А данные из витрин уровня распределения и мастер-данные загружались в Arenadata DB с помощью PXF (Platform Extension Framework) – фреймворка, обеспечивающего параллельный высокопроизводительный доступ к данным из внешних источников.

После определения сроков, скоупа и команды мы составили дорожную карту проекта.

Команды последовательно приступают к работам.

• Начинает проект команда технологических компонентов, задача которой доработать Superset, разработав ряд фич для соответствия Superset возможностям Analysis for Office и Lumira. Бэклог команды приоритизируется исходя из логики: обязательные и требующиеся для большинства отчетов фичи реализуются первыми, в конце реализуются точечно применимые фичи и прочие “бантики”.

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

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

  Каждая фаза разработки фич Superset и каждая фаза разработки отчетности должна заканчиваться приемо-сдаточными испытаниями.

  В проект была заложена длительная стабилизация как для фич Superset, так и для отчетов.

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

• Обнаружить и исправить дефекты внедрения;

• Учесть пожелания заказчика, реализовав ряд дополнительных требований для улучшения пользовательского опыта;

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

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

f. План коммуникаций с заказчиком
В этом месте уместно написать несколько слов о коммуникациях с бизнес-заказчиком. Наш опыт говорит о том, что крайние позиции команды проекта по отношению к бизнес-пользователям («закрыться в бункере и выйти из него к дедлайну» или «максимально вовлекать бизнес-заказчика во все процессы») содержат риски.

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

Мы привлекали заказчика для:

• Обязательного согласования ключевой проектной документации перед каждой фазой проекта (по одной визе от каждого подразделения);

• Опционального участия в операционных комитетах проекта (раз в две недели);

• Опционального участия в демо;

• Обязательного участия в приемо-сдаточных испытаниях для отчетов (минимум один участник от каждого направления отчетности);

• Опционального участия в еженедельных рабочих группах по приемке отчетности.

Мы не привлекали заказчика для:

• Планирования бэклогов команд на спринт;

• Исследования, декомпозиции и приоритизации фич Superset;

• Согласования дизайна инструмента построения отчетности;

• Согласования технологической документации;

• Участия в технологических приемо-сдаточных испытаниях (например, в случае тестирования шифрования, полномочий ТУЗ, интеграционных взаимодействий и т.п.).

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

Результаты работы

Мы добились поставленных результатов, завершив проект. Весь скоуп проекта выполнен с соблюдением первоначально определенных параметров по срокам и бюджету.

Результатом проекта стала импортонезависимая система, включающая:

• Набор инструментов на базе Apache Superset для замещения технологии SAPBusinessObjects в части построения аналитических отчетов, форм ввода и дэшбордов;

• Отчетность на целевом стеке – 293 отчета (193 аналитических отчета, 66 форм ввода и 28 дэшбордов);

• Хранилище данных на базе ArenaData DB и ClickHouse (на оба компонента 18 000+ таблиц и представлений).

В новой системе обеспечена поддержка ключевых бизнес-процессов формирования управленческой отчетности для внутрихозяйственной деятельности ВТБ, включая отчеты по расходам Сети банка, ИТ, а также отчетности для департамента по работе с персоналом. Обеспечен бесшовный переход на новый стек для 750+ пользователей отчетности.

Завершая статью, авторы хотели бы поблагодарить команду проекта и всех его стейкхолдеров. Это было славное путешествие и для нас было честью двигаться вместе с вами.