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

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

Почему исправная интеграция может переносить ошибки

Статус «успешно передано» подтверждает техническое действие. Правильность смысла он не проверяет. Сто единиц в источнике могут означать штуки, упаковки или метры. Одно и то же название материала может скрывать разные размеры. Контактное лицо может сменить работодателя, а его старая связь останется в CRM.

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

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

Назначьте владельца каждого вида данных

Для каждого справочника нужно определить основную систему и ответственного. У финансовых реквизитов это может быть учётная база и бухгалтерия, у товарных характеристик каталог и снабжение, у контактных данных CRM и продажи. Нужна конкретная договорённость: универсальное правило «всё главное хранится в ERP» здесь не работает.

В 1С:Библиотеке стандартных подсистем описаны средства работы с классификаторами, включая адресные и банковские сведения. Это пример того, что структурированные данные уже могут поддерживаться существующими инструментами. Наличие библиотеки не гарантирует, что нужная функция включена и настроена в вашей конфигурации.

Назначьте также порядок изменения. Кто создаёт новую карточку, кто проверяет обязательные поля, кто разрешает объединение и как об этом узнают другие системы? Если любое подразделение может независимо переименовать одну сущность, разовая уборка не удержит качество надолго.

Проверьте ключи и связи между системами

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

Дубли контрагентов ищут по сочетанию признаков. Для российских юридических лиц могут использоваться проверенные реквизиты вместе с организационной структурой, но одно совпадение названия ничего не доказывает. Филиал, отдельное юридическое лицо и группа компаний требуют разного представления. Для иностранных контрагентов состав идентификаторов зависит от страны и имеющихся документов.

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

Единицы измерения требуют явных правил

Качество данных для ИИ особенно заметно на единицах и характеристиках. Модель может понять, что «уп.» означает упаковку, но не знает, сколько штук находится в конкретной упаковке без источника. Коэффициент относится к определённому товару и версии упаковки. У слова «коробка» вообще коэффициента нет.

Учебный пример: в заказе указано 12 упаковок, в согласованном справочнике для этого артикула зафиксировано 20 штук в упаковке. Заказ соответствует 240 штукам. На склад поступило 200 штук. Непоставленный остаток по заказу составляет 40 штук, то есть две такие упаковки. Если поставщик заявил, что отгрузил все 240, расхождение по приёмке требует отдельной проверки; само сравнение с заказом ещё не доказывает недостачу. Сравнение чисел 12 и 200 без единиц не имеет смысла.

Если поставщик изменил упаковку на 25 штук, старый коэффициент нельзя молча переписать во всей истории. Для новой поставки фиксируют актуальное основание и дату действия. Предыдущий заказ продолжает означать свои 240 штук, пока его условия отдельно не изменены. Это задача версий справочника и документов. Распознавание текста её не решает.

Как провести небольшой аудит в существующих инструментах

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

В Excel уже могут использоваться средства Power Query. Официальная документация описывает профиль и качество колонок и предупреждает, что по умолчанию анализ может охватывать первые 1 000 строк. Для проверки полного набора нужно изменить режим. Это полезная конкретная проверка: аккуратная первая тысяча не доказывает чистоту всей выгрузки.

Результат аудита: реестр проблем с владельцами. Абстрактный процент качества в презентации здесь ничего не даст. Например: 14 товаров без единицы, 6 спорных соответствий поставщиков, 3 отсутствующие связи с объектами. Такие числа берут из собственной выгрузки и маркируют датой и объёмом проверки.

Где ИИ помогает, а где нужны строгие проверки

ИИ полезен для группировки похожих названий, извлечения характеристик из описаний и предложения возможных соответствий. На вход поступают ограниченный справочник и подтверждённые примеры. На выходе нужны пары записей, признаки совпадения, различающиеся поля и ссылка на источник каждого существенного признака.

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

Точные правила находят пустые ключи, недопустимые форматы и нарушение уникальности. ИИ помогает там, где описания неодинаковы, но смысл может совпадать. При таком разделении модель не тратит деньги на проверку пустого поля, а похожесть не принимают за доказательство идентичности.

Почему объединение дублей требует отдельного решения

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

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

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

Что считать готовностью к запуску

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

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

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

Какой продукт можно сделать первым

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

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

Смежные разборы: Обмен данными между системами: как не терять заявки при сбоях; Техническое задание на автоматизацию: что описать заказчику.