Чому експерт з ERP-систем, який працює лише з однією платформою, не може об’єктивно оцінити перехід

Порада про перехід на нову ERP-систему рідко буває нейтральною. 

• Консультант, який знає лише нову платформу, зацікавлений у переході.
• Консультант, який знає лише стару, зацікавлений у статус-кво.

Чесна порада вимагає третьої позиції: гібридної експертизи, досвіду з обома системами одночасно.

Сьогодні ми в CBPM Service впроваджуємо Microsoft Business Central. Наш попередній досвід з 1С, БАС, LS Central та Odoo сформував гібридну експертизу: ми бачимо не тільки нову платформу, а й логіку системи, з якою клієнт прийшов до нас.

За 25 років у впровадженні ERP систем і понад 200 завершених проєктів у 12 галузях ми переконалися, що саме здатність розуміти обидві сторони визначає якість поради консультанта більше, ніж сертифікат з однієї платформи.

Авторами статті є експерти CBPM Service:

Нестор Барановський, архітектор ERP-систем з понад 20-річним практичним досвідом на 1С, БАС і Business Central.

Євген Моргаєв, комерційний директор CBPM Service з понад 15-річним досвідом у сфері автоматизації бізнес-процесів.

Чому фахівець, який знає тільки одну ERP-систему, бачить лише половину картини

Обмеженість тут не про кваліфікацію, а про кут зору: консультант з досвідом лише однієї платформи фізично не може порівняти те, чого сам ніколи не бачив.

Значна частина українських спеціалістів з інформаційних систем сформувала свій професійний досвід у межах однієї екосистеми. 

За оцінкою галузевої асоціації IT Ukraine, станом на 2026 рік близько 75% українських компаній усе ще користуються продуктами 1С або БАС. Це не тимчасове явище, а результат тридцяти років поширення однієї системи обліку на переважній більшості підприємств країни.

Нестор описує наслідок цього прямо:

“Бачу надзвичайно обмежене розуміння сучасних світових ERP-систем серед наших спеціалістів, оскільки більшість підприємств тривалий час, десятиліттями, працювала з 1С. Уся філософія мислення вибудовується крізь призму цієї системи.”

→ Практично це означає конкретну прогалину. Фахівець, що ніколи не працював з нічим іншим, не має бази для порівняння: він не може сказати, що саме клієнт втрачає, залишаючись на старій платформі, і що саме отримує, а що втрачає, переходячи на нову.

Модель трьох компонентів: що насправді визначає успіх впровадження

Три компоненти повинні зійтися одночасно, щоб рішення не спиралося лише на одну сторону картини.

Нестор зазначає:

“Для ефективного впровадження ERP-системи потрібен резонанс трьох компонентів: розуміння бізнес-процесів замовника, розуміння діючої системи і розуміння нової системи. Тільки так можна досягти успіху.”

1. Розуміння бізнес-процесів замовника критичне, бо саме від них ми відштовхуємося у будь-якому проєкті.
2. Розуміння діючої системи, того, що є “під капотом”, дає змогу побачити логіку, за якою компанія вже працює.
3. Розуміння нової системи завершує картину: без нього неможливо оцінити, що зміниться і чи виправдає перехід витрачені ресурси.

Консультант, який має досвід лише з новою системою, бачить третій компонент добре, а перші два, у кращому випадку, з чужих слів клієнта. Це не обов’язково погана порада, але вона неповна: клієнт розповідає про свої процеси так, як сам їх розуміє, а не так, як вони реально відображені в структурі його поточної системи.

Недокументовані доопрацювання БАС: хаос чи мапа реальних бізнес-процесів вартих вивчення, а не видалення

Досвідчений спеціаліст завжди спробує зрозуміти, навіщо клієнт свого часу зробив те чи інше доопрацювання. Складніше — інше: технічно оцінити, наскільки конкретний нюанс критичний саме для цього бізнесу, а не просто ускладнення, яке можна спростити. 

Помилка тут коштує дорого: спеціаліст пропонує прибрати щось у новій платформі як зайве, а виявляється, що це відображало процес, критичний для роботи клієнта.

Гнучкість платформи, яка стала і перевагою, і проблемою

БАС історично вирізнявся суттєвою гнучкістю: систему можна було донастроювати під конкретного клієнта майже без обмежень. Наслідком стало те, що більшість підприємств з роками обросла різноманітними незадокументованими доопрацюваннями.

Типова інтерпретація такого стану проста: це технічний борг, який нова ERP система має просто прибрати. Але Нестор пропонує інший погляд:

“Незадокументовані доопрацювання, пов’язані з гнучкістю БАС, але вони дуже часто відображають реальні бізнес-процеси замовника, які потрібно було автоматизувати для його діяльності.”

