Ключові висновки

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

Metadata Driven — про структуру, не про EAV. Метадані керують сутностями, полями, workflow і інтерфейсами. Бізнес-дані живуть у реальних таблицях з індексами й зв'язками.

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

Готового open-source конструктора ERP-рівня не існує. Low-code платформи й CRUD-фреймворки закривають частину задач, але не замінюють платформенний шар.

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

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

---

Вступ

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

Типова траєкторія виглядає знайомо: на старті все швидко, команда з п'яти людей знає весь код, діаграма поміщається на серветку. Бізнес зростає — зростає й ERP. З'являються філії, нові продуктові лінійки, вимоги регуляторів. Кожна зміна бізнесу вимагає відображення в системі. ERP стає центральною нервовою системою компанії.

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

Сучасна ERP у 2026 році — це спроба розірвати цей цикл. Не через магію low-code й не через нескінченну універсальність EAV, а через платформенну архітектуру: набір рушіїв, які перетворюють опис системи на робочий код, інтерфейс і процеси.

---

Чому більшість ERP старіють

Типовий життєвий цикл

Життєвий цикл більшості корпоративних ERP передбачуваний:

Таблиця
  ↓
PHP-код (або будь-який backend)
  ↓
React-форма
  ↓
Звіт
  ↓
Ще один модуль

На кожному кроці створюється ручне зв'язування між шарами. Таблиця corrosion_maps — контролер CorrosionMapController — компонент CorrosionMapForm — SQL-запит у звіті «Корозія за об'єктами» — правило в permissions.php. З кожним роком кількість таких зв'язків зростає експоненційно.

З'являються передбачувані симптоми:

• Дублювання логіки. Валідація поля «Швидкість корозії» написана в трьох місцях: в API, у формі й в імпорті з Excel.
• Копіювання CRUD. Кожен новий модуль — копіпаста попереднього з заміною імен.
• Десятки однакових екранів. Таблиця + фільтри + форма + картка — той самий патерн, але щоразу з нуля.
• Складні інтеграції. Модуль A напряму читає таблиці модуля B, бо «так швидше».
• Проблеми з продуктивністю. Звіти рахуються годинами, бо ніхто не проєктував аналітичний шар.

Симптоми старіючої ERP

Якщо впізнаєте себе — система вже на плато розвитку:

• Новий модуль створюється тижнями, хоча по суті це «ще одна сутність з полями й статусами».
• Будь-яка зміна вимагає участі кількох розробників — backend, frontend, DBA, автор звітів.
• Бізнес-процеси зашиті в код — if ($status == 'approved') замість опису workflow.
• Користувачі не можуть налаштувати інтерфейс під себе — колонки, фільтри, представлення жорстко задані розробником.
• Архітектурні рішення приймаються виходячи з обмежень старого коду, а не з вимог бізнесу.

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

---

ERP як платформа, а не як застосунок

Найважливіша зміна мислення при проєктуванні сучасної ERP:

ERP має бути не набором модулів. ERP має бути платформою для створення модулів.

Класична модель:

ERP = Код + Таблиці + Форми

Кожен новий розділ — новий цикл розробки: міграція, API, UI, права, тести, документація.

Платформенна модель:

ERP = Платформа + Метадані + Бізнес-модулі

Платформа — набір рушіїв: метадані, міграції, CRUD-runtime, workflow, права, події, аудит.

Метадані — опис сутностей, полів, зв'язків, процесів і інтерфейсів у даних, а не в коді.

Бізнес-модулі — спеціалізована логіка, яку не можна виразити декларативно: розрахунок залишкового ресурсу, прогноз корозії, інтеграція з зовнішньою SCADA.

Різниця принципова. У класичній ERP додавання сутності «Корозійна карта» — проєкт на два тижні. У платформенній ERP — опис у Metadata Engine і автоматична генерація таблиці, API, форми й списку. Спеціалізована логіка підключається як плагін, а не як черговий монолітний контролер.

Це не означає «без програмування для всього». Це означає, що 80% типових операцій — CRUD, списки, фільтри, базові workflow — не вимагають ручного коду, а 20% складної доменної логіки отримує чіткі точки розширення.

---

Що таке Metadata Driven Architecture

Metadata Driven Architecture (MDA) — підхід, за якого структура системи зберігається в даних, а не лише в коді.

Замість створення нового контролера, нової форми й нової міграції вручну розробник (або архітектор) описує сутність і її властивості:

Сутність: Корозійна карта

Поля:
  - Номер (string, required, unique)
  - Об'єкт (relation → Equipment)
  - Швидкість корозії (decimal, mm/year)
  - Дата вимірювання (date)
  - Статус (enum: draft, review, approved)

