Перейти до змісту

Після 1С: чому «переходьте на Odoo» — неправильна відповідь

Маніфест ESWF / DOP. Квітень 2026.

1. Порожнеча

1С пішов з України. Формально — під санкціями, фактично — з ринку, у якому працював 25 років і куди повертатися не буде.

Після нього лишилась порожнеча, розмір якої досі недооцінюють. Не тому що «нема альтернатив облікових систем» — альтернатив повно: SAP, Microsoft Dynamics, NetSuite, Odoo. А тому що 1С закривав клас задач, який жоден із цих продуктів не закриває так само: швидка розробка галузевих конфігурацій силами локального інтегратора.

Це була усвідомлена і добре спроектована модель: платформа + типова конфігурація + предметно орієнтована мова + мережа франчайзі, налаштована саме на галузеву кастомізацію. На ній виросла реальна індустрія — три тисячі дрібних галузевих рішень, від вагарні зернового елеватора до приймальні ювелірки, і тисячі спеціалістів, які вміли швидко дати бізнесу робочий інструмент під його домен. Модель працювала, і вона закривала український ринок.

Окремо варто сказати про BAS. Це чесна спроба українських команд зберегти цю індустрію в правовому полі після 2014 року — на тій самій технологічній платформі. Юридично BAS — український продукт; архітектурно — пряме продовження 1С з усіма його перевагами (швидкість галузевої кастомізації) і обмеженнями (desktop-first, пропрієтарна мова, залежність від однієї платформи). Це не критика людей, які його зробили — це констатація того, що «вуха платформи» видно, і стратегічно країна лишається у тій самій технологічній колії.

Коли 1С піде, жодна конкретна компанія його не оплакуватиме — а сукупно виявиться, що замість цієї моделі (платформа + галузеві конфігурації + екосистема інтеграторів) на веб-стеку та у відкритій архітектурі нема нічого.

Поширена відповідь: «переходьте на Odoo». Вона звучить розумно, вона неправильна, і ця стаття пояснює чому.

2. Два слова, які вирішують усе: generic і specific

Є дві стратегії побудови бізнес-софту.

Generic-підхід. Один інструмент покриває всі галузі через абстрактні сутності: Product, Partner, Order, Invoice. Specific-конфігурації — або через параметри, або через кастом-модулі. Приклади: Odoo, Salesforce, SAP, NetSuite.

Specific-підхід. Інструмент побудований навколо сутностей конкретної галузі як first-class об'єктів. Приклади: Shopify (e-commerce), Procore (будівництво), Toast (ресторани), Veeva (фармацевтика).

Generic виграє на широкому ринку: одна кодова база покриває сотні use-case-ів, низька ціна розробки на клієнта, масштабування через consultant-hours.

Generic програє у вертикалі. Завжди. І ось чому.

Візьмемо Multimodal Freight Forwarding — ринок, на якому в Україні працюють сотні компаній, і який після 1С-апокаліпсиса лишився без жодного адекватного інструменту.

Концепт Odoo (generic) Що реально потрібно
Що продаємо Product з категорією Shipment з House B/L ↔ Master B/L
Кому продаємо Partner Shipper + Consignee + Notify Party — три ролі на одному коносаменті
Процес Sale Order → Delivery → Invoice Inquiry → Quote → Booking → Pre-carriage → Main → On-carriage → POD → Invoice
Ціна Pricelist з rules Tariff з FCL/LCL + BAF/CAF/THC/DOC по напрямках і лініях
Документ Stock Picking CMR / B/L / AWB з юридичною силою
Таймер нема Demurrage timer від gate-out, Detention timer від discharge
Інтеграції нема Maersk/MSC/CMA tracking, carrier booking, eCMR

Формально Odoo це може. Ви мапите Container на Product, Booking на Sale Order, пишете 20 кастом-модулів, наймаєте консультанта на €120/год, через два роки маєте працюючу систему.

Фактично форвардер, який відкриває цю систему, бачить не свою роботу — бачить узагальнений ERP, в який свою роботу треба перекладати в голові. Кожен день, кожною операцією, кожен новий співробітник, якого треба навчати «а наш Stock Picking — це насправді CMR, а Product — це контейнер, і не питай чому».

Це не технічна проблема. Це когнітивне навантаження, яке generic-підхід перекладає з виробника ПЗ на користувача, щодня, назавжди.

3. Domain — не архітектурний термін

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

Domain — це не архітектура. Це предметна область: набір сутностей, процесів, документів, правил і термінології конкретної галузі.

