6 прихованих проблем Odoo у виробництві, які проявляються після впровадження

Демо Odoo для виробничого підприємства будується за передбачуваною логікою. Інтегратор показує модуль планування матеріальних потреб (MRP), веде через створення специфікації виробу, демонструє планування робочих центрів, проводить через виробниче замовлення. Усі ці екрани існують. На демо вони працюють.

Питання, які при цьому не озвучуються, найважливіші:

Як Odoo поведеться, коли постачальник пришле рахунок із ціною на дванадцять відсотків вищою через два тижні після закриття виробничого замовлення?
Як рахується собівартість двох візуально однакових двигунів, куплених у різний час за різну ціну, якщо в складанні використано саме другий?
Що відбувається з виробничим планом, коли робочий центр уже завантажений вщент, а система додає туди ще три замовлення?
Скільки коштуватиме оновлення Odoo через рік, якщо в проєкті накопичилось десяток кастомізацій?

Відповіді Odoo на ці питання починають розходитись з очікуваннями власника. Архітектура цієї системи проєктувалась як універсальна платформа для дистрибуції, послуг і електронної комерції. Виробничий модуль у ній є, і на демо він виглядає переконливо. Реальні проблеми проявляються через шість, дванадцять, вісімнадцять місяців після впровадження. Тоді, коли мігрувати назад уже надто дорого.

Нижче шість конкретних місць, де архітектурні рішення Odoo створюють приховані витрати і викривлення для складального виробництва. Йдеться про малий і середній бізнес (підприємства з оборотом приблизно від півмільйона до п’ятдесяти мільйонів доларів), де компоненти проходять через виробничі ділянки, де є серійні номери, де клієнт час від часу замовляє виріб у конфігурації, якої немає в каталозі. Виробники дронів, меблів, обладнання, електроніки, спецтехніки — типова аудиторія цього тексту.

Вміст

Виробничий модуль Odoo — один із тридцяти, спроєктованих за одним шаблоном

Odoo пропонує понад тридцять модулів. Виробничий є одним з них. Бухгалтерія, продажі, склад, проєкти, кадровий облік, e-commerce, маркетинг — усі вони побудовані в одній логіці і використовують одну архітектурну рамку.

Для дистриб’юторської компанії це сила. Один продукт замикає всі процеси на одній платформі.

Для складального виробництва це фундаментальна слабкість.

Виробничий модуль Odoo проєктувався командою, яка одночасно проєктувала ще двадцять дев’ять модулів. Глибина, яка потрібна складальному підприємству, не була пріоритетом.

Конкретні приклади того, чого в Odoo або немає, або реалізовано в обмеженій формі:

Зміна креслення в процесі складання. Систему не можна попросити видалити компонент із підтвердженого виробничого замовлення. Тільки додати новий. Старий компонент із нульовим споживанням залишається в системі назавжди, плутаючи операторів і ховаючи реальні витрати.
Реальна потужність ділянок. За замовчуванням Odoo планує з нескінченною потужністю. Це означає, що система складає графік так, ніби всі робочі центри вільні, ігноруючи фактичні обмеження цеху. Документація це підтверджує. Для обходу пропонують купити сторонню надбудову.
Облік собівартості при паралельному складанні. Система розподіляє трудовитрати так, ніби вироби складаються послідовно. У цехах, де кілька операторів одночасно складають різні одиниці однієї партії, це призводить до хибного розподілу вартості праці на одиницю продукції.
Субпідряд між компаніями однієї групи. Стандартний потік субпідряду не формує коректних податкових зобов’язань між юридичними особами. Підприємства змушені налаштовувати фіктивні склади і дзеркальні операції в обхід вбудованого функціоналу.

Усі ці точки або потребують кастомної розробки за десятки тисяч доларів, або обходяться через сторонні модулі від спільноти, або залишаються “сліпими зонами” системи на роки.

Bimp спроєктовано тільки під складальне виробництво

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

Власник, який обирає ERP, має визначити пріоритет. Широкий охват процесів на середній глибині — це Odoo. Спеціалізована глибина в межах виробничого ядра — це нішева виробнича ERP.

Ціна Odoo на сайті — лише вершина того, що ви заплатите

