Автоматизация редко ломается из-за отсутствия красивого интерфейса. Гораздо чаще проект стартует на данных, в которых один клиент записан пятью способами, даты смешаны с текстом, а обязательное поле заполняется по памяти. До разработки нужно определить, какие данные нужны решению, где находится источник истины и какие ошибки нельзя пропустить.
Подготовка данных — не бесконечная уборка архива. Цель — довести рабочий контур до состояния, в котором система безопасно принимает решения и показывает понятные ошибки. Часть истории можно оставить в архиве, часть исправить правилами, а часть отправлять на ручную проверку.
Если вы рассматриваете внутреннюю систему или интеграцию, посмотрите контур веб-разработки Paladin Engineering. До оценки полезно провести короткое обследование, которое выявляет не только объём интерфейса, но и качество исходных данных.
Начните с решения, а не с выгрузки
Одна таблица может быть пригодна для отчёта, но непригодна для автоматического назначения задачи. Сначала опишите решение: что должна сделать система, какой объект создать или изменить, какие поля обязательны и когда нужен человек. Затем определите минимальный набор данных для сценария.
- Сценарий: зарегистрировать заявку и назначить ответственного.
- Результат: запись, статус, уведомление или отчёт.
- Обязательные поля: без них сценарий нельзя завершить.
- Правила: допустимые значения, диапазоны, уникальность и связи.
- Исключение: что происходит при пропуске, конфликте или сомнении.
Пять измерений готовности данных
В практической проверке удобнее смотреть не на абстрактную «чистоту», а на измерения качества. В официальных материалах Google и AWS встречаются полнота, валидность, согласованность, точность, уникальность, свежесть и объём. Эти термины превращают спор о качестве в набор правил.
| Измерение | Вопрос | Пример правила |
|---|---|---|
| Полнота | Хватает ли обязательных полей? | Не более 2% заявок без телефона |
| Валидность | Верный ли формат? | Дата и сумма проходят диапазон |
| Согласованность | Одинаково ли значение в источниках? | Код совпадает в CRM и ERP |
| Уникальность | Нет ли повторов? | Один внешний id — одна запись |
| Свежесть | Достаточно ли актуальны данные? | Выгрузка не старше периода |
Порог зависит от сценария. Для отчёта пропуск контакта может быть допустим, для отправки документа — нет. Поэтому правило качества связывают с решением, а не с желанием получить красивый процент.
Профилирование: первая выборка
До миграции возьмите репрезентативную выборку и посчитайте число строк, пустые значения, уникальные значения, диапазоны дат и чисел, повторяющиеся ключи и распределение по статусам. Сравните несколько периодов, если процесс менялся со временем.
- Какие столбцы обязательны для целевого процесса.
- Какие значения являются идентификаторами и могут ли повторяться.
- Есть ли разные форматы телефонов, дат, адресов и названий.
- Какие статусы активны, закрыты или ошибочны.
- Какие строки нельзя переносить автоматически без владельца.
Источник истины и владельцы полей
Без владельца данных спор о правильном значении превращается в техническую переписку. Для каждого поля зафиксируйте систему-источник, ответственную роль, правило изменения и порядок разрешения конфликта. Если CRM говорит одно, а таблица другое, код не должен молча выбрать вариант.
| Поле | Источник | Владелец | Конфликт |
|---|---|---|---|
| Клиентский id | CRM | Продажи | Задача на сверку |
| Статус заявки | Система заявок | Операции | Последняя подтверждённая смена |
| Сумма договора | Учётная система | Финансы | Не импортировать без проверки |
| Контакт | CRM + канал | Продажи | Сохранить историю |
Нормализация и миграция без потери смысла
Нормализация — не механическая замена всех строк на один шаблон. Сначала сформулируйте смысловое правило: что считается одним клиентом, какой статус означает «готово», можно ли объединять записи и как сохранить исходное значение для аудита. Новую структуру полезно наполнить на копии и собрать отчёт об отклонённых строках.
На уровне базы данных часть правил можно закрепить NOT NULL, CHECK, UNIQUE, PRIMARY KEY и FOREIGN KEY. Документация PostgreSQL описывает ограничения как механизм, отклоняющий строки, нарушающие правило, а внешние ключи поддерживают ссылочную целостность. Но межтабличные условия, исторические исключения и ручное решение часто требуют отдельного процесса.
Автоматическая проверка и ручная очередь
Хороший импорт не скрывает ошибки. Он разделяет строки на принятые, исправленные по безопасному правилу и отклонённые с причиной. Для последней группы нужна очередь: кто проверяет, что видит, как исправление возвращается в источник и когда повторяется загрузка.
- Сохранить исходную строку или безопасный идентификатор.
- Показать понятное правило отказа, а не stack trace.
- Не смешивать исправление данных с бизнес-решением.
- Считать отдельно технические ошибки и ошибки качества.
- Сделать повторную загрузку идемпотентной, чтобы не плодить дубли.
Типовые ошибки перед автоматизацией
Самая дорогая ошибка — перенести неоднозначность в новый интерфейс. Если статус «в работе» означает пять состояний, система не исправит это новым выпадающим списком. Ещё одна ошибка — мигрировать весь архив до проверки активного сценария: команда тратит время на исключения, не проверив ежедневный маршрут.
| Ошибка | Почему опасна | Что сделать |
|---|---|---|
| Чистить весь архив | Большой объём и неизвестная ценность | Начать с активного контура |
| Нет владельца | Конфликты без решения | Закрепить роль за полем |
| Молчаливо исправлять | Теряется смысл и аудит | Логировать правило |
| Одна тестовая выгрузка | Данные меняются | Проверить периоды |
| Не считать rejected | Проблемы скрываются | Ввести отчёт |
Минимальный план на неделю
- День 1: описать процесс и результат.
- День 2: собрать выборку, найти пропуски и дубли.
- День 3: назначить источники истины и владельцев.
- День 4: оформить правила и ручную проверку.
- День 5: прогнать пилотный импорт на копии и пересчитать MVP.
Paladin Engineering может помочь превратить подготовку в карту данных, интеграционный контур и план первой версии. Оставьте заявку, если нужно обсудить обезличенную выгрузку, правила проверки и границы автоматизации.
FAQ: данные перед автоматизацией
Нужно ли идеально очистить весь архив?
Нет. Начните с данных, необходимых для одного сценария. Архив и редкие исключения можно вынести отдельно.
Кто решает, какое значение правильное?
Владелец бизнес-процесса или поля. Разработчик не должен угадывать смысл конфликтующих записей.
Можно ли исправлять значения автоматически?
Да, если правило однозначно и обратимо, например нормализация пробелов. Конфликтующие суммы выбирать автоматически не стоит.
Как понять, что данные готовы к пилоту?
Есть источник истины, обязательные поля, измеримые пороги, отчёт об отклонённых строках и ответственный за очередь.
Что делать с историческими строками?
Разделить активный контур и архив, определить нужный уровень миграции и не переносить историю без пользы для процесса.
Подготовленные данные не гарантируют успех автоматизации, но дают проекту управляемые границы. Чем раньше бизнес договорится о смысле полей и правилах исключений, тем меньше неоднозначности попадёт в код и интеграции.
Комментарии