АВТОМАТИЗАЦИЯ · ДАННЫЕ · ИНТЕГРАЦИИ · 12 МИНУТ
Как подготовить данные к автоматизации
Проверяем поля, идентификаторы, дубли и владельцев до подключения обмена.
Короткий ответ: подготовьте не всю базу, а данные одного процесса
Начните с объекта, который проходит через выбранный процесс: обращение, заказ, документ, задача или клиент. Зафиксируйте, где он появляется, какие поля меняются, кто отвечает за их смысл и какая система должна считаться источником истины.
Источники → объекты и поля → формат и обязательность → владелец → правило обновления → источник истины → ошибки и дубли → доступы и ограничения.
РАБОЧИЙ ОБРАЗЕЦ / ДЕМОНСТРАЦИОННЫЕ ДАННЫЕ
Шесть строк: найти проблему до обмена
На небольшом экране таблицу можно прокрутить в сторону →
| До: ID / объект | Проблема | После проверки |
|---|---|---|
| ДЕМО-01 / Узел А | Корректная запись | Сохранить |
| ДЕМО-01 / Узел А | Дубль идентификатора | Сверить, не создавать вторую запись |
| — / Узел Б | Нет обязательного ID | Уточнить у владельца |
| ДЕМО-03 / Узел В | Лишние пробелы | Нормализовать формат |
| ДЕМО-04 / старое имя | Неактуальный справочник | Сопоставить с действующим |
| ДЕМО-05 / пусто | Нет обязательного объекта | Оставить в очереди исправления |
Безопасные вымышленные данные. До запуска согласуйте обязательные поля, уникальность ID, допустимые значения и владельца исправлений.
Как проверить исходные данные
- Возьмите небольшой безопасный набор одного процесса.
- Проверьте идентификаторы, обязательные поля, дубли и справочники по типам ошибок.
- Согласуйте исправления, владельца и правила обработки новых ошибок.
Что учесть
Не переносите реальные персональные данные в демонстрацию. Очистка примера не гарантирует качество всей базы; production-доступы проверяются отдельно.
Подробный разбор, подготовка и вопросы
Составьте инвентаризацию систем и файлов
В карту стоит включить не только CRM и официальные базы. Реальный процесс часто использует таблицы, почту, формы сайта, Telegram, локальные файлы и ручные списки. Для каждого источника запишите назначение, владельца, способ доступа, частоту обновления и возможность выгрузки.
| Источник | Что хранит | Что проверить |
|---|---|---|
| Форма сайта | Первичное обращение и источник | Названия полей, обязательность, согласие |
| CRM | Карточки, статусы, ответственные | API, пользовательские поля, дубли |
| Таблица | Расчёты или временный учёт | Владелец, формулы, версии |
| Мессенджер | Коммуникации и уведомления | Идентификаторы, права, история |
| Внешний сервис | Документы, оплаты или доставка | Лимиты, webhook, тестовый контур |
Соберите карту полей и преобразований
Одного совпадения названий недостаточно. Поле «телефон» может храниться в разных форматах, «статус» — иметь несовместимые значения, а «клиент» — означать человека, компанию или сделку.
| Поле | Источник | Назначение | Правило |
|---|---|---|---|
| Внешний ID | Система-источник | Связь записей | Не изменяется и уникален |
| Телефон | Форма или CRM | Поиск клиента | Нормализация формата |
| Статус | CRM | Этап процесса | Явное соответствие значений |
| Ответственный | CRM или правило | Владелец следующего шага | Проверка активного пользователя |
| Дата изменения | Каждая система | Разрешение конфликтов | Единый часовой пояс |
Проверяйте качество по типам ошибок
- Пустые значения. Какие поля действительно обязательны на конкретном этапе?
- Дубли. По каким идентификаторам записи считаются одинаковыми?
- Несогласованные справочники. Какие значения статусов и категорий допустимы?
- Устаревшие записи. Как определить актуальность и не восстановить удалённое?
- Неверный формат. Даты, телефоны, суммы, кодировки и часовые пояса.
- Неясное происхождение. Можно ли понять, кто и когда изменил значение?
Не исправляйте данные молча. Для каждого преобразования должно быть правило, а спорные записи — попадать в понятный маршрут проверки.
Отделите примеры от production-доступов
На этапе оценки достаточно документации, обезличенных примеров и описания способов интеграции. Рабочие ключи не следует передавать в переписке или встраивать в публичный код. Для разработки полезны отдельные учётные записи, минимальные права, тестовый контур и возможность отозвать доступ.
- Назначьте ответственного за выдачу и отзыв доступов.
- Разделите тестовые и рабочие окружения.
- Ограничьте права нужными объектами и действиями.
- Зафиксируйте лимиты API, доступные события и журналы.
- Определите, какие данные можно использовать в тестах.
Спроектируйте ошибки как часть процесса
Надёжная интеграция должна отвечать на вопросы: что произойдёт при недоступности системы, как повторяется операция, где видна очередь ошибок, кто получает уведомление и как исключается повторное создание записи.
Подробный технический контекст оценки разобран в материале о доступах и границах интеграции, а пример связи клиентских каналов — в разборе сайта, Telegram и CRM.
Чек-лист готовности данных к первому этапу
- Выбран один процесс и основной объект.
- Перечислены все реальные источники, включая таблицы и ручные каналы.
- Для каждого поля назначен смысл и источник истины.
- Есть обезличенные примеры обычных случаев и исключений.
- Определены дубли, пустые значения и спорные статусы.
- Проверены API, лимиты, события и тестовые доступы.
- Назначены владельцы бизнес-правил и технических доступов.
- Описаны повтор, журнал и ручной маршрут ошибки.
Частые вопросы
Нужно ли сначала очищать всю базу данных?
Нет. Сначала определяют поля и записи, нужные первому процессу. Полная очистка без границы задачи может занять много времени и не повлиять на первый релиз.
Что делать, если данные расходятся в нескольких системах?
Назначить источник истины для каждого типа данных и правило разрешения конфликта. Интеграция не должна молча выбирать случайное значение.
Достаточно ли выгрузки Excel для оценки?
Она помогает понять структуру и качество примеров, но для рабочей интеграции дополнительно нужны способы доступа, ограничения API, частота обновления и правила ошибок.
Нужно ли передавать разработчику реальные персональные данные?
Для первичной проверки предпочтительны обезличенные или синтетические примеры, сохраняющие структуру. Реальный доступ предоставляют только когда он необходим и согласованы границы обработки.
Кто должен отвечать за карту данных?
Бизнес-владелец подтверждает смысл и правила, технический представитель — источники и доступы, а команда разработки фиксирует преобразования и контроль ошибок.
СЛЕДУЮЩИЙ ШАГ
Разобрать данные одного процесса.
Зафиксируем источники, поля, ограничения и границу первого этапа без требования заранее готовить полное ТЗ.