Defense-специфіка

L1 · Ремісниче

Серійники — це табличка в Excel: готові вироби з датою. Зв'язку з лотами компонентів немає. На запит «з якої партії батареї в дроні №X» відповіді не буде.

Приклад: Армія повертає 8 дронів зі схожою несправністю. Питає: спільна партія батарей? Дивимось у файл — бачимо лише дату виробництва (3–7 березня). Які саме батареї стояли, не знаємо. Готуємо «компенсацію» на 80 дронів, бо вибірково замінити не можемо.

⚠ Defense-замовники припиняють співпрацю. Втрата контрактів на 5–50 млн UAH. Замість заміни однієї партії за 200k — заміна на 2 млн.

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

Лоти компонентів ведуться в BAS, серіали ГП — теж. Але зв'язок між ними частковий: через дату списання матеріалів. Якщо одного дня списали лоти A і B на 100 виробів, у які саме вони пішли — невідомо.

Приклад: Дрон №1234 виготовлений 15 березня. 14–15 березня на виробництво списали 80 батарей з 3 лотів (L1: 30, L2: 35, L3: 15). У дроні №1234 стоїть батарея з одного з цих лотів — але з якого саме, невідомо.

⚠ Часткова відповідь на запит МО для повноцінного root cause аналізу не годиться. Постачальник відповідає лише частково.

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

Повний ланцюжок в Odoo: компонент → лот постачальника → партія приймання → виробниче замовлення → серіал ГП → клієнт → контракт. Кожна одиниця готового виробу має повне дерево походження, доступне за 30 секунд. Трасабіліті в обидва боки — зворотна і пряма.

Приклад: Дрон №D-2026-1234 → повне дерево за 18 секунд: батарея LiPo лот L-2026-02-156 (постачальник ТОВ Енерджі, договір №42, прибуття 2026-02-15, QC passed 2026-02-16). Контролер STM32F407 лот STM-2026-Q1-089 (постачальник DigiKey через ТОВ Імпорт, договір №38, прибуття 2026-01-22). Решта 14 критичних компонентів — теж з повними джерелами. Збирав Петренко 2026-03-15, зміна 2, дільниця ASM-1. QC: Сидоров, passed all 23 checks. Контракт А-2026-42 МО, відвантажено 2026-03-20 на склад 25 ОДШБр.

L1 · Ремісниче

В обліку контракти не розрізняються. Усі продажі лягають на 70 рахунок гуртом. Маржа за контрактом невідома — її прикидають на око вже після завершення.

Приклад: Виконали контракт МО на 50 дронів за 8 млн UAH. Прибутковий він чи ні — довести не вдалося: усе змішано з ще 5 контрактами і 200 комерційними продажами. «Загалом за місяць маржа 22%» — і все.

⚠ Збиткові контракти беруть знову і знову. Системну помилку в ціноутворенні так і не видно.

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

Контракти лежать в окремих папках на сервері або у файлах. У BAS «договір» може бути атрибутом продажу, але без аналітики за витратами. P&L за контрактом рахують раз на квартал в Excel.

Приклад: Контракт А-2026-42 МО на 50 дронів, 8 млн UAH. Прямі витрати — 5.2 млн (за BAS). ЗВВ розподілені пропорційно — 1.1 млн (за розрахунком CFO в Excel). Чистий P&L — 1.7 млн UAH, тобто 21%. Точність — ±5%.

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

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

Кожен контракт — це analytic account в Odoo. Усі витрати, прямі й непрямі, розподіляються на контракт автоматично. P&L у real-time. Прогноз: за поточними даними — який буде результат на завершенні. Маржу контролюють ще на етапі pricing, до підписання.

Приклад: Контракт А-2026-42 МО: дашборд CFO у real-time. Виручка: 8 млн UAH (з них 30% передоплати отримано). Прямі витрати: 5.18 млн (на 60% виконання — на плані). ЗВВ: 0.92 млн (трохи нижче за прогноз). Прогноз на завершення: маржа 23.4% (план 20%). О 10:00 CFO дзвонить CEO з гарними новинами.

L1 · Ремісниче

EUC — паперові документи в шафі юриста. Кожен контракт — окремий комплект. Доступ обмежений. Загубили документ — на запит показати нічого.

Приклад: На перевірці ДСЕКУ інспектор просить EUC за контрактом з ОАЕ 2024 року. Юрист пригадує, що документ «начебто в архіві». Три години пошуку — і знайшли.

