Представьте: вы три года пользуетесь ERP-системой. Все процессы настроены, сотрудники обучены, история сделок и документов — всё там. А однажды утром получаете письмо: «Сервис закрывается через 30 дней». Что вы делаете?

Это не теоретический вопрос. SaaS-сервисы для бизнеса закрываются регулярно — от небольших украинских стартапов до крупных международных продуктов. Для одних пользователей это означает 2-3 месяца хаоса и переобучения. Для других — полную остановку работы. В этой статье разберём, как «открытый код» в ERP защищает ваш бизнес от такого сценария — и чем наша модель отличается от классического open-source.

Что обычно означает «open-source ERP»?

Когда вы слышите «ERP с открытым кодом» — обычно имеются в виду крупные публичные проекты: Odoo Community, ERPNext, Dolibarr. У них общая модель:

• Публичный репозиторий на GitHub или GitLab — любой может скачать код
• Лицензия (GPL, AGPL, MIT) — формально разрешает использовать, модифицировать, распространять
• Сообщество — тысячи разработчиков по всему миру
• Самостоятельная установка — вы ставите систему на свой сервер, настраиваете, поддерживаете

Звучит идеально — но есть нюансы. Классический open-source ERP требует сильной IT-команды для внедрения и сопровождения. Для бизнеса на 10-50 человек это часто непосильно: нужен DevOps, БД-администратор, разработчики под вашу отрасль. Или вы нанимаете интегратора — и снова зависите от одного исполнителя.

Поэтому многие украинские компании выбирают SaaS — быстро, без своей IT-команды, с поддержкой «из коробки». Но SaaS возвращает вас к тому же vendor lock-in: ваши данные и процессы у вендора, и если что-то случится — вы снова в ситуации, с которой начинали.

Как работает доступ к коду в ERPJS

В ERPJS две опции работы, и каждая по-своему решает вопрос независимости:

Опция 1: SaaS на erpjs.biz. Вы регистрируетесь, получаете свою компанию в нашем облаке, начинаете работать в течение 15 минут. Код бизнес-логики на наших серверах — у вас к нему прямого доступа нет. Это быстрый старт, но полного контроля над системой у вас нет — вы зависите от нас как от SaaS-вендора.

Опция 2: On-premise установка на ваш сервер. Мы переносим ERPJS на ваш сервер — физический или облачный. И вот здесь начинается главное: код бизнес-логики — документы, процедуры, регистры, отчёты, формы, валидации — автоматически оказывается у вас на диске. Не как «доступ по запросу», не «пришлём архив когда захотите» — а как просто файлы на сервере, к которым у вас прямой доступ.

Бизнес-логика — это полноценный читаемый JavaScript. Не минимизированный, не обфусцированный. Любой JS-разработчик может открыть файлы, прочитать логику, понять что происходит. Системное ядро (фреймворк) при этом поставляется как собранная библиотека — как принято в Node.js-экосистеме. Это не ограничение: всю специфику вашей отрасли и процессы вы можете адаптировать без вмешательства в ядро.

Это не «open-source ERP» в классическом понимании — у нас нет публичного GitHub с тысячами контрибьюторов. Но это — техническая доступность бизнес-логики в ваших руках, что по факту даёт вам тот же уровень контроля над вашими процессами.

Что это даёт вам на практике?

Перейдём от теории к конкретике. Вот 4 следствия того, что код бизнес-логики у вас на сервере:

1. Любой JS-разработчик может работать с бизнес-логикой. Не нужен «сертифицированный ERPJS-консультант». Файлы .js бизнес-логики на вашем сервере — это обычный JavaScript. Нанимаете разработчика-фрилансера, штатного, аутсорсинговую компанию — любой вариант рабочий.

2. Не зависите от нашего roadmap. Нужна специфическая фича под вашу отрасль, а в нашем плане она запланирована на следующий год? Вы можете заказать её реализацию у любого разработчика, который работает с кодом. Не ждёте нас.

3. Имеете план Б на случай любых событий с ERPJS. Сервис закрылся, нас купила другая компания, война — неважно. Ваша система продолжает работать на вашем сервере. Поддержку обеспечивает тот разработчик, который у вас есть сейчас — или новый, которого вы найдёте.

4. Данные + код = полный контроль. Это принципиальная разница от чистого SaaS, где у вас есть только данные, но без кода вы не можете ничего изменить. И от чистого open-source без вендора, где у вас есть код, но вся ответственность на вас.

По такой же логике мы писали о том, когда Excel перестаёт работать — там тоже основной риск в отсутствии контроля. А если вы только выбираете ERP — наш гайд 7 критериев выбора поможет учесть независимость как один из пунктов.

SaaS или on-premise: какой вариант именно для вас?

Это не два этапа одного пути, как часто пишут. Это два разных продукта для разных сегментов — и выбирать нужно на старте.

SaaS подходит вам, если:

• Вы самозанятый, фрилансер, или у вас 1-3 человека в команде
• Одна точка: кофейня, салон, небольшой магазин, сервис
• Простой продуктовый каталог, простые процессы
• Вопрос контроля над кодом для вас не актуален — вам нужен быстрый старт, а не долгосрочная стратегия

На этом уровне vendor lock-in — теоретический риск: процессы у вас стандартные, объём данных ограничен, переключиться на другую систему при необходимости не будет катастрофой. Регистрируйтесь, начинайте за 15 минут, работайте.

On-premise — это правильный стартовый выбор, если:

• У вас производство, дистрибуция, сеть магазинов, СТО, склад
• 10+ сотрудников и несколько юрлиц
• Сложные процессы, специфическая отрасль, возможно — интеграции с другими системами
• Регуляторные требования (фарма, медицина, финансы) или корпоративная политика безопасности
• Вы понимаете, что зависимость от одного SaaS-вендора — это бизнес-риск

Здесь on-premise — это не «следующий уровень когда дозреете», а правильный выбор с самого начала. Чем раньше вы на собственном сервере, тем меньше переделывать при росте. И тем меньше риск, если что-то изменится у нас.

Переход с SaaS на on-premise остаётся технически возможным — например, если начинали небольшой командой на SaaS, а потом бизнес вырос. Данные переносятся с SaaS на on-premise и обратно — это тот же продукт, та же база. Но лучше не доводить до момента, когда «нужно было on-premise с самого начала».

Кто может делать вашу ERP кроме нас?

Вот тут история становится интересной для IT-компаний и разработчиков. Если у клиента on-premise — код у него, значит потенциально его может сопровождать и расширять любая внешняя IT-компания. Это создаёт пространство для сотрудничества. Три формата, которые мы видим реальными:

Формат 1: Реферал. Вы приводите клиента на ERPJS, мы его ведём. Ваша роль — продажа и первичная консультация.

Формат 2: Внедрение и кастомизация. Вы как IT-подрядчик: внедряете ERPJS у клиента, настраиваете под его процессы, дописываете специфические модули. Деньги получаете от клиента напрямую за свою работу. Код бизнес-логики у вас в руках через on-premise установку.

Формат 3: Self-hosted SaaS. Вы берёте код, разворачиваете свой SaaS под своим брендом — например, специализированную ERP для аптек, СТО, или салонов красоты на базе ERPJS. Это white-label вариант.

Конкретные условия сотрудничества для каждого формата — индивидуально, кейс-зависимо. Если вам интересно обсудить — напишите нам, разберёмся, как это может выглядеть в вашей ситуации.

Частые вопросы