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

Данные составляют фундамент для принятия оптимальных управленческих и операционных решений, однако для его построения необходимо не только развернуть полный набор сервисов обработки данных, включающий хранение данных и формирование отчетности, помогающей повысить уровень зрелости компании с базового уровня “data aware” до уровня “data-driven” [1] для текущей модели бизнеса, но и построить культуру работы с данными для ускорения «второй производной» от работы с данными — сокращение времени вывода продуктов и сервисов на рынок, начиная от идей по новым элементам стратегии и заканчивая оценкой их эффективности и монетизации.

Вполне естественно, что одной из ключевых для решения поставленных перед компанией задач стала практика Data Governance: процессы и инструменты (каталог данных, система управления качеством данных, управление нормативно-справочной информацией). Конечно, инструменты важны, но вторичны.

Если посмотреть на «колесо» DMBOK [2], охватывающее различные аспекты эффективного управления данными, можно сделать вывод, что для каждого сектора имеется свой инструмент или их набор. Поэтому если в компании, например, принят уровень детализации до департамента, то для аудита состояния эффективности внедрения процессов необходимо будет построить свое хранилище метаданных и далее по своим правилам объединять метаданные в нужных разрезах. Однако посмотрим внимательнее на сектор «metadata management» и «каталог данных». Какой здесь скрывается набор действий? Попробуем расширить его с таких классических понятий, как «таблица», «представление», «отчет», на различные типы артефактов, которые потребуются в процессе аудита эффективности практик управления данными: системы управления справочными данными (Reference Data Management Systems, RDM), «ML-модель», «глоссарий», «бизнес-процесс» и т. д. Если добавить сюда возможность связывания всего этого в граф, то получим универсальную модель, по которой можно двигаться от стратегии до элементов инфраструктуры (рис. 1).

Рис. 1. Пример полного графа метаданных

В конце 2021 года в компании использовалась проприетарная система класса «каталог данных» компании Collibra, обеспечивающая гибкость как метамодели, так и ролевой модели. Однако система имела очень перегруженный интерфейс, не говоря уже о высокой стоимости экстракторов метаданных (коннекторов к различным типам СУБД), а также ограниченное количество лицензий редакторов (пользователей, имеющих возможность что-либо редактировать в каталоге). Кроме этого, система закрыта, а приоритеты внедрения новых возможностей традиционно были в пользу крупных заказчиков. При этом процесс импорта данных для решения задач аналитики представлял из себя мощную смесь наших собственных разработок, расширяющих стандартный технический стек ETL-процессинга.

Опыт внедрения каталогов данных показывает, что инициативы «снизу» — от технических специалистов рано или поздно приводят к провалу проекта внедрения инструментов работы с метаданными — бизнес не понимает их ценности либо понимает, но не участвует в процессах актуализации метаданных. В итоге задачи актуализации метаданных постепенно отходят на второй план, а со сменой ИТ- и дата-команд подобные инструменты и вовсе забрасываются.

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

Итак, необходимо было реализовать репозиторий метаданных (каталог данных), удовлетворяющий следующим требованиям:

  • гибкая метамодель и ролевая модель для возможности оперативной подстройки под процессы;
  • релевантный и настраиваемый поиск — одна из ключевых свойств любых каталогов;
  • разнообразные интерфейсы взаимодействия, позволяющие подстраиваться под бизнес-процессы и увеличивать охват пользовательской аудитории для различных когорт пользователей — не только для специалистов по данным, но и по технологиям и бизнесу (системные аналитики, архитекторы, методологи, бизнес-аналитики);
  • дружественный интерфейс, максимально облегчающий учет пользовательского опыта.

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

С учетом ограниченного срока реализации проекта была введена строгая приоритезация задач по созданию каталога данных, но изначально была предложена целевая архитектура поддержки универсальности метамодели и ролевой модели. Корневая архитектура состоит из универсальных объектов хранения данных: asset — описание произвольного артефакта, attribute — описание произвольного свойства артефакта, relation — описание произвольного отношения между активами, relation attribute — описание свойств отношения (рис. 2).

Рис. 2. Упрощенная схема модели хранения метаданных

Расширение метамодели происходит без участия разработчика, а карточка актива в интерфейсе имеет универсальный вид.

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

Рис. 3. Общая схема позиционирования каталога данных в корпоративном ландшафте

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

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

При выбранном подходе каталог данных может служить базовым инструментом CMDB [3] для ИТ-департамента или репозиторием корпоративной архитектуры для домена корпоративной архитектуры.

На сегодняшний день (за почти год эксплуатации) каталогом данных пользуется более 400 пользователей без учета пользователей метаданных вторичных интерфейсов; уникальных должностей пользователей каталога около 70; различных типов заведенных артефактов — 16; уникальных сервисов потребителей метаданных — четыре. Как инструмент и процесс Data Governance каталог демонстрирует гибкость в подключении различных ролей и новых когорт пользователей, принимающих участие в поддержке экосистемы метаданных.

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

***

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

Литература

1. Erin Pearson. The Journey from Data-Aware to Data-Driven: Transforming Enterprise Analytics Maturity. URL: https://www.evalueserve.com/blog/the-journey-from-data-aware-to-data-driven-transforming-enterprise-analytics-maturity (дата обращения: 31.12.2024).

2. Антон Смирнов, Евгений Виноградов. Как без потерь оценить актуальный уровень зрелости компании // Открытые системы.СУБД. — 2023. — № 4. — С. 33–35. URL: https://www.osp.ru/os/2023/04/13057871 (дата обращения: 31.12.2024).

3. Александр Александров. Конкретно о CMDB // Открытые системы.СУБД. — 2007. — № 6. — С. 45–51. URL: https://www.osp.ru/os/2007/06/4339018 (дата обращения: 31.12.2024).

Руслан Ахметзянов (Ruslan.Ahmetzyanov@lemanapro.ru) — руководитель направления Data Governance, «Лемана ПРО» (Москва). Статья подготовлена на основе материалов выступления на форуме «Управление данными 2024».