Представим витрину с подтверждённой ошибкой. Пользователь завёл дефект, ИТ взяло его в работу, а светофор качества как был зелёным, так и остался.

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

Заодно переписали историю. Такой задачи, правда, никто не ставил.

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

Для исправления нужно добавить загрузку истории закрепления клиентов и пересчитать затронутые периоды. Это займёт время. Дефект признан, задача есть, команда работает.

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

Если зелёный статус означает «эти правила выполнены», он вполне честный. Но наверху этот светофор могут воспринять как результат работы с качеством данных: внедрили ещё 100500 DQ, покрытие выросло, по всем категориям зелёное. Есть о чём рассказать на очередном комитете.

А другие подразделения тем временем берут показатели из витрины в свои отчёты и расчёты. В обсуждении дефекта они не участвовали, на задачу не подписаны. Зато видят, что данные проверены и с качеством всё хорошо.

Так и получается: ИТ исправляет, обнаруживший ошибку пользователь ждёт, руководство отчитывается об успехах, а ошибочное распределение продаж за прошлые периоды продолжает использоваться дальше. Уже в отчётах людей, которые о проблеме вообще не знают.

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

Количество правил и доля охваченных ими витрин позволяют отслеживать внедрение DQ. Подменять ими качество и осмысленность контроля недопустимо.

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

Впрочем, может, мы просто верим в переход количества проверок в качество данных. Гегель бы одобрил.

#DataQuality #DQ #DataEngineering #DataGovernance #DWH #СистемноеМышление