Задачи бизнеса и проблема данных
Сегодня бизнес хочет принимать решения, основываясь на данных, а не на ощущениях, тем более что сейчас для этого есть все возможности. Предприятия накопили терабайты и эксабайты данных, их количество растет в геометрической прогрессии каждый день.
Как повлиял ковид на ценообразование загородной недвижимости? Какой регион выбрать для новой мебельной фабрики? Вложиться в жилой комплекс эконом или бизнес-класса? Какие факторы влияют на продление ДМС? Как должно работать индивидуальное автострахование?
В наши дни ты должен быть data-driven или проиграешь.
Сырые данные предприятия проходят большой путь, чтобы превратиться в управленческие решения. Этот путь включает такие шаги как:
выделение мастер‑данных (данных, критично важных для работы предприятия);
определение лучших источников этих данных — выбор источников из всего зоопарка интегрированных друг с другом систем предприятия;
преобразование данных из разных систем к единому формату, создание так называемой «единственной версии правды»
Далее появляются метрики и дименшены, графики и дашборды, витрины данных и прочая Business Intelligence. Но какие бы замечательные ETL и BI-инструменты не были заложены в эту цепочку, все испортить может качество исходных данных.
Мусор на входе – мусор на выходе, и не важно от какого шеф-повара рецепт.
Хорошо, если бизнес сразу распознает плохое качество данных на дашборде (“не может такого быть, чтобы продажи в этом месяце настолько упали”), хуже если плохие данные так и не будут распознаны и бизнес-решения будут приняты на неверных данных.
Почему данные бывают плохими?
Пользовательские ошибки, ошибки интеграций, миграций, трансформаций, несовершенное качество используемых сторонних систем, плохая адаптация ПО под бизнес-процессы предприятия – вот каналы возникновения некачественных, то есть неполных, противоречивых, ненадежных и попросту неверных исходных данных. Причем, чем более старые данные мы хотим использовать для анализа, тем больше вероятность, что придется разгребать кучи мусора. Ошибки в ПО исправляют постоянно, ошибки в данных, вызванные ошибками ПО, далеко не всегда.
Рассмотрим такой кейс. Предположим, у страховой компании есть филиалы, которые ведут договора страхования в разных учетных системах, с разной моделью данных, словарями и прочим. Но управляющая компания хочет иметь сквозной отчет по договорам по всем филиалам, чтобы там сравнивалось сравнимое и складывалось складываемое. Для этого мастер-данные из разных филиалов необходимо иметь в едином формате, с унифицированными видами договоров, статусами, ключевыми датами и т. п. В идеале это могло бы выглядеть так:
Данные о договорах в разных форматах поступают из разных систем, преобразуются в единый выверенный формат, дополняются данными о клиенте из CRM системы и складируются в корпоративное хранилище данных. Аналитическая система в итоге работает с договорами единообразно, не обращая внимания на то, откуда они пришли.
Но в реальной жизни исходные данные поступают из систем предприятия с разной степенью некачественности:
Кроме того, алгоритмы преобразования данных, заложенные в ETL (Extract-Transform-Load), редко удается сделать такими как нужно с первого раза:
В итоге вместо готового для анализа хранилища договоров получается что-то такое:
Аналитическая система, пытаясь работать с такими данными, или спотыкается или выдает ерунду.
Что делать? Выявление некачественных данных
Согласно Gartner Analyst group одной из важных причины неуспешности систем корпоративных данных является отсутствие политики предприятия в области качества данных, отсутствие технически реализованных инструментов для постоянного мониторинга этого качества или задержка внедрения таких инструментов.
На нашем проекте руководству удалось выстроить систему работы с мастер-данными предприятия, включая:
создание единого словаря терминов, метрик, моделей данных;
создание политик, инструкций в области качества данных;
выделение отдельного подразделения, назовем его Отдел качества данных, обладающего широкими полномочиями;
организацию еженедельных кросс-командных встреч для решения вопросов, связанных с потоками данных в рамках бизнес-процессов предприятия.
Отдел качества данных подготовил первоначальный набор правил, которым должны соответствовать данные – Data Quality правил. Техническая команда реализовала несложное решение постоянного мониторинга качества данных.
Data Quality (DQ) правила в виде SQL-запросов хранятся в отдельной базе, каждую ночь эти правила автоматически запускаются на хранилище данных (разные правила могут запускаться на разных базах). Результаты ежедневных проверок сохраняются. По каждому правилу записывается количество проверенных записей, количество успехов, количество ошибок и ключи ошибочных записей.
DQ-правила могут быть простыми, «техническими» - проверка на пустые значения, проверка на дубликаты, или банально на то, что дата подписания договора не может быть больше даты конца договора. Конечно, само наличие таких ошибок говорит о том, что плохо сделана валидация в том ПО, где эти данные создавались, и в идеале эту валидацию надо просто настроить. Но в реальной жизни предприятия часто работают со сторонним, часто старым ПО и не всегда могут влиять на возможность и сроки исправления ошибок этого ПО. Да и испорченные старые данные никуда не деваются даже после того, как валидацию улучшили.
Кроме того, подобные ошибки могут возникать при добавлении новой функциональности. Ошибки в данных часто замечают с гораздо большей задержкой, чем ошибки в интерфейсе или бизнес-логике. Бывают ошибки данных, которые не мешают работать оперативному персоналу, и в этом кроется их опасность.
DQ-правила могут быть более «бизнесовыми», отслеживающими непротиворечивость данных в разных системах или соответствие законодательству/бизнес-правилам. Например, ошибки в выставленных процентных ставках ипотечного страхования из-за неверно введенной стоимости жилья.
Инициаторами новых Data Quality правил может выступать как Отдел качества данных, так и любое другое подразделение компании, и в том числе техническая команда дата хаба. Часто новые правила инициирует команда BI-отчетности. Детальную логику правила на уровне таблиц и связей разрабатывают Отдел качества и команда корпоративного хранилища. Важным моментом может являться выбор – проверять исходные данные – до их преобразований в единую модель, или проверять уже преобразованные данные. В первом случае быстрее можно найти корневую причину неверных данных, но, с другой стороны, устранение найденной причины не гарантирует, что после преобразования все будет как ожидается. Во втором случае наоборот.
Отдел качества данных мониторит ситуацию с правилами с помощью дашбордов. Например, на графиках ниже можно увидеть такие ситуации:
Ошибки по данному правилу продолжают появляться, справиться с их возникновением пока не удалось.
Ошибки по этому правилу медленно накапливались, потом произошел резкий скачок, что заставило найти решение и устранить причину появления ошибок, заодно исправили старые данные.
Ситуация похожа на предыдущую, только полностью устранить ошибки не удалось, но они находятся на стабильно низком уровне.
Ситуация с этими ошибками хоть и медленно, но улучшается.
Что делать? Исправление некачественных данных
Хорошо, ошибки мы выявили, что с ними делать? Как и с ошибками ПО ошибки данных хорошо бы а) устранять и б) предотвращать их повторное появление.
Работой надо ошибками занимаются Отдел качества данных и техническая команда в тесном сотрудничестве.
Техническая команда для улучшения качества данных может:
Выявить корневые причины ошибок.
Разово исправить ошибочные данные.
Усовершенствовать ETL/модель данных, если ошибки связаны с их несовершенством.
Вместе с бизнесом определить альтернативные, дополнительные источники для неполных данных.
Создавать алгоритмы автоматического исправления данных на основании аппроксимации и т.п. (здесь просится использование ИИ).
Анализ ошибок Отделом качества данных может привести к:
Изменению бизнес-процессов предприятия. Например, смене подразделений-владельцев данных, изменению порядка согласования данных и другим изменениям в data flow.
Смене используемого ПО или его доработкам.
Изменению интеграции систем предприятия. Например, оставить одну точку входа для ввода информации о клиентах, откуда она будет перетекать в другие системы.
Дополнительным инструкциям, обучению и мотивации пользователей.
Увольнению администратора CRM системы и др.
Подводя итоги
Когда наша команда пришла на текущий проект, компания уже больше года не могла запустить в бизнес-использование созданную BI-отчетность. Ни у оперативного, ни у управленческого персонала не было и толики доверия к тому, что показывают дашборды. Еще почти целых два года мы занимались практически исключительно качеством данных в тесном взаимодействии бизнеса и айти-команды.
На данный момент на нашем не очень масштабном проекте порядка 100 различных Data Quality правил. И полностью согласно Gartner Analyst group только когда на проекте заработало управление качеством данных (выявление, мониторинг, исправление, предупреждение ошибок, совершенствование процессов), только тогда на предприятии в полную силу заработала и Business Intelligence.
