Почему «open-source ERP» больше не означает один тип решения

Если читать большинство материалов про open-source ERP, может показаться, что мир до сих пор делится на «готовые системы» и «разработку с нуля». На практике к 2024–2025 годам почти никто уже так не мыслит.

Компании больше не ищут ERP как продукт. Они ищут способ собирать и сопровождать свои бизнес‑системы в условиях постоянных изменений: процессов, команд, интеграций — и теперь ещё AI.

Поэтому в этом списке намеренно перемешаны ERP, платформы и low-code‑инструменты — именно так они сосуществуют в реальных компаниях сегодня.

Мало времени?

Большинство команд не оценивают все варианты одинаково. Список быстро сужается под конкретный контекст:

Выберите, что ближе всего:

На что смотреть в первую очередь:

Выберите один из вариантов выше — я подсвечу наиболее релевантные системы.

Если вы узнаёте себя в одном из описаний, обычно имеет смысл рассматривать лишь небольшое подмножество систем из статьи.

Перейти к разделу:

Классические ERP: по‑прежнему живы, но уже не универсальны

Odoo (Community Edition)

Odoo остаётся самой узнаваемой open-source ERP‑платформой. Она до сих пор хорошо работает как «точка входа»: учёт, продажи, склад, базовые рабочие процессы — всё доступно из коробки.

Проблемы обычно начинаются не на запуске, а через год‑два. Когда бизнес выходит за рамки стандартных сценариев, Odoo превращается в продукт, который вы по сути поддерживаете сами: собственные модули, сложные апгрейды и зависимость от экосистемы.

Хорошо подходит, если: нужен быстрый старт и относительно стандартные процессы.
Плохо подходит, если: бизнес‑логика часто меняется, а ERP должна эволюционировать, а не «замораживаться».
Links: Site · GitHub

ERPNext

ERPNext часто выбирают команды, которым нужна цельная, структурированная ERP без избыточности уровня крупного enterprise. Система дисциплинирует: если ваши процессы укладываются в её модель, она ведёт себя предсказуемо и надёжно.

Цена этой предсказуемости — гибкость. ERPNext плохо переносит постоянное «подгибание» под новые операционные модели.

Хорошо подходит, если: бизнес готов стандартизироваться.
Плохо подходит, если: процессы нестабильны и часто меняются.
Links: Site · GitHub

Dolibarr

Dolibarr представляет собой лёгкий сегмент open-source ERP. Его часто выбирают небольшие компании, которым нужны базовые CRM, выставление счетов и складской учёт без операционной сложности.

Основное преимущество Dolibarr — простота, а не архитектурная гибкость. Система лучше всего работает, когда процессы понятны и вряд ли будут часто меняться.

Хорошо подходит, если: простота важнее расширяемости.
Плохо подходит, если: от ERP ожидают эволюции в платформу.
Links: Site · GitHub

metasfresh

metasfresh фокусируется на операционных процессах: логистике, закупках и планировании производства. Система менее универсальна, чем многие ERP, но сильна в своих основных областях.

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

Хорошо подходит, если: в центре — цепочка поставок и операции.
Плохо подходит, если: нужна универсальная бизнес‑платформа.
Links: Site · GitHub

Платформенный подход к ERP: когда ERP — это результат, а не продукт

MyCompany (lsFusion)

Всё больше команд понимают, что ERP как «коробочный продукт» плохо выдерживает реальную жизнь: меняющиеся процессы, новые каналы, автоматизацию и AI.

MyCompany — пример платформенного подхода. Формально это ERP, но по сути это способ описывать бизнес‑логику так, чтобы она могла эволюционировать без переписывания системы.

Это особенно важно в контексте AI. Декларативная, прозрачная логіка проще для анализа, объяснения и автоматизации — и для людей, и для AI‑инструментов.

Хорошо подходит, если: ERP должна расти и трансформироваться вместе с бизнесом.
Плохо подходит, если: вы хотите ERP по принципу «внедрил и забыл».
Links: Site · GitHub

Tryton

Tryton менее популярен, но архитектурно очень чист. Его часто выбирают команды, которым нужен полный контроль над моделью данных и которые не боятся писать код.

Это не про быстрый старт, а про надёжный фундамент для долгоживущих систем.

Хорошо подходит, если: у вас есть инженерная команда и длинный горизонт планирования.
Плохо подходит, если: ERP нужна «ещё вчера».
Links: Site · GitHub

Apache OFBiz

