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

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

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

Тому конкурентний аналіз у defence tech варто починати з операційного результату, якого прагне користувач. Далі команда визначає реальні альтернативи, порогові вимоги, критерії вибору та якість доказів. У підсумку має з’явитися продуктове рішення: масштабувати, вдосконалювати, шукати партнера, змінювати позиціонування або зупиняти напрям.

Конкурент — кожен, хто претендує на ту саму місію

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

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

До такого переліку входять:

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

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

Спочатку опишіть сценарій застосування

Сценарій — це конкретний зріз концепції застосування системи або ConOps (Concept of Operations). Він описує місію, користувача, середовище та обмеження. Саме з нього виводяться критерії порівняння.

Я рекомендую фіксувати щонайменше вісім складових.

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

Розділіть вимоги на три рівні

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

1. Порогові умови

Порогові умови, або gates, працюють за принципом «пройдено / не пройдено». Вони описують мінімальну придатність системи до місії. Якщо рішення не проходить хоча б одну критичну умову, високий середній бал за рештою показників не робить його придатним.

Підписуйтеся на наші соцмережі

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

2. Зважені критерії

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

Важливо розділяти технічну перевагу й операційну цінність. Додаткова година автономності може мати низьку вагу для короткої тактичної місії. Натомість скорочення екіпажу з чотирьох людей до двох здатне суттєво вплинути на реальну застосовність системи.

3. Рівень довіри до доказів

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

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

Два сценарії майже завжди дають два різні рейтинги

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

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

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

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

Звідси випливає важливе продуктове правило: заявляти перевагу варто в межах конкретного сценарію. Формулювання «найкраща система» майже завжди потребує уточнення: для якої місії, користувача, інфраструктури, загрози та моделі витрат?

Побудуйте ієрархію доказів

У defence tech якість даних часто нерівномірна. Частина інформації відкрита, частина конфіденційна, конфігурації швидко змінюються, а умови тестів важко відтворити. Тому джерела варто оцінювати за рівнем доказовості.

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

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

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

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

Не змішуйте різні версії продукту в один «факт»

Для кожної важливої оцінки слід фіксувати точну модель, конфігурацію, дату, джерело та умови отримання даних. Діапазон на кшталт «16–22 години автономності» без прив’язки до версії, встановлених сенсорів, погоди й профілю польоту може поєднувати кілька різних продуктів під одним ярликом.

Корисно вести короткий паспорт кожного доказу:

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

Завершуйте аналіз рішенням

Матриця конкурентів має змінювати план дій. Я використовую п’ять типів продуктового рішення.

WIN — масштабувати. У сценарії є підтверджена перевага. Команда інвестує в продаж, виробництво, сервіс і масштабування.

IMPROVE — вдосконалити. Сегмент привабливий, але виявлено конкретний розрив у спроможності, або capability gap. Він переводиться в план розвитку продукту та перевірювану гіпотезу.

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

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

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

Рішення IMPROVE потребує особливої дисципліни. Фраза «потрібно зробити продукт кращим» сама по собі не задає роботу команді. Якісний висновок називає конкретний розрив, сценарій, у якому він критичний, очікувану зміну результату та тест, що підтвердить прогрес.

Практичний шаблон на одну сторінку

Перед інвестицією в розробку, масштабування або вихід у новий сегмент команда має дати відповіді на сім запитань:

Підсумок можна сформулювати одним абзацом:У сценарії ___ наш продукт має підтверджену перевагу завдяки ___ і ___. Це підтверджують ___. Він поступається альтернативі ___ за критерієм ___. Тому ми обираємо рішення ___. До наступної інвестиції перевіряємо ___, ___ і ___.

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

Сильний аналіз може привести до незручного висновку

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

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