Когда два отчета правы: почему данные расходятся

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

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

У каждой ошибки своё измерение

Обычно данные оценивают по нескольким характеристикам. Точность означает соответствие реальному объекту или событию. Полнота — наличие необходимых значений. Согласованность — отсутствие противоречий между системами. Актуальность показывает, успели ли сведения обновиться к моменту использования. Валидность отвечает за соответствие формату и бизнес-правилам, уникальность — за отсутствие лишних дублей. Эти шесть измерений выделяет IBM.

Вернёмся к отчёту. Повторная карточка клиента нарушает уникальность, пустой ИНН — полноту, разные категории покупателя в двух системах — согласованность. Вчерашняя выгрузка может быть безошибочной, но уже неактуальной. Исправлять всё одной «очисткой базы» бессмысленно: у дефектов разные причины и способы контроля.

Проверка начинается с бизнес-правила

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

Затем требование переводят в правило. Например: ИНН обязателен для юридического лица; дата отгрузки не может предшествовать дате заказа; идентификатор клиента не должен повторяться; выгрузка должна обновляться до начала рабочего дня. Такие правила можно запускать по расписанию, измерять долю прошедших проверку записей и задавать порог приемлемого результата. Как показывает Microsoft, показатель полноты 92% пройдёт порог 90%, но не пройдёт порог 95%.

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

Ошибку важно ловить до отчёта

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

Контроль полезнее ставить там, где проблема возникает или передаётся дальше: при вводе, обмене между системами и загрузке в хранилище. Результаты проверок нужно отслеживать во времени. Резкое падение полноты после изменения формы или рост дублей после объединения баз укажут не только на плохие записи, но и на источник сбоя.

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