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

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

Стратегия по управлению данными была принята в «М.Видео-Эльдорадо» в 2021 году. Она распространяется не только на дата-офис, но и на весь цифровой блок, а также сотрудников операционных подразделений. В ней особое место уделялось качеству данных, но начать активные работы по этому направлению компания смогла лишь к середине 2023 года, когда мы стали достаточно зрелыми с точки зрения управления данными.

Был внедрен организационный фреймворк Data Mesh, сформированы 10 доменов данных со своими инженерными командами. При этом данные стали восприниматься не как статичная, а как динамическая сущность, то есть продукт со своими метриками и планами развития, назначены владельцы данных. Появилась централизованная платформа данных, включающая в себя ETL, хранилища, BI, инструменты MLOps, а также самописный каталог данных M.Data.

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

Валидация, достоверность, консистентность

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

Пользователи, даже найдя данные в нашем каталоге данных M.Data, не могли понять достаточного ли качества эти данные для их задач и были вынуждены обращаться за поддержкой.

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

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

Независимые оценки по методологии CMMI Data Management Maturity подтвердили необходимость разработки политики управления качеством и достоверностью данных на основе критических элементов данных, а также рекомендовали расширить платформу данных инструментами мониторинга и контроля их качества.

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

По мере роста бизнеса появлялось все больше ключевых data-driven процессов. Так возникла необходимость реализовывать такие проверки быстро и дешево. Качество данных стало для компании очевидной зоной роста.

Фокус

Чтобы сформировать стратегическое видение по развитию качества данных, было важно определиться не только с тем, что надо делать, но еще и с тем, что точно не стоит делать. Изучив теорию, дата-аналитики компании выделили четыре блока управления качеством данных (Data Quality, DQ):

1. Мониторинг DQ в соответствии с заведенными правилами и проверками. Мониторинг не меняет сами данные, а считает показатели DQ для конкретного актива в системе-источнике или хранилище данных.

2. Профилирование. Это статистический контроль — например, количество значений, частотная характеристика значений. Профилирование может быть как инженерное (количество заполненных полей, пустые поля и др.), так и бизнесовое.

3. Управление инцидентами. По мере запросов от пользователей или возникновения в результате мониторингов инциденты необходимо фиксировать и обрабатывать.

4. Клинзинг — процесс исправления ошибок не только в отчете или хранилище, но еще и в системе-источнике.

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

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

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

На основе анализа потребностей были сформулированы требования для инструмента Data Quality.

Главных требования три:

1. Система должна преимущественно запускать проверки над теми же хранилищами платформы данных, в которых и хранятся данные. Запуск внутри инструмента DQ должен осуществляться только для кастомных проверок, требующих использования данных одновременно из нескольких систем.

2. Для масштабирования инструмента результаты проверок DQ должны представляться в нашей внутренней BI‑системе, привычной для всех. Иначе мы бы сосредоточились не на внедрении процесса, а на внедрении ИТ‑системы.

3. Система должна бесшовно интегрироваться с нашим самописным каталогом данных M.Data для отображения метрики DQ и истории проверок непосредственно в карточке дата‑актива.

Результат

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

Во-вторых, измеряется уровень качества данных. В каждом домене данных выделены критические элементы данных, по которым в динамике измеряется и отслеживается уровень качества данных, который доступен всем желающим.

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

В-четвертых, уже решено более 100 конкретных бизнес-кейсов. Теперь, можно масштабировать количество критичных элементов данных, не раздувая штат разработки и поддержки.

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

Принято считать, что демонстрацией зрелости в области управления качеством данных является и то, что в компании поставлены метрики качества в персональные KPI владельцам данных. CDO пришлось выступить амбассадором нововведения: он взял на себя самые востребованные дата‑активы: чеки, заказы, веб‑трафик, розничный трафик и основные справочники.

За первый квартал 2024 года дата‑аналитики замерили текущие показатели DQ по этим активам и поставили измеримые цели на второй квартал. Для владельцев других доменов данных во втором квартале 2024 года они сформируют показатели DQ по критическим элементам данных, и ставят цели на следующие кварталы.

«Мы приняли решение сделать собственный инструмент качества данных — M.DQ. Силами шести человек за три месяца инструмент был запущен в эксплуатацию. В следующие два месяца он был масштабирован на все инженерные команды дата-офиса в каждом домене данных».

