Качество данных для аналитики: 7 проверок перед дашбордом

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

Модельная база дальше по тексту одна: оптовая компания, 50 000 строк реализаций за 18 месяцев, 12 000 карточек контрагентов, 8 400 позиций номенклатуры, 1С:УТ и amoCRM. Все находки и часы ниже — по ней. У вашей базы числа будут другими, но порядок проверок и пороги не меняются.

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

Семь проверок и что они находят

Проверки идут в порядке убывания ущерба. Первая обычно даёт половину всей работы, последняя — несколько документов, но именно она чаще всего объясняет странный всплеск на графике.

Седьмую проверку часто пропускают как необязательную, а она самая быстрая по трудозатратам и самая полезная для доверия к отчёту. Двадцать один документ на 3,1 млн ₽ в модельной базе — это одна ошибочная накладная с количеством в тысячах вместо штук, несколько тестовых документов, оставшихся после внедрения, и три реальных крупных сделки, которые трогать не надо. Пока эти двадцать один документ не разобраны, любой график по месяцам будет иметь необъяснимый пик, и объяснять его придётся на каждой планёрке.

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

Как провести эти проверки самому за вечер

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

1. 1Выгрузите три файла: строки реализаций за 12–18 месяцев со всеми полями, справочник контрагентов и справочник номенклатуры. Именно строки документов, а не итоги отчётов: в итогах брак уже усреднён и не виден.
2. 2Дубли ищите сводной по ключу. Для контрагентов — количество карточек на один ИНН, для номенклатуры — на один артикул. Всё, где значение больше единицы, идёт в список. Отдельно посчитайте карточки, у которых ключ пустой: их проверить нельзя вообще, и это самая опасная группа.
3. 3Пустые поля считайте долей, а не количеством. Постройте сводную «поле — доля пустых значений» по десятку полей, которые реально участвуют в отчётах. Поля, которых нет ни в одном отчёте, не проверяйте: их пустота ничего не стоит.
4. 4Единицы измерения и справочные значения проверяйте частотной сводной. Список уникальных значений поля, отсортированный по убыванию частоты, показывает разнобой мгновенно: сверху «шт» с 7 000 повторений, ниже «шт.» с 400 и «ШТ» с 60.
5. 5Даты, суммы и выбросы — фильтрами. Дата больше сегодняшней, дата оплаты раньше даты отгрузки, сумма меньше или равна нулю, количество или сумма больше среднего в двадцать раз. Каждый фильтр — минута работы и отдельный список на разбор.
6. 6Запишите результат в одну таблицу: проверка, количество, доля, предположительная причина, оценка часов. Этот лист — и есть отчёт о качестве данных, и с ним уже можно идти к подрядчику или принимать решение самому.

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

Доля брака и рабочие пороги

Отдельные находки сами по себе ничего не говорят: 320 осиротевших строк — это много или мало? Считать надо долю. Берётся число строк, к которым есть хотя бы одна претензия из семи, с убранными пересечениями — одна строка может нарушать сразу три правила, но в знаменателе она одна.

В модельной базе таких строк 6 800 из 50 000, то есть 13,6 %. Складывать находки напрямую нельзя: 4 100 строк без склада, 2 100 строк по дублирующимся контрагентам, 900 с неоднозначной единицей измерения, 610 нулевых, 320 осиротевших, 74 с датами и 21 выброс дают 8 125, но 1 325 строк попали в список дважды и трижды.

• До 2 % — фон. Живут с этим, отмечают в словаре метрик и не тратят деньги. Отчётность на таких данных строится сразу, расхождения укладываются в допустимую дельту.
• 5–10 % — чинить до старта проекта. Отчёты собрать можно, но их будут оспаривать, и обоснованно. Чистка на этом уровне занимает недели, а не месяцы, и почти вся делается скриптами.
• Выше 10 % — сначала процесс ввода. Это случай модельной базы. Чистить данные, не меняя форму ввода, бессмысленно: через квартал вы получите ту же долю брака и второй счёт за ту же работу.

Откуда берётся мусор: три источника

Чинить находки, не разобравшись в источнике, — это уборка под протекающей крышей. Источников ровно три, и у каждого своё лечение.

1. 1
   Ручной ввод без обязательных полей

   Форма позволяет сохранить документ без склада, без ответственного и без ставки. Менеджер под давлением клиента пропускает поля, и через год их пропущено в 8 % строк. Лечится не обучением, а настройкой контроля заполнения: система не даёт сохранить документ без критичных полей.

2. 2
   Миграция из старой системы

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

3. 3
   Интеграция, которая молча дублирует

   Обмен с сайтом или маркетплейсом не находит существующего клиента и создаёт нового, повторная отправка заказа создаёт вторую строку. Это самый неприятный источник: он работает непрерывно и добавляет мусор быстрее, чем вы его убираете. Механика таких сбоев разобрана в материале про задвоенные заказы при обмене.

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

Что чинится скриптом, а что только руками

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

Почему чистка без изменения ввода возвращает мусор

Это главный вывод всей проверки, и он неприятный. Разовая чистка приводит базу в порядок на короткое время: в модельном примере доля строк без склада отгрузки падает с 8,2 % до 0,4 %. Через квартал при неизменённой форме ввода она возвращается к 5,1 % — потому что источник мусора никуда не делся. Ещё через квартал вы платите за чистку второй раз.

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

• Контрагент с ключом. Не текстовое название, а карточка с ИНН. Именно это поле связывает документ с клиентом во всех отчётах и в сверке с контрагентами.
• Номенклатура из справочника. Позиция выбирается, а не вписывается руками. Свободный ввод названия товара — гарантированный источник дублей.
• Количество и единица измерения. Единица берётся из справочника позиции, а не из свободного поля документа.
• Склад или подразделение. Поле, которого чаще всего не хватает: без него не считается ни оборачиваемость, ни остатки, ни нагрузка на подразделение.
• Ответственный. Не «отдел», а сотрудник. Без него не собирается ни один отчёт в разрезе людей, а именно их просят чаще всего.
• Дата события. Отдельно от даты создания документа: дата отгрузки, дата оказания услуги, дата оплаты. Смешение этих дат — первая причина расхождения цифр между системами, мы разбирали её отдельно — одна цифра в трёх системах разная.

Когда чистить не надо

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

• Доля брака ниже 2 % и не растёт. Разбирать её дороже, чем терпеть. Достаточно записать в словарь метрик, что такая погрешность ожидаема, и вернуться к вопросу, если доля вырастет.
• Данные не участвуют в решениях. Если на показателе не строится ни одно решение, точность в нём не нужна. Проверка простая: назовите последнее решение, которое было бы другим при других цифрах.
• Система скоро меняется. Идёт переезд на другую конфигурацию или слияние юрлиц — чистить надо после переезда и один раз, а не до и потом ещё раз. Исключение — данные, которые переносятся: их чистят до миграции, иначе мусор приезжает вместе с ними и разбирать его становится дороже.

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

Дашборд не улучшает данные. Он делает их видимыми — вместе со всем, что в них накопилось.