Нова CRM або ERP може бути налаштована правильно, але після імпорту користувачі побачать трьох однакових клієнтів, товари без одиниць виміру, негативні залишки та відкриті замовлення, які давно виконані. Команда швидко втратить довіру й повернеться до старих таблиць.
Міграція даних — окремий етап впровадження з власником, правилами очищення, пробними завантаженнями та актом звірки. Її мета — перенести необхідну операційну основу, а не весь цифровий архів компанії.
Що переносити, а що залишити в архіві
| Група | Зазвичай переносимо | Можна залишити в архіві |
|---|---|---|
| Клієнти й постачальники | Активні картки, реквізити, контакти, відповідальні | Дублікати та записи без підтвердженої цінності |
| Номенклатура | Активні товари, одиниці, категорії, штрихкоди | Закриті позиції без залишку й руху |
| Залишки | Кількість за складами та узгоджена оцінка на дату | Старі проміжні перерахунки |
| Відкриті операції | Невиконані замовлення, резерви, борги, аванси | Завершені документи, доступні у старій системі |
| Історія | Період, потрібний для поточної роботи й аналітики | Детальна давня історія в режимі читання |
Рішення залежить від юридичних і управлінських вимог. Архів не означає видалення: старі дані можуть залишатися доступними лише для перегляду, не ускладнюючи новий робочий контур.
Почніть із інвентаризації джерел
Один клієнт може бути записаний у CRM, бухгалтерії, таблиці менеджера й інтернет-магазині. Для кожного джерела зафіксуйте власника, актуальність, формат, обсяг, ключі та якість.
| Джерело | Що перевірити | Ризик |
|---|---|---|
| Стара CRM | Унікальний ID, власник клієнта, статус угод | Дублі після ручного створення карток |
| Облікова система | Реквізити, борги, одиниці й оцінка | Інша логіка довідників |
| Інтернет-магазин | Email, телефон, SKU, замовлення й повернення | Гостьові та повторні акаунти |
| Таблиці | Автор, дата оновлення, формули, приховані листи | Немає єдиного формату й контролю |
Визначте ключі та правила дублів
ПІБ або назва компанії не є надійним ключем. Люди змінюють написання, компанії мають філії, а один телефон можуть використовувати кілька контактів. Правило об'єднання повинно враховувати тип клієнта, податковий номер, нормалізований телефон, email і зв'язок контактної особи з організацією.
Автоматично об'єднуйте лише очевидні дублікати. Сумнівні пари краще винести в чергу ручної перевірки, ніж втратити історію двох різних контрагентів.
Карта відповідності полів
Для кожного цільового поля вкажіть джерело, перетворення, обов'язковість, значення за замовчуванням і дію при помилці.
| Цільове поле | Джерело | Перетворення | Контроль |
|---|---|---|---|
| Телефон | Кілька текстових колонок | Єдиний міжнародний формат | Некоректні номери в окремий звіт |
| SKU | Код товару | Прибрати службові пробіли, не втратити нулі | Унікальність активних позицій |
| Одиниця виміру | Текстове скорочення | Зіставити із затвердженим довідником | Невідомі одиниці блокують рядок |
| Статус замовлення | Старий код | Таблиця відповідності новим статусам | Без мовчазного значення «нове» |
| Відповідальний | Ім'я менеджера | Зіставити з активним користувачем | Звіт про звільнених співробітників |
Початкові залишки — це контрольна точка
Залишок не можна переносити «на зараз», поки в старій системі продовжуються рухи. Визначте дату й час зрізу, завершені документи до цієї межі та правило для операцій після неї.
Окремо звіряють кількість товару, резерви, собівартість, дебіторську й кредиторську заборгованість, аванси та касу. Загальний нуль не гарантує правильності: переплата одного клієнта може компенсувати борг іншого.
Пробний імпорт до бойового
- Візьміть повну копію даних, а не лише десять красивих рядків.
- Завантажте її в тестовий контур за тією ж процедурою, що буде використана на запуску.
- Порахуйте кількість вхідних, створених, об'єднаних і відхилених записів.
- Звірте контрольні суми й вибірково пройдіть ланцюжки клієнт → замовлення → оплата.
- Виправте правило в джерелі або карті, очистіть тестовий результат і повторіть.
Ручне виправлення сотень записів після кожного тесту приховує проблему. Міграція повинна відтворюватися з однаковим результатом.
Критерії приймання міграції
- кількість записів пояснена: імпортовано, об'єднано, пропущено, відхилено;
- контрольні суми залишків і боргів збігаються на дату зрізу;
- немає невідомих одиниць, складів, валют і відповідальних;
- відкриті документи зберегли зв'язки та залишкові суми;
- користувачі перевірили реальні картки зі своєї роботи;
- старі ID збережені для трасування й повторної звірки.
Висновок
Успішне перенесення складається з інвентаризації джерел, відбору потрібної історії, очищення, карти відповідності, пробного імпорту й фінальної звірки на єдиний момент часу. Нова система не повинна ставати дорогою копією старого хаосу.
Після перевіреної міграції можна планувати пілот, навчання й момент переходу, не зупиняючи весь бізнес одним ризиковим запуском. Переглянути ядро Business Reactor.