Домен форвардера включає: HBL, MBL, Booking, Consolidation, Incoterms як стан, Demurrage/Detention таймери, multi-leg перевезення зі зміною моди, specific документи (CMR, AWB, SWB, Manifest, T1). Ці поняття або є у системі first-class — або їх там немає, і тоді їх доводиться «ліпити» з Product + Partner + Sale Order.

Та ж логіка працює для десятка інших українських вертикалей:

  • Контейнерні термінали / депо. Stack position, reefer monitoring, survey reports, M&R (maintenance & repair), gate operations. В Odoo цього нема зовсім.
  • Автопарки з водіями в полі. Offline-first мобільний додаток для водіїв, telematics, путівка, пальне, ремонти як цикли. Odoo Mobile — онлайн-обгортка, яка в степу не працює.
  • Агро. Gin books, польові операції, залікова вага, сортність, лабораторні аналізи, митне оформлення зерна. Нема.
  • Ювелірка. Проба, облік за грамами + шт., лома, давальницька сировина, пробірна палата. Нема.
  • Автосервіси. Нормо-години, order-to-repair, гарантійні акти, схеми TecDoc. Нема.

1С цей список закривав правильно — він від початку був платформою саме для галузевих конфігурацій, і навколо нього виросла екосистема з тисячею франчайзі, кожен зі своїм доменом. Модель була хороша, люди — сильні, українська ERP-індустрія у значній мірі виросла саме там. Проблема не з моделлю і не з людьми — проблема в тому, що конкретна технологічна платформа, на якій усе це стояло, зникає з-під ніг разом з 1С, а її наступник (BAS) лишається у тій самій колії.

Ця екосистема не перенесеться на Odoo автоматично. Не тому що люди погані, а тому що сам продукт побудований навколо іншої моделі світу — і ті самі сильні 1С-спеціалісти у цій моделі просто менш продуктивні, ніж були у своїй.

4. Стратегічна помилка, яку зараз роблять

Майже всі українські проєкти, що намагаються зайняти постодного місце, роблять одну й ту ж помилку: будують «кращий generic». Ще одну горизонтальну ERP-систему, з модулями «Продажі / Закупівлі / Склад / Бухгалтерія / Зарплата», з надією, що якщо вона буде локалізована + компактніша + дешевша від SAP — ринок прийде.

Ринок не прийде.

Тому що на горизонтальному полі вже сидять Odoo, NetSuite, SAP Business One — а в українському сегменті BAS продовжує успадковану від 1С лінію. У всіх них 10–20 років edge-кейсів, екосистема консультантів, маркетплейси модулів або типові конфігурації. Змагатися з ними у їхньому жанрі — це битва, де ви на їхньому полі, з їхніми правилами, без їхніх ресурсів.

Результат передбачуваний: через три роки «ще один український ERP» матиме 50 клієнтів, 15 співробітників, buy-out розмову з одним з інтеграторів, і тихо зникне.

Виграшна стратегія — інша.

5. Wedge: почни з того, де їх нема

Wedge (буквально «клин») — термін зі стартап-стратегії: вузька точка входу, через яку малий гравець пробиває собі місце проти великого. Колоду лобом не розколоти — клин у щілину розколює.

Класика: - Amazon — wedge: книги. Не «магазин усього». - Facebook — wedge: студенти Гарварду. Не «соцмережа всім». - Tesla — wedge: Roadster для багатих ентузіастів. Не «машина для всіх». - Stripe — wedge: прийом платежів для розробників у 7 рядків коду. Не «платежі для бізнесу». - Shopify — wedge: малий e-commerce без IT. Не «заміна Amazon».

Для Ukrainian post-1C реальності wedge — це одна конкретна вертикаль, де Odoo не знає домену, а 1С-альтернативи нема. Для нашої команди це спочатку Multimodal Freight Forwarding. Для когось іншого — це агро, автосервіс, будівництво, приватна медицина, ювелірка, виробництво меблів на замовлення.

Принцип єдиний: не «кращий Odoo», а «єдиний specific» у вузько обраній галузі.

6. Що таке ESWF і DOP

ESWF (Extensible System Web Framework) — технологічний шар: Django + React, multi-tenancy, metadata-driven UI, plugin-система, платіжки, мобільні додатки з offline-синхронізацією. Це фреймворк, на якому швидко будуються вертикальні додатки.

DOP (Digital Operations Platform) — reference implementation на ESWF: Essentials (облікове ядро), CRM, HRM, Production, Client Portal, Fleet, Multimodal F&F, ContainerHub. Він одночасно повноцінний продукт і приклад того, як будувати специфічні галузеві рішення поверх ESWF.

