Переїзд із таблиці в CRM або зі старої системи в нову рідко зривається через технічні складнощі. Зривається він через дані: їх виявляється більше, ніж здавалося, вони брудніші, ніж хотілося, і половина полів у старій системі означає не те, що написано в назві.
Гарна новина в тому, що переїзд — керована процедура з передбачуваними етапами. Погана — пропуск будь-якого з них помітний не одразу, а через місяць, коли працювати вже треба, а звіти не сходяться.
Спершу вирішіть, що НЕ переносити
Головне рішення ухвалюється до першого вивантаження: що залишається позаду.
Переносять зазвичай активне: чинних клієнтів, актуальний асортимент, незакриті замовлення, залишки, борги. Плюс історію за розумний період — рік-два, залежно від того, як довго ви реально до неї звертаєтеся.
Усе старше вивантажують в архівний файл і зберігають окремо. Це рішення економить тижні: дані десятирічної давності — це не тільки обсяг, а й весь накопичений безлад, який доведеться чистити руками. До архіву звертаються раз на пів року, і файлу для цього достатньо.
Друге, що не переносять, — сміття: тестові записи, клієнти без жодного контакту, товари, знятих з продажу три роки тому. Переїзд — рідкісна можливість почати з чистого, і нею варто скористатися.
Чистка й довідники
Ця частина займає більше часу, ніж усе інше разом, і саме її зазвичай недооцінюють.
Формат контактів. Телефони мають бути в єдиному вигляді — це основа для пошуку дублів і для будь-яких розсилок пізніше. Пошта — без пробілів і друкарських помилок.
Дублі. Спершу визначте правило унікальності (зазвичай телефон), потім зведіть повтори, вирішивши наперед, яке значення перемагає при розбіжностях — найновіше чи з найповнішої картки. Переносити дублі «як є» не можна: у новій системі вони почнуть обростати новими замовленнями кожен окремо.
Довідники. Статуси, категорії, джерела, одиниці виміру. У старій системі їх зазвичай накопичилося втричі більше, ніж потрібно: пʼять статусів означають одне й те саме різними словами. Звести їх до робочого набору треба до перенесення — інакше ви перевезете хаос у нове місце. Заодно варто одразу розписати, хто що бачить і редагує, — про це в матеріалі про права доступу співробітників.
Звʼязки. Замовлення привʼязані до клієнтів, товари — до категорій. Якщо ідентифікатори при перенесенні зміняться, звʼязки розсиплються, і ви отримаєте базу замовлень без покупців. Це найчастіша технічна помилка міграції.
Тестовий прогін — обовʼязковий
Ніколи не переносьте дані одразу в бойову систему. Спочатку — тестове завантаження на невеликій вибірці: 20–50 клієнтів, кілька десятків товарів, кілька замовлень різних типів, включно з нетиповими.
Далі перевіряють не «чи завантажилося», а конкретне: чи стали числа числами, а дати датами; чи не зʼїхали суми через кому й крапку; чи не перетворилися українські літери на знаки питання; чи збереглися звʼязки замовлень із клієнтами; чи не обрізалися довгі коментарі.
Після цього — контрольні цифри. Кількість клієнтів, кількість замовлень, сума замовлень за період мають збігтися зі старою системою. Якщо не збігаються — шукайте причину зараз, а не після повного завантаження. Як звіряти суми, коли розбіжність саме у грошах, розібрано в матеріалі про автоматичну звірку оплат.
Переїзд і паралельна робота
Саме перенесення краще робити в найспокійніший день тижня, а не в піковий. Перед стартом — фінальне вивантаження зі старої системи, щоб не втратити дані, які зʼявилися після тестового прогону.
Далі — короткий період паралельної роботи за чітким правилом: усі нові дані заводяться тільки в нову систему, стара залишається виключно для перегляду історії. Один-два тижні достатньо. Довша паралельна робота гарантовано призводить до розбіжностей, коли частина замовлень тут, частина там.
І окремо — люди. Система, у яку перевезли ідеальні дані, але не показали команді, як із нею працювати, не запрацює. Мінімум — короткі інструкції для типових дій і одна людина, до якої йдуть із питаннями перший місяць. Найпростіше зібрати їх у базі знань для команди.
Типові помилки
Переносити все й одразу. Найпоширеніша: обсяг зростає, строки пливуть, переїзд відкладається на «після сезону» назавжди.
Чистити після, а не до. У новій системі брудні дані вже обростають новими звʼязками, і чистка стає вдесятеро дорожчою.
Не мати шляху назад. До переїзду має бути повна копія старої бази у файлі, який ви точно можете відкрити. Не «доступ до старої системи», а саме файл — доступ може закінчитися разом із підпискою.
Забути про інтеграції. Сайт, каса, банк, перевізник — усе, що було підʼєднане до старої системи, треба переключити й перевірити. Замовлення з сайту, які тиждень падали в стару базу, — класика жанру; як їх правильно зʼєднати, описано в матеріалі про інтеграцію сайту з CRM. Що саме обрати під ваші задачі, ми розписали в матеріалі CRM чи ERP: що потрібно вашому бізнесу.
Коротко
Перенесення даних починається не з вивантаження, а з рішення, що не переносити: активні дані й історію за рік-два беруть у нову систему, старіше — в архівний файл, сміття видаляють. Найдовший етап — підготовка: єдиний формат телефонів, зведення дублів за чітким правилом унікальності, скорочення довідників до робочого набору, збереження звʼязків між замовленнями й клієнтами. Тестовий прогін на невеликій вибірці обовʼязковий, і перевіряти треба не факт завантаження, а типи даних, кодування, звʼязки й контрольні суми. Сам переїзд роблять у спокійний день, після нього — один-два тижні паралельної роботи з правилом «нові дані тільки в нову систему». Обовʼязково мати повну копію старої бази у файлі та переключити всі інтеграції. З чого взагалі починати автоматизацію — у матеріалі про те, з чого почати автоматизацію.
Ми в Obliko впроваджуємо системи обліку й автоматизації і починаємо саме з даних — бо система, у яку перевезли безлад, не економить час, а лише робить безлад швидшим.
Чи треба переносити всі дані зі старої системи?
Ні, і саме спроба «перенести все» найчастіше зриває переїзд. Переносять активні дані — чинних клієнтів, актуальний асортимент, незакриті замовлення й борги — та історію за розумний період, зазвичай останній рік-два. Старий архів залишають доступним у вигляді вивантаженого файлу: він потрібен раз на пів року, а тягне за собою місяці роботи й весь накопичений безлад. Нова система з чистими даними працює, нова система з десятирічним сміттям — ні.
Що робити з дублями клієнтів?
Чистити до перенесення, а не після. Спочатку визначте, що вважається унікальним записом — зазвичай це телефон у єдиному форматі, рідше пошта, — потім зведіть дублі, вибравши правило, яке поле перемагає при розбіжностях. Якщо перенести дублі як є, вони розмножаться: до кожного варіанту клієнта почнуть чіплятися нові замовлення, і через пів року розділити їх буде вже неможливо.
Скільки часу закладати на перенесення?
Реалістично — від кількох днів для невеликої бази до кількох тижнів, і більшість цього часу займає не саме перенесення, а підготовка: чистка, зведення довідників, узгодження, що чим стає в новій системі. Технічне завантаження файлу — це години. Плануючи переїзд, закладайте ще тестовий прогін і період паралельної роботи: без них строк виглядає коротшим, але ризик втратити дані зростає в рази.
Чи можна працювати у двох системах одночасно?
Не просто можна, а потрібно — але недовго й за чіткого правила, де саме джерело правди. Типовий формат: один-два тижні всі нові дані заводять у нову систему, стару залишають тільки для перегляду історії. Вести облік паралельно в обох довше — гарантований шлях до розбіжностей, коли частина замовлень є тут, частина там, і зводити це доводиться руками.
Потрібен сайт або застосунок?
Розробляємо під ключ — від дизайну до запуску. Порахуємо ваш проєкт безкоштовно.