ERP, яка не перетворюється на дорогий гальмівний механізм

1.1 Чому архітектурні обмеження ERP проявляються однаково

Більшість ERP (1С, SAP, Microsoft Dynamics, Odoo) на старті виглядають стійко: даних мало, процеси спрощені, винятки рідкі, інтеграції «тонкі». Архітектурні обмеження в цей момент майже не помітні.

Проблеми проявляються пізніше — коли компанія починає змінювати правила. Причина не в «поганій системі», а в тому, що типові ERP побудовані навколо схожих компромісів: об’єктна модель, окремий шар звітності, рознесена логіка (форма/сервер/інтеграції), а також обмеження запитного шару та масових операцій. За зростання даних і кількості винятків ці компроміси дають однакові симптоми незалежно від вендора.

1.2 Що вважати «зміною правил», а не доопрацюванням

«Зміна правил» — це не «додати поле» і не «зробити новий звіт». Це зміна, яка одночасно:

• змінює поведінку транзакцій (валідність, проведення, статуси, обмеження);
• змінює показники (маржа, собівартість, ліміти, залишки, ризик);
• змінює контроль (блокування, погодження, заборони за умовами);
• не має ламати звітність та інтеграції (CRM/WMS/маркетплейси/BI).

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

1.3 Як читати цей розбір і що він дає на практиці

Далі йдуть конкретні архітектурні пункти (об’єкти, регістри, запити, форми, блокування, типізація тощо). Для кожного пункту використовується один і той самий формат:

• Що мається на увазі — обмеження без загальних слів;
• Як це проявляється у 1С / SAP / Dynamics / Odoo (типові механізми, а не «в цілому складно»);
• Який симптом ви побачите в експлуатації (що реально «болить»);
• Як перевірити на демо/пілоті — запитання або сценарій, який «розкриває» проблему.

2. Модель даних і обчислень

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

2.1 Об’єкти: довідники, документи тощо

Як це зазвичай реалізовано в ERP

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

1С

Метадані (Довідники, Документи, Регістри) — основа архітектури. Перевірки та розрахунки розподіляються між проведенням, модулями форм і службовими обробниками.

SAP

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

Microsoft Dynamics

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

Odoo

ORM-моделі виглядають цілісно, але зі зростанням кастомізації логіка розподіляється між моделями, computed fields та модулями.

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

Як перевірити: попросити показати одне правило й усі об’єкти, де воно реалізоване або впливає на поведінку.

2.2 Неоптимальне отримання даних об’єктів

Як це зазвичай реалізовано в ERP

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

1С

Типовий сценарій: запит + читання об’єктів + цикли. Продуктивність залежить від дисципліни розробника.

SAP

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

Dynamics

ORM/API легко породжують багато звернень замість однієї оптимальної вибірки.

Odoo

ORM приховує реальні запити; проблеми проявляються зі зростанням даних.

Експлуатаційний симптом: система деградує за продуктивністю не одразу, а «раптом» — зі збільшенням обсягу.

2.3 Таблиці й подання: регістри

Як це зазвичай реалізовано в ERP

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

1С

Регістри — ключовий механізм, але логіка розрахунку часто частково залишається в коді.

SAP

Аналог — поєднання рухів, агрегатів і аналітичних подань.

Dynamics

Агрегати часто виносять у BI або вітрини.

Odoo

Типові агрегати є, але зі зростанням вимог з’являються SQL views і зовнішня аналітика.

Експлуатаційний симптом: операції та звіти розходяться, перерахунки потребують спеціальних процедур.

2.4 Регістри працюють лише у дуже приватних випадках

Що мається на увазі

Аналітичний шар (регістри/агрегати/вітрини) добре працює, поки бізнес-правило вкладається в «типовий» патерн: залишки, обороти, прості розрізи, стандартні періоди. Щойно з’являється нетипова семантика (винятки, умовні правила, альтернативні джерела, історичне «як було на дату» за нестандартною ознакою), частина логіки перестає виражатися в моделі й іде в код/обробки/інтеграції.

Як це проявляється в стандартних ERP

1С