Перший рік на Odoo виглядає прийнятно. Інтегратор показує демо з кількома базовими модулями (виробництво, склад, закупівлі, продажі). Стандартна підписка Odoo Standard коштує близько двадцяти п’яти доларів за користувача на місяць. Тариф Custom з усіма додатками виходить приблизно у шістдесят один долар. Цифри відкриті, виглядають прозоро.

Реальна вартість Odoo складається з чотирьох статей, з яких на сайті видно лише одну.

Стаття перша: модулі. Базової підписки складальному виробництву не вистачить. Для повноцінного виробничого контуру потрібні також модулі управління життєвим циклом продукту, контролю якості, обслуговування обладнання, розширеного планування ресурсів, обліку основних засобів. У світовій практиці впровадження Odoo для виробничого контуру кількість оплачуваних модулів зазвичай досягає п’яти-восьми. Кожен модуль накладається на загальну вартість користувача.

Стаття друга: впровадження. Odoo не публікує ціну впровадження. У більшості випадків його робить сертифікований партнер за погодинною ставкою (у світовій практиці від п’ятдесяти до ста п’ятдесяти доларів за годину). Бюджет проєкту складається з кількості годин, яку партнер заклав на ваш сценарій. Якщо сценарій тривіальний, це двадцять-тридцять годин. Якщо складний, це сто, двісті, тисяча. Реальний бюджет упровадження Odoo для українського складального виробництва малого і середнього розміру коливається в діапазоні від десяти до п’ятдесяти тисяч доларів. Інтегратор, який чесно говорить про повну вартість проєкту на старті, на українському ринку зустрічається рідко. Йому це невигідно комерційно.

Стаття третя: щорічне оновлення. Odoo випускає мажорну версію щорічно. Кожна нова версія може зламати кастомізації, написані під попередню. Документований сценарій з ринку: підприємство впроваджує Odoo з п’ятнадцятьма кастомізаціями. Через рік виходить нова версія. Вісім кастомізацій конфліктують з оновленим ядром і потребують доопрацювання. Три потребують повного перепису. Дві стають непотрібними, бо аналогічний функціонал увійшов у стандарт. Бюджет такого оновлення — близько сорока тисяч доларів і шість тижнів тестування. Щороку.

Стаття четверта: підтримка партнера. Щомісячна або поквартальна плата за супровід системи, без якої будь-яка серйозна зміна потребує годин консультанта за повним тарифом.

Сума цих чотирьох статей за три роки експлуатації може в три-п’ять разів перевищити те, що показав інтегратор у комерційній пропозиції. І найгірше: видимою ця сума стає поступово, коли мігрувати на іншу систему вже дорого.

Bimp працює за іншою моделлю. Одна підписка, яка включає всю функціональність складального виробництва. Впровадження включене в підписку, без партнерів. Оновлення на стороні Bimp, без обвалу кастомізацій клієнта. Підтримка включена. Це не дешевше за рахунок меншої функціональності. Це інша комерційна модель, де вендор бере на себе ризики, які в Odoo лягають на клієнта.

Конфігуратор Odoo не вміє замовне виробництво

У Odoo є механізм варіантів продукту. Він працює, коли виріб має фіксований набір атрибутів. Магазин канцелярії з лінійкою папок різних кольорів і розмірів — задача для варіантів Odoo. Кожна папка має передбачуваний набір атрибутів, і кількість можливих комбінацій кінцева й відома наперед.

Складальне виробництво за замовленням працює інакше.

У дроновому замовленні замовник може попросити іншу батарею, іншу камеру, іншу плату керування, інший корпус. У меблевому — іншу фурнітуру, іншу деревину, іншу обивку, інший спосіб з’єднання. У промисловому обладнанні — практично будь-який компонент. Кожне замовлення породжує унікальну специфікацію, яку неможливо звести до набору фіксованих варіантів, бо нові варіанти з’являються щомісяця разом з новими замовленнями.

Документація Odoo пропонує два варіанти рішення:

