Стратегия по управлению данными была принята в «М.Видео-Эльдорадо» в 2021 году. Она распространяется не только на дата-офис, но и на весь цифровой блок, а также сотрудников операционных подразделений, ведь каждый бизнес — процесс, ИТ-система, цифровой продукт — является и потребителем, и генератором данных. О том, какая роль в управлении данными отводится их качеству, и об их влиянии на бизнес, рассказывает Данила Наумов, CDO «М.Видео-Эльдорадо» и номинант на премию Data Award.
— Почему обеспечение качества данных стало актуальным для «М.Видео-Эльдорадо», да и ретейла в целом?
К середине 2023 года мы подошли достаточно зрелыми с точки зрения управления данными. У нас внедрен организационный фреймворк Data Mesh, сформированы 10 доменов данных со своими инженерными командами. При этом данные воспринимаются не как статичная, а как динамическая сущность, то есть продукт со своими метриками и планами развития, назначены владельцы данных. Есть централизованная платформа данных, включающая в себя ETL, хранилища, BI, инструменты MLOps, а также самописный каталог данных M.Data.
Кроме того, в компании внедрен федеративный орган – Дата Комитет, состоящий из владельцев доменов данных и представителей корпоративных функций архитектуры и информационной безопасности. Он устанавливает корпоративные политики в области работы с данными и согласует планы по развитию платформы данных.
Качество данных стало для нас очевидной зоной роста. Во-первых, мы занимались «тушением пожаров» вместо того, чтобы действовать проактивно. Мы узнавали об инцидентах с данными от пользователей и только после их обращения в поддержку. Во-вторых, хотя у нас уже были сформированы проверки качества для наиболее чувствительных данных, они являлись уникальными разработками со своей спецификой. Например, продукт по управлению ассортиментом магазинов крайне отзывчив к качеству данных – как загружаемых, так и расчетных. Стоимость потерь для компании в случае несвоевременной загрузки данных в этом продукте оценивалась в 60 млн руб. в день. Внедрение каждой новой проверки качества данных становилось долгой и ресурсоемкой задачей, не поддающейся масштабированию и переиспользованию. По мере роста бизнеса появлялось все больше ключевых data-driven процессов. Так возникла необходимость реализовывать такие проверки быстро и дешево.
— Какие из проблем были наиболее чувствительными?
Согласно внутренним опросам, отсутствие контроля за качеством данных входило в тройку «больных вопросов» по управлению данными, а повышение качества данных (валидация, достоверность, консистентность) – в тройку ожиданий. Пользователи, даже найдя данные в M.Data, не могли понять, достаточного ли качества эти данные для их задач и были вынуждены обращаться за поддержкой. И, наконец, из-за отсутствия процессов и политик управления качеством данных у владельцев данных просто не было возможности ставить долгосрочные и среднесрочные цели по развитию их активов.
Независимые оценки по методологии CMMI Data Management Maturity подтвердили необходимость разработки политики управления качеством и достоверностью данных на основе критических элементов данных, а также рекомендовали расширить платформу данных инструментами мониторинга и контроля их качества.
— На чем вы фокусировались при повышении качества данных?
Чтобы сформировать стратегическое видение по развитию качества данных, нам было важно определиться не только с тем, что мы делаем, но еще и с тем, что мы точно не делаем. Изучив теорию, мы выделили четыре блока управления качеством данных (Data Quality, DQ).
Первый из них – мониторинг DQ в соответствии с заведенными правилами и проверками. Мониторинг не меняет сами данные, а считает показатели DQ для конкретного актива в системе-источнике или хранилище данных. Второй блок – профилирование. Это статистический контроль – например, количество значений, частотная характеристика значений. Профилирование может быть как инженерное (количество заполненных полей, пустые поля и др.), так и бизнесовое. Третий блок – управление инцидентами. По мере запросов от пользователей или возникновения в результате мониторингов инциденты необходимо фиксировать и обрабатывать. И, наконец, клинзинг – процесс исправления ошибок не только в отчете или хранилище, но еще и в системе-источнике.
.jpg) |
| Рассылка в Telegram по инциденту на свежесть данных |
— Что из этого оказалось важнее всего?
Проанализировав боли и ожидания, мы решили, что важнее всего сфокусироваться именно на мониторинге. Например, у команды логистики 95% проблем касались несвоевременной или неполной загрузки данных в хранилище.
Проверку качества данных над транзакционными системами-источниками мы решили оставить вне рамок нашего проекта, так как DQ-проверки – весьма ресурсоемкая операция, зачастую требующая полного сканирования, что сильно снизило бы производительность транзакционных систем. DQ-проверки в транзакционных системах релевантны только при распределенных транзакциях, и даже в этом случае сканирование будет осуществляться силами команд этих транзакционных систем. При этом, если мы на стороне аналитических систем находим ошибки, мы должны передавать информацию о них в команды исходных систем.
— Если обобщить, то какие цели перед вами стояли?
Мы хотели выстроить процесс управления DQ и обучить ему как инженерные команды дата-офиса и представителей других цифровых команд, так и операционные функции. Кроме того, требовалось внедрить дешевый, быстрый и автоматизированный инструмент, а также упростить предоставление информации о результатах проверок всем категориям заинтересованных пользователей. И, наконец, выстроить процесс и механизм передачи информации об ошибке в данных на сторону систем-источников.
— Как изменился процесс по управлению качеством данных?
Раньше если пользователь обнаруживал проблему с данными, он в самом худшем случае самостоятельно исправлял данные в своем дата-активе – например, внутри выгрузки в Excel. Таким образом, в компании появлялась новая, более качественная версия данных, а остальные пользователи продолжали работать с некачественными данными.
Раньше наш стандартный процесс выглядел следующим образом. Пользователь заводил инцидент в службу поддержки, которая вносил минорное изменение в дата-актив, если оно не требовало существенных доработок. В ином случае поддержка обращалась в соответствующую инженерную команду (конвейер данных), которая в свою очередь узнавала у пользователя требуемые изменения. Если пользователь не являлся владельцем дата-актива, изменения согласовывались с владельцем данных. Далее команда разработки модифицировала дата-актив, а приемочное тестирование проводилось с владельцем данных. В конце концов владелец подтверждал качество данных и передавал обновление на поддержку. Из-за этой непростой схемы нас в шутку называли дата-сатанистами.
В текущей версии количество субъектов и сущностей остается тем же, но связующим дополнительным звеном становится инструмент Data Quality. Пользователь заходит в дашборд DQ, дата-каталог или получает уведомление от системы мониторинга и видит текущий уровень качества данных.
.jpg) |
| Рассылка в почту на статистическое отклонение |
— Есть ли у вас требования для инструмента Data Quality?
Конечно, мы сформулировали их на основе анализа потребностей. Главных требований три.
Система должна преимущественно запускать проверки над теми же хранилищами платформы данных, в которых и хранятся данные. Запуск внутри инструмента DQ должен осуществляться только для кастомных проверок, требующих использования данных одновременно из нескольких систем.
Для масштабирования инструмента результаты проверок DQ должны представляться в нашей внутренней BI-системе, привычной для всех. Иначе мы бы сосредоточились не на внедрении процесса, а на внедрении ИТ-системы.
Система должна бесшовно интегрироваться с нашим самописным каталогом данных M.Data для отображения метрики DQ и истории проверок непосредственно в карточке дата-актива.
— Можно ли назвать то, что вы сделали, инновационным?
В общем-то, да. Мы приняли решение сделать собственный инструмент качества данных — M.DQ. Силами шести человек за три месяца инструмент был запущен в эксплуатацию. В следующие два месяца он был масштабирован на все инженерные команды дата-офиса в каждом домене данных.
.jpg) |
| Интеграция метрик Data Quality в карточку дата актива в каталоге данных |
— Измеряли ли эффективность проекта? Как оценить пользу для бизнеса от решения?
Эффективность можно показать на примере конкретных кейсов и бизнес-процессов, в которые было встроено это решение.
Например, команда логистики при планировании перемещений и поставок товаров использовала весогабаритные характеристики товара (ВГХ) из ERP. В какой-то момент коллеги заметили несоответствие данных фактическим значениям. В частности, не совпадали габариты товаров. DQ-команда выявила, что большинство аномальных значений выглядят как 1х1х1. Вместе с коллегами из команды мастер-данных выяснили, что заведение данных происходит сразу в нескольких системах: ВГХ для клиентов заводится в одной системе, для внутренних пользователей – в другой. Поля были обязательными для заполнения, но не было никакого контроля над процессом, поэтому при заведении нередко указывали пустые значения. На момент внедрения проверки в системе значилось более 5 тыс. наименований с некорректными габаритами. Логисты брали средние значения ВГХ по товарной группе, и неправильные расчеты приводили к ошибкам маршрутизации, необходимости ручных корректировок при планировании рейсов, а это означает задержки и отмены клиентских заказов.
Другой кейс – дубли чеков. Только за четвертый квартал 2023 года вторая линия поддержки дата-офиса обработала более 300 таких инцидентов качества данных. Это значит, что более 300 инцидентов не дошло до пользователей. Мы считаем, что демонстрацией зрелости в области управления качеством данных является и то, что мы поставили метрики качества в персональные KPI владельцам данных. Мне пришлось выступить амбассадором нововведения: я взял на себя самые востребованные дата-активы: чеки, заказы, веб-трафик, розничный трафик и основные справочники. За первый квартал 2024 года мы замерили текущие показатели DQ по этим активам и поставили измеримые цели на второй квартал. Для владельцев других доменов данных во втором квартале 2024 года мы сформируем показатели DQ по критическим элементам данных, и поставим цели на следующие кварталы.
Еще один важный кейс для любого ретейлера – расчет премий для сотрудников розницы. Иногда не вся атрибутика чека бывает верно загружена: не везде определяется продавец, кассир и категория товара. Была осуществлена проверка, и теперь наши коллеги заранее «отлавливают» отклонения и обрабатывают 150-200 обращений в месяц в рабочем режиме. При закрытии периода премия рассчитывается правильно.
И последний пример. Как известно, мы передаем фискальные данные в ФНС, а они в свою очередь сравнивают их с ОФД. Если есть хоть какое-то отклонение, из ФНС поступает запрос в бухгалтерию на проверку и корректировку. Когда возникали случаи несовпадения данных по причине сбоев в передаче данных с локальных касс в ОФД, это фиксировалось бухгалтерией через личный кабинет ОФД и требовало правок на стороне директора магазина. Конечно же, инциденты возникали в последний момент перед закрытием отчетного периода, что вызывало проблемы. Сейчас эти отклонения выявляются заблаговременно.
— Каковы основные итоги проекта?
Во-первых, мы успешно выстроили процесс управления качеством данных. Теперь при создании и изменении дата-активов силами инженерных команд конвейеров данных заказчику предлагается создать проверки DQ. Во-вторых, мы измеряем уровень качества данных. В каждом домене данных выделены критические элементы данных, по которым в динамике измеряется и отслеживается уровень качества данных, который доступен всем желающим. В-третьих, мы сократили срок реализации проверок DQ с двух недель до четырех часов. Теперь стандартные проверки может создавать даже представитель операционной функции, а разработчики не тратят время на сопутствующие процессы (оповещение, хранение и т.п.). В-четвертых, уже решили более 100 конкретных бизнес-кейсов. Наконец, мы можем масштабировать количество критичных элементов данных, не раздувая штат разработки и поддержки.
.jpg) |
— В чем заключаются основные факторы успеха?
Очень помогла поддержка со стороны дата-архитекторов, и корпоративных архитекторов. Важную роль сыграло выделение отдельной команды для разработки инструмента. Кроме того, правильным было подключение центральной второй линии поддержки дата-офиса. Возможность передачи DQ-проверок, созданных с помощью общего инструмента, являлась решающим фактором, чтобы команды стали приобщаться к инструменту, а не плодить собственные наработки. И для любого подобного проекта важна удобная система оповещения в разных каналах.
— Каковы направления развития проекта?
Мы хотим, чтобы у всех владельцев доменов данных появилось персональное целеполагание, основанное на метриках качества данных по дата-активам у них во владении. Для этого мы замеряем текущий уровень и согласовываем с владельцами целевые уровни.
Также через инструмент M.DQ мы хотим фиксировать контракты – то есть требования пользователей к данным, находящихся во владении у других, и проверять исполнение этих требований через проверки качества данных. И, естественно, планируем увеличивать количество дата-активов с проверками качества данных, наращивать базу стандартных проверок для увеличения скорости внедрения.
.jpg)