Регістри (накопичення/бухгалтерії/відомостей) покривають багато сценаріїв, але реальна логіка часто «розпадається»: частина — у рухах під час проведення, частина — в запитах звітів (СКД), частина — в обробках перерахунку. Щойно потрібен «нештатний» алгоритм (умовні перерахунки, складні винятки, альтернативна оцінка), він іде в процедурний код і перестає бути частиною єдиної моделі.

SAP

Типові обліки й аналітика тримаються на багатій моделі та механізмах розширення, але «нестандарт» часто реалізується сумішшю налаштувань + розширень + окремої аналітичної моделі (або винесенням в окремий шар аналітики). У підсумку правило існує одразу в кількох місцях, а синхронізація стає проєктом.

Microsoft Dynamics

У типовому контурі показники часто «розводяться» по шарах: транзакційні сутності, правила/плагіни, звітні подання та зовнішня аналітика. Нестандартні правила майже неминуче опиняються в комбінації: код + low-code автоматизації + вітрина/BI.

Odoo

Базові агрегати й computed-поля працюють до певної складності. Далі з’являються: окремі моделі для «похідних» показників, SQL views, фонові перерахунки та зовнішня аналітика. Правило перестає бути «частиною моделі» і перетворюється на набір реалізацій.

Експлуатаційний симптом: частина правил живе в «моделі» (регістри/агрегати), частина — в «особливих обробках». Невелика зміна починає вимагати правок у кількох місцях, а пояснюваність «чому так порахувалося» падає.

Як перевірити на демо/пілоті: попросити взяти один показник (наприклад, доступний залишок/маржа/ліміт) і додати 2–3 винятки (на кшталт типу клієнта, складу, дати, альтернативного джерела ціни). Подивіться, чи зберігається єдиний механізм (одне місце/один тип механізму) або правило «розповзається» на код + звіт + перерахунок + інтеграцію.

2.5 Немає обмежень і подій для значень регістрів

Що мається на увазі

У багатьох ERP обмеження та події добре визначені для операцій (документ/проведення/запис), але погано визначені для обчислених/агрегованих значень (залишки, ліміти, рейтинги, ризик). Тобто платформа не дає нативного механізму рівня: «якщо агрегат став таким — заборони/сповісти/запусти реакцію», як частину моделі. Тому контроль реалізують процедурно: перевірками під час проведення, фоновими перевірками, звітами-валідаторами та ручними регламентами.

Як це проявляється в стандартних ERP

1С

Типовий шлях — перевіряти «на місці» під час проведення документа або у формі. Але агрегат (наприклад, ліміт/залишок/обіговість) може змінюватися не лише з одного документа: з кількох видів операцій, ретро-змін, перерахунків, обмінів. Тоді контроль починає дублюватися, а «коли саме спрацює заборона» залежить від сценарію.

SAP

Контроль часто будують через статуси/процеси/перевірки в транзакціях, а моніторинг агрегатів — окремими механізмами (процедури контролю, звіти, workflow). Формально це потужно, але правило частіше стає процесною конструкцією, а не декларативним обмеженням на значення.

Microsoft Dynamics

Бізнес-правила й плагіни зручно чіпляти на подію зміни сутності, але агрегати зазвичай рахуються окремо (фон, інтеграція, звітний шар). У результаті «обмеження на агрегат» реалізується як набір перевірок + автоматизацій, і його важко доказово зробити повним (без дір).

Odoo

Є constraints і onchange на рівні моделей, але агрегати часто живуть у computed fields, які можуть перераховуватися ліниво/за тригерами/за cron. Тому контроль за агрегатом легко стає недетермінованим: «інколи ловить, інколи ні», якщо не вибудувати жорстку дисципліну.

Експлуатаційний симптом: заборони та контроль працюють «не завжди однаково»: один користувач ловить обмеження одразу, інший — пізніше; частина порушень виявляється звітом/перевіркою постфактум. З’являються регламенти «перевіряйте вручну».

Як перевірити на демо/пілоті: попросити зробити обмеження на агрегат: «не можна відвантажувати, якщо сумарний ризик/ліміт по клієнту > X, з урахуванням усіх документів і коригувань». Далі попросити показати 3 способи зміни агрегата (документ, коригування заднім числом, інтеграція/імпорт) і переконатися, що обмеження спрацьовує однаково в усіх трьох сценаріях.

