Как «приготовить» Data Quality

Универсальной инструкции или рецепта правильного внедрения процессов управления качеством данных, подходящей любой компании, разумеется, не существует. Тем не менее есть основные этапы, которые должны быть пройдены для «приготовления» того самого идеально выверенного Data Quality (DQ).

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

Ставим цели

Банально говорить о значении правильной постановки целей, но это шаг номер 0. Цели могут быть разные и зависеть от потребностей компании. Например: снизить возможные риски от использования некачественных данных в операционных процессах в компании в целом или для какого-то конкретного подразделения. Другой вариант: избежать репутационных рисков или иных издержек при предоставлении вовне данных.

Пример: Компания планирует увеличить качество данных на 95% за три года. С точки зрения измеримости — отлично. Но каких именно данных, всех, которые есть в компании? И увеличение на 95% по отношению к чему? Увы, цель до конца не продумана.

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

Определяем объем данных

Амбициозные цели по повышению качества всех данных, которые есть в компании — здорово. Но давайте не забывать про закон Парето 20/80.

Фреймворк DAMA (Data Management) предлагает сфокусироваться на определении наиболее критичных для организации данных и внедрять процесс управления качеством данных именно для этого объема. Дополню, что определенный ранее объем для внедрения DQ должен полностью соотносится с целями.

Пример: В компании фокус внедрения процессов DQ был направлен на данные, получаемые от внешних контрагентов. Именно этот объем данных и был определен для проекта.

Cовет: при определении объема данных (или сущностей) для внедрения DQ наиболее подходящим инструментом будет дата-каталог/бизнес-глоссарий/др. Это одна из связей с областью управления метаданными. Также это может быть важно при построении дорожной карты для полноценного внедрения процессов Data Governance.

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

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

Здесь сложно привести пример, потому что требования к качеству уникальны для каждого датасета.

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

Декомпозируем требования к DQ

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

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

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

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

Совет: к данному шагу в контексте типизации лучше возвращаться несколько раз и двигаться итеративно, так как предусмотреть заранее все невозможно.

Управление инцидентами

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

Это один из ключевых шагов всего «рецепта», в котором как раз важен и сам процесс, и участники (то есть роли) и технологии – то, из чего и состоит Data Quality. Инцидент-менеджмент должен ответить, как минимум, на следующие вопросы: как часто отправляются результаты выполнения проверок DQ; каким ролям; каким способом; какие действия необходимо предпринять для ошибок разного уровня критичности; в какие сроки. Часто данный этап включает оформление различных SLA с потребителями данных.

Пример: В компании была настроена ежедневная рассылка с результатами выполнения проверок DQ ответственным лицам, которая содержала указание на конкретную строку с ошибкой и рекомендации по дальнейшим действиям.

Совет: идея с SLA по инцидентам качества данных довольно популярна. Но чтобы это реально работало, необходимо предусмотреть мотивационные механизмы.

Анализ первопричин

Управление инцидентами — важный процесс, но главная цель — сократить количество возникающих инцидентов. Для этого используют инструмент root cause анализа. Если инцидент-менеджмент можно сравнить со срочным ремонтом, то анализ первопричины скорее похож на замену или даже апгрейд детали. Разумеется, важно не только определить первопричину возникновения ошибок качества данных, но и определить способ ее устранения.

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

Совет: Разделяйте root cause анализ и процесс инцидент-менеджмента, так как у этих разные задачи и уровень выполняемых действий.

Оцениваем результаты

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

На этом этапе создаем дашборд, который отражает текущее состояние качества данных и динамику за необходимый период. В данном случае речь идет не просто о визуализации данных с ошибками, а о методике расчета интегральных (или комплексных) показателей. Эта задача нетривиальная, если принять во внимание: наличие разных уровней критичности правил DQ, которые могут отличаться от датасета к датасету, наличие разных типов правил с точки зрения обрабатываемых строк в датасете, наличие кросстабличных проверок и др.

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

Совет: приведу формулу из DAMABoK, основного «учебника» для всех, кто работает с Data Governance, по расчету показателей результатов DQ, который лучше меня опишет, как надо действовать (r — rule, то есть в разрезе конкретного правила):