Корпоративные системы в 2032: как мы пришли к AI-читаемым архитектурам

1) Почему старые ERP “умерли” (вежливо)

В 2020-х мы строили корпоративные системы как города ручной работы: правила, экраны, модули и “ещё один патч” нарастали друг на друга, пока никто уже не помнил, что из этого несущая конструкция.

Потом пришёл AI — и оказался удивительно бесполезен. Не потому что он слабый, а потому что системы были нечитаемыми.

• Бизнес-логика жила в разбросанных if по модулям.
• UI, данные и правила эволюционировали в разных “часовых поясах”.
• Документация отставала от реальности (на пару релизов… и на пару лет).

2) Паттерн 2032: стек, а не комбайн

К 2032 компании перестали “выбирать одну ERP на 15 лет”. Они начали собирать ERP-стеки: модульную архитектуру, где каждый слой делает одну работу — и может эволюционировать, не ломая весь организм.

Суть не в “большем количестве инструментов”. Суть в разделении ответственности: держать строгие вещи строгими (деньги, запасы, аудит), а быстрые — быстрыми (UI, workflow, интеграции).

3) Реальные стеки, которые действительно запускали

Здесь теория либо становится архитектурой… либо превращается в очень уверенную презентацию. Следующие комбинации часто встречались в реальных проектах, потому что совпадали с тем, как работают команды:

Примеры ERP-ядра

• ERPNext как стабильное операционное ядро (запасы, бухгалтерия, базовые процессы).
• Odoo Community Edition, когда важна широта модулей (CRM + продажи + операции), часто с аккуратными границами расширения.
• metasfresh / iDempiere, когда центр тяжести — дистрибуция и логистика.

Примеры low-code слоя

• ToolJet / Appsmith для внутренних экранов: админки, “столы согласования”, “сделайте дашборд к пятнице”.
• NocoBase для data-driven приложений, когда нужны расширения через плагины и более богатое моделирование.

4) Таймлайн эволюции: что было, что стало

Поворот был незаметным: команды не “добавили AI”. Они заменили неструктурированную логику на правила, которые можно читать, ревьюить, версионировать — и да, понимать машинам.

5) Почему open-source стал условием выживания

К 2032 “open-source” перестал быть философией. Это стало практическим ограничением:

• AI не может оптимизировать то, чего не видит. Закрытый код становится “чёрным ящиком” для автоматизированного ревью и рефакторинга.
• Бизнес перестал доверять системам, которые нельзя инспектировать. Особенно на горизонте 10–20 лет.
• Открытые ERP стали базовым слоем для стеков. Сложилась типовая триада: ERP-ядро → Low-code → Декларативные правила.

6) Что должен спрашивать CEO / владелец в 2032 (а не только “какую ERP?”)

1. Может ли AI читать правила? Если правила не формализованы — вы строите музейный экспонат.
2. Есть ли декларативная структура? Язык важен меньше, чем то, что вы можете выразить ясно.
3. UI генерируется или сделан вручную? Ручной UI быстро стареет; сгенерированный держится в такт модели.
4. Явна ли доменная модель? Если модель имплицитна — каждая новая команда “переоткрывает” систему заново.
5. Правила — это правила (а не разбросанные условия)? Бизнес-правило в if трудно аудировать и трудно развивать.
6. Выдержит ли это 20 лет изменений? Команды, рынки, комплаенс и интеграции изменятся. Структура не должна развалиться.

7) Одна диаграмма, которая объясняет всё десятилетие

8) Итог: системы будущего строятся вместе с AI, а не только для людей

ERP даёт фундамент. Low-code даёт скорость. Декларативная логика даёт структуру. AI даёт эволюцию — но только когда систему можно прочитать.

Если архитектура формальная, модульная и пригодная для инспекции — она переживёт следующее десятилетие. Если нет… она станет “проектом миграции legacy” ещё до того, как высохнут чернила.