Як Odoo масштабує виробництво БпЛА та зберігає контроль над специфікацією з 254 позицій

Чому виникла потреба у змінах? 

Команда Angel Aerial Systems працювала з набором розрізнених інструментів, і кожен містив лише частину достовірної інформації. Комерційні пропозиції створювали у шаблоні Word, номери пропозицій присвоювали вручну. Договори відстежували в таблиці, а контакти зберігали в HubSpot, який майже не використовували.

Бухгалтерію та оплату рахунків вели в QuickBooks Online, а дані для розрахунку заробітної плати вручну вивантажували з окремого сервісу. Попередню спробу впровадити безкоштовний MRP-інструмент припинили. Причина була не в недоліках самого рішення: його запровадили зарано, коли компанія ще не була до нього готова.

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

"Я хочу, щоб саме в Odoo ми шукали свою інформацію",  — зазначив представник компанії.

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

Який підхід до впровадження ми обрали?

Спочатку ми розгорнули стандартну збірку Odoo за одним принципом:

• готова функціональність, де вона вже є;
• Odoo Studio, коли потрібно лише змінити поле чи форму;
• кастомна розробка тільки там, де стандартна модель справді не може відобразити процес.

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

Друге рішення полягало в тому, щоб будувати систему разом із клієнтом, а потім передати йому щоденне керування. Ми перетворили вимоги на налаштовані процеси для продажів, закупівель, виробництва, складу, обліку витрат на R&D та роботи цеху. Команда тим часом навчалася на практиці, відпрацьовувала навички між сесіями і вивчала систему на реальних виробах і замовленнях.

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

Що відкладено на наступний етап?

Не все, що заслуговувало на увагу, вдалося реалізувати одразу. Команда невелика, часу небагато, тому клієнт віддав пріоритет операційним процесам, потрібним для виконання замовлень. Фінансовий облік, оплата рахунків та звітність наразі залишаються в QuickBooks Online.

Ми підготували й задокументували основу для подальшого впровадження Odoo, зокрема локалізацію для США, план рахунків на основі експорту з QuickBooks та модель оцінки запасів, щоб згодом облік можна було перенести без складнощів.

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

Читайте більше про Централізований облік для групи компаній Reface на базі Odoo з “Обліком для України”

З яких кроків складалося впровадження? 

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

Модель даних про продукти і багаторівнева специфікація (BOM)

Ми побудували повну модель даних про продукти та перетворили специфікацію дрона на повноцінну ієрархію в Odoo.

1. Категорії продуктів. Ми розділили сировину, закуплені компоненти, деталі власного виробництва, вузли та готові вироби. Для кожної категорії задали власні одиниці виміру та метод розрахунку собівартості.
2. Номер деталі (Part Number). Поле “Референс” ми перейменували на “Номер деталі” та свідомо залишили його для ручного введення, оскільки в компанії вже була перевірена система нумерації.
3. Атрибути для електроніки. За допомогою Odoo Studio ми додали поля, потрібні інженерам-електрикам для роботи з компонентами. Вони відображаються лише в тих категоріях, до яких стосуються.
4. Багаторівнева специфікація. Специфікацію дрона перебудовано в справжню ієрархію: готовий виріб, вузли, вкладені підвузли та компоненти.
5. Внесення даних. Дані про механічні деталі інженери вносили самостійно, а дані про електроніку та друковані плати підготували окремо для імпорту.
6. Контроль інженерних змін. Зміни вносять або прямим редагуванням із записом у журналі повідомлень, або через формальний запит на зміну з повною історією версій, якщо причина змін принципово важлива.

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

Виробництво та закупівлі на основі попиту

Наступний етап стосувався виробництва та специфікацій. Головне завдання полягало в тому, щоб система автоматично розраховувала, що і коли потрібно виготовити чи закупити, а не покладалася на ручні розрахунки за специфікацією з 254 рядків.

• Підтвердження замовлення на продаж розгортає все дерево специфікації й автоматично створює потрібний документ для кожної позиції: виробниче замовлення для деталей власного виготовлення, запит цінової пропозиції (RFQ) для закуповуваних позицій і нічого для тих, що вже є на складі. Дрони виготовляють під замовлення, а запчастини, як-от акумуляторні блоки, тримають на складі за правилами поповнення з мінімальним і максимальним рівнем.
• Закупівлі відтворюють реальний процес роботи з постачальниками: RFQ, замовлення постачальнику з умовами компанії на друкованому шаблоні, приймання товару та рахунок постачальника, де колонка зі знижкою з'являється лише тоді, коли знижка застосовується. Виробничі замовлення на одну й ту саму деталь із різних замовлень на продаж можна об'єднувати в одне з пропорційним перерахунком строку виконання.
• Субпідряд працює за стандартним процесом Odoo. Компоненти передають підряднику, а готові деталі повертаються через замовлення постачальнику. Завдяки доступу через портал підрядник бачить потрібні документи та статус робіт без внутрішнього облікового запису.
• Один виняток вимагав кастомної розробки. Оскільки кілька конструктивних деталей друкують разом на одній платформі, реальною одиницею виробництва є платформа, а не деталь. Правило автоматизації консолідує потребу в друкованих деталях у замовлення на платформи: збільшує кількість в наявному замовленні або створює нове, зберігаючи зв'язок із вихідним замовленням.

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

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