⚠ Бракує EUC на перевірці — дозвіл ДСЕКУ призупиняють. Експортувати більше не можна.

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

Скани EUC лежать у Google Drive або на файловому сервері, в папках за роками і контрактами. Упорядковано, але з продажами в обліку не пов'язано.

Приклад: EUC за контрактом А-2026-42 лежить у папці «/EUC/2026/04_April/А-2026-42_MO_EUC.pdf». Знаходиться за 5–10 хвилин.

⚠ Змінилася структура папок чи відповідальний — і все розсипається. З обліком продажів не пов'язано.

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

EUC зберігається в Odoo як attachment до sale.order і до окремого об'єкта «Defense Contract». Прив'язаний до клієнта, контракту, тендера. Доступ — за ролями. Немає EUC — система не дасть створити sale.order для defense-контракту.

Приклад: Контракт А-2026-42 МО: при створенні sale.order Odoo вимагає EUC. Менеджер завантажує EUC.pdf. Система звіряє дату, підписи, контрагента — усе ОК. Sale.order підтверджено. Через 6 місяців на запит ДСЕКУ EUC відкривається за 5 секунд з повною історією.

L1 · Ремісниче

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

Приклад: Контракт на експорт 100 дронів до Польщі підписали 1 квітня, термін поставки — 15 травня. Заявку в ДСЕКУ подали 20 квітня, дозвіл отримали 10 травня. А хто помітив би, якби подати забули? Ніхто — аж до митного оформлення.

⚠ Кримінальна стаття за ст. 333 КК України (порушення порядку експортного контролю). Кримінальна відповідальність керівництва — від 2 до 10 років позбавлення волі.

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

Дозволи ДСЕКУ ведуть у реєстрі в Excel. Перед відвантаженням звіряють вручну. Уся гарантія від помилки — слово співробітника.

Приклад: Менеджер: «Юра, дозвіл за контрактом А-2026-42 чинний?» — Юрист: «Зараз гляну… так, до 30 червня». Відвантажуємо. Через 2 тижні з'ясовується: дозвіл на 90 одиниць, а ми відвантажили 95. Формальне порушення.

⚠ Залишковий ризик кримінальної відповідальності через людський фактор.

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

Системне блокування в Odoo: кожен defense-product має поле «Export Control Status», прив'язане до активного дозволу ДСЕКУ. Немає активного дозволу — sale.order не підтвердиш, delivery order не виконаєш. Сам дозвіл — це об'єкт в Odoo з датою початку й кінця, обсягом і географією.

Приклад: Менеджер створює sale.order на 95 дронів до Польщі. Odoo звіряє: дозвіл DSEKU-2026-018 — 90 одиниць до Польщі, чинний до 2026-06-30. 95 > 90 — БЛОК. Повідомлення: «Перевищення обсягу. Розширте дозвіл до 95 одиниць або розбийте на 2 етапи». Менеджер запускає розширення дозволу — без нього відвантажити неможливо. Кримінальну статтю система відвернула на корені.

L1 · Ремісниче

Рекламацій не реєструють. Повернув клієнт виріб — переробили, без розбору. Брак списали.

Приклад: За рік повернули 23 дрони. Що з ними сталося — невідомо. Може, в усіх одна бракована партія батарей? Не знаємо.

⚠ Системні проблеми не лікуються, тож повторюються. Клієнти втрачають довіру.

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

Реєстр рекламацій в Excel. Поля: дата, клієнт, виріб, проблема, рішення. Зв'язку з компонентами немає. Статистика часткова — за моделями, не за лотами.

Приклад: Дрон моделі Р-3 — 15 рекламацій за квартал. Чому? Не знаємо. Скидається на «природний відсоток».

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

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

Повне дерево рекламацій в Odoo Helpdesk + Quality + Inventory. Кожна рекламація має серіал виробу, а від нього — повне дерево компонентів. Аналітика зіставляє рекламації з лотами, постачальниками, дільницями, змінами виробництва. Система сама виловлює patterns.

Приклад: Дашборд QA, «Кореляція рекламацій з лотами»: партія акумуляторів L-2026-02-156 — 11 рекламацій із 23 за квартал. 48% рекламацій — з одного лоту. Система попереджає автоматично. Перевіряємо ще не використані 200 одиниць — справді брак. Повертаємо постачальнику з повним доказом. Замість «непрозорих 5% браку» — точна причина і компенсація.