Данные перед автоматизацией: справочники, дубли, форматы

7 августа 2026 · 10 мин чтения

Сценарий собран, на тестовых записях всё отрабатывает: заявка приходит, карточка создаётся, ответственный получает уведомление. Первый день на боевой базе - и одному заводу заводятся три карточки. В CRM он записан как «ООО Ромашка», «Ромашка ООО» и «ромашка», телефон в одной карточке начинается на «+7», в другой на «8», в третьей его нет. Менеджер Марина знает, что это один клиент. Система не знает.

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

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

Правило Марины: почему сценарий не запускается на грязных данных

Человек сопоставляет записи по смыслу. Марина видит «ООО Ромашка» и «ромашка», помнит, что завод один, - и работает дальше, не замечая, что выполнила сложную операцию. Программа сопоставляет по совпадению значений в полях: совпадения нет - значит, объекты разные.

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

• Дубли, которые видно. Три карточки одного завода, два уведомления менеджеру, счёт не на тот адрес. Заметно сразу.
• Тихие пропуски. Запись не подходит ни под одно условие и не обрабатывается. Ошибки нет, алерта нет, запуск в журнале зелёный, а заявка лежит там, куда никто не смотрит.
• Ложные срабатывания. Правило «источник равен Авито - назначить Петрова» не срабатывает на «авито», «Авито » с пробелом в конце и «Авито/звонок». Заявки уходят в ветку «прочее», и отдел уверен, что сценарий сломан.

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

Четыре типа мусора в базе

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

1. Дубли: один контрагент под тремя написаниями

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

2. Пустые обязательные поля

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

3. Разные форматы одного и того же

Список, с которого имеет смысл начать проверку: телефоны («+7 912 000-00-00», «8(912)0000000», «912-00-00 доб. 12»), даты («05.06.2026», «2026-06-05», «5 июня»), ИНН, потерявший ведущий ноль или уехавший в «7,7E+11», единицы («кг», «килограмм», «Кг»), суммы с текстом («12 000 руб.»). Для человека это одно значение, для сравнения строк - разные.

4. Справочники-помойки

Если поле «источник» заполняется свободным текстом, за пару лет в нём набирается, скажем, 40 значений: восемь рабочих, остальные - варианты написания тех же восьми, опечатки и разовые записи вроде «не помню». То же случается с полями «статус», «категория», «регион». Опереться на такой справочник в правиле нельзя: условие будет ловить часть записей и пропускать остальные.

Таблица: тип мусора - как проверить - что делать

Час на оценку базы: шесть проверок в выгрузке

Полноценный аудит данных - отдельная работа, но первое понимание даёт выгрузка в CSV или XLSX и час времени. Выгружаются поля, нужные сценарию, плюс идентификатор записи и дата создания.

1. Доля пустых в ключевых полях. Для базы в 6 000 карточек: =СЧИТАТЬПУСТОТЫ(C2:C6001)/6000 по каждой колонке. Ловушка: ячейка с пробелом формально не пустая, её ловит =СЧЁТЕСЛИ(C2:C6001;" ").
2. Число уникальных значений в справочниках. Сводная таблица: поле в строки, количество в значения. Видно общее число вариантов и хвост значений с одним вхождением - кандидаты в опечатки.
3. Дубли по телефону и email. Новая колонка: из телефона убираются все знаки, кроме цифр, берутся последние 10; email приводится к нижнему регистру. Дальше =СЧЁТЕСЛИ() по колонке: всё, что больше единицы, - кандидаты.
4. Записи без ответственного. Фильтр по пустому полю владельца: это строки, которые сценарий маршрутизации не сможет никому передать.
5. Разброс форматов. Колонка с длиной строки телефона: если разных длин больше трёх-четырёх, форматы не едины. Даты, прижатые влево, - текст, а не даты.
6. Свежесть. Сводная по году создания: видно, какая часть базы относится к периоду, о котором уже никто ничего не помнит.

Результат часа - записка на страницу с шестью числами. Смысл в том, чтобы дальше говорить не «база грязная», а «в поле телефона пусто у 12 процентов записей, кандидатов в дубли 540, в справочнике источников 40 значений». Если баз несколько и они расходятся, полезно посмотреть на синхронизацию данных между системами: расхождение двух баз - отдельный тип беспорядка.

