Український ринок БпЛА росте швидше за системи управління: чому облік стає критичною технологією
Мене звати Дмитро Обухов, я — CEO Bimp, виробничої ERP-системи для українських підприємств малого і середнього бізнесу — від виробників дронів до підприємств харчової і медичної промисловості. Маю понад 18 років досвіду в автоматизації виробничих процесів.
Коли ми в Bimp почали працювати з виробниками дронів, то перше, що впало в очі, — це не відсутність обліку (бо він був майже у всіх), а те, що він будувався для попереднього розміру компанії. Та версія виробника, яка збирала 200 бортів на місяць, мала одні інструменти. І та, яка виросла до 2000, — ті самі. Це і є точка, де починається справжній розрив.
Ринок виріс, але проблема не в обсязі, а в архітектурі
Ринок оборонних технологій України у 2025 році досяг $6,8 млрд. Сегмент БпЛА — $6,3 млрд. Наземні роботизовані комплекси показали зростання у шість разів за рік до $252 млн. Системи РЕБ — $220 млн, що утричі більше, ніж роком раніше. Це дані KSE Institute, Brave1 і Defence Builder.
Але за цифрами важливіша структурна зміна. Ринок більше не складається з виробників одного продукту. Він складається з виробників систем: дрон без навігації, захищеної від РЕБ, функціонально неповний. Дрон із непідтвердженою якістю кожного вузла — те, що неможливо відтворити серійно.
Тож зараз компанії ламаються не тому, що виробляють замало, а бо їхня система обліку будувалась під інший ринок.
Де саме виникає злам
Я бачу цей патерн регулярно, і він проявляється у кількох місцях.
Склад. Компанія закуповує один і той самий компонент у трьох постачальників за різними цінами і з різною якістю. У системі вони під однією позицією. Коли приходить рекламація, то невідомо, з якої партії борт. А коли змінюється постачальник, то незрозуміло, як це вплинуло на собівартість конкретної партії.
Версійність виробу. Дрон змінюється кожні два-три місяці: новий контролер, інший стек, змінений профіль прошивки. Якщо система не фіксує ці зміни як окремі версії структури виробу, виробник не може довести, що борт № 4721 відповідає специфікації, яку він узгодив із замовником у лютому.
Мультивалютна собівартість. Компоненти купуються за долари і євро, іноді за юані. Логістика, митниця і банківська конвертація рознесені в часі. Якщо система не абсорбує ці витрати в собівартість конкретної партії в момент транзакції, фінансова картина запізнюється на тижні. Рішення ухвалюються на основі даних, які вже не відображають реальності.
Жодна з цих точок є проблемою не обсягу, а архітектури обліку.
Що відбудеться з ринком за рік-півтора
Деякі зміни вже відбуваються, і кожна з них безпосередньо підвищує вимоги до глибини обліку.
Навігація без GPS стає базовою вимогою. Оптична одометрія (метод визначення положення, швидкості та переміщення рухомого об’єкта), інерційні системи, орієнтування за радіомаяками — кожен із цих підходів додає в конструкцію нові критичні компоненти з вузькою специфікацією. Коли навігаційний модуль перестає бути набором деталей і стає системою наведення, виробнику вже недостатньо знати модель компонента. Потрібна точна партія, постачальник і версія прошивки кожного конкретного борту.
Алгоритми на борту ускладнюють виріб до рівня, де ручний контроль версій стає фізично неможливим. Адже система розпізнавання цілей — це не один файл прошивки, а комбінація апаратної платформи, версії нейромережевої моделі, параметрів калібрування і датасету. Кожен борт потенційно із власним профілем. Облікова система, яка не вміє вести цю глибину, стає слабкою ланкою у контролі якості саме тоді, коли контроль найбільш важливий.
Сертифікація і кооперація вийдуть на перший план. Виробники інтегруватимуться у глобальні ланцюги постачання. Стандарти на кшталт MIL-STD-810H, як підтвердження надійності в умовах вібрації, температурних перепадів та електромагнітних перешкод, стануть базовою кваліфікаційною вимогою. Виробник без наскрізної трасованості від закупівлі до відвантаження не пройде кваліфікацію субпідрядника для жодного міжнародного партнера незалежно від якості самого продукту.
Вирішуватиме архітектура, а не функціонал. Більшість облікових систем будуються за принципом «додати функцію під запит». Клієнт попросив серійні номери — додали поле; мультивалюту — додали конвертацію; версійність — додали вкладку.
Результат передбачуваний: латане поверх латаного. Система, яка реально справляється з тим, що описано вище, має іншу основу: кожна транзакція прив’язана до конкретного виробу, а не до партії. Кожен компонент має трасовану історію від постачальника до збірки. Кожна зміна специфікації фіксується як подія, не перезаписуючи попередню версію, а додаючи до неї.
Це рішення не можна допилити пізніше. Якщо воно не закладене на рівні моделі даних, перебудувати можна тільки з нуля.
А компанії, які зараз закладають правильну архітектуру, отримують не просто порядок у даних, а здатність довести якість кожного виробу інвестору, партнеру чи замовнику за кілька хвилин, а не за кілька днів аудиту. Як і здатність локалізувати дефектну партію без зупинки виробництва або вийти на кооперацію з міжнародними партнерами без болісного запитання: «А де у вас серійні номери?».
Ринок виробництва дронів проходить ту саму точку, яку аерокосмічна галузь пройшла кілька десятиліть тому: від виробництва як ремесла до виробництва як інженерної дисципліни зі стандартами, документуванням і повною трасовістю кожного компонента.
За кілька років конкурентною перевагою буде не лише здатність виробити дрон, а й довести походження, склад і повну історію кожного виробу, а також зробити це швидко, без підготовки до аудиту за тиждень до нього.
6 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівТак, це аналітика статі від ШІ, та заодно корисна вправа по формуванню прмоптів. Так щоб не дуже заморочно було. Відповідь недосконала. Третій фрагмент, схоже, ШІшка не потягнула, впринципі автор і сам залишив «простір для фантазії». Але загалом, зачеплені ті самі «проблеми» в які б і я потикав пальцем. Бо знаю домен.
📌 [«Та версія виробника, яка збирала 200 бортів на місяць... І та, яка виросла до 2000, — ті самі [інструменти обліку]»]
* 🔴 КРИТИКА / ОБМЕЖЕННЯ: Автор розглядає масштабування суто як проблему «архітектури даних», повністю ігноруючи фізичні обмеження складської логістики та людського фактора. Стрибок з 200 до 2000 виробів на місяць — це не просто збільшення кількість рядків у базі даних ERP. Це фізичне «вузьке місце» (bottleneck): потреба вдесятеро більших площах зберігання, жорсткі ліміти пропускної спроможності зон приймання/видачі, а головне — критична залежність від низькокваліфікованого персоналу складів. Жодна ідеальна ERP-архітектура не завадить комірнику переплутати візуально ідентичні плати різних версій, якщо процеси не підкріплені фізичними бар’єрами (WMS, конвеєри, автоматизована інспекція).
* ➔ «SO WHAT?» (НАСЛІДКИ): Фокус лише на програмній архітектурі призводить до ілюзії контролю. На практиці, навіть із впровадженою ERP-системою, виробництва стикаються з «паперовим колапсом» на етапі первинного внесення даних. Без перебудови фізичної топології складу та автоматизації зчитування (RFID/QR-кодування в реальному часі) «ідеальна модель даних» заповнюватиметься згенерованим людиною сміттям (GIGO — Garbage In, Garbage Out), що лише прискорить злам системи.
---
📌 [«Якщо система не абсорбує ці витрати в собівартість конкретної партії в момент транзакції, фінансова картина запізнюється на тижні.»]
* 🔴 КРИТИКА / ОБМЕЖЕННЯ: Вимога розрахунку мультивалютної собівартості «в момент транзакції» в умовах реальної транскордонної логістики є математичною та юридичною утопією. Автор ігнорує часові лаги, які неможливо усунути програмуванням: митне очищення, додаткові збори, коливання курсів валют на дату розмитнення (а не оплати), відстрочені рахунки за брокерські послуги чи рекламації. Фінансова картина фізично не може бути остаточною в секунду перетину кордону компонентом, оскільки повний пул витрат формується нерівномірно.
* ➔ «SO WHAT?» (НАСЛІДКИ): Намагання примусово «абсорбувати» незавершені витрати в момент транзакції змушує систему працювати на основі планових або розрахункових (віртуальних) показників. Це створює прихований ризик: управлінські рішення ухвалюються на базі красивих, але фіктивних цифр «у реальному часі», що веде до касових розривів, коли реальні акти виконаних робіт від логістів нарешті наздоганяють облік за підсумками місяця.
---
📌 [«Облікова система, яка не вміє вести цю глибину [версії нейромереж, датасети, калібрування], стає слабкою ланкою»]
* 🔴 КРИТИКА / ОБМЕЖЕННЯ: Автор намагається натягнути класичну виробничу ERP на стек керування програмним забезпеченням (DevOps/MLOps). База даних ERP-системи фізично й архітектурно не пристосована для трекінгу конвеєрів машинного навчання (ML pipelines), хеш-кодів гігабайтних датасетів чи вагових коефіцієнтів нейромереж. Спроба змусити облікову систему дублювати функції Git, DVC (Data Version Control) або MLflow створить надлишкове навантаження на реляційну БД і призведе до критичного падіння швидкодії.
* ➔ «SO WHAT?» (НАСЛІДКИ): Замість створення єдиного «монстра», реальність вимагає жорсткої інтеграції через API між промисловою ERP (що веде облік заліза та серійних номерів) та спеціалізованими MLOps-платформами. Якщо виробник піде шляхом, який пропонує автор (заштовхування датасетів в ERP), він отримає неповоротку систему, яка гальмуватиме випуск релізів прошивок і безпосередньо вплине на швидкість адаптації дронів до нових частот РЕБ ворога.
---
📌 [«Виробник без наскрізної трасованості від закупівлі до відвантаження не пройде кваліфікацію субпідрядника для жодного міжнародного партнера...»]
* 🔴 КРИТИКА / ОБМЕЖЕННЯ: Тут присутня серйозна логічна помилка у визначенні причинно-наслідкових зв’язків (карго-культ стандартів). Сертифікація за стандартами на кшталт MIL-STD-810H або AS9100 — це насамперед про фізичні випробування, інженерні процеси, вхідний контроль у лабораторіях та культуру виробництва, а не про наявність «правильної» ERP-системи. Міжнародні партнери оцінюють технологічні карти, калібрування верстатів та сертифікати походження матеріалів. Сама по себе ERP, навіть із наскрізною трасованістю, є лише цифровим відображенням процесу: якщо фізичний процес хаотичний, система просто ідеально задокументує хаос.
* ➔ «SO WHAT?» (НАСЛІДКИ): Сліпа віра в те, що «архітектура обліку вирішує все», відволікає критичні оборонні ресурси (гроші та час) від реальної модернізації виробничих ліній та закупівлі випробувального обладнання (кліматичних камер, вібростендів). Виробник може витратити рік на впровадження ERP, але все одно провалити аудит NATO через те, що його паяльні станції не проходять регулярну повірку.
---
⚠️ ЩО ЗАЛИШИЛОСЯ ЗА КАДРОМ (Підсумок):
Аналізований матеріал свідомо або несвідомо ігнорує три фундаментальні загрози, які роблять описану концепцію «ідеального обліку» вразливою у реаліях війни:
1. **Кібербезпека та фактор «Єдиної точки відмови» (Single Point of Failure):** Автор, як керівник ERP-сервісу, просуває ідею тотальної деталізації даних: в одній системі збираються серійні номери, прошивки, постачальники, прив’язка до конкретних бортів та фінанси. У сучасному контррозвідувальному контексті така база даних — це готове та найцінніше польотне завдання для ворожої ракетної або хакерської атаки. Злам або витік з такої ERP миттєво розкриває ворогу реальні обсяги виробництва, ланцюжки постачання, технологічні слабкості (через аналіз рекламацій) та геолокацію субпідрядників. Проблему безпеки, шифрування та розподіленого зберігання цих даних у статті взагалі не порушено.
2. **Специфіка «чорного» та «сірого» ринків комплектуючих:** Концепція «чистої трасованості від постачальника» розбиється об реалії обходу санкцій та закупівлі дефіцитних чипів через треті-четверті руки (фірми-одноденки, готівкові розрахунки, волонтерські канали). Жоден постачальник з Китаю чи Туреччини не надасть офіційну «історію походження компонента» для військового дрону. Намагання побудувати жорстку білу архітектуруMIL-STD в умовах партизанської логістики закупівлі призведе до того, що система або заблокує виробництво, або змусить менеджерів масово вносити фейкові дані для закриття замовлень.
3. **Ціна впровадження та адміністрування (Resource Drain):**
Ведення обліку з точністю до «кожної транзакції, прив’язаної до конкретного виробу, а не до партії» вимагає колосального ресурсу: окремого штату дата-ентрі операторів, аналітиків та контролерів якості на лінії. Для українського малого та середнього бізнесу (на який орієнтується автор) цей додатковий адміністративний апарат — пряме вимивання оборотних коштів, які могли б піти на R&D або закупівлю комплектуючих. Співвідношення «вартість підтримки системи / реальна цінність для фронту» у статті не прораховано.
zippy.com.ua
Безкоштовна облікова (склад, торгівля,виробництво,ПРРО) програма з відкритим кодом і веб інтерфейсом як альтернатива платного та/або російського ПЗ
яка нікому не потрібна (як і купа інших) без адаптації до налаштованих процесів та персоналу що вміє їх виконувати.
— персонал — проблема
— навчаний персонал — наступна проблема
— налаштований процес — проблема
— персонал що вміє в налагоджений процес — наступна проблема
— адаптований до процесів код — проблема
— незакладені в бюджет кошти на :
— якість персоналу (пошук, пробний найм, знову пошук)
— якість процесів (як с т.з. «аналітиків» та «експертів» які будуть цим займатись, так і с т.з. самої операційної діяльності)
— якість систем/коду (....)
набiр маркетонигових гасел — на практицi таким вимогам не вiдповiда навiть одноце
кожна програма потребуе налагодження процесiв i навчання персоналу
ви мабуть живете в якомусьб паралельному всесвiтi -
я живу в світі в якому люди вміють читати )))
Цікаво, а яка конверсія буде у цього коментарю? В сенсі звернень — ось хочу облік з трасеабіліті, щось так хочу, як у Делл ) Dell TechDirect. (Asset Management) А ще як у Slumberge -Asset Management і шоб інспекції та нормативи використання трекались ) А ви здогадуєтеся про складність цього? Ну, чи хоч пробували почитати у цьому напрямі?
Якщо спростити, то вся нормативка НАТО для виробництва ділиться на три великі кити: якість (AQAP), конфігурація (ACMP) та маркування (STANAG по UID).
AQAP 2110 (NATO Quality Assurance Requirements for Design, Development and Production): Головна біблія для будь-якого оборонного заводу. Цей стандарт прямо вимагає, щоб виробник мав систему, яка може протрейсити компонент на всіх етапах: від вхідного контролю на складі до фінального гвинтика в готовому виробі. Якщо впав дрон, за цим стандартом військове представництво (GQA) має право вимагати документи на партію транзисторів, які туди впаяли.
AQAP 2210 (NATO Supplementary Software Quality Assurance Requirements):
А це якраз про софт та алгоритми на борту (до питання про комп’ютерний зір та навігацію). Він вимагає наскрізної зв’язності: вимога до софту -> архітектурний модуль -> конкретний комміт -> тестовий звіт. Не можна просто залити нову бінарку «бо вона краще працює»
ACMP-2100 (Configuration Management Policy and Requirements):
Стандарт регулює життєвий цикл структури виробу (BOM). Він вводить жорсткі поняття базових ліній (Baselines):
Functional Baseline (що дрон має робити), Allocated Baseline (з яких вузлів складається) і Product Baseline (як саме зібраний конкретний серійний борт).За цим стандартом будь-яка заміна (наприклад, інший польотний контролер, бо старі закінчилися) — це не просто «поставили аналог», а офіційна процедура ECP (Engineering Change Proposal).
Система обліку зобов’язана зберігати історію: борти до серійника $X$ йшли за ревізією А, після — за ревізією Б
STANAG 4661 / MIL-STD-130:
Вводить поняття Item Unique Identification (IUID). Будь-який вузол оборонного виробу, який коштує дорожче певної суми або є критичним для місії (наприклад, навігаційна плата, двигун, камера), повинен мати унікальний двовимірний код (DataMatrix), який зчитується машиною.