Приклад: шляхові листи транспортної компанії як бізнес-вимога, не забаганка старої системи

Підприємство, що займається транспортними перевезеннями, законодавчо і логічно потребує шляхових листів. Незалежно від того, яку систему воно використовує, БАС, іншу ERP чи Business Central, ця вимога нікуди не зникає: її треба відобразити в системі так чи інакше.

Те саме стосується і будь-яких унікальних особливостей, які відрізняють конкретне підприємство від інших компаній тієї ж галузі. 

→ Консультант, який не розуміє логіку старої системи, ризикує сприйняти таке доопрацювання як зайвий кастом, який треба спростити, замість того, щоб розпізнати в ньому реальну бізнес-вимогу, яку нова система теж повинна закрити.

Приклад Power BI: як розуміння старої системи формує рішення поверх нової

Гібридна експертиза працює не тільки на етапі вибору платформи, а й під час самого впровадження: вона підказує, чого саме клієнту бракувало роками на БАС і що варто додати поверх нової системи, наприклад, Microsoft Business Central.

З багаторічного досвіду команди CBPM можна навести узагальнений приклад: Microsoft Power BI.

У БАС-екосистемі топ-менеджмент здебільшого не працює з інформаційною системою напряму. Йому готують дані у вигляді таблиць Excel, які складно оперативно комбінувати, щоб побачити динаміку за різні періоди.

Power BI, який ми часто налаштовуємо в межах впровадження ERP-систем, дозволяє топ-менеджменту самостійно маніпулювати показниками, бачити, які періоди були успішними, а які — ні, і швидко переходити до глибшого аналізу проблеми.

Схожа ситуація і зі штучним інтелектом. У напрямку БАС ці механізми історично пропрацьовувалися значно менше, тоді як Microsoft останніми роками активно розвиває AI-інструментарій: у процесах програмування, аналізу даних, налаштування звітності. Досвід роботи з цими інструментами дозволяє підвищити рівень застосування програмного продукту навіть без переходу на нову платформу, а отже, підвищити й ефективність аналізу діяльності підприємства.

“Свіже око” проти знання старої системи: чому Discovery-етап поєднує обидва підходи

Глибоке знання старої системи має і зворотний бік. Хто занадто добре знає, як усе влаштовано зараз, ризикує сприймати поточний стан як єдино можливий і пропустити рішення, які кращі, але не звичні.

Євген:

“Часом має сенс подивитися свіжим оком, не зациклюючись на поточному процесі, і перебудувати бізнес-процес. Типові рішення, так звані “best practices”, дозволяють суттєво його покращити.”

Саме тому наша компанія перед тим, як запускати будь-який проєкт, проводить всебічний аналіз бізнес-процесів замовника. Але важливо побачити і те, що “під капотом”, і як побудована автоматизація. Мабуть, для початку варто вникнути в діючий процес, а тоді вже думати, чи він ефективний і чи потрібно його модифікувати.

Це не суперечність, а послідовність: спочатку діючий процес, потім рішення про зміну.

Ефект свіжого ока при цьому не втрачається. Замовники зазвичай досить чітко пояснюють, чого їм бракувало і що не було враховано в поточній системі, і саме це формулювання, а не абстрактна порада ззовні, стає основою для рішення про модифікацію процесу.

Це і є логіка етапу Discovery в нашій методології: передпроєктне дослідження не для того, щоб зберегти старі процеси недоторканими, а для того, щоб зміни спиралися на реальну картину, а не на припущення ззовні.

Санкційний тиск: чому питання вже не “чи переходити”, а “коли”

Перелік заборонених продуктів зріс у 50 разів за пів року

Питання переходу з БАС чи 1С рідко зводиться до того, яка платформа краща технічно. Точніше, питання інше: які ризики готове прийняти конкретне підприємство, обираючи те чи інше рішення.

Один із цих ризиків, санкційний, перестав бути гіпотетичним. Держспецзв’язку веде офіційний перелік забороненого до використання програмного забезпечення. Станом на 9 січня 2026 року, коли перелік щойно опублікували, у ньому було 40 позицій. Станом на початок серпня 2026 року перелік налічував уже понад 2000 позицій, і до нього системно додавалися продукти торгової марки БАС.

Пряма заборона чи непрямий тиск: де опиняється ваш бізнес просто зараз

Формально заборона поширюється на державний сектор і об’єкти критичної інфраструктури: спочатку йшлося переважно про державні компанії, які адаптувалися до подібних обмежень ще з 2018 року, а також про енергетику, водопостачання та інші життєво важливі для держави галузі.

Приватний бізнес формально залишається поза межами прямої дії переліку. Але непрямий тиск на нього вже реальний: компанії, що беруть участь у тендерах Prozorro, мусять підтверджувати відсутність забороненого ПЗ у своїх системах, і наявність БАС автоматично призводить до дискваліфікації. 