Что чинить до автоматизации, а что можно оставить

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

Список полей берётся из описания сценария: что он читает, по чему ветвится, во что пишет. Если маршрутизация читает телефон, email, источник и регион, а пишет ответственного, - это пять полей, остальные сорок полей карточки к запуску отношения не имеют. Два дополнения.

• Поля отчётности приравниваются к полям сценария. Если по справочнику источников строится отчёт, он попадает в область работ, даже когда сценарий его не читает.
• Поля, которые уедут в другую систему, чинятся до переезда. Грязь, перенесённая в новую CRM, размножается по двум базам сразу; порядок действий описан в материале про переезд между CRM.

И обратное: то, что скоро будет выброшено, чинить не нужно - поля от старого процесса и колонки таблицы, которую заменяет система, разумнее выгрузить в архив одним файлом (о границе между ними - статья Excel или CRM).

Порядок чистки: сначала форматы, потом дубли

Это единственное место, где очерёдность принципиальна. Дедупликация ищет совпадения, а совпадение считается по строке: «+7 912 000-00-00» и «8(912)0000000» для человека один номер, для алгоритма две разные строки, и пара дублей не находится.

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

1. Копия. Все операции идут на выгрузке или в копии базы: первый прогон скрипта по боевой системе - плохая идея по причинам, очевидным на втором.
2. Правила на каждое поле. Телефон - цифры с кодом страны; ИНН - текст с ведущими нулями; дата - один формат; единицы - из закрытого списка; регистр названий - один.
3. Прогон и выборочная сверка. Сто записей проверяются глазами: здесь ловятся номера с добавочным и иностранные телефоны, под которые правило не написано.
4. Повторный подсчёт кандидатов в дубли. После нормализации их число может вырасти: значит, предыдущая цифра была неполной.
5. Склейка в два потока. Строгое совпадение (нормализованный телефон плюс ИНН) - автоматически, остальное - в список для человека, порциями.
6. Ничего не удаляется. Выжившая запись остаётся рабочей, проигравшая помечается и ссылается на неё: через месяц кто-нибудь спросит, куда делась сделка.
7. Справочники закрываются. Согласованный список значений, таблица соответствий «старое - новое», замена по ней, выпадающий список вместо свободного ввода.
8. Правила ввода. Обязательные поля, маска телефона, запрет заводить контакт с существующим номером. Без этого шага поводов для повторного захламления базы остаётся столько же, сколько было до чистки.

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

Владелец данных: почему без него порядок в базе редко удерживается

Уборка без назначенного человека нередко держится ровно до момента, когда в справочник понадобится добавить новое значение. Дальше знакомое: менеджер не находит нужный пункт, просит администратора, тот заводит «Авито (новый кабинет)», через месяц кто-то пишет «авито 2».

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

• Держит закрытые списки. Новое значение добавляется через него, а не любым, у кого есть права.
• Смотрит короткий отчёт раз в месяц. Четыре числа: новые значения в справочниках, доля пустых в ключевых полях, кандидаты в дубли, записи без ответственного.
• Разбирает спорные склейки. Порциями, в оговорённое время, а не когда накопится тысяча пар.
• Отвечает на вопрос «как правильно». У каждого справочника одно место и один человек, знающий смысл каждого значения.

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

Что делать с историей, которую нельзя восстановить

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

• Провести черту по дате. До неё - архив, после - рабочая база. Дата выбирается по здравому смыслу: смена системы, приход нынешней команды.
• Пометить, а не выбросить. Отдельное поле вида «запись до чистки» позволяет и не мешать сценарию, и не терять то, что может пригодиться.
• Не подставлять правдоподобное. Проставить «источник: сайт» трём тысячам сделок, где источника нет, - значит испортить отчётность сильнее, чем это делает пустое поле: пустота честно говорит «неизвестно», выдуманное значение врёт уверенно.
• Научить сценарий пустоте. В описании появляется явная ветка: данных нет - запись уходит в отдельный список человеку, а не теряется молча.
• Отдельно посмотреть на персональные данные. Что из старых контактов можно хранить, что стоит удалить и на каком основании - зависит от состава данных, целей обработки и статуса компании; это вопрос к юристу, а не к скрипту. Техническую сторону хранения разбирает статья про данные и 152-ФЗ.