2.6 У параметрах віртуальних таблиць можна використовувати лише константи

Що мається на увазі

Коли аналітичний шар можна параметризувати лише константами (або дуже обмежено), система не вміє «підлаштовувати» обчислення під контекст операції. У результаті доводиться: (1) вибирати дані «ширше, ніж потрібно», а потім фільтрувати в коді/формі, (2) створювати копії запитів/звітів під різні варіанти, (3) виносити частину логіки з моделі в процедурні шари. Це тихо збільшує вартість змін: кожна нова умова породжує нові копії.

Як це проявляється в стандартних ERP

1С

Типовий ефект: звіт/запит «універсальний» лише на словах. Щойно з’являються умови «залежні від контексту» (поточний користувач, роль, стан документа, параметри форми), частина фільтрації йде в код, а запити копіюються. З часом виникає «зоопарк» варіантів майже однакових звітів/вибірок.

SAP

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

Microsoft Dynamics

Обмеження виразів і контексту призводять до розмноження подань/запитів/flows: «для цієї ролі одне», «для цієї форми інше». Коли бізнес змінює правило, доводиться шукати всі копії та синхронно правити.

Odoo

ORM зручний, але складний контекст часто приводить до: доменів/контекстів на рівні UI + окремих методів вибірки в коді + SQL для важких випадків. Варіативність фільтрів швидко породжує дублікати та «локальні рішення».

Експлуатаційний симптом: з’являються «майже однакові» звіти, списки та вибірки. Невелика зміна умови (ще один фільтр/виняток) перетворюється на серію правок: запит, код форми, права, окремий звіт, окрема обробка.

Як перевірити на демо/пілоті: попросити реалізувати один і той самий список/звіт із 3 контекстами: (1) для бухгалтера, (2) для менеджера, (3) для керівника — з різними фільтрами та колонками, але з одним джерелом правила. Потім попросити змінити правило (додати виняток) і подивитися, змінюють це в одному місці чи в кількох копіях.

3. Запитний рівень і робота з даними

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

3.1 Запити як самостійний шар системи

Як це зазвичай реалізовано в стандартних ERP

У більшості ERP запити призначені для читання даних і звітності. Бізнес-правила (валідації, розрахунки, обмеження) реалізуються в прикладній логіці: у коді об’єктів, обробниках, workflow та автоматизаціях. Запитний шар не вважається джерелом істини для правил.

1С

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

SAP

Розрахунки розподіляються між CDS View, ABAP-кодом та налаштуваннями. Ці рівні потужні, але не утворюють єдиної мови правил.

Microsoft Dynamics

Views та FetchXML — для читання, бізнес-правила — у плагінах, flows та клієнтських скриптах. Запит не є носієм логіки.

Odoo

ORM-запити використовуються для вибірок, а логіка реалізується в Python-коді та computed fields.

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

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

3.2 Запити у вигляді рядків

Як це зазвичай реалізовано в стандартних ERP

Запити та умови часто задаються у вигляді рядків: текст SQL, вирази фільтрів, формули в налаштуваннях. Платформа не може аналізувати їхню структуру і перевіряти вплив змін.

1С

Запити — рядкові. Помилки та залежності виявляються лише в рантаймі.

SAP

У стандартних шарах контроль вищий, але кастом та інтеграції швидко приводять до текстових конструкцій.

Microsoft Dynamics

Умови й вирази у flows та налаштуваннях формально no-code, але по суті рядкові.

Odoo

Raw SQL вирішує задачі, але ламає аналіз залежностей і оновлення.

Експлуатаційний симптом: зміна схеми даних призводить до помилок «постфактум», з’являється правило «краще не чіпати».

3.3 Відсутність передбачуваної оптимізації як частини моделі правил

Як це зазвичай реалізовано в стандартних ERP

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

1С

Запит може бути логічно коректним, але фізично неефективним.

SAP

Сильна СУБД допомагає, але складні моделі дають неочікувані плани виконання.

Microsoft Dynamics

Складну аналітику часто виносять у BI, а не оптимізують усередині ERP.

Odoo

ORM приховує реальні плани виконання, оптимізація стає «мистецтвом».

Експлуатаційний симптом: звіти «літають» на тесті й деградують на реальних даних.