Заборонене ПЗ поступово перетворюється на репутаційний ризик, навіть там, де прямого юридичного обов’язку відмовитися від нього ще немає.

Як зрозуміти, у якій ви ситуації: почекати чи діяти негайно

Коли перехід можна відкласти

Не кожне підприємство мусить переходити негайно. Приватний бізнес, що не належить до критичної інфраструктури, ймовірно, отримає жорсткі обмеження найпізніше з усіх категорій. 

Якщо діюча ERP система все ще виконує свою роль без критичних обмежень, і якщо перехід не пов’язаний із швидким результатом на критичних ділянках, інвестування ресурсів у розробку на попередній платформі часом окупається швидше, ніж очікування нової функціональності, яка може з’явитися лише через місяці чи роки.

Кому варто починати зараз

Три категорії компаній повинні діяти без зволікань. 

1. Новостворені компанії, які тільки обирають, з чого почати. Логічно розпочинати одразу з сучасної платформи, а не будувати процеси на продукті з ризиками, щоб потім думати, як з нього перейти.
2. Підприємства, що перебувають під суттєвим санкційним ризиком
3. Компанії, що дуже активно розвиваються і потребують якнайшвидшої автоматизації.

Ринок України наближається до моменту масового переходу. 

Компанії, які вже мають обраний продукт, сформовану команду і підрядника до цього моменту, отримають перевагу в ціні й часі. Ті, хто відкладає рішення, почнуть із нуля тоді, коли попит на впровадження різко зросте, і заплатять за це дорожче.

Аудиторський слід: технічна відмінність, яку рідко бачать до переходу

У старих системах обліковий документ можна було зайти й змінити без жодного сліду. У сучасних системах будь-яка зміна вже облікованого документа фіксується автоматично: хто змінив, коли, яким було значення на початку і яким стало в кінці.

Нестор:

“Спочатку це виступає подразником: “Як я не зможу просто змінити документ, якщо він уже облікований?” Але згодом ефект стає зворотним: ти можеш прослідкувати весь процес: що було спочатку, що змінилося і що стало в кінці. Це насамперед дисциплінує людей.”

Ефект подвійний. 

1. По-перше, людина стає обережнішою при внесенні даних, бо знає, що кожна зміна залишає слід. 
2. По-друге, зміну все ще можна внести, просто вона зафіксована в протоколі, який показує, хто, коли і як саме змінював документ. Управлінський персонал отримує можливість відстежити, якою була цифра, як вона змінювалася і чому.

Ця відмінність пов’язана й з архітектурною філософією: БАС історично тяжів до того, щоб робити все в одній системі, поєднуючи різні модулі. Західні системи частіше розподілені за платформами: під кожен напрямок — свій найкращий модуль, і компанія обирає рішення відповідно до конкретної задачі, а не підлаштовує один продукт під усе.

Кейс: як реальне міжнародне масштабування визначило вибір платформи

Один із наших клієнтів, ювелірне виробництво, фізично розташоване в Іспанії, але розвиває роздрібну мережу в кількох країнах Євросоюзу: Іспанії, Нідерландах, Польщі, а також в Україні.

До початку проєкту продажі, звітність і облік клієнта працювали в різних, не пов’язаних між собою системах. 

Рішення, яке ухвалили: 

• Впровадити цілісну систему на базі Business Central з іспанською локалізацією для основного напрямку виробництва й продажів. 
• Окремо впровадили підсистему LS Central, розширення для Business Central, для роздрібної мережі в чотирьох локалізаціях. 
• Для українського регламентованого обліку сформували окрему базу з українською локалізацією.

→ Перехід на міжнародну систему викликала не абстрактна перевага нової платформи, а конкретна бізнес-потреба: компанія вже частково розташовувалась поза межами України, і розрізнені системи більше не витримували операцій, що росли одночасно в кількох країнах.

Підсумок: гібридний досвід працює в обидва боки

Гібридний досвід не залишається абстрактною перевагою в описі команди. Він визначає, скільки несподіванок виникає під час проєкту і наскільки чесною може бути порада ще до його початку. 

Це працює в обидва боки: і коли клієнт мігрує, і коли лишається на своїй платформі. Іноді достатньо просто ефективніше працювати на діючій платформі, збагачуючи її можливостями, які раніше здавалися доступними тільки в новій системі. 

В інших випадках зважене рішення вимагає розуміння всіх плюсів і мінусів обох систем одночасно, зіставлених із реальними бізнес-процесами підприємства. Тільки так можна побачити, де насправді є проблеми, а де — тепер уже видимі додаткові можливості.

Про те, як саме побудований наш процес впровадження, від першого дослідження до запуску, можна почитати в розділі про методологію на сайті CBPM Service.