До и после

Раньше если пользователь обнаруживал проблему с данными, он в самом худшем случае самостоятельно исправлял данные в своем дата‑активе — например, внутри выгрузки в Excel. Таким образом, в компании появлялась новая, более качественная версия данных, а остальные пользователи продолжали работать с некачественными данными.

Стандартный процесс выглядел следующим образом. Пользователь заводил инцидент в службу поддержки, которая вносила минорное изменение в дата‑актив, если оно не требовало существенных доработок. В ином случае поддержка обращалась в соответствующую инженерную команду (конвейер данных), которая в свою очередь узнавала у пользователя требуемые изменения. Если пользователь не являлся владельцем дата‑актива, изменения согласовывались с владельцем данных.

Далее команда разработки модифицировала дата‑актив, а приемочное тестирование проводилось с владельцем данных. В конце концов владелец подтверждал качество данных и передавал обновление на поддержку. Из‑за этой непростой схемы дата‑аналитиков в шутку называли дата‑сатанистами.

В текущей версии количество субъектов и сущностей остается тем же, но связующим дополнительным звеном становится инструмент Data Quality. Пользователь заходит в дашборд DQ, дата‑каталог или получает уведомление от системы мониторинга и видит текущий уровень качества данных.

Бизнес-эффект. Без цифр, но интересно

Эффективность нововведений можно показать на примере конкретных кейсов и бизнес-процессов, в которые было встроено это решение.

1. Команда логистики при планировании перемещений и поставок товаров использовала весогабаритные характеристики товара (ВГХ) из ERP. В какой‑то момент заметили это несоответствие данных фактическим значениям. В частности, не совпадали габариты товаров. DQ-команда выявила, что большинство аномальных значений выглядят как 1х1х1.

Аналитики вместе с коллегами из команды мастер-данных выяснили, что заведение данных происходит сразу в нескольких системах: ВГХ для клиентов заводится в одной системе, для внутренних пользователей – в другой. Поля были обязательными для заполнения, но не было никакого контроля над процессом, поэтому при заведении нередко указывали пустые значения.

На момент внедрения проверки в системе значилось более 5 тыс. наименований с некорректными габаритами. Логисты брали средние значения ВГХ по товарной группе, и неправильные расчеты приводили к ошибкам маршрутизации, необходимости ручных корректировок при планировании рейсов, а это означает задержки и отмены клиентских заказов.

2. Другой кейс — дубли чеков. Только за четвертый квартал 2023 года вторая линия поддержки дата-офиса обработала более 300 таких инцидентов качества данных. Это значит, что более 300 инцидентов не дошло до пользователей.

3. Еще один важный кейс для любого ритейлера — расчет премий для сотрудников розницы. Иногда не вся атрибутика чека бывает верно загружена: не везде определяется продавец, кассир и категория товара. Была осуществлена проверка, и теперь сотрудники компании заранее «отлавливают» отклонения и обрабатывают 150–200 обращений в месяц в рабочем режиме. При закрытии периода премия рассчитывается правильно.

4. И еще один пример с чеками. Компания передает фискальные данные в ФНС, а они в свою очередь сравнивают их с ОФД. Если есть хоть какое‑то отклонение, из ФНС поступает запрос в бухгалтерию на проверку и корректировку. Когда возникали случаи несовпадения данных по причине сбоев в передаче данных с локальных касс в ОФД, это фиксировалось бухгалтерией через личный кабинет JAL и требовало правок на стороне директора магазина.

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

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

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

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

Развитие проекта

Мы хотим, чтобы у всех владельцев доменов данных появилось персональное целеполагание, основанное на метриках качества данных по дата‑активам в их владении. Для этого они измеряют текущий уровень и согласовывают с владельцами целевые KPI по DQ.

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

Также через инструмент M.DQ мы хотим фиксировать контракты — то есть требования пользователей к данным, находящихся во владении у других, и проверять исполнение этих требований через проверки качества данных. И, естественно, планируют увеличивать количество дата‑активов с проверками качества данных, наращивать базу стандартных проверок для увеличения скорости внедрения проверок и улучшения качества данных.