OFBiz редко используют как готовую ERP. Чаще это фундамент для построения собственных бизнес‑систем.

Он даёт свободу, но требует зрелой команды и архитектурной дисциплины.

Хорошо подходит, если: ERP — часть вашей внутренней платформы.
Плохо подходит, если: не хватает ресурсов разработки.
Links: Site · GitHub

Openbravo

Openbravo часто используют как ERP‑ядро, а не как полный набор модулей. Его обычно применяют как backend‑основу для ритейла и распределённых корпоративных систем.

На практике Openbravo встраивают в более крупные стеки, а не используют как самостоятельный продукт.

Хорошо подходит, если: ERP — часть более широкой корпоративной архитектуры.
Плохо подходит, если: ожидается полностью готовая система из коробки.
Links: Site

Low-code и внутренние инструменты: как на практике строят ERP

ToolJet

ToolJet — хороший пример того, как компании сегодня фактически строят «ERP‑подобные» системы. Это не один монолит, а набор внутренних интерфейсов, подключённых к данным и сервисам.

Это не ERP в классическом понимании, но именно так часто выглядит современная операционная система бизнеса.

Хорошо подходит, если: ERP по сути — набор внутренних инструментов.
Плохо подходит, если: требуется единое монолитное бухгалтерское ядро.
Links: Site · GitHub

NocoBase

NocoBase появляется в сценариях, похожих на ToolJet, но с более сильным акцентом на расширяемость и плагины.

Его выбирают, когда ERP — это экосистема внутренних приложений, а не одна система.

Хорошо подходит, если: нужен low-code‑слой поверх данных.
Плохо подходит, если: вы ищете готовый ERP‑комплект.
Links: Site · GitHub

Budibase

Budibase занимает близкую нишу — быстрое создание внутренних админ‑панелей и операционных интерфейсов.

Хорошо подходит, если: нужно быстро собирать интерфейсы для команд.
Плохо подходит, если: сложная бизнес‑логика должна жить в ядре системы.
Links: Site · GitHub

Retool

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

Его часто используют вместе с ERP и платформами как операционный слой, а не как замену.

Хорошо подходит, если: ERP по сути — это набор внутренних инструментов.
Плохо подходит, если: бухгалтерский контур должен жить в той же системе.
Links: Site

Как принимали решения в 2025 году

  1. Если нужны быстрые результаты: берут готовую ERP.
  2. Если ERP — живой организм: выбирают платформенный подход.
  3. Если ERP — это набор инструментов: делают ставку на low-code и внутренние приложения.

В реальности многие компании используют комбинацию всех трёх. И это главный тренд последних лет.

Итоги: как выбирать в 2026 году (без иллюзий)

Ключевая ошибка при выборе ERP в 2025 году — вера в то, что существует одна «правильная» система, которая раз и навсегда решит все задачи.

Реальность иная: современные компании строят архитектуру бизнес‑систем, где ERP — это не продукт, а слой логики и данных.

  1. Если нужны быстрые результаты прямо сейчас
    Выбирайте готовую ERP и осознанно ограничивайте кастомизацию. Это решение про скорость, а не про идеальное совпадение с процессами.
  2. Если бизнес постоянно меняется
    Ищите платформенный подход. Критично, чтобы бизнес‑логика была декларативной, читаемой и объяснимой — не только для разработчиков, но и для AI‑инструментов, которые всё чаще участвуют в анализе, автоматизации и сопровождении систем.
  3. Если ERP на практике — это набор внутренних инструментов
    Low-code и внутренние инструменты уже давно не «временное решение», а полноценный операционный слой. Они позволяют быстро закрывать новые потребности без переписывания ядра системы.

Важно:

Избегайте одновременного смешения всех трёх подходов.
Выберите один как ядро, а остальные используйте только как вспомогательные слои.

Обращайте внимание на читаемость и формализуемость бизнес‑логики.
То, что нельзя чётко описать, нельзя надёжно автоматизировать — ни вручную, ни с помощью AI.

Что должен понимать владелец до выбора системы

  • Как часто меняются ключевые бизнес‑процессы?
  • Должна ли система объяснять свои решения людям и AI?
  • Готов ли бизнес жить внутри чужой модели — или развивать собственную?
  • ERP — это только инструмент учёта или основа оперативного управления?

Ответы на эти вопросы важнее любого списка функций. Именно они определяют, будет ли система поддерживать рост бизнеса или замедлять его.