Платформа на основі цього опису самостійно розуміє:

• як зберігати дані — створити таблицю corrosion_maps з типізованими колонками;
• як відображати форму — згенерувати UI з валідацією й зв'язками;
• як будувати таблицю — список із сортуванням, фільтрами й пагінацією;
• як валідувати поля — required, unique, діапазони, кастомні правила;
• як застосовувати права — хто бачить, хто редагує, хто затверджує.

Важливо: MDA не скасовує програмування. Вона переносить рутину з рівня «написати ще один CRUD» на рівень «описати сутність і додати бізнес-логіку там, де вона справді потрібна».

Що зберігається в метаданих

Метадані — джерело істини для структури. Код — для того, що не можна виразити декларативно.

---

Чому EAV — не рішення

Почувши слово «метадані», багато розробників одразу згадують Entity–Attribute–Value — класичну схему «універсального зберігання»:

entity_values
  entity_id
  field_id
  value

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

• Погана продуктивність. Кожен запит — JOIN на JOIN. Типовий список із 50 записів і 10 полями перетворюється на 500 рядків проміжного результату.
• Складні запити. «Показати карти зі швидкістю корозії > 0.5 mm/year за останній квартал» — SQL, який DBA оптимізуватиме тиждень.
• Відсутність нормальних індексів. Індексувати value у TEXT-колонці, де лежить і число, і дата, і рядок — безглуздо.
• Складна аналітика. BI-інструменти, звіти, агрегації — усе вимагає ETL поверх EAV.

Сучасна ERP має використовувати реальні таблиці PostgreSQL і реальні зв'язки між сутностями. Метаданими керується структура системи — які таблиці створити, які поля додати, як побудувати форму. Не зберігання бізнес-даних.

Правильна модель:

Метадані описують → Migration Engine створює → PostgreSQL зберігає

Таблиця corrosion_maps з колонками number, equipment_id, corrosion_rate, measured_at — це нормальна реляційна модель. Metadata Engine знає, що ця таблиця існує, які в неї поля й як їх відображати. Entity Engine читає й пише дані через типізований runtime, а не через entity_values.

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

---

Основні рушії платформи

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

Metadata Engine

Центральне джерело істини про структуру системи.

Зберігає й версіонує:

• сутності та їхні поля;
• зв'язки між сутностями;
• визначення workflow;
• політики доступу;
• описи інтерфейсів (списки, форми, дашборди).

Metadata Engine відповідає на питання: «що існує в системі й як це влаштовано». Усі інші рушії читають метадані, а не хардкодять структуру.

Вимоги до реалізації:

• Версіонування — зміна схеми не ламає робочі модулі.
• API для читання — frontend і backend отримують актуальний опис у runtime.
• Валідація — не можна створити поле без типу або зв'язок на неіснуючу сутність.

Migration Engine

Відповідає за синхронізацію структури бази даних з метаданими.

Принцип роботи:

Desired State (метадані)
        ↓
Actual State (поточна схема БД)
        ↓
SQL Diff (міграція)

Розробник додає поле «Коментар» в опис сутності — Migration Engine генерує ALTER TABLE corrosion_maps ADD COLUMN comment TEXT і застосовує безпечно. Не потрібно вручну писати міграції для кожного модуля.

Критичні властивості:

• Ідемпотентність — повторний запуск не ламає схему.
• Rollback — можливість відкотити зміну.
• Zero-downtime — для великих таблиць: додавання колонки без блокування.

Entity Engine

Універсальний runtime-рушій для роботи з сутностями.

Замість генерації тисяч контролерів CorrosionMapController, EquipmentController, InspectionController — один механізм:

GET    /api/entities/corrosion_maps
POST   /api/entities/corrosion_maps
GET    /api/entities/corrosion_maps/:id
PATCH  /api/entities/corrosion_maps/:id
DELETE /api/entities/corrosion_maps/:id

Entity Engine:

• читає метадані сутності;
• будує SQL-запити до реальних таблиць;
• застосовує валідацію з опису полів;
• перевіряє права через Permission Engine;
• пише в Audit Engine;
• публікує події в Event Bus.

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

Workflow Engine

Бізнес-процеси стають даними, а не ланцюжками if у коді.

Замість:

if ($status == 'approved') {
    $this->notifyManager($card);
    $this->createInspectionTask($card);
}

Опис процесу:

Чернетка → Погодження → Затверджено

Перехід «Погодження → Затверджено»:
  - Умова: роль = «Інженер з корозії»
  - Дія: сповістити відповідального
  - Дія: створити завдання на повторне обстеження

Workflow Engine:

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

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

Permission Engine