Экономика: чистка - это часы, а не магия

Скажем прямо: подготовка данных нередко занимает столько же времени, сколько сама настройка сценария. Это повод заложить её в смету отдельной строкой - иначе она всё равно всплывёт, но уже в виде сдвига сроков.

Посчитаем на явных допущениях. База - 6 000 карточек клиентов. Сценарий смотрит на пять полей: телефон, email, ИНН, источник, ответственный. По результатам часовой оценки: пусто в поле телефона у 12 процентов записей, кандидатов в дубли - 9 процентов, в справочнике источников 40 значений. Округляем не в свою пользу.

• Оценка выгрузки - 1 час. Шесть проверок выше.
• Нормализация форматов - 6 часов. Правила на пять полей - 4 часа, прогон по копии и сверка ста записей - 2 часа.
• Дедупликация - 4,5 часа. 9 процентов от 6 000 - это 540 записей-кандидатов, то есть примерно 270 пар. Закладываем, что автоматически и безопасно склеиваются 135 пар; оставшиеся 135 разбирает человек по 2 минуты на пару, это 270 минут, то есть 4,5 часа.
• Справочник источников - 3 часа. Свести 40 значений к восьми, согласовать список с продажами, составить таблицу соответствий и заменить по ней.
• Пустые телефоны - 1 час. 12 процентов от 6 000 - это 720 записей. Восстанавливать их неоткуда, поэтому час уходит на метку «нет контакта» и выгрузку списка менеджерам.
• Правила ввода - 3 часа. Обязательные поля, маска телефона, выпадающий список вместо свободного текста, запрет дубля по номеру.

Складываем: 1 + 6 + 4,5 + 3 + 1 + 3 = 18,5 часа. При восьмичасовом дне это чуть больше двух рабочих дней одного человека, и то если решения принимаются сразу. В календаре растянется дольше: согласование списка источников упирается в занятость отдела продаж.

Сравнить эти 18,5 часа есть с чем: в нашем прайсе автоматизация одного процесса - от 55 000 ₽ и от 7 дней. Подготовка данных бывает сопоставима по объёму с настройкой сценария, поэтому смету без такой строки стоит считать неполной; порядок цен разбирает статья про стоимость автоматизации. Процентов улучшения мы не обещаем: чистка сокращает поводы для ручного разбора и влияет на вероятность отката запуска.

Чек-лист готовности данных: 10 пунктов

Каждый пункт - да или нет. «Нет» не запрещает начинать работы, но требует назвать срок и ответственного, иначе всплывёт в день запуска.

1. Выписан список полей, на которые смотрит сценарий. Что читается, по чему ветвление, во что пишется.
2. Есть свежая выгрузка, работа идёт на копии. Боевая база не правится скриптом с первого прогона.
3. Посчитана доля пустых по каждому ключевому полю. Отдельно проверены строки из пробелов.
4. По каждому справочнику известно число уникальных значений. И виден хвост значений, встречающихся один-два раза.
5. Форматы нормализованы до дедупликации. Телефоны, даты, ИНН, единицы, регистр названий - по одному правилу на поле.
6. Кандидаты в дубли пересчитаны после нормализации. Спорные пары разобраны человеком, не склеены автоматически.
7. Ничего не удалено. Проигравшие записи помечены и ссылаются на выжившие.
8. Справочники закрыты списками. Есть таблица соответствий старых значений новым, на вводе - выпадающий список.
9. Назначен владелец данных. Держит справочники, разбирает спорные случаи, раз в месяц смотрит отчёт из четырёх чисел.
10. Проведена черта по истории. Известно, что считается архивом, и в сценарии есть ветка на случай пустого поля.

Пункты 1 и 5 задают рамку: первый ограничивает объём работ, второй - порядок. Остальные восемь удерживают результат. Типовые провалы на соседних шагах собраны в статье про ошибки при автоматизации.

Честно: чистая база не отменяет сбоев

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

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

Итог

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

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

Не готовы обсуждать проект? Оцените выгоду сами: калькулятор ROI автоматизации - 1 минута, без контактов. Или заберите чек-лист «Что автоматизировать первым».