Важливо, чим ми не є:

  • Ми не «український Odoo». Якщо ви шукаєте generic-ERP — Odoo кращий, і ми не намагаємося бути ним.
  • Ми не «заміна 1С» у сенсі «той самий продукт, тільки український». Але правильну ідею 1С — галузеві конфігурації силами локальних команд, поверх спільної платформи — ми беремо цілеспрямовано. Що ми не повторюємо — це технологічну платформу: ми робимо веб-first, open-source, без залежності від одного вендора і без пропрієтарної мови.
  • Ми не «ще одна універсальна платформа». Ми цілеспрямовано вужчі за тих, хто бореться за горизонтальний ринок.

Чим ми є:

  • Фреймворк, на якому інтегратор може за місяці (не роки) зібрати галузеве рішення, якого раніше не було — тому що ядро бере на себе multi-tenancy, permissions, мобільні додатки, friend API, бухгалтерську базу.
  • Референсна вертикаль (Multimodal F&F, ContainerHub, Fleet), яка показує, як це робиться, і одночасно є повноцінним продуктом для цієї конкретної галузі.
  • Open-source — бо екосистему post-1C не збудує одна компанія. Її побудує спільнота з десятків команд, кожна зі своєю вертикаллю.

7. Що це означає практично

Якщо ви форвардер: існує продукт, у якому HBL, Booking, Demurrage — центральні об'єкти, а не кастом-поля на Sale Order.

Якщо ви контейнерний термінал: можемо поговорити. ContainerHub у ранній стадії, але побудований правильно — stack, gate, survey, M&R first-class.

Якщо ви інтегратор: замість писати свою архітектуру з нуля або калічити Odoo — візьміть ESWF як базу, і зосередьтесь на домені, а не на multi-tenancy і JWT.

Якщо ви 1С / BAS-розробник: цей проєкт — цілеспрямовано для вас. Ваш досвід у галузевих конфігураціях, у розумінні того, як бізнес реально працює день-у-день, у швидкій кастомізації під конкретного замовника — це саме ті навички, які роблять вертикальний софт. Ми не пропонуємо «перейти на Python і React» — ми пропонуємо перенести модель (платформа + галузеві конфігурації + локальний інтегратор) на сучасний стек, де замість пропрієтарної мови — відкритий фреймворк, замість однієї компанії-вендора — спільнота, замість desktop — web+mobile. Доменний мозок переноситься; змінюється тільки технологічний носій.

Якщо ви розробник: цей проєкт — спроба зробити те, що постпострадянський простір не робив ніколи: вертикальний open-source стек, який не залежить від однієї компанії. Це амбіційно, ймовірно провалиться — але шанс нетривіальний, а альтернатива (чекати поки прийде Odoo) — гарантовано програє.

Якщо ви скептик: ви маєте рацію. Один-два-десять людей проти Odoo S.A. з 2000+ співробітників — це не гра з рівними шансами. Виграшний варіант тут один: не грати з ними у шахи, а грати у ту гру, у яку вони не вміють. Вертикальний домен — це гра, у яку generic-гравці за означенням не вміють.

8. Закриваючий абзац

1С не повернеться. BAS продовжує його лінію, але на тій самій платформі — і стратегічно це не розв'язує проблеми технологічної залежності. Odoo порожнечу повністю не закриє — бо domain-knowledge не переноситься разом з кодом. На цьому роздоріжжі Україні потрібен не «ще один ERP», а нова модель: відкритий веб-фреймворк, на якому десятки вертикальних продуктів можна збудувати паралельно, кожен зі своїм доменом, але з єдиним стеком і єдиною екосистемою — і з тими самими людьми, які вже 20 років уміють робити галузеві рішення.

ESWF / DOP — спроба зробити цей фреймворк.

Чи вийде — побачимо. Але правильне питання сьогодні не «коли у нас буде свій 1С», а «хто зробить першу вертикаль, у якій ніхто не хоче мапити контейнер на Product».

— Команда ESWF / DOP

Update 2026-05-12 — формалізація wedge у ShipCore

«Multimodal Freight & Forwarding» з § 5 цього маніфесту з 2026-05-12 формалізовано у продуктову лінію ShipCore — umbrella vertical, що об'єднує існуючі transport-модулі (Fleet ✅ → shipcore_auto, Logistic 💎 → shipcore_forwarder, ContainerHub ✅ → shipcore_terminal) і нові вертикалі (Sea, Rail, Avia stub) під єдиним thin shared core backend/shipcore/.

12 архітектурних/бізнес-рішень — у ShipCore decisions-2026-05-12. Програмний документ — ShipCore README. Активний research — market-research, integration-matrix, roadmap.

Ця гілка — конкретна відповідь на питання «хто зробить першу вертикаль» для UA+EU транспортного ринку post-1С.