Виконання та облік на виробничій дільниці

Далі потрібно було перенести реальний виробничий потік у систему, не спотворюючи того, як насправді працює цех.

Робочі центри змоделювали відповідно до фактичного планування виробництва: видалення підтримок, виготовлення джгутів, складання плат і фінальне складання. Оператори входять у застосунок “Цех” на спільному планшеті за персональними PIN-кодами зі своїх профілів працівників, а не через окремі внутрішні облікові записи. Тривалість робочих операцій відстежують у порівнянні запланованого й фактичного часу, тож план відповідає реальності, а не навпаки.

Розділення машинного часу та часу оператора може здатися дрібницею, але насправді вона має значення. Робочий центр 3D-принтера має нульову погодинну вартість, а коротка дія оператора коштує за реальною ставкою, тому собівартість друкованої деталі відображає спожиту працю, а не безперервну роботу машини.

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

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

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

Витрати на R&D окремо від собівартості продукту

Кожна нова модель дрона ведеться як окремий проєкт в Odoo з власними етапами, завданнями та рахунком витрат. Компоненти, використані в розробці, списують через спеціальну локацію R&D і відносять на рахунок витрат проєкту. Це забезпечує прозорість як на рівні проєкту, так і на рівні фінансової звітності. Питання, капіталізувати ці витрати чи відображати їх як поточні, залишається в межах облікової політики компанії. Замовлення постачальникам можна прив'язати до проєкту під час створення або пізніше.

Ми встановили й задокументували одне правило: витрати фіксуються один раз, або через закупівлю, або через переміщення запасів, але ніколи двічі. Усі витрати проєкту відображаються в єдиному списку з кількістю, сумою за рядком і загальною вартістю проєкту.

Чому це важливо: Для стартапу, який розробляє обладнання, дослідження і розробки зазвичай належать до найбільших статей витрат. Якщо змішати їх із собівартістю виготовленої продукції, спотворюються обидва показники: маржа продукту виглядає гіршою, а R&D здається дешевшим, ніж є насправді. Розділення на етапі споживання компонентів дає компанії зрозумілу операційну картину витрат на R&D, і відновлювати її вручну за бухгалтерськими записами не потрібно.

Собівартість продукту на основі фактичних подій

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

Чому це важливо: Розрахунок собівартості надійний настільки, наскільки надійні дані, на яких він ґрунтується. Коли вартість компонентів визначається фактичними закупівлями, а вартість складання відповідає реальним виробничим операціям, компанія може встановити ціну одиниці без здогадок і точно побачити, яка зміна конструкції подорожчала дрон. Ця перевага зберігається незалежно від того, чи веде компанія головну книгу в Odoo, тому впроваджувати її до остаточного вирішення питання з обліком не було сенсу.

Також рекомендуємо ознайомитися з кейсом Як виробник дронів перейшов від ручного обліку до регульованого виробництва з Odoo

Що змінилося після впровадження Odoo? 

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

Рішення впроваджено для 5 користувачів Odoo в 7 операційних напрямах (CRM, продажі, закупівлі, склад, виробництво, цех і облік витрат на R&D) зі багаторівневою специфікацією з 254 рядків і одним кастомним правилом автоматизації. Впровадження трималося близько до стандартної функціональності Odoo, а обсяг робіт відповідав реальним можливостям стартапу на цьому етапі.

Ключові висновки

Проєкт дав Angel п'ять операційних можливостей для наступного етапу зростання:

1. Єдине джерело достовірної інформації про склад і структуру виробів.
2. Потреба, що формується автоматично із замовлень клієнтів, без ручного планування.
3. Виробнича собівартість, яка витримує перевірку.
4. Витрати на R&D, виділені в окрему статтю.
5. Простежуваність саме там, де вона окупається.

Тепер Angel самостійно працює із системою й розширює її та звертається до Self-ERP лише тоді, коли потрібна додаткова експертиза.

Наостанок

Коли наш клієнт отримав перше замовлення, компанія опинилася в нетиповій ситуації: інженерна команда вже оперувала готовими до використання даними, а операційна ще ні.

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

Сьогодні виробнику не потрібна зовнішня команда, щоб підтримувати роботу системи. Він керує нею самостійно, спираючись на власні вимоги, а Self-ERP залишається поруч рівно настільки, наскільки це потрібно.