3.4 Відсутність розширених SQL-можливостей

Як це зазвичай реалізовано в стандартних ERP

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

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

Як перевірити: попросити показати складний управлінський розрахунок без циклів і тимчасових таблиць.

3.5 Відсутність запитів на зміну (UPDATE / DELETE / MERGE)

Як це зазвичай реалізовано в стандартних ERP

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

1С

Масові зміни = перебір об’єктів і перепроведення.

SAP

Масові операції можливі, але потребують високої кваліфікації та обережності.

Microsoft Dynamics

Масові зміни часто виносяться в ETL та Dataflows.

Odoo

ORM повільний для масових операцій, raw SQL ризикований з точки зору підтримки.

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

4. Потік виконання і гарантії консистентності даних

Цей розділ — про гарантії, а не про зручність. Про те, чи можна формально визначити момент завершення операції, джерело істини та порядок застосування бізнес-правил. Саме відсутність формальних гарантій приводить до помилок, які «неможливо відтворити», і підриває довіру до даних.

4.1 Відмова від автоматичних блокувань

Суть обмеження

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

Гарантії, яких немає

Немає формального твердження: «у момент X дані були узгоджені та не могли змінюватися конкурентно».

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

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

4.2 Відмова від єдиного потоку виконання

Суть обмеження

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

Гарантії, яких немає

Неможливо формально відповісти: «які перевірки та розрахунки були застосовані саме до цієї операції».

Експлуатаційний симптом: користувач бачить одну поведінку, а підсумковий стан даних відрізняється; виникають «незрозумілі» відмови й відкати.

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

4.3 Відмова від синхронності та чіткого commit point

Суть обмеження

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

Гарантії, яких немає

Відсутній чіткий commit point — момент, після якого можна стверджувати, що операція завершена і її ефект остаточний.

Експлуатаційний симптом: дублювання операцій, «відкладені помилки», ручні перевірки та повторні дії користувачів.

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

5. Форми та подання даних

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

5.1 Форми як окремий шар логіки

Як це зазвичай реалізовано в стандартних ERP

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

1С

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

SAP

UI-логіка розподіляється між екранними сценаріями, backend-перевірками та процесними правилами.

Microsoft Dynamics

Клієнтські скрипти та бізнес-правила в інтерфейсі доповнюють серверні плагіни, створюючи кілька рівнів поведінки.

Odoo

Форми відносно прості, але при кастомізації логіка починає дублювати backend.

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

Як перевірити: попросити показати, які перевірки виконуються лише у формі і що станеться при завантаженні даних в обхід UI.

5.2 Відмова від WYSIWYG: розділення інтерфейсу на запис і читання

Як це зазвичай реалізовано в стандартних ERP

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

1С

Різні режими форми та події приводять до розходжень між відображенням і збереженням.

SAP

Багатокрокові екрани та статуси ускладнюють розуміння, що саме зафіксовано.

Microsoft Dynamics

Частина полів обчислюється або оновлюється асинхронно, що створює ефект «візуальної фіксації».

Odoo

Базово WYSIWYG дотримано, але при ускладненні форм з’являються розходження.

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

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

5.3 Неможливість звертатися в списках до реквізитів форм і поточних значень інших списків

Як це зазвичай реалізовано в стандартних ERP

Списки та форми живуть у різних контекстах. Логіка списку обмежена доступними полями даних, а поточні значення форми або інших списків недоступні напряму.

Наслідок

Контекстні правила (залежні від поточного вибору, стану форми, пов’язаних списків) реалізуються обхідними шляхами або дублюються.

Експлуатаційний симптом: інтерфейс не може коректно відобразити реальні обмеження та правила, з’являються «незрозумілі» заборони.

Як перевірити: попросити реалізувати правило, залежне від стану кількох списків, без додаткового коду й обходів.

5.4 Надлишкові рівні абстракції в UI

Як це зазвичай реалізовано в стандартних ERP

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

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

Як перевірити: попросити показати, через які шари проходить зміна одного UI-правила і де саме воно зафіксоване.

6. Архітектура мови та розширюваність

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

6.1 Відсутність спадкування й поліморфізму

Як це зазвичай реалізовано в стандартних ERP

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

