Что значит «качественные данные» для вашей задачи?
Универсального стандарта «чистых данных» не существует. Набор данных достаточно хорош, если он позволяет принять нужное решение с ограничениями, которые вас устраивают. Поэтому начинайте с цели: какие поля обязательны для этого отчёта или процесса, какие форматы допустимы, по каким идентификаторам связываются записи и насколько свежими должны быть данные. Записывайте эти требования отдельно для каждого отчёта или процесса: одна и та же таблица может вполне подходить для месячного обзора и совершенно не подходить для автоматического выставления счетов. С таких требований и стоит начинать аналитику данных для бизнеса.
Не все пропуски одинаковы. Пустое поле «Комментарий» и пустой номер заказа — проблемы разного масштаба: первое почти ни на что не влияет, а второе может сломать весь расчёт. Если расставить проблемы по тому, как они влияют на задачу, команда не потратит неделю на приведение в порядок полей, которыми никто не пользуется.
При проверке разделяйте точность, полноту и своевременность. Запись может быть верной, но запоздавшей, или полной, но неточной. Когда каждый тип проблемы назван отдельно, понятно, кто и как должен её исправлять. Единый сводный «показатель качества» стирает эту разницу и не даёт команде ничего конкретного для работы.
Где ломаются записи при объединении систем?
Большинство проблем возникает там, где встречаются данные из разных систем, поэтому разработка баз данных и интеграций начинается с этих мест. Посмотрите, как сопоставляются записи — по какому ключу и по каким правилам — и как обновления меняют их статус, когда заказ проходит путь от оформления к оплате и отгрузке или отменяется.
Специально проверьте типичные слабые места: задвоенные идентификаторы, ссылки, которые никуда не ведут, отменённые сделки, которые всё ещё попадают в итоги, и данные, приходящие уже после того, как отчёт собран. Аудит базы данных проверяет эти места системно. Сверьте типичную выборку с теми, кто отвечает за исходные системы: они часто знают об особенностях, которые нигде не записаны. Запоздавшим данным уделите особое внимание: если отчёт собирается до того, как пришли последние обновления, решите, пересобирается ли он позже или помечается как предварительный, чтобы читатели знали, какие цифры ещё могут измениться.
Записи, которые не прошли проверку, должны попадать в отдельный порядок разбора. Хуже всего, когда неверные данные молча превращаются в нули или выпадают из итогов без записанного правила. Отчёт в этом случае выглядит аккуратно, но никто не знает, что из него убрали и почему, и объяснить цифры, когда о них спросят, невозможно. Лучше, когда такие записи видны и у них есть ответственный за разбор: тогда спорные случаи не копятся неделями.
Как встроить проверки в повседневную работу?
Разовая чистка помогает лишь на время: без проверок в самом процессе те же ошибки возвращаются. Ставьте проверки там, где данные пересекают границу: при сборе, при передаче между системами и при попадании в отчёт. Чем раньше проверка поймает ошибку, тем дешевле её исправить: на входе это одна запись, а в отчёте — уже вопрос к цифре для руководства. Поэтому самые важные проверки стоит ставить как можно ближе к месту, где данные появляются.
Для каждой проверки решите, кто разбирается, если она не пройдена, как исправляются данные и в какой момент стоит приостановить их дальнейшее использование: иногда лучше задержать отчёт на день, чем опубликовать неверную цифру. Записывайте исключения и следите за тем, какие ошибки повторяются, — именно повторы показывают, где кроется настоящая причина. Повторяющиеся ошибки часто указывают на неудобную форму ввода или неясное правило, а не на невнимательность сотрудников.
Чтобы ошибки не вернулись после чистки, кроме самого исправления нужны ответственный и правило, которое предупреждает повторы. Иначе дашборд или ИИ-процесс будет добросовестно воспроизводить одну и ту же нестыковку при каждом запуске, а силы, потраченные на чистку, окажутся потраченными зря.
Чек-лист: качество данных
- Определите обязательные идентификаторы, допустимые форматы и то, насколько свежими должны быть данные для этой задачи.
- Проверьте дубли, сопоставление записей между системами и запоздавшие обновления.
- Сверьте выборку записей с теми, кто отвечает за исходные системы.
- Решите, кто разбирает непройденные проверки и кто отвечает за то, чтобы ошибки не повторялись.
Пример: задвоенные ключи клиентов в отчёте о продажах
Отчёт о продажах объединяет заказы с данными клиентов, но после одной из загрузок ключи клиентов задвоились, и часть заказов могла попасть не к тому клиенту. Команда переносит неоднозначные строки в отдельный набор для разбора, уточняет правило сопоставления у ответственного за систему и заново проводит сверку, прежде чем публиковать цифру.
После этого в загрузку добавляют записанную проверку, так что следующая партия данных проверяется автоматически и та же ошибка больше не повторяется. Так разовая проблема превращается в постоянную защиту.