Єдина система керування доступом для всієї платформи.

Підтримує рівні:

• Ролі — «Інженер», «Керівник ділянки», «Аудитор».
• Політики — «може редагувати карти свого ділянки».
• Доступ до полів — «швидкість корозії бачать усі, прогноз залишкового ресурсу — лише інженери».
• Доступ до дій — «затверджувати може лише роль X при статусі Y».

Permission Engine інтегрований з Entity Engine і Workflow Engine: права перевіряються на кожному запиті, а не розмазані по контролерах.

Event Bus

Основа слабозв'язаної архітектури всередині ERP.

Модулі не викликають одне одного напряму. Вони публікують і підписуються на події:

ContractApprovedEvent
        ↓
   Notification Module → email відповідальному
        ↓
   Audit Module → запис у журнал
        ↓
   Integration Module → webhook у зовнішню систему

Переваги:

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

Реалізація: in-process event bus для моноліту, RabbitMQ / NATS при горизонтальному масштабуванні.

Audit Engine

Фіксує повну історію змін — хто, коли, що саме змінив.

Відповідає на питання, які в промисловій ERP ставлять щодня:

• Хто змінив швидкість корозії з 0.3 на 0.8?
• Коли карта перейшла в статус «Затверджено»?
• Які поля змінилися при останньому редагуванні?

Audit Engine працює на рівні Entity Engine: кожна операція create/update/delete автоматично логується. Не потрібно вручну додавати $this->auditLog() в кожен контролер.

---

Чому CRUD уже недостатньо

Більшість туторіалів з ERP закінчуються на CRUD: створити, прочитати, оновити, видалити. Для демо цього достатньо. Для промислової експлуатації — ні.

Проста система

Дозволяє:

• створити корозійну карту;
• змінити поля;
• видалити запис;
• вивести список.

Реальна промислова система

Вимагає:

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

Саме ця логіка — процеси, розрахунки, сповіщення, аналітика — складає 80% складності промислової ERP. CRUD — решта 20%, які при цьому займають 80% часу розробки в класичній архітектурі.

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

---

Що показало дослідження готових рішень

При проєктуванні платформи було проведено огляд існуючих open-source інструментів:

Головний висновок

Готового open-source конструктора інтерфейсів для ERP знайдено не було.

Існуючі рішення діляться на дві категорії:

Low-code платформи (Appsmith, ToolJet, Budibase) швидко створюють інтерфейси, але накладають архітектурні обмеження й нав'язують власну модель даних. Підходять для внутрішніх інструментів і прототипів, але не для ERP, яка має жити десятиліття.

Framework-підхід (React Admin, Refine) прискорює розробку CRUD-інтерфейсів, але не вирішує задачі платформенного рівня: metadata engine, migration engine, workflow designer, permission engine, audit.

Висновок: платформенний шар доведеться будувати. Можна й потрібно спиратися на готові бібліотеки для UI, але архітектура ERP — власна.

---

Чому React Admin не вирішує проблему

React Admin — відмінний інструмент. Він допомагає за години зібрати:

• таблиці з сортуванням і фільтрами;
• форми з валідацією;
• картки сутностей;
• базові права через authProvider.

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

• Dashboard Builder — конструктор аналітичних панелей з віджетами;
• Workflow Designer — візуальний редактор бізнес-процесів;
• користувацькі представлення — коли кінцевий користувач налаштовує колонки й фільтри;
• конструктори інтерфейсів — коли архітектор описує форму в метаданих, а не в JSX.

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

Правильне використання: React Admin (або його патерни) — як будівельний блок всередині Entity Engine для рендерингу списків і форм на основі метаданих. Не як заміна платформи.

---

Сучасний стек фронтенду для ERP

Якщо не використовувати готову платформу цілком, у 2026 році розумно спиратися на перевірений набір бібліотек:

Цей набір покриває більшу частину задач корпоративного інтерфейсу:

• Ant Design + TanStack Table — списки сутностей з фільтрами, сортуванням, експортом.
• React Hook Form + Ant Design — динамічні форми на основі метаданих полів.
• React Flow — візуальний редактор workflow для архітекторів.
• dnd-kit — конструктор дашбордів: перетягування віджетів.
• ECharts — графіки корозії, тренди, KPI-панелі.
• TanStack Query — єдиний шар роботи з Entity Engine API.

Ключовий принцип: UI рендериться з метаданих, а не хардкодиться для кожної сутності. Один компонент EntityList отримує опис із Metadata Engine і малює таблицю. Один EntityForm — форму. Спеціалізовані екрани — виняток, а не правило.

---

ERP Studio і персоналізація користувача

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

Рівень архітектора (ERP Studio)

