Міграція даних — етап, на якому ERP-проєкти ламаються найчастіше. Систему налаштувати можна за будь-яким графіком, а от перенести десять років обліку зі старої програми, де контрагенти дублюються, товари записані п’ятьма способами і залишки давно ніхто не звіряв, — це робота, яку не приховаєш за красивою презентацією. На досвіді CBPM Service можемо сказати: коли міграція проходить спокійно, перед цим була ретельна підготовка. Розберемо її по кроках.
Що саме переносити в нову ERP, а що лишити в минулому
Типова помилка — намагатися перенести все, що накопичилося за роки роботи. За цим стоїть чесне побоювання: раптом стара інформація знадобиться. На практиці 80% щоденної роботи використовує не більше пари років історії, а все решта просто тягне за собою сміття. Тому на старті разом з інтегратором складають перелік того, що їде в нову систему:
- Довідники — контрагенти, товари, працівники, одиниці виміру. Серце системи, тут помилки найдорожчі.
- Залишки на дату переходу — складські, касові, взаєморозрахунки. Саме з цієї цифри нова система починає жити.
- Відкриті документи — незакриті замовлення, рахунки, зобов’язання.
- Історія операцій — обмежена домовленим періодом, зазвичай одного-двох років для аналітики.
- Архів решти — зберігається окремо, у доступному форматі, для податкової та аудиторів.
Окремим рішенням стоїть питання рахунків обліку: мапінг старого плану рахунків на структуру нової ERP роблять вручну і узгоджують із головним бухгалтером ще до першої тестової вигрузки, тому що помилка на цьому рівні спливе місяцями пізніше, коли розбиратися буде дорого.
Чистка даних перед міграцією: нудна робота, яка економить місяці
Міграція не виправляє хаос, вона його переносить. Якщо в старій системі один і той самий контрагент заведений чотири рази з різними написаннями, нова ERP чесно збереже всі чотири. Тому до будь-яких скриптів потрібно провести аудит і чистку довідників, і ось що в нього входить:
- пошук і злиття дублікатів контрагентів та номенклатури;
- перевірка обов’язкових полів: коди, одиниці виміру, податкові реквізити;
- позначення неактивних позицій, які не поїдуть у нову систему;
- звірка залишків з фактичними — склад, каса, розрахунки;
- вирішення по «висяках»: дебіторка, якій три роки, документи без проведення.
За практикою, чистка займає від кількох тижнів до пари місяців, залежно від стану даних, і це той випадок, коли варто залучати людей, які знають бізнес, а не лише програмістів.
Технічна частина: тестові переноси і звірка
Жоден нормальний інтегратор не робить міграцію «в один стрибок». Схема, яка працює, виглядає так: спочатку технічна вигрузка даних і розробка скриптів перенесення, потім міграція в тестову базу, потім кілька тижнів тестової експлуатації, коли користувачі працюють уже на нових даних і знаходять огріхи, і лише після цього — перенесення в бойову систему на узгоджену дату, коли стара система остаточно заморожується.
Після кожного переносу — обов’язкова звірка: залишки нової системи проти старої, кількість документів, суми взаєморозрахунків по кожному контрагенту. Цифри мають сходитися до копійки, і перевіряти треба не десять вибіркових позицій, а весь обсяг.
Типові помилки, які дорого обходяться
Кілька помилок трапляються настільки часто, що варто їх назвати окремо:
- Переносити все без вибору. Сміття їде в нову систему і отруює звітність роками.
- Заморозити стару систему пізно. Хтось продовжує вносити документи під час перенесення — і залишки розходяться вже в перший день.
- Звіряти вибірково. «Десять довільних контрагентів сходяться» не означає, що сходяться всі дві тисячі.
- Залишити чистку «на потім». «Перенесемо як є, а потім приберемо» — фраза, після якої ніхто нічого не прибирає.
- Не призначити відповідального за дані. Якщо ніхто з боку замовника не перевіряє результат, інтегратор перевіряє сам себе.
Специфіка міграції з 1С і BAS
Компанії, що йдуть з 1С або BAS, стикаються зі своїми підводними каменями, і їх варто знати заздалегідь. По-перше, структури даних цих систем виросли десятиліттями допрацювань, тож вигрузка рідко буває чистою: поля дублюються, кілька довідників дратують один одного, частина інформації взагалі лежить у зовнішніх файлах. По-друге, план рахунків українського обліку відрізняється від структури Microsoft Business Central, тож прямого переносу не існує — тільки мапінг з рішеннями щодо кожної групи операцій.
По-третє, варто відразу вирішити долю допрацювань старої системи, якими компанія користувалася роками: якщо їх список ніхто не проглянув, через місяць після запуску виявиться, що якийсь звіт, без якого відділ не уявляє роботу, ніхто не переніс. Досвідчений інтегратор починає з інвентаризації таких речей, а не з технічної вигрузки.
Як виглядає день переходу на нову ERP
Перенесення даних планують на вихідні або в момент мінімальної активності, щоб мати запас часу на непередбачене. У п’ятницю ввечері стару систему заморожують: ніхто більше не вносить документів. Далі запускають скрипти перенесення, після яких бухгалтерія звіряє критичні залишки — склад, касу, взаєморозрахунки.
Якщо звірка чиста, у понеділок компанія працює вже в новій системі, а стара лишається доступною лише для читання. Бажано, щоб у цей період підтримка інтегратора була на зв’язку щодня, тому що перші питання користувачів приходять саме в перший тиждень, і швидкі відповіді тоді коштують дешевше, ніж помилки, накопичені за місяць.
Як міграцію даних роблять у CBPM Service
У нашій методології міграція — окремий етап з власним планом і критеріями приймання. Ми починаємо з аудиту даних замовника та чистки довідників, окремо веземо довідники і окремо залишки на узгоджену дату, рахунки обліку мапимо вручну з головним бухгалтером клієнта, а перед бойовим переходом проводимо повну звірку всіх залишків і документів. Після запуску ми залишаємося поруч на перше закриття місяця, адже саме тоді будь-яка помилка міграції дає про себе знати.
Якщо плануєте переносити дані з 1С або BAS у Microsoft Business Central — почніть з безкоштовної експрес-оцінки на сайті CBPM Service. На першій зустрічі вже видно, у якому стані ваші дані і що з ними робити.
