Как подготовить данные к загрузке в новую систему, если старые справочники не совпадают?
Если старые справочники не совпадают, сначала не загружайте их в новую систему. Сначала нужно договориться, что именно означает каждая запись, выбрать главный источник и проверить связи на небольшой копии данных. Иначе новая система просто унаследует старую путаницу, но будет выглядеть современнее.
Справочник — это не просто таблица со значениями. В нём живут названия товаров, клиентов, подразделений, статусы заказов, единицы измерения и правила, на которых держатся документы. Когда один и тот же контрагент в продажах записан как «Альфа», на складе — как «ООО Альфа», а в бухгалтерии — по ИНН, проблема не в трёх строках. Проблема в трёх разных способах понимать одного участника процесса.
Начните с вопроса, для чего нужен каждый справочник
Не все старые таблицы нужно переносить целиком. У одних значений есть действующие документы и остатки. Другие нужны для отчёта по истории. Третьи давно не используются, но остались «на всякий случай».
Составьте короткий список: название справочника, владелец, где он используется, какой ключ считается главным и что будет, если значение не перенести. Эта работа хорошо ложится на карту данных компании. Карта помогает увидеть не только файлы, но и людей, которые принимают решения о данных.
Найдите не только точные, но и смысловые дубли
Точные повторы обнаружить легко: одинаковый ИНН, артикул или номер телефона. Гораздо опаснее почти одинаковые записи. «Доставка по городу» и «Доставка Иркутск» могут быть одной услугой, а могут означать разные условия. Склеить их автоматически — значит незаметно поменять правила расчёта.
Полезно разбить разбор на три корзины:
- точно объединяем — совпадают ключи и смысл;
- оставляем отдельно — различие влияет на работу;
- нужна проверка владельца — данных недостаточно для решения.
Третья корзина важнее скорости. Владелец процесса лучше всех знает, является ли «срочный заказ» самостоятельным сценарием или просто неудачной пометкой в старой системе.
Договоритесь о главном источнике для каждого поля
Нельзя назначить одну систему главной «вообще». Для реквизитов клиента главным может быть бухгалтерский контур, для статуса заказа — операционная система, для условий доставки — карточка сделки. Это и есть практический смысл единого источника данных: не одна база на все случаи, а ясное правило, кому верить в каждом вопросе.
Зафиксируйте это в таблице соответствий. Слева — старое поле и его значение. Справа — новое поле, правило преобразования и ответственный. Если часть значений не подходит новой модели, не прячьте это в скрипте загрузки. Отдельный список исключений честнее и безопаснее.
Сделайте пробную загрузку на небольшом наборе
Пробная загрузка нужна не для того, чтобы «проверить, запускается ли импорт». Она проверяет обычный рабочий день. Создаётся ли заказ? Подставляется ли правильный клиент? Сходятся ли остатки? Понимает ли сотрудник новый статус?
Возьмите несколько реальных, но обезличенных при необходимости сценариев: постоянный клиент, новый клиент, возврат, нестандартная единица измерения, закрытый договор. После загрузки пройдите эти сценарии вместе с пользователем. Так легче заметить ошибку в значении, которую не покажет строка «успешно импортировано».
Особенно осторожно работайте с объединением дублей. В статье о дублях клиентов я разбирал, почему нельзя терять историю и сделки. То же правило действует до миграции: сначала понять, что произойдёт со связями, и только потом склеивать карточки.
Оставьте путь назад
До основной загрузки сохраните исходный набор, таблицу соответствий и журнал преобразований. Это не бюрократия. Через неделю кто-то обязательно спросит, почему конкретный статус стал «выполнен», а не «закрыт». Возможность показать правило лучше, чем спор о памяти участников.
Новая система не обязана хранить все старые ошибки. Но команда должна уметь объяснить, что именно было исправлено, что перенесено как есть и кто это решил.
Короткий порядок действий
- Соберите перечень справочников и их владельцев.
- Отделите используемые значения от архивных.
- Разберите точные и смысловые дубли.
- Назначьте главный источник для каждого важного поля.
- Сделайте таблицу соответствий и список исключений.
- Проверьте пробную загрузку на реальных сценариях.
- Сохраните исходные данные и журнал решений.
Хорошая загрузка начинается задолго до кнопки «Импорт». Она начинается с общего языка между продажами, складом, финансами и теми, кто настраивает систему. Когда этот язык найден, перенос становится предсказуемой работой, а не лотереей.
Не превращайте очистку в тайный проект IT-отдела
Справочники невозможно качественно привести в порядок силами только тех, кто настраивает систему. Техническая команда может найти пустые значения и похожие строки. Но она не знает, можно ли объединить две одинаково названные услуги, какой клиент уже закрыт и какой статус важен для премии менеджера. Решения о смысле нужно подтверждать с владельцами процессов, а результат — фиксировать так, чтобы его можно было проверить.
Полезный формат — короткая еженедельная сверка спорных случаев. Не пытайтесь обсудить все тысячи строк на одном совещании. Покажите десять-двадцать исключений, примите решения, обновите правила и примените их к следующей партии. Такой темп спокойнее, чем большой «день чистки», после которого участники не помнят, почему приняли конкретное решение.
После запуска работа не заканчивается
Новая система начнёт получать новые данные сразу же. Если не задать владельца справочника и правило создания значения, через месяц появятся те же дубли, только уже в красивом интерфейсе. Нужны простой маршрут: кто предлагает новое значение, кто утверждает, что оно действительно новое, и где видно историю изменения. Тогда первая загрузка станет не разовой героической операцией, а началом управляемого порядка.
Обсудим?