Як російські ERP-системи змінили прапор, але не змінили код

Розслідування походження програмного забезпечення

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

Російські ERP-системи, які змінили прапор, але не змінили код — це проблема українського ринку автоматизації бізнесу, де частина програмних продуктів після санкцій, ребрендингу або зміни юридичного позиціонування почала продаватися як нові системи, але зберегла ознаки старої технологічної екосистеми.

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

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

Загальний контекст

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

Типові приклади:

компанія більше не використовує назву 1С;
замість 1С використовується BAS;
замість Парус з’являються інші продукти бюджетного обліку;
програмне забезпечення продається під новим брендом;
юридична оболонка виглядає локальною або нейтральною;
маркетинг говорить про нове покоління систем автоматизації.

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

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

Ребрендинг не дорівнює технологічній незалежності

Ребрендинг може змінити:

назву продукту;
логотип;
сайт;
юридичну оболонку;
партнерську мережу;
маркетингову подачу;
комерційні договори;
спосіб продажу.

Але ребрендинг сам по собі не змінює:

мову внутрішньої бізнес-логіки;
архітектуру конфігурацій;
структуру бази даних;
підхід до SQL;
залежність від старої платформи;
логіку розробки;
спосіб масштабування;
складність міграції;
кадрову залежність від старих спеціалістів.

Головний ризик ребрендингу

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

Правда, яку бачать розробники

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

Саме конфігурація визначає:

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

Якщо конфігурація зберігає спадкові підходи, то навіть новий бренд не робить систему принципово новою.

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

BAS: новий бренд старої екосистеми?

Після санкцій 1С формально зникла з українського ринку. На її місці з’явився бренд BAS.

Сьогодні в Україні продаються десятки продуктів під брендом BAS:

BAS Бухгалтерія;
BAS Бухгалтерія КОРП;
BAS Малий бізнес;
BAS Управління торгівлею;
BAS Роздрібна торгівля;
BAS Зарплата та управління персоналом;
BAS Управління торговим підприємством;
BAS ERP;
BAS Комплексне управління підприємством;
BAS Документообіг КОРП;
BAS Управління холдингом;
BAS АГРО;
BAS Будівництво;
BAS Медицина;
BAS Управління автотранспортом;
інші галузеві конфігурації.

Ці продукти продаються як сучасні рішення для автоматизації бізнесу. Але для технічної оцінки важливо перевіряти, чи змінилася лише назва, чи справді змінилася архітектура.

Російська мова всередині бізнес-логіки

У багатьох конфігураціях BAS фахівці можуть зустрічати ознаки спадкової логіки:

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

Приклад конфігурації з російськомовними елементами бізнес-логіки

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

База даних як чорна скринька

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

У таких базах можуть бути:

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

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

Проблема міграції. Якщо база даних не читається як зрозуміла бізнес-структура без конфігурації, система стає “чорною скринькою”. Це ускладнює аудит, інтеграції, аналітику та перехід на сучасні ERP-платформи.

SQL, який контролює не бізнес, а платформа

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

Можливі наслідки:

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

Ознака	Спадкова ERP-модель	Сучасна відкрита ERP-логіка
Структура даних	Залежить від конфігурації та внутрішніх механізмів	Має бути прозорою, документованою та зрозумілою
SQL	Формується платформою	Бізнес і команда мають більше контролю над моделлю даних
Інтеграції	Часто потребують спеціальних механізмів	Будуються через API, відкриті структури та сучасні підходи
Міграція	Складна через непрозорість	Планується через зрозумілу модель даних
Масштабування	Обмежене старою архітектурою	Орієнтоване на сучасні web/cloud-сценарії

Процеси ОС як технічний сигнал

Інколи під час запуску BAS в операційній системі можуть відображатися процеси з історичними назвами платформи 1С. Для системних адміністраторів це може бути технічним сигналом спадковості платформи.

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

Парус → Афіна: ребрендинг бюджетного обліку

Схожа ситуація може спостерігатися і в бюджетному секторі.

Після зникнення Парус на ринку почали з’являтися нові системи, зокрема Афіна. Користувачі можуть відзначати:

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

Тому виникає практичне питання:

Це справді нова система чи модернізована стара система під новою назвою?

Чому це небезпечно для бізнесу

ERP — це фундамент цифрової економіки підприємства.

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

Основні ризики:

залежність від вузького пулу розробників;
складність переходу на сучасні технології;
обмежена масштабованість;
складність інтеграції з web, mobile, AI та API-сервісами;
вища вартість майбутньої міграції;
ризики кібербезпеки;
складність аудиту;
залежність від старої технологічної школи;
втрата конкурентоспроможності.

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

Економічний аспект

Українські компанії щороку витрачають значні кошти на автоматизацію. Ці кошти можуть працювати в двох різних напрямах.

Старий сценарій	Новий сценарій
Підтримка спадкових технологічних моделей	Розвиток української ERP-екосистеми
Оплата старих доробок і вузьких спеціалістів	Інвестиція в сучасні web/cloud-рішення
Залежність від старої архітектури	Формування локальних компетенцій
Ребрендинг без зміни суті	Перехід на справді нову технологічну базу
Відкладена міграція	Поступова цифрова модернізація

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

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

Україна вже має власних розробників корпоративного ПЗ

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

До таких прикладів належать:

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

Стратегічна думка. Український бізнес може не лише відмовлятися від старих систем, а й підтримувати створення власних ERP, CRM, BPM, IDE, хмарних і корпоративних платформ.

K2 Cloud ERP як приклад нової архітектури

K2 Cloud ERP позиціонується як система нового покоління, що має допомогти бізнесу перейти зі спадкових ERP-систем до сучаснішої архітектури.

K2 Cloud ERP орієнтована на:

перехід зі спадкових систем;
перенесення даних без втрати історії;
прозорішу архітектуру;
масштабування бізнесу;
cloud-модель;
web-орієнтованість;
модульність;
інтеграції;
кросплатформені сценарії;
поступову заміну старих процесів.

За оцінками інтеграторів, повна міграція зі спадкової ERP-системи може займати близько 7–8 місяців, залежно від обсягу даних, кількості доробок, складності обліку, інтеграцій і готовності компанії до змін.

Перевага нової архітектури
Перехід на K2 Cloud ERP — це не лише зміна програми. Це можливість перейти від спадкової, закритої та важкої для міграції архітектури до сучаснішої ERP-логіки з прозорішою структурою даних і ширшими можливостями розвитку.

Демонстрація K2 Cloud ERP

Анкета переходу перших 50 компаній

Анкета переходу перших 50 компаній

Повний перелік продуктів BAS, які продаються в Україні

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

BAS для масового ринку

BAS Бухгалтерія;
BAS Бухгалтерія КОРП;
BAS Малий бізнес;
BAS Управління торгівлею;
BAS Роздрібна торгівля;
BAS Зарплата та управління персоналом;
BAS Управління торговим підприємством.

Корпоративні рішення BAS

BAS ERP;
BAS Комплексне управління підприємством;
BAS Документообіг КОРП;
BAS Управління холдингом.

Галузеві рішення BAS

Агросектор

BAS АГРО. Бухгалтерія;
BAS АГРО. ERP.

Будівництво

BAS Будівництво. Бухгалтерія;
BAS Будівництво. Керування фінансами;
BAS Будівництво. Управління будівельним виробництвом;
BAS Будівництво. ERP.

Паливний сектор

BAS Комплексне управління паливним підприємством;
BAS Модуль обліку акцизного палива.

Транспорт

BAS Управління автотранспортом.

Харчова промисловість та HoReCa

BAS Громадське харчування.

Переробна промисловість

BAS Бухгалтерія елеватора, млина і комбікормового заводу.

Медична галузь

BAS Медицина. Лікарня;
BAS Медицина. Поліклініка.

Що об’єднує продукти BAS

Попри різні назви, галузі та функціональність, продукти BAS об’єднує єдина платформна екосистема.

Фахівці звертають увагу на такі ознаки:

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

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

Порівняння старої та нової ERP-логіки

Критерій	Спадкова ERP-логіка	Нова ERP-логіка
Бренд	Може бути змінений після ребрендингу	Має відповідати реальній архітектурній зміні
Конфігурації	Зберігають старі підходи та термінологію	Будуються на сучасній моделі даних і бізнес-процесів
База даних	Залежить від конфігураційної чорної скриньки	Має бути прозорішою та зручнішою для інтеграцій
SQL	Контролюється платформними механізмами	Має бути зрозумілішим для розробки, аналітики та оптимізації
Інтеграції	Ускладнені старою архітектурою	Орієнтовані на API, web, cloud та сучасні сервіси
Масштабування	Обмежене історичними підходами	Проєктується під зростання бізнесу
Міграція	Складна через непрозорість	Планується як керований перехід
Стратегічна цінність	Підтримка старої технологічної моделі	Розвиток української цифрової незалежності

Як бізнесу перевірити реальну незалежність ERP

Перед вибором або продовженням використання ERP компанія має поставити не лише комерційні, а й технічні питання.

Напрям	Питання
Походження	Яка реальна технологічна історія продукту?
Конфігурації	Якою мовою описана внутрішня бізнес-логіка?
База даних	Чи можна зрозуміти структуру даних без “магії” платформи?
SQL	Хто контролює запити, оптимізацію та доступ до даних?
Інтеграції	Наскільки легко інтегрувати систему з API, сайтами, CRM, BI та AI?
Міграція	Наскільки реально перенести дані в іншу систему?
Спеціалісти	Чи є широкий ринок фахівців, чи залежність від вузького пулу?
Санкції	Чи не має система ризиків, пов’язаних зі старою екосистемою?
Архітектура	Чи є система справді новою, чи це стара архітектура з новим брендом?

Майбутнє українського бізнесу вирішується зараз

В Україні працюють мільйони бізнесів, підприємств, ФОПів, організацій і державних установ. Їхній вибір програмного забезпечення визначає, куди рухатиметься цифрова економіка країни.

Є два сценарії:

продовжувати фінансувати спадкові ERP-архітектури;
будувати сучасну українську ERP-екосистему.

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

Якщо бізнес переходить на нове покоління систем, Україна може стати одним із центрів корпоративного програмного забезпечення в Європі.

Бізнес-висновок

Ребрендинг не змінює технологію. Назва продукту не гарантує цифрової незалежності. Новий логотип не означає нову архітектуру.

ERP-система визначає не лише бухгалтерію. Вона визначає:

структуру даних;
процеси;
інтеграції;
можливість масштабування;
вартість міграції;
залежність від спеціалістів;
безпеку;
цифрову незалежність бізнесу.

Головний ризик. Компанія може думати, що вже відмовилася від старої системи, але фактично продовжувати працювати в тій самій спадковій архітектурі під новою назвою.

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

Коротко для керівника

Питання	Відповідь
Чи достатньо зміни назви продукту?	Ні. Потрібно перевіряти архітектуру, конфігурації, базу даних і внутрішню логіку
У чому проблема BAS?	Продукти можуть мати ознаки спадкової платформи, старої бізнес-логіки та залежності від історичної екосистеми
Чому важлива мова внутрішньої логіки?	Вона показує, у якій технологічній школі створювалася система
Чому база даних може бути проблемою?	Якщо її неможливо зрозуміти без конфігурації, система стає чорною скринькою
Чому це небезпечно для бізнесу?	Зростають ризики міграції, інтеграцій, масштабування, кібербезпеки й залежності від вузьких спеціалістів
Чому це економічне питання?	Кошти на автоматизацію можуть підтримувати старі моделі або будувати українську ERP-екосистему
Що дає K2 Cloud ERP?	Сучаснішу cloud-архітектуру, прозоріший підхід до даних, масштабування та можливість міграції зі спадкових систем
Головне питання для власника?	Ви використовуєте справді нову систему чи стару систему з новим логотипом?

Пов’язані терміни

Джерело

Оригінальна стаття на erp.kyiv.ua