Качество базы измеряется одним числом: какая доля карточек проходит все обязательные проверки. Ниже четырнадцать проверок, которые можно выполнить в обычной таблице до начала любого проекта, за пять часов работы одного внимательного человека. На выходе получается не «база у нас, конечно, не идеальная», а «пригодны 7 100 карточек из 10 000, это 71 %, и вот что мешает остальным».
Число нужно до сметы, а не после. Оно определяет и объём чистки, и то, стоит ли вообще переносить базу целиком. Сквозной пример один на всю статью: оптовая компания, в CRM 10 000 карточек контрагентов, 6 300 позиций номенклатуры, четыре года истории. Что именно ломается в работе от грязных данных и сколько стоит сама чистка, разобрано отдельно в материале про грязные данные в CRM — здесь чек-лист, который даёт число.
Четырнадцать проверок, способ и порог
Каждая строка чек-листа устроена одинаково: что проверяем, как это сделать в выгрузке средствами обычной таблицы, какой результат считается допустимым. Пороги — рабочие ориентиры для базы малого и среднего бизнеса; если ваш процесс требует строже, ужесточайте, но фиксируйте это письменно до проверки, а не после того, как увидели результат.
| № | Что проверяем | Как проверить в выгрузке | Порог |
|---|---|---|---|
| 1 | Есть телефон или почта | Счётчик строк, где оба поля пусты, делённый на общее число строк | не более 5 % |
| 2 | Назначен ответственный менеджер | Счётчик пустых значений в поле ответственного | не более 2 % |
| 3 | У сделки есть сумма и дата закрытия | Счётчик закрытых сделок с нулевой суммой или пустой датой | не более 1 % |
| 4 | Дубли по ИНН | Сводная таблица по столбцу ИНН, фильтр «встречается больше одного раза» | 0 для юрлиц |
| 5 | Дубли по нормализованному телефону | Отдельный столбец: убрать всё, кроме цифр, привести к 11 знакам, затем сводная | не более 2 % |
| 6 | Дубли по названию | Столбец из первых трёх слов названия без кавычек и ОПФ, затем сводная | не более 3 % |
| 7 | Телефон разбирается в 11 цифр | Длина нормализованного значения не равна 11 | не более 3 % |
| 8 | Почта похожа на почту | Проверка наличия «@» и точки после него | не более 1 % |
| 9 | Значения справочников из списка | Сводная по столбцу статуса, типа, категории: смотрим весь список уникальных значений глазами | не более 2 % вне списка |
| 10 | Справочник живой, а не декоративный | Доля значений справочника, которые встречаются хотя бы в 20 карточках | не менее 60 % |
| 11 | У сделки есть контрагент | Поиск сделок, чей идентификатор клиента не находится в таблице контрагентов | 0 |
| 12 | У карточки есть хоть какая-то жизнь | Доля карточек без единой сделки, задачи и звонка за всё время | не более 15 % |
| 13 | Карточку трогали за 12 месяцев | Фильтр по дате последнего изменения | не менее 45 % |
| 14 | Номенклатура двигалась за 12 месяцев | Сопоставление справочника номенклатуры с документами продаж | не менее 70 % |
Проверки 4, 5 и 6 нельзя заменять одна другой: это три независимых способа поймать дубль, и они находят разные группы. Один и тот же клиент бывает заведён дважды с разными телефонами, но одним ИНН — и наоборот, с одним телефоном под двумя юрлицами, что дублем не является. Поэтому автоматически склеивать можно только совпадения по ИНН и по паре «телефон плюс первые три слова названия»; остальное идёт людям.
Схема бланка: шесть подписанных блоков, внутри которых пронумерованные строки — «Полнота полей» (1–3), «Дубли» (4–6), «Форматы контактов» (7–8), «Справочники» (9–10), «Связи между записями» (11), «Жизнь и актуальность» (12–14). У каждой строки справа узкая ячейка с порогом: 5 %, 2 %, 1 %, 0, 2 %, 3 %, 3 %, 1 %, 2 %, 60 %, 0, 15 %, 45 %, 70 %. Внизу итоговая строка «Индекс пригодности». Чертёжный стиль, подписи по-русски.
Как свести четырнадцать проверок в одно число
Индекс пригодности — это доля карточек, которые одновременно проходят пять обязательных условий: есть контакт, есть ответственный, телефон разбирается, карточка не состоит в неразобранной группе дублей, у карточки есть хотя бы одна сделка, задача или звонок. Остальные девять проверок описывают качество справочников и номенклатуры: они важны для отчётности, но не решают судьбу конкретной карточки.
Дальше индекс читается по трём порогам. 85 % и выше — база рабочая, переносим как есть и чистим точечно уже после запуска. 60–84 % — нужна чистка на 2–4 недели до переноса, и её надо ставить в план проекта отдельной строкой, а не надеяться, что «по ходу разберёмся». Ниже 60 % — переносить целиком не имеет смысла: берём активное ядро за последние 12 месяцев, остальное оставляем в архивной выгрузке и заводим заново по мере обращений. Пример с 71 % попадает в средний сценарий. Число это нужно не только для переезда: на нём же держится сегментация клиентской базы и любая рассылка — сегмент, собранный по полю, которое заполнено у половины карточек, врёт ровно наполовину.
Вертикальная воронка из шести ступеней с подписями: «10 000 карточек», «−520 без контактов», «−310 без ответственного», «−290 телефон не разобран», «−680 в 290 группах дублей», «−1 100 без единого события». Итоговая ступень «7 100 — индекс пригодности 71 %» выделена. Справа шкала трёх порогов: «85 % и выше — переносим как есть», «60–84 % — чистка 2–4 недели», «ниже 60 % — только активное ядро», отметка 71 % стоит в средней зоне. Чертёжный стиль, подписи по-русски.
Кто чистит и сколько это стоит на 10 000 записей
Чистка — работа заказчика с технической поддержкой подрядчика, а не наоборот. Скриптом решаются форматы и бесспорные склейки; решения «это один и тот же клиент» и «этот статус нам больше не нужен» принимают только те, кто работает с базой. Расчёт по канонным для журнала ставкам: инженер-подрядчик 3 000 ₽/час, руководитель отдела 1 800 ₽/час, менеджер 900 ₽/час.
По календарю это две недели, а не четыре дня: 23 часа менеджеров не выдаются подряд, они размазываются по два часа в день между звонками. Планируйте чистку как параллельный поток к остальному проекту и назначайте ей владельца — иначе она встанет на первой же неделе. Дальше базу надо удерживать в чистоте, и это уже вопрос ввода: автозаполнение карточек CRM из почты и телефонии убирает главный источник мусора — ручной ввод в спешке.
Что делать, если индекс оказался плохим
Три сценария с условиями выбора. Ошибка здесь стоит дорого в обе стороны: чистить базу, которую всё равно надо было выбросить, — потерянный месяц; выбросить базу, которую можно было починить, — потерянные клиенты.
- 1Чистить всё — если индекс 60–84 % и в базе есть история сделок
Работает, когда мусор системный: одинаковые ошибки в форматах, дубли от импорта, незаполненные поля. Такое чинится скриптом на 80 %. Признак: в отчёте по проверкам два-три пункта дают почти весь провал, остальные в норме.
- 2Перенести ядро — если индекс ниже 60 % или база собиралась из четырёх мест
Берём карточки с событием за последние 12 месяцев, остальное кладём в архивную выгрузку со ссылкой. В примере это 4 500 карточек вместо 10 000. Клиент, который вернётся через два года, заводится заново за три минуты, и это дешевле, чем чистить 5 500 мёртвых записей.
- 3Начать с чистого листа — если данных о клиенте меньше, чем занимает его повторное заведение
Редкий, но реальный случай: в базе только имя и телефон без истории. Тогда переносится справочник контактов, а сделки, статусы и категории строятся заново под новый процесс. Решение принимает владелец данных письменно, потому что назад его не отыграть.
Какой бы сценарий вы ни выбрали, он записывается в план миграции данных в раздел правил отбраковки — до того, как назначена дата переезда. Решение «эти 5 500 карточек не едут», принятое заранее, называется планом; то же решение, принятое ночью в момент переноса, называется потерей данных.
Почему для ИИ-проекта грязная база опаснее
Обычная автоматизация на мусорных данных спотыкается заметно: сценарий падает, обмен ругается, письмо уходит на несуществующий адрес и возвращается. Ошибку видно в тот же день. Языковая модель ведёт себя иначе: она не падает. Она уверенно и вежливо отвечает клиенту по той карточке, которую нашла, — включая дубль с устаревшим адресом доставки и закрытым договором.
Если у половины карточек не заполнен тип клиента, ассистент не скажет «не знаю» — он достроит ответ по контексту и назовёт оптовую цену розничному покупателю. Поэтому перед запуском ассистента индекс пригодности по тем полям, которые он читает, должен быть не 71 %, а близко к 100 %: проще сузить круг данных, чем чистить всё. Тот же механизм разобран в материале про то, почему поиск по базе знаний ошибается.
Практический вывод: для ИИ-проекта чек-лист прогоняется не по всей базе, а по тем полям и сущностям, к которым получит доступ модель. Часто это пять-шесть полей, и довести их до чистоты в 98 % дешевле и быстрее, чем чистить базу целиком. Требования к таким полям стоит записать заранее — в тот же документ, где вы описываете, что модель имеет право читать.
Когда четырнадцать проверок — избыточная бюрократия
Чек-лист рассчитан на базу, которую годами наполняли разные люди. Если это не ваш случай, половина проверок вернёт идеальные значения и просто отнимет день.
- База до 500 записей. Быстрее просмотреть её глазами: 500 строк листаются за два часа, и человек попутно видит то, чего не покажет ни одна проверка.
- Один источник и один оператор ввода. Систематических дублей в такой базе почти не бывает; хватает проверок 1, 5 и 12.
- Данные приходят из системы с обязательной валидацией — с сайта с проверкой формата, из ЭДО, из кассы. Форматы там уже чистые, смысл проверять только связи и актуальность.
- Вы всё равно переносите только активное ядро. Тогда проверки 13 и 14 делаются первыми, и по их результату отпадает необходимость в остальных двенадцати.
И обратная граница: чек-лист бесполезен, если по его итогам ничего не произойдёт. Проверка, после которой не назначен ответственный за чистку и не выделены часы, превращает разговор о данных в жанр отчёта. Тогда честнее не проверять вовсе и заложить в бюджет проекта ручной разбор — по крайней мере, эти деньги будут видны в смете, а не всплывут в виде сорванного срока.
