1. Почему расширять через low-code, а не менять ядро

Прямые правки ядра ERP ведут к боли при обновлениях, vendor lock-in и хрупкой логике. Low-code расширения — альтернатива: ядро хранит авторитетные данные и учетные правила, а эксперименты и быстро меняющиеся процессы уходят во внешний гибкий слой.

Типичные цели low-code расширений:

  • добавлять workflow без правок базовых таблиц и транзакций,
  • безопасно экспериментировать с UX и боковыми процессами,
  • интегрировать внешние сервисы без прямого «вшивания» в ядро ERP,
  • давать citizen developers (бизнес-пользователи, создающие решения сами) строить инструменты с ограничениями.

2. Паттерн #1 — Workflow-слой над ERP

Простой вариант: ERP остается системой записи, а approvals и доп. шаги оркестрируются в low-code движке. Workflow дергает API ERP для чтения/обновления и хранит минимум собственного состояния.

Хорошие кандидаты:

  • утверждение заявок на закупку до создания заказа в ERP,
  • обработка исключений: кредитные лимиты, ценовые оверрайды, скидки,
  • ручные проверки на комплаенс, качество, риски.

Декларативные платформы вроде lsFusion удобны: формы, состояния и правила задаются декларативно, а при завершении шага вызываются API или процедуры ERP.

3. Паттерн #2 — Side-car приложения для сложных процессов

Если процесс слишком специфичен или быстро меняется, его можно вынести в отдельное low-code приложение (side-car), использующее ERP как источник и приемник данных.

Примеры:

  • диспетчеризация производства и UI для цеха,
  • специализированные инструменты для проектов или сервиса,
  • конфигураторы сложных продуктов.

Side-car читает справочники (клиенты, товары, цены) из ERP и пишет обратно только финальные транзакции (заказы, табели, результаты производства). Схема ERP остается чистой, а side-car быстро эволюционирует.

4. Паттерн #3 — Event-driven микрорасширения

В event-driven архитектуре ERP публикует события order.created, invoice.posted, inventory.below_threshold. Low-code компоненты подписываются и выполняют маленькие действия.

Примеры микрорасширений:

  • уведомления в чат или email,
  • создание задач в тикет-системе,
  • выгрузка агрегатов в аналитику/дашборды,
  • триггер генерации документов.

В декларативных платформах реакции описываются правилами: 

EVENT orderCreated WHEN Orders.status = 'Approved' DO
            createShipment(Orders);
            notifySales(Orders.customer);

Так логика расширений остается читаемой и аудируемой, в отличие от набора случайных скриптов.

5. Паттерн #4 — Low-code отчеты и «операционный BI»

Пользователям нужны быстрые ad-hoc отчеты с фильтрами, группировками и вычисляемыми полями. Вместо добавления каждого отчета в ядро ERP можно дать read-only представления и вынести визуализацию в low-code слой.

Плюсы:

  • бизнес сам итеративно правит отчеты без деплоев,
  • read-only доступ снижает риск случайных изменений данных,
  • логика агрегаций эволюционирует быстрее, чем схема ERP.

6. Ограничители: как не сломать ERP

Сила low-code требует дисциплины. Несколько правил:

  • Единый источник истины. Финансовые и складские данные живут в ERP.
  • Понятная ответственность. Каждый workflow знает, какая система за что отвечает.
  • Версионирование. Low-code приложения версионируются и тестируются как код.
  • Доступы. По возможности наследовать роли и права ERP.
  • Мониторинг. Логировать и трейсить действия low-code, касающиеся ERP.

7. Где low-code неуместен

Есть зоны, которые остаются в ядре ERP или в классической разработке:

  • проводки бухучета и налогов,
  • регуляторная отчетность со строгими форматами,
  • производительные batch-процессы на больших данных,
  • модули безопасности с секретами или критичными данными.

Итог

Low-code не заменяет ERP — он помогает расширять и защищать его ядро. Workflow-слой, side-car приложения, event-driven микрорасширения и low-code отчеты дают возможность быстро экспериментировать, сохраняя ядро ERP стабильным и чистым.