Архітектор або адміністратор системи керує структурою:

• сутності й поля — створення, типи, валідація;
• workflow — статуси, переходи, дії;
• права — ролі, політики, доступ до полів;
• інтерфейси — базові списки, форми, дашборди.

ERP Studio — це середовище, в якому архітектор описує систему, а платформа матеріалізує опис у таблиці, API й UI. Аналогія: Figma для структури ERP, тільки зміни одразу працюють у prod.

Інструменти ERP Studio:

• конструктор сутностей (drag-and-drop полів);
• редактор workflow (React Flow);
• налаштувач прав (матриця ролей і дій);
• попередній перегляд форм і списків.

Рівень користувача (Personalization)

Кінцевий користувач керує своїм робочим простором:

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

Користувач не створює сутності й не змінює workflow. Він налаштовує інтерфейс під себе — як закладки в браузері або колонки в Excel.

Розділення критичне: якщо дати кінцевому користувачу доступ до Metadata Engine, система розвалиться. Якщо не дати персоналізацію — користувачі ненавидітимуть «жорсткий» інтерфейс.

---

Стратегія міграції існуючої ERP

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

Правильний шлях — еволюція, а не революція.

Етап 1. Аудит поточної архітектури

• Інвентаризація модулів, таблиць, інтеграцій.
• Карта залежностей: хто від кого залежить.
• Виявлення «гарячих точок» — модулів, які змінюються найчастіше.
• Оцінка: які модулі кандидати на перший перенос.

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

Етап 2. Впровадження Metadata Engine

• Описати існуючі сутності в метаданих (без зміни БД).
• Metadata Engine читає опис, але поки не керує міграціями.
• Мета: перевірити модель метаданих на реальних даних.

Етап 3. Впровадження Migration Engine

• Підключити синхронізацію метаданих із схемою БД.
• Перші автоматичні міграції — на тестовому середовищі.
• Існуючі таблиці залишаються; нові поля додаються через Metadata Engine.

Етап 4. Створення Entity Engine

• Універсальний API для CRUD на основі метаданих.
• Паралельно з існуючими контролерами — не заміна, а альтернативний шлях.
• Перший модуль переводиться на Entity Engine.

Етап 5. Розробка нових модулів на платформі

• Усі нові сутності створюються лише через Metadata Engine + Entity Engine.
• Старий код не чіпається.
• Команда звикає до платформенного workflow.

Етап 6. Поступовий перенос старих розділів

• По одному модулю, за пріоритетом з аудиту.
• Strangler Fig Pattern: новий API обгортає старий, frontend перемикається поступово.
• Старий код видаляється лише коли модуль повністю перенесений і протестований.

Типові терміни: 12–24 місяці для середньої ERP (20–50 модулів). Не «великий вибух», а безперервна доставка цінності.

---

Якими будуть ERP через 10 років

З високою ймовірністю індустрія рухається до такої моделі:

Від ERP як набору екранів — до ERP як платформи.

• Нові сутності з'являються через конструктори, а не через спринти розробки.
• Інтерфейси збираються динамічно з метаданих і користувацьких налаштувань.
• Бізнес-процеси налаштовуються архітектором без зміни коду.
• Розробники зосереджуються на складній доменній логіці: розрахунки, ML-прогнози, інтеграції з обладнанням.
• AI-асистенти допомагають архітекторам описувати сутності й процеси природною мовою — але ядро залишається metadata-driven, а не «згенерованим на льоту без структури».

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

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

---

Висновок

Сучасна ERP у 2026 році — це вже не набір таблиць і форм. Це платформа, що об'єднує:

• метадані — опис структури в даних;
• рушії — migration, entity, workflow, permission, audit, events;
• бізнес-модулі — спеціалізована логіка поверх платформи;
• персоналізацію — ERP Studio для архітекторів, налаштування для користувачів;
• інтеграції — через Event Bus, а не прямі виклики.

Ключові принципи:

1. Метадані керують структурою, PostgreSQL зберігає дані — не EAV, не універсальні таблиці.
2. CRUD автоматизується платформою — розробники пишуть те, що не можна описати декларативно.
3. Міграція — еволюція — Metadata Engine спочатку, Entity Engine потім, перенесення модулів поступово.
4. Готового рішення немає — стек бібліотек є, платформенний шар будується під себе.

Головне питання при проєктуванні ERP сьогодні звучить не:

«Як реалізувати новий модуль?»

а:

«Як побудувати платформу, на якій нові модулі з'являтимуться максимально дешево й швидко?»

Відповідь на це питання визначає, чи зростатиме ваша ERP разом із бізнесом — чи стане наступним монолітом, який через п'ять років доведеться переписувати знову.