Майстер-специфікація з полем “застосувати до варіантів”. Працює, поки кількість варіацій залишається обчислюваною. Як тільки кожен виріб унікальний, поле перетворюється на хаос.
Створення специфікації вручну під кожне замовлення. Менеджер з продажів кожного разу відкриває інтерфейс специфікації, додає рядки, перевіряє наявність компонентів, переглядає планову собівартість. У підприємстві з обсягом понад п’ятдесят замовлень на місяць цей процес стає некерованим. Помилки в специфікації проявляються вже у цеху: не вистачає компонента або в складанні використовуються деталі, яких немає в плановій вартості. Маржа по замовленню перестає відповідати реальній.

Третій варіант, який пропонують партнери, — кастомний конфігуратор від інтегратора. Це окремий проєкт, окремий бюджет і окрема точка ризику при кожному оновленні ядра Odoo. Кастомний конфігуратор переписуватиметься практично на кожній мажорній версії.

Замовне виробництво — це базовий режим роботи більшості українських підприємств цього сегменту. Норма, не виняток. Архітектура, яка обробляє його через ручне редагування специфікацій або кастомну розробку, фактично повертає підприємство до того стану, від якого воно намагалось піти впровадженням ERP. До ручної праці в обхід системи.

У Bimp конфігуратор виробу і специфікації під замовлення працюють з коробки

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

Серійний номер в Odoo не пам’ятає, скільки він коштував

Це місце, де архітектура Odoo стає особливо болючою для виробника, який працює з серіалізованими компонентами. Складальні підприємства (виробники дронів, спецтехніки, медичного обладнання, складної електроніки) використовують серійну ідентифікацію щодня. Сама природа їхньої продукції цього вимагає: гарантійні зобов’язання, простежуваність, регуляторні вимоги, паспортизація виробу.

Логіка Odoo така. Коли система рахує вартість запасу, вона використовує одну з трьох методологій:

Середньозважена вартість. Система рахує середню вартість усіх однакових товарів на складі і використовує її замість фактичної вартості конкретної одиниці.
FIFO (first in, first out). Система спочатку списує найстаріші одиниці на складі, незалежно від того, які з них фізично пішли у виробництво.
Стандартна ціна. Фіксована планова вартість, з якою порівнюється фактична.

Вибір методології відбувається на рівні категорії товару, не на рівні окремої одиниці. Коли у виробництво забирається серійний компонент, система не дивиться на реальну закупівельну вартість саме цієї одиниці. Вона звертається до глобальної логіки категорії і списує середню або найстарішу вартість.

У реальному цеху це виглядає так. Підприємство купує перший двигун за десять тисяч доларів. Через три місяці курс змінився, постачальник підняв ціну, і другий двигун коштує п’ятнадцять тисяч. На складі лежать дві одиниці з різними серійними номерами і різною реальною закупівельною вартістю. Складальник бере другий двигун, сканує серійний номер, ставить у виріб. Виріб закривається. Система записує в собівартість виробу десять тисяч доларів — тобто вартість найстарішої одиниці на складі, а не тієї, яка фізично пішла у складанні.

Наслідки накопичуються в трьох напрямках:

Баланс підприємства перестає відповідати фізичній реальності. На складі залишився перший двигун, але система вважає, що там лежить актив вартістю п’ятнадцять тисяч.
Собівартість при продажі занижена, прибуток штучно завищений, податок переплачений.
Управлінський звіт по маржі конкретного виробу бреше. Власник дивиться на цифру, яка не має відношення до реального руху грошей.

Це не баг, який виправляється в наступній версії Odoo. Документація описує цю поведінку як штатну. Це архітектурний компроміс, прийнятий розробниками для спрощення моделі оцінки запасів. Він прийнятний для дистриб’юторської компанії, де серійні номери виконують роль гарантійного атрибута. Для виробника складної серіалізованої продукції ця архітектура несумісна з реальністю бізнесу.

Модель собівартості Bimp спроєктована від протилежного. Кожен серійний номер тримає власну закупівельну вартість як атрибут самої одиниці. Не похідну від категорії, не середню, не FIFO. Фізична вартість фізичної одиниці залишається з нею від моменту приходування до моменту відвантаження готового виробу клієнту. Управлінська собівартість збігається з фактичним рухом грошей через цех.

Управлінський облік в Odoo — побічний продукт бухгалтерії

