Уявіть: ви три роки користуєтесь 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 варіант.

Конкретні умови співпраці для кожного формату — індивідуально, кейс-залежно. Якщо вам цікаво обговорити — напишіть нам, розберемось, як це може виглядати у вашій ситуації.

Часті запитання