Тема переходу з 1С/BAS в Україні дедалі менше стосується вибору “залишатися чи ні” , а в бізнесових колах все частіше обговорюється готовность бізнесу до самої міграції. Той факт, що деякі законодавчі ініціативи поки не були ухвалені, не знімає відповідальності з компаній. Навпаки, зростає потреба оцінити залежність від ворожого софту та підготувати сценарій переходу. Більшість ризиків — регуляторний тиск, вимоги до кібербезпеки та загальний курс на відмову від російського ПЗ — нікуди не зникають.
Відкладена міграція з 1С часто перетворюється на терміновий проєкт, який доводиться запускати під тиском обставин та без достатнього часу на аудит, вибір системи та підготовку даних. Нерідко цей процес тягне за собою багато помилок.
Що показують цифри щодо впровадження ERP?
Складнощі під час переходу на ERP це скоріше не виняток, а типова частина таких проєктів. Перехід з 1С/BAS за обсягом робіт багато в чому наближається до повноцінного впровадження нової системи, адже потребує перегляду процесів, перенесення даних, налаштувань і навчання команди. Тому очікувати, що все пройде ідеально та без труднощів, не варто. Щоб показати масштаб проблеми ширше, ми звернулися до міжнародних досліджень та статистики ERP-впроваджень.
Наприклад, у прогнозі Gartner йдеться про понад 70% нещодавно впроваджених ERP-ініціатив до 2027 року, які не досягнуть повністю початкових бізнес-цілей:
- 25% з них провалиться катастрофічно,
- 75% ERP-стратегій не узгоджені з бізнес-стратегією компанії.
Масштаб перевитрат показує дослідження McKinsey й Оксфордського університету на вибірці понад 5 400 ІТ-проєктів з бюджетом понад $15 млн:
- перевищення бюджету в середньому на 45%,
- перевищення строків на 7% при недоотриманні 56% очікуваної цінності, причому кожен додатковий рік тривалості додає 15% до перевитрати.
“Бізнес починає мислити проактивно — не лише виконувати вимоги регулятора, а будувати фундамент для власної зрілості”, — зазначає Олена Кузьмічова, співзасновниця Ukrainian ERP Forum
12 помилок при переході з 1С/BAS
Міграція на нову ERP майже завжди приносить несподівані задачі та складні рішення. Усі ризики передбачити неможливо, але типові помилки — цілком реально. Далі розберемо 12 із них, щоб допомогти пройти цей шлях із меншими втратами часу, бюджету й ресурсу команди.
1. Мета сформульована як дія, а не як результат
Дія “замінити 1С” описує сам факт переходу, але не пояснює, що бізнес має отримати по завершенню проєкту. Без чіткої цілі складно визначити пріоритети, обґрунтовано відмовлятися від другорядних вимог та, зрештою, оцінити, чи було впровадження успішним. Мета має бути пов’язана з конкретними змінами в роботі компанії.
Як уникнути: Ще до вибору системи зафіксуйте 3-5 вимірюваних показників у форматі “поточне значення → цільове значення → період”, наприклад зменшити час закриття місяця, частку ручних звірок або кількість систем, у які доводиться повторно вводити той самий документ.
2. Обирати ERP лише за списком функцій
Продукти порівнюють за списком функцій, припускаючи, що сама їх наявність уже означає відповідність потребам компанії. Panorama у звіті 2026 року називає найчастішою причиною перевищення бюджету неочікувану потребу в додаткових технологіях і пояснює її поганим вибором системи.
Як уникнути: До вибору зафіксувати варто процеси з власниками, обсяги операцій, точки інтеграції та звіти, за якими ухвалюють рішення, а постачальника перевіряти сценарієм на власних даних: цикл від рахунку до податкової накладної, реєстрації в ЄРПН і РК на зменшення тощо.
3. Плутати локалізацію з українським обліком
Повної української заміни 1С/BAS, яка б відтворювала весь звичний контур “один в один”, фактично немає. Тому бізнес часто обирає міжнародну ERP і окремо вирішує питання локалізації під український бухгалтерський і податковий облік.
Саме тут важливо розрізняти переклад інтерфейсу, базову локалізацію та повноцінні доопрацювання під чинне законодавство України. Український облік має власну специфіку, тому сама наявність української мови або локального плану рахунків ще не означає, що система закриє всі вимоги бухгалтерії.
Окремо варто визначити масштаб задачі. Якщо компанії потрібно лише замінити бухгалтерський контур, це один сценарій. Якщо ж мова про повноцінну ERP для фінансів, продажів, закупівель, складу, виробництва чи інших процесів, це вже значно ширша трансформація всієї роботи компанії.
Як уникнути: Перед вибором системи уточніть, хто відповідає за український облік у продукті, як швидко виходять оновлення після змін законодавства і чи є реальні впровадження в Україні. Паралельно зафіксуйте, що саме ви замінюєте — тільки бухгалтерію чи весь операційний контур.
4. Рахувати бюджет лише за ліцензіями та роботою інтегратора
Фактична вартість переходу майже завжди ширша за початковий кошторис. До неї входить час команди на звірки, підготовку даних, тестування й навчання, а також тимчасове падіння продуктивності в перші місяці після запуску. Окремою статтею варто рахувати міграцію даних. Наприклад, NetSuite оцінює її приблизно у 10-15% вартості ERP-проєкту.
Як уникнути: Рахуйте не лише стартову вартість впровадження, а повну вартість володіння системою на кілька років. Окремо закладіть ліцензії, впровадження, міграцію даних, інтеграції, навчання, внутрішні трудовитрати, підтримку кастомізацій і резерв на непередбачені роботи.
Також рекомендуємо ознайомитися зі статтею Self-ERP — офіційного партнера Oblik-ERP. У матеріалі «З чого складається вартість ERP та як її ефективно планувати? Досвід Self-ERP» Володимир Ткаченко, Head of Sales Self-ERP, пояснює, з чого формується бюджет ERP-проєкту, які додаткові витрати можуть виникнути та як зменшити ризик непередбачених перевитрат.
5. Переносити старі процеси в нову систему без перегляду
Під час міграції компанії часто намагаються відтворити в новій ERP звичну логіку роботи з 1С/BAS. Разом із корисними процесами переносяться ручні обходи, дублювання та старі компроміси, які накопичувалися роками.
Наслідок — більше кастомізацій, складніша підтримка і дорожчі майбутні оновлення. Показовий приклад — Birmingham City Council. Спочатку рада планувала використовувати стандартну логіку Oracle і відповідно змінити власні процеси, але згодом систему почали кастомізувати під наявний спосіб роботи. У звіті Grant Thornton це названо одним із факторів, що ускладнили впровадження.
Як уникнути: Виходьте з принципу “стандартна функціональність — за замовчуванням”. Кожне доопрацювання має відповідати на просте питання: чи справді без нього бізнес не може працювати. Якщо так — окремо оцініть вартість розробки, підтримки та майбутніх оновлень.
6. Додавати кастомізації без ліміту та оцінки майбутньої підтримки
Окреме доопрацювання часто здається невеликим, але десятки таких рішень поступово ускладнюють систему. Зростають витрати на підтримку, тестування й майбутні оновлення. SAP прямо зазначає, що накопичений кастомний код і недокументовані зміни знижують гнучкість ERP, уповільнюють оновлення та збільшують загальну вартість володіння.
Показовий масштаб ризику дає проєкт Lidl eLWIS на SAP for Retail. Компанія працювала над ним сім років, але у 2018 році зупинила впровадження, оскільки поставлених цілей не вдалося досягти з прийнятними витратами, і повернулася до розвитку старої системи.
Як уникнути: Встановіть ліміт на кастомізації ще на старті проєкту. Кожне нове доопрацювання оцінюйте не лише за вартістю розробки, а й за майбутньою підтримкою та впливом на оновлення. Для орієнтиру, у дослідженні Panorama 2023 року 34,4% компаній впроваджували ERP без кастомізації, використовуючи стандартні можливості, конфігурацію або персоналізацію.
7. Переносити в нову ERP всю історію без оцінки її реальної потреби
Спроба перенести всю історію суттєво збільшує обсяг робіт: дані потрібно очистити, зіставити з новою структурою, протестувати й перевірити після завантаження. При цьому бізнесу далеко не завжди потрібна вся історія безпосередньо в новій ERP.
SAP, наприклад, розділяє сценарії переходу: для нового впровадження завершені та закриті транзакції не переносяться, а в Selective Data Transition обсяг історії визначають окремо. Схожий підхід ми використовуємо й у проєктах переходу з 1С/BAS: спочатку визначаємо, які дані реально потрібні для старту нової системи — актуальні довідники, контрагенти, початкові залишки та відкриті операції, а історію оцінюємо окремо.
Як уникнути: До міграції розділіть дані на категорії: довідники, залишки, відкриті документи, налаштування та історію. Якщо стара інформація потрібна лише для перегляду або аудиту, часто достатньо залишити стару базу як архів, а не переносити її повністю.
Корисною буде стаття на тему Як обрати альтернативу 1С/BAS? Критерії вибору
8. Мігрувати довідники без попереднього очищення
Разом із контрагентами, товарами та іншими довідниками в нову ERP часто переїжджають дублікати, різні варіанти назв, застарілі записи й некоректні коди. Якщо не прибрати ці помилки до міграції, нова система починає працювати з уже неякісними даними.
Показовий приклад — Target Canada. Внутрішня перевірка показала, що дані про товари були коректними приблизно лише у 30% випадків. Помилки в характеристиках товарів впливали на роботу складів і автоматичного поповнення, тому магазини могли залишатися з порожніми полицями, тоді як розподільчі центри були переповнені.
Як уникнути: Очищення даних потрібно починати ще до міграції. Microsoft рекомендує залучати до цього користувачів, які найкраще знають свої дані, і призначати відповідального за їх якість. До перенесення варто прибрати дублікати, стандартизувати назви та визначити, які записи справді потрібно переносити.
9. Не звіряти перенесені дані
Успішне завантаження ще не означає, що дані перенесені правильно. Після міграції потрібно перевірити, чи збігаються залишки, відкриті операції та ключові показники в новій і старій системах. Інакше помилки можуть проявитися вже після запуску, коли повернутися до старої бази значно складніше.
Для 1С/BAS це особливо важливо, адже залишки змінюються разом із новими проведеними документами. Якщо під час фінального перенесення користувачі продовжують працювати в старій системі, результати звірки можуть постійно змінюватися.
Як уникнути: Заздалегідь визначте дату відсічення, після якої дані в старій системі більше не змінюються, і проведіть кілька тестових міграцій. Microsoft рекомендує тестувати перенесення кілька разів до запуску, а Oracle використовує окремі mock-цикли для перевірки процесу конвертації даних. Після фінального перенесення обов’язково звірте залишки й ключові показники зі старою системою.
10. Зводити UAT до демонстрації окремих функцій
Перевірити, що форма відкривається, документ проводиться, а звіт формується, недостатньо. Перед запуском потрібно пройти повні бізнес-сценарії від початку до кінця на даних, максимально наближених до реальних.
Показовий приклад — спір National Grid із Wipro після впровадження SAP. National Grid стверджувала, що тестування було скороченим і не виявило частину критичних дефектів до запуску. Після go-live компанія зіткнулася, зокрема, з проблемами в розрахунку зарплати. Сторони згодом врегулювали спір, а Wipro виплатила $75 млн без визнання відповідальності.
Як уникнути: Не зводьте User Acceptance Testing (UAT) до презентації готової системи. Microsoft рекомендує проводити кілька циклів end-to-end тестування, у яких бізнес-користувачі проходять повні робочі сценарії на мігрованих даних. Для бухгалтерського контуру варто окремо відтворити закритий період і звірити ключові результати — залишки, ПДВ, собівартість і зарплату. Обов’язково перевіряйте й нетипові сценарії, а не лише стандартні операції.
У дослідженні Залежність від 1С/BAS: чому український бізнес відкладає перехід та чим це загрожує? детально розбирали фактори, що стримують перехід.
11. Сприймати ERP-впровадження як суто ІТ-задачу
ERP змінює роботу не лише ІТ-команди, а й бухгалтерії, фінансів, продажів, закупівель та інших підрозділів. Якщо рішення про процеси нікому ухвалювати, а користувачів залучають лише перед запуском, багато проблем виявляються надто пізно.
Дослідження причин невдалих ERP-впроваджень регулярно називають серед ключових факторів слабку підтримку керівництва та недостатню підготовку користувачів. Схожу проблему зафіксував і аудит Birmingham City Council — операційні команди були недостатньо залучені, а ризики перед запуском не отримували належної уваги.
Як уникнути: Проєкт має мати бізнес-спонсора, керівника з повноваженнями ухвалювати рішення та відповідальних за ключові процеси. Користувачів варто залучати ще на етапі проєктування і тестування, а навчання будувати навколо їхніх реальних робочих сценаріїв, а не показу інтерфейсу перед запуском.
“Найбільша помилка – зосереджуватися лише на технологіях і забути про людей. ERP – це не просто нова програма, а зміна способу роботи”, — говорить Ірина Пемпус, співзасновниця компанії One Service Consulting в інтерв'ю ERP Forum
12. Вважати go-live завершенням проєкту
Запуск системи — це лише перехід у реальну роботу, а не завершення проєкту. Якщо немає чіткого плану переходу, відповідальних, критеріїв перевірки та сценарію дій у разі проблем, навіть технічно успішний старт може швидко перетворитися на операційний збій.
Tennant Company запустила SAP у Північній Америці в листопаді 2025 року, оцінивши готовність за успішним запуском у меншому регіоні. За власною оцінкою компанії, збої в управлінні замовленнями дали близько $30 млн негативного впливу на продажі кварталу і $22 млн зниження скоригованого EBITDA, а повна інвентаризація вимагала двотижневої зупинки виробництва.
Як уникнути: До go-live потрібен окремий план переходу: хто і що робить, у якій послідовності, як перевіряється кожен крок і що відбувається, якщо система працює не так, як очікувалося. Після запуску варто передбачити період посиленої підтримки, швидке виправлення критичних проблем і повторну перевірку бізнес-результатів через кілька місяців.
Висновок
Більшість помилок міграції з 1С/BAS не є технічними. Вони походять від двох рішень, ухвалених до старту, зокрема компанія замінює облікову програму чи змінює спосіб роботи, та вона починає проєкт за планом чи під тиском обставин. Перше визначає строки, бюджет і критерій успіху, друге — чи буде час на обстеження процесів, очищення довідників і кілька циклів тестування.
Найдешевша частина міграції — та, яку можна зробити до появи дедлайну і навіть до вибору системи, а саме описати процеси у скоупі й призначити їм власників, почати очищення довідників, визначити глибину історії, скласти перелік кастомізацій тощо. Жоден із цих пунктів не потребує бюджету на ліцензії, але кожен знімає ризик, який під тиском строків уже не знімається.