Це найглибше архітектурне розходження. Воно стає видимим лише після першого закриття місяця, коли фінансовий контролер виявляє, що управлінська цифра по виробу не сходиться з фактичним рухом грошей через цех.

Odoo побудований навколо бухгалтерського контуру. Кожна операція генерує бухгалтерські проводки. Приходування товару, виробниче замовлення, відвантаження, нарахування зарплати — все це події в головній книзі підприємства. Це класична логіка ERP, успадкована від тої епохи, коли ERP і бухгалтерська система були синонімами. Управлінські звіти в такій архітектурі є похідною від бухгалтерських проводок, відфільтрованою за певними категоріями і періодами.

У стабільному дистриб’юторському бізнесі ця модель працює. Операції прості, статті очевидні, управлінська цифра близька до бухгалтерської. Проблеми починаються у виробництві, де між моментом покупки сировини і моментом продажу готового виробу лежать десятки складних подій: списання компонентів, нарахування праці, розподіл накладних витрат, переоцінка матеріалів, повернення браку, доопрацювання.

Класичний приклад — облік праці. У Odoo вартість праці можна додавати в собівартість виробу через кілька механізмів:

Робочі центри з погодинною ставкою. Дозволяють прив’язати лише одну категорію витрат до робочого центру. Вартість праці і амортизація обладнання зливаються в один потік, який потім важко розкласти назад на компоненти.
Витратний продукт типу “годин роботи” у специфікації. Не генерує автоматичних проводок, накопичує вартість на проміжному рахунку, потребує ручного закриття щомісяця.
Додаткові витрати на закрите виробниче замовлення. Не масштабуються на виробництво з великою кількістю замовлень, бо вимагають окремої операції на кожне.

Поверх цього існує окремий процес у бухгалтерії. Зарплата виробничих робітників нараховується через модуль кадрового обліку і потрапляє у витрати на оплату праці в стандартному обліку. Якщо архітектор системи на впровадженні не побудував складний ланцюжок поглинаючих рахунків (це спеціальний бухгалтерський інструмент, який нейтралізує подвійний облік), та сама вартість праці потрапляє у звіти двічі: один раз як компонент собівартості готової продукції, який потім піде у собівартість реалізації, другий раз як прямі поточні витрати на зарплату.

На звіті про прибутки і збитки це виглядає як штучний колапс маржі.ласник дивиться на P&L і бачить, що бізнес у нього збитковий, хоча гроші є і виробництво працює. Виявлення цього подвійного обліку зазвичай займає кілька місяців і потребує годин зовнішнього аудитора, який знає Odoo на рівні архітектури.

Ця проблема відома сертифікованим бухгалтерам Odoo. Вона вирішується. Вирішення коштує годин фінансового консультанта на впровадженні, написання спеціальних правил у налаштуваннях, регулярних коригувальних проводок наприкінці кожного періоду. Жодне з цих рішень не є частиною стандартної конфігурації Odoo. Кожне з них потребує спеціальної експертизи на старті і дисципліни в експлуатації. Обидва ці ресурси на українському ринку дефіцитні.

Bimp спроєктовано від протилежного. У продукті немає модуля бухгалтерії, і це свідомий архітектурний вибір. Конкретні наслідки цього вибору:

Управлінський облік не є похідним від бухгалтерського. Він основний і єдиний контур.
Бухгалтерія клієнта живе в окремій системі (1С, BAS, M.E.Doc — на вибір клієнта) і інтегрується з Bimp на рівні фактів, без боротьби за один план рахунків.
Ризик подвійного обліку праці виключений архітектурно, бо немає двох конкуруючих контурів, які боролися б за пріоритет.
Управлінська собівартість залишається чистою, без щомісячних коригувальних маневрів.

Цей підхід має своє обмеження. Для підприємства, яке хоче замкнути всі контури (управлінський, бухгалтерський, кадровий, продажний, маркетинговий) в одній системі, відсутність бухгалтерії в Bimp читається як недолік. Для власника складального підприємства, який передусім хоче бачити реальну маржу по виробу, замовленню, клієнту, та сама відсутність читається як архітектурне рішення на користь чистоти управлінських цифр.

