Виробництво

L1 · Ремісниче

Специфікація живе в голові майстра або в Excel-файлі на ноутбуці. Версій немає; коли змінюється конструкція, старий і новий BOM ходять паралельно.

Приклад: Виробляємо 3 моделі дрона, у кожній по 80-120 компонентів, але хтось пише BOM в Excel, хтось у Notion, хтось — на роздрукованому аркуші зі змінами на полях.

⚠ Понаднормативний брак не спіймати, бо немає еталонної норми витрат. Собівартість одиниці — приблизна.

L2 · Стандартизоване

BOM лежить в окремому файлі (Excel/Google Sheets) або в модулі BAS. Версії контролюють, але слабко — переважно через дату в назві файлу. Зміни вносять, але до виробничої зміни вони доходять із запізненням.

Приклад: У BAS заведено номенклатуру з нормативами, але багаторівневі підвузли роздуто на верхньому рівні — виглядає як 200-позиційна плоска специфікація замість 4-рівневої.

⚠ Щоб змінити один компонент, BOM треба руками оновити в усіх продуктах, де він стоїть. Помилки неминучі.

L3 · Інтегроване

BOM — повноцінний об'єкт Odoo MRP: багаторівневі специфікації, alternative-компоненти, версії з датою введення в дію. Зміна компонента запускає engineering change order і автоматично оновлює всі дочірні специфікації.

Приклад: Для дрона моделі Р-3, ревізія v3.4 від 2026-04-15, дозволено заміну батареї X на Y, якщо X немає в наявності. Виробництво саме обирає правильний варіант під поточний залишок.

⚠ Ризик слабшає, але зміщується в площину налаштування — складна BOM-структура потребує MRP-інженера, а не лише бухгалтера.

L1 · Ремісниче

Виробництво планують усно або в чаті. Замовлення оформляють актом постфактум, коли продукція вже на складі. Облік іде заднім числом.

⚠ НЗВ на рахунку 23 — фікція. Реальної собівартості не знає ніхто.

L2 · Стандартизоване

Виробничі замовлення оформляють у BAS, але без зв'язку зі складом і витратами. Матеріали списують окремою операцією, часто із затримкою. Стан НЗВ — наближення.

Приклад: MO відкрито в BAS 1-го березня, фактично закрито 25-го, матеріали списано 28-го. У звіті за лютий усе одно вилазить.

⚠ Інвентаризаційні розбіжності важко довести — паперовий слід нечіткий.

L3 · Інтегроване

MO в Odoo MRP — це повний документ: резервування компонентів, фактичне списання на початку зміни (Manufacturing → Consume), оприбуткування ГП у мить виконання операції. НЗВ оновлюється в реальному часі. Видно, що просто зараз роблять на дільниці №3.

Приклад: MO M-2026-1102 на 50 дронів. Зарезервовано 600 батарей зі складу №1. Коли майстер фіксує операцію «Збирання», система автоматично пише Д 23 / К 201 на ці батареї.

L1 · Ремісниче

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

Приклад: Клієнт повертає дрон з претензією — а ми не можемо швидко відповісти: з якої партії батареї? коли вироблений? хто збирав?

⚠ Рекламації проходять без аналізу root cause. Якість системно не покращується.

L2 · Стандартизоване

BAS веде серійники як атрибут номенклатури, але без зв'язку з конкретними партіями вхідних компонентів. Трасабельність часткова — від готового виробу до накладної постачання, але не до конкретного компонента.

⚠ На запит ДПС чи армії — лише часткова відповідь, наполовину доказова.

L3 · Інтегроване

Кожен компонент має lot/serial, кожне виробниче замовлення в Odoo прив'язує конкретні лоти до конкретних серійників ГП. За 30 секунд будуєте дерево: дрон №1234 → батарея з партії 2026-02-15 від ТОВ Х → закуплена за договором №54.

Приклад: Армія повідомляє про систематичну несправність у партії зі 100 дронів — за 5 хвилин знаходимо винуватця: одна партія мікроконтролерів від постачальника, що потрапила у 8 серій. Замінюємо точково.

L1 · Ремісниче

Собівартість — це сума витрат за місяць, поділена на кількість виробленого. Не за продуктом, не за серією. Загальновиробничі витрати або не виділяють, або кидають на «загальний рахунок».

⚠ Управлінського рішення за рентабельністю продукту не ухвалити. Тариф на оборонну продукцію може не покривати собівартість.

L2 · Стандартизоване

BAS рахує собівартість за нормативами, але ЗВВ розподіляє раз на місяць, без зв'язку з реальними машино-годинами. Аналітика за продуктами є, але неточна.

Приклад: Звіт «Собівартість» виходить 5-го числа наступного місяця, на 7-й день закриваємо.

L3 · Інтегроване

Odoo з Oblik-ERP розподіляє ЗВВ через аналітичні рахунки на основі реальних timesheet-ів робітників і machine-hours. Собівартість оновлюється в реальному часі. Видно маржу за конкретним продуктом, клієнтом, контрактом.

Приклад: За оборонним контрактом А-1234 (200 дронів) маржа 18% — на 4 пункти нижче за середню по компанії. З'ясовуємо чому: матеріальна частина — як планували, але переробок через QA на 12% більше.

L1 · Ремісниче

Якість майстер контролює «на око». Браковані вироби або мовчки переробляють, або викидають без обліку.

⚠ Брак в обліку не видно → собівартість занижена, а рентабельність насправді гірша. ПДВ на понаднормативний брак не нараховують.

L2 · Стандартизоване

Акти браку є, але з MO не пов'язані. Контроль ВТК — на словах. Брак списують гуртом раз на місяць.

L3 · Інтегроване

Quality module в Odoo вбудований у виробничий процес. Перед закриттям MO — обов'язкові QA-чекпойнти. Брак фіксується за серією, з причиною та винуватцем, і за нормативом автоматично йде на 947 або 91. ПЗ за ПКУ 198.5 нараховуються автоматично.

Приклад: MO на 100 дронів. На QA-stage 73 проходять, 27 — браковані. Із них 8 — у межах норми (5% за наказом), 19 — понаднормативно. Система сама виставляє ПН на себе на 19 × вартість матеріалу.