1С

Спадкування обмежене. Типовий підхід — копіювання об’єктів із подальшими доопрацюваннями.

SAP

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

Microsoft Dynamics

Розширення сутностей можливе, але поліморфізм частіше імітується через плагіни та умови.

Odoo

Спадкування — сильна сторона, але при активних override'ах важливо контролювати точки зміни поведінки.

Експлуатаційний симптом: правила дублюються, зміни в «базовій логіці» потребують ручної синхронізації.

6.2 Відсутність явної типізації в коді

Як це зазвичай реалізовано в стандартних ERP

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

1С

Слабка типізація ускладнює аналіз великих конфігурацій та безпечний рефакторинг.

SAP

Типізація сильніша, але ціна — висока складність і вимоги до кваліфікації команди.

Microsoft Dynamics

Типи є, але при змішуванні low-code та плагінів контракт поведінки розмивається.

Odoo

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

Експлуатаційний симптом: зміни перевіряються «на око», зростає кількість регресійних помилок.

6.3 Відсутність модульності

Як це зазвичай реалізовано в стандартних ERP

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

1С

Загальні модулі розростаються, межі відповідальності розмиваються.

SAP

Модульність є на рівні процесів, але налаштування та розширення розмивають межі.

Microsoft Dynamics

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

Odoo

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

Експлуатаційний симптом: «маленькі» зміни перестають бути маленькими, зростає обсяг регресу.

6.4 Ставка на візуальне програмування

Як це зазвичай реалізовано в стандартних ERP

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

1С

Візуальні механізми змішуються з кодом, логіка «розпилюється».

SAP

Workflow та налаштування потужні, але трасування «чому спрацювало» стає нетривіальним.

Microsoft Dynamics

Flows зручні, але зі зростанням перетворюються на важкокерований набір сценаріїв.

Odoo

Візуальні інструменти менш агресивні, але перенесення логіки з коду в налаштування дає ті самі ефекти.

Експлуатаційний симптом: правила існують як «схеми», а не як єдина модель, супровід залежить від конкретних людей.

7. Фізична модель і відкритість системи

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

Тут з’являються обмеження, які неможливо «обійти акуратним кодом» — вони визначаються самим устроєм платформи.

7.1 Закрита фізична модель даних

Як це зазвичай реалізовано в стандартних ERP

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

1С

Фізична структура БД формується платформою. Прямий аналіз і оптимізація можливі, але не вважаються штатним способом роботи.

SAP

Модель даних формально відкрита, але надзвичайно складна. Без глибокої експертизи втручання ризиковане.

Microsoft Dynamics

У SaaS-моделі фізична БД прихована. Робота ведеться через Dataverse, API та вітрини.

Odoo

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

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

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

7.2 Статична фізична модель даних

Як це зазвичай реалізовано в стандартних ERP

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

1С

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

SAP

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

Microsoft Dynamics

Розширення схеми можливе, але в межах обмежень SaaS-платформи.

Odoo

Модель можна змінювати, але це впливає на оновлюваність і сумісність модулів.

Експлуатаційний симптом: зміна моделі даних відкладається, накопичуються «тимчасові» рішення та додаткові таблиці.

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

7.3 Закриті вихідні коди та ліцензії

Як це зазвичай реалізовано в стандартних ERP

Вихідний код та внутрішні механізми частково або повністю закриті. Можливості аналізу та змін обмежені умовами ліцензії.

1С

Платформа закрита, поведінку багатьох механізмів неможливо вивчити напряму.

SAP

Код доступний обмежено, зміни потребують дотримання строгих правил.

Microsoft Dynamics

SaaS-модель посилює залежність від вендора та обмежує низькорівневий контроль.

Odoo

Open-source ядро знижує бар’єр, але комерційні модулі та екосистема можуть створювати новий lock-in.

Експлуатаційний симптом: команда не може самостійно розібратися в причинах поведінки системи і змушена покладатися на підтримку або партнерів.

Як перевірити: запитати, які частини системи можна аналізувати, дебажити та змінювати без участі вендора.

8. Експлуатаційні та культурні обмеження

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

8.1 Неповага до розробників у ліцензуванні та брендованості

Як це зазвичай реалізовано в стандартних ERP

Ліцензування часто будується навколо користувачів, середовищ і окремих компонентів. Це обмежує кількість тестових стендів, ускладнює CI/CD і робить експерименти дорогими. Брендованість і жорсткі правила використання підкреслюють залежність від вендора.

1С

Ліцензії на користувачів і сервери обмежують кількість повноцінних контурів. Часто існує один «живий» стенд, де й тестують зміни.

SAP

Вартість ліцензій і середовищ робить кожен додатковий стенд предметом погодження. Автоматизація тестування обмежена.

Microsoft Dynamics

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

Odoo

Open-source знижує бар’єр входу, але комерційні модулі та сервіси можуть накладати схожі обмеження.

Експлуатаційний симптом: менше тестових контурів, правки перевіряються «на проді», зміни викочуються рідше й обережніше, ніж потребує бізнес.

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

8.2 Фатальний недолік як сума архітектурних рішень

Жодне з описаних обмежень не є фатальним саме по собі. Проблема виникає, коли вони накладаються одне на одне.

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

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

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

9. Як перевіряти архітектурні обмеження на демо та пілоті

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

Єдиний надійний спосіб — перевіряти ERP не за функціями, а за реакцією на зміни.

9.1 Три зміни, які варто попросити показати

Для перевірки достатньо трьох сценаріїв. Важливо не те, що «вийшло», а як саме це робили.

1. Зміна правила з винятками
   Наприклад: знижка або ліміт, залежні від кількох умов (тип клієнта, оборот, ризик, історія).
2. Зміна процесу
   Погодження не «за посадою», а за даними: сума, маржа, ризик, відхилення від норми.
3. Додавання нового типу сутності
   Новий договір, послуга або модель розрахунку, яка має: брати участь у транзакціях, потрапляти у звіти і підпорядковуватися тим самим правилам контролю.

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

9.2 На що дивитися під час демонстрації

• Скільки шарів довелося змінювати
  Один модуль або форма — це зміна правила. Кілька шарів — зміна системи.
• Де саме описано правило
  Чи можна показати одне місце, або логіка розподілена між кодом, формами та запитами.
• Як пояснюється вплив на звіти
  Чи є чітка відповідь, які показники зміняться і чому.
• Чи є перевірка регресу
  Тест, сценарій або хоча б формальний чек-лист, а не «потім подивимось».

9.3 Типові «червоні прапорці»

• «Це краще робити після впровадження»
• «У реальному проєкті ми б зробили інакше»
• «Тут багато нюансів, на демо не показати»
• «Це робиться, але потрібен окремий проєкт»
• «Треба подивитися, як це вплине на звіти»

Ці фрази не означають, що система погана. Вони означають, що вартість змін поки невідома й неконтрольована.

9.4 Що вважати добрим результатом пілота

Добрий результат — не «ми все зробили», а таке:

• правило описано в одному місці або в одному типі механізму;
• видно, які дані та розрахунки воно зачіпає;
• зрозуміло, як перевірити регрес;
• зміна не потребує «особливого знання» конкретної людини.

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

10. Висновок

Цей розбір не про «хороші» й «погані» ERP. 1С, SAP, Microsoft Dynamics та Odoo успішно працюють у тисячах компаній. Проблеми починаються не на етапі впровадження, а в момент, коли бізнес починає змінювати правила.

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

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

У такій архітектурі виникає практичний lock-in — не стільки від вендора, скільки від конкретних людей, які «пам’ятають, як усе працює».

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

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

Для цього платформа має мати кілька критичних властивостей:

• Висока щільність змісту — бізнес-правила виражаються коротко, без надлишкового коду.
• Декларативність — правила описують «що має бути», а не «як саме виконати».
• Єдина модель — дані, правила й обчислення описуються в одному формалізмі.
• Відсутність «магії» — мінімальна кількість неявних обробників, подій і винятків.

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

Практичний наслідок цього підходу — різке зниження «вартості володіння знаннями»:

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

У протилежному випадку — коли бізнес-логіка «розмазана» по об’єктах, формах, рядкових запитах, візуальних схемах та історичних винятках — AI не стає стратегічним активом. Він лише прискорює роботу з хаотичною системою, але не знижує її вартість.