Українська локалізація Odoo — мозаїка від десятка незалежних розробників

Останнє розходження стосується специфіки України. Локалізація Odoo для українського ринку не є цілісним продуктом, написаним однією командою. Це сукупність окремих модулів від різних розробників, написаних у різний час під різні версії Odoo.

Хто що покриває:

Одна команда — податкову систему
Інша — кодифікатор УКТЗЕД
Третя — формати документів первинного обліку
Четверта — облік для ФОП
П’ята — інтеграцію з банками
Шоста — електронний документообіг
І так далі

Кожен модуль має власний цикл оновлень, власний рівень підтримки, власну сумісність з ядром Odoo.

При щорічному оновленні Odoo виникає лотерея сумісності. Чи всі локалізаційні модулі вже вийшли в новій версії. Чи вони сумісні між собою. Чи не зламались інтеграції між ними і між ними та ядром. Партнер може закрити цю проблему, але за рахунок додаткового часу на тестування і часто за рахунок свого ресурсу як проміжного інтегратора між кількома локалізаційними командами.

Це не недогляд локалізаторів. Це наслідок того, як архітектурно влаштований Odoo. Платформа проєктувалась у Бельгії як глобальний продукт, локалізації добудовуються спільнотою в кожній країні після того, як ядро вже сформоване. Підхід працює добре в країнах з великим ринком, стабільним правовим середовищем і потужною партнерською мережею. В Україні, де законодавство змінюється раз на півроку і де партнерська екосистема Odoo помітно вужча за бельгійську чи німецьку, мозаїчна локалізація створює постійну точку нестабільності.

Bimp не несе цього навантаження з двох причин одночасно. По-перше, більшість того, що в Odoo вимагає окремих локалізаційних модулів — податкова система, облік ФОП, банківські інтеграції, ЄДРПОУ-реєстри — у Bimp взагалі немає в продукті, бо немає бухгалтерського контуру. Усе це лежить у бухгалтерській системі клієнта (1С, BAS, M.E.Doc на вибір), яка інтегрується з Bimp на рівні фактів.
По-друге, те, що Bimp дійсно мусить локалізувати — формати первинних документів складального виробництва, кодифікатори матеріалів, специфіку обліку серійних компонентів — є частиною ядра продукту, не окремих модулів. Зміни тут потрапляють у Bimp одним релізом, без лотереї сумісності між десятком сторонніх розробників.

Висновок: архітектура має значення!

Усі шість пунктів вище мають однакову природу. Це не баги Odoo. Це не недоліки конкретного інтегратора. Це архітектурні рішення Odoo, прийняті в певному контексті, які добре працюють для одних типів бізнесу і погано для інших.

Тип бізнесу, для якого ці рішення створюють приховані витрати і викривлення в управлінському обліку, це складальне виробництво з серійними номерами, замовним характером і нелінійним цеховим процесом. Виробники дронів, меблів, обладнання, електроніки, спецтехніки. Малий і середній бізнес, де ERP має закривати реальні виробничі процеси, а не імітувати їх через ручні обхідні шляхи.

Власник, який зараз веде переговори з інтегратором Odoo, може зробити кілька конкретних речей до підписання договору:

Поставити інтегратору шість питань з початку цього тексту і вимагати конкретних відповідей, без узагальнень про модульність і гнучкість.
Запитати про повну вартість володіння системою за три роки, з урахуванням усіх модулів, впровадження, щорічних оновлень і підтримки партнера.
Перевірити, скільки часу і грошей пішло на впровадження у двох-трьох інших підприємств того самого розміру і профілю.
Запитати, що відбувається при мажорному оновленні з кастомізаціями, написаними під попередню версію, і яким буде бюджет цього оновлення.

Інтегратор, який не може відповісти конкретно або переводить розмову на узагальнення, вже відповів.

Складальному виробництву потрібна ERP, спроєктована саме під нього. Bimp — це той випадок, коли вузька спеціалізація продукту є його головною комерційною перевагою. Чим вужче архітектурне фокусування ERP на типі бізнесу клієнта, тим менше прихованих ризиків клієнт принесе додому. Демо Odoo цього не покаже. Перевірити це можна тільки до підписання договору.

Post Views: 54