От «Дата-ада» к знаку качества

В любой современной компании бизнес-процессы, ИТ-системы и цифровые продукты одновременно и потребляют, и генерируют данные, качество которых определяет успех деятельности всей компании. В 2021 году в «М.Видео-Эльдорадо» была принята стратегия по управлению данными, затрагивающая дата-офис и весь цифровой блок ретейлера, включая сотрудников операционных подразделений. Данила Наумов, CDO «М.Видео-Эльдорадо» и номинант на премию Data Award 2024, рассказывает о роли качества данных в общем процессе управления ими, а также о влиянии данных на бизнес компании.

Почему стало актуальным обеспечение качества данных?

К середине 2023 года мы подошли достаточно зрелыми с точки зрения управления данными: внедрен фреймворк Data Mesh, сформированы десять доменов данных со своими инженерными командами, данные воспринимаются как динамическая сущность — продукт со своими метриками и планами развития, назначены владельцы данных. Развернута централизованная платформа данных, включающая в себя ETL, хранилища, BI, инструменты MLOps, а также наш собственный каталог данных M.Data. Кроме того, в компании внедрен федеративный орган — Дата Комитет, состоящий из владельцев доменов данных и представителей корпоративных функций архитектуры и информационной безопасности. Комитет определяет корпоративные политики работы с данными и согласует планы по развитию платформы данных.

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

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

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

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

На что был сделан акцент?

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

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

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

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

Какие цели предполагалось достигнуть?

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

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

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

Как изменился процесс по управлению качеством данных?

Раньше при обнаружении проблемы с данными пользователь в худшем случае самостоятельно исправлял данные в своем дата-активе, например внутри выгрузки в Excel, в компании появлялась новая, более качественная версия данных, но остальные пользователи продолжали работать с некачественными данными. Стандартный процесс выглядел следующим образом (рис. 1). Пользователь заводил инцидент в службу поддержки, которая вносила минорное изменение в дата-актив, если оно не требовало существенных доработок. В ином случае поддержка обращалась к соответствующей инженерной команде (конвейер данных), которая в свою очередь узнавала у пользователя требуемые изменения. Если пользователь не являлся владельцем дата-актива, изменения согласовывались с владельцем данных. Далее команда разработки модифицировала дата-актив, а с владельцем данных проводилось приемочное тестирование. В конце концов владелец подтверждал качество данных и передавал обновление на поддержку. Из-за этой сложной и продолжительной схемы нас в компании в шутку называли «дата-сатанистами» — служителями «Дата-ада».

Рис. 1. Стандартный процесс проверки качества данных

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

Рис. 2. Современная схема проверки качества данных

Из рис. 3 видно, какой использовался технологический стек.

Рис. 3. Технологический стек

Что можно считать новацией в этом проекте?

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

Как оценить пользу для бизнеса от решения?

Эффективность можно проиллюстрировать конкретными кейсами и бизнес-процессами, построенными на базе решения. Например, команда логистики при планировании перемещений и поставок товаров использовала весо-габаритные характеристики товара (ВГХ), полученные из системы ERP. В какой-то момент было обнаружено несоответствие данных фактическим значениям, в частности, не совпадали габариты товаров. DQ-команда выявила, что большинство аномальных значений выглядят как 1×1×1. Вместе с коллегами из команды мастер-данных выяснили, что заведение данных происходит сразу в нескольких системах: ВГХ для клиентов заводится в одной системе, а для внутренних пользователей — в другой. Поля были обязательными для заполнения, но не было контроля над процессом, поэтому нередко поля оставались пустыми. На момент внедрения проверки в системе значилось более 5 тыс. наименований с некорректными габаритами. Логисты брали средние значения ВГХ по товарной группе, и неправильные расчеты приводили к ошибкам маршрутизации, необходимости ручных корректировок при планировании рейсов, а это означает задержки и отмены клиентских заказов.

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

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

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

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

Каковы основные итоги и факторы успеха проекта?

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

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

Как планируется развивать проект?

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

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

Николай Смирнов (nsmirnov@osp.ru) — независимый автор (Москва).