Гранты для DefTech: как подготовить продукт, команду и заявку без слабых мест

Что именно финансируют DefTech-гранты

Пять проверок продукта до работы над заявкой

Как упаковать техническую часть

Бюджет: переведите технический план на язык расходов

Команда, которой поверят и которая действительно выполнит проект

Как написать заявку, которую легко проверять

Учет и документы нужно настроить до первого расхода

Реалистичный план подготовки за шесть недель

Типичные ошибки, из-за которых сильный продукт выглядит слабо

Финальный чек-лист перед подачей

Вывод

В DefTech сильная идея еще не равна сильной грантовой заявке. Экспертам нужно увидеть не только перспективную технологию, но и управляемый проект: конкретную потребность пользователя, подтвержденный уровень готовности, компетентную команду, измеримый результат и бюджет, связанный с работами. Для директора это также вопрос финансовой дисциплины. Разобраться, как читать показатели, контролировать расходы и проверять документы перед подписанием, помогает курс бухгалтерского учета для директоров в учебном центре «Стимул».

В качестве отправной точки для поиска финансирования стоит просмотреть страницу «Грант для разработчиков оборонных технологий» на портале Дія.Бізнес. При этом названия программ, приоритеты, суммы, сроки и требования меняются, поэтому информацию с обзорной страницы нужно сверять с действующим положением конкретного конкурса непосредственно перед подачей. В этой статье условия приведены по состоянию на 14 октября 2026 года.

Что именно финансируют DefTech-гранты

Грант в сфере оборонных технологий — это не вознаграждение за интересную концепцию и не способ закрыть все текущие расходы компании. Это финансирование определенного этапа разработки с результатом, который можно продемонстрировать, испытать и подтвердить документами. Заявитель фактически отвечает на три вопроса: какую проблему решает продукт, до какого нового состояния он дойдет за средства гранта и как будет доказано достижение этого состояния.

По состоянию на 14 октября 2026 года Brave1 сообщает о нескольких моделях поддержки. В классической грантовой программе речь идет о суммах до 500 тыс., 2 млн, 4 млн и 8 млн грн в зависимости от технологической готовности продукта. Спецгрантовая программа предусматривает поддержку до 8 млн грн в приоритетных направлениях независимо от уровня готовности, а отдельные грантовые конкурсы формируются под конкретные технические характеристики. Это разные инструменты с разной логикой отбора, а не шкала, на которой достаточно выбрать наибольшую сумму.

Текущие направления, требования к заявителю, допустимые расходы, документы, порядок оценивания и сроки следует проверять в актуальной редакции положения и в объявлении выбранной программы. Если конкурс пока анонсирован, но окончательные правила не опубликованы, планировать подачу можно, а утверждать, что команда уже соответствует условиям, — нет.

Начинайте не с суммы, а с разрыва в готовности

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

Если команда не может четко назвать этот переход, смета почти неизбежно превратится в список желаемых покупок. Экспертам будет сложно понять, почему именно эти расходы ведут к нужному результату.

Пять проверок продукта до работы над заявкой

1. Проблема должна принадлежать конкретному пользователю

Фраза «повышает эффективность подразделения» слишком широка. Нужно объяснить, кто пользуется решением, в какой ситуации возникает проблема, что происходит сейчас и какой показатель должен изменить продукт. Не раскрывайте в открытых материалах чувствительные сведения: достаточный для оценивания уровень детализации следует согласовывать с правилами программы и режимом доступа к информации.

2. Нужно доказательство, а не только описание возможности

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

К заявке стоит добавлять не красивую демонстрацию, а воспроизводимые результаты тестов с привязкой к версии прототипа.

3. Уровень готовности должен соответствовать фактам

Не повышайте уровень технологической готовности декларативно. Если отдельные узлы работают на столе, это еще не означает готовность интегрированной системы к полевому применению. Составьте таблицу доказательств: для каждой заявленной характеристики укажите документ или испытание, которое ее подтверждает, и пробел, который нужно закрыть.

4. Архитектура должна выдерживать не только демонстрацию

Проверьте зависимости от импортных компонентов, питания, связи, программного обеспечения, внешней инфраструктуры и квалификации оператора. Отдельно оцените ремонтопригодность, поставки критических деталей, обновление прошивки, киберзащиту и контроль версий. Для аппаратного продукта полезно иметь предварительную спецификацию материалов, а для программного — перечень сторонних компонентов и лицензий.

5. Есть путь от прототипа до применения

Заявка должна заканчиваться не словом «прототип», а сценарием следующего шага: повторные испытания, доработка конструкции, подготовка малой серии, кодификационные или другие необходимые процедуры, производственный партнер или передача пользователю. Не обещайте этапов, для которых у команды нет ресурсов или подтвержденного маршрута.

Как упаковать техническую часть

Техническое описание удобно строить от потребности к доказательству. Для каждой ключевой функции сформулируйте измеримый показатель, текущее значение, целевое значение, способ проверки и ожидаемый документ. Такая структура дисциплинирует команду и упрощает экспертную оценку.

Не перегружайте основной текст второстепенными деталями. Краткое объяснение принципа работы, границ применения и преимущества должно читаться без участия автора. Чертежи, расчеты и протоколы лучше структурировать в приложениях, если это разрешено правилами и требованиями к защите информации.

Бюджет: переведите технический план на язык расходов

Лучшую смету можно прочитать в двух направлениях. От этапа работ видно, какие ресурсы нужны; от каждого расхода видно, какой результат он создает. Если позиция не имеет такой связи, ее нужно уточнить или убрать.

Сначала сформируйте структуру декомпозиции работ

1. Разбейте проект на этапы с результатами, а не только на календарные месяцы.
2. Для каждого этапа определите работы, исполнителей, материалы, услуги и испытания.
3. Зафиксируйте допущения: количество образцов, нормы расходов, цены, курс, сроки поставки.
4. Сверьте каждую статью с перечнем допустимых расходов именно вашей программы.
5. Добавьте контрольную точку, по которой можно принять результат этапа.

Не стоит механически «подгонять» сумму под максимальный грант. Завышенный бюджет вызывает вопросы, а заниженный может сделать проект невыполнимым. Если оборудование будет служить не только этому проекту, нужно заранее понять, допускается ли его приобретение и как обосновывается использование. То же касается запасов, заработной платы, внешних услуг, логистики, налогов и НДС: порядок их включения определяет действующее положение, а не привычная практика компании.

Проверьте смету по трем сценариям

• Базовый: цены и сроки соответствуют полученным предложениям поставщиков.
• Стрессовый: критический компонент дорожает или задерживается; команда знает, что переносится, а что заменяется.
• Минимальный: определено неприкосновенное ядро работ, без которого заявленный результат невозможен.

Резерв не следует маскировать в завышенных ценах. Если правила разрешают непредвиденные расходы или перераспределение, опишите механизм прозрачно. Если не разрешают — планируйте альтернативы в пределах утвержденных статей и процедуру согласования изменений.

Смету стоит пересматривать вместе: технический специалист подтверждает необходимость, финансист — расчет, руководитель проекта — связь со сроками и результатом.

Команда, которой поверят и которая действительно выполнит проект

В заявке важны не громкие должности, а закрытые компетенции. В небольшой команде один человек может выполнять несколько ролей, но ответственность все равно должна быть обозначена.

• Владелец продукта отвечает за проблему пользователя, границы продукта и критерии приемки.
• Технический руководитель держит под контролем архитектуру, интеграцию, версии и технические риски.
• Руководитель проекта ведет календарь, зависимости, контрольные точки и изменения.
• Финансовая функция проверяет смету, первичные документы, платежи, учет и отчетность.
• Ответственный за испытания готовит методику, фиксирует условия и обеспечивает воспроизводимость результатов.
• Производственная или закупочная функция контролирует поставщиков, спецификации, сроки и замены компонентов.

Для каждого ключевого результата укажите одно ответственное лицо. Формула «отвечает вся команда» обычно означает, что в критический момент не отвечает никто. Также покажите доступность специалистов: эксперт с сильным резюме, который может уделять проекту два часа в месяц, не закрывает операционную потребность.

Как написать заявку, которую легко проверять

Сильная заявка имеет одну логическую линию:

потребность → текущее доказательство → технический пробел → работы → измеримый результат → бюджет → способ проверки.

Если два раздела противоречат друг другу, эксперт заметит это быстрее, чем автор. Например, техническая часть обещает пять образцов, смета содержит компоненты на три, а календарь предусматривает испытания шести. Перед подачей проведите перекрестную проверку чисел, названий версий, единиц измерения, сроков и ответственных.

Полезная формула для каждого этапа

Опишите этап в четырех строках: входное состояние, работы, выходной результат и критерий приемки. Например: «На входе — интегрированный прототип версии 0.3. Команда изготавливает корпуса, собирает три образца и проводит серию стендовых тестов. На выходе — три работоспособных образца версии 0.4 и протокол. Этап принят, если все образцы проходят определенные проверки по одинаковой методике».

Эта формула не гарантирует победы, но устраняет типичную двусмысленность: финансируется ли процесс или достижение результата.

Учет и документы нужно настроить до первого расхода

Грант создает отдельный контур управления. Команде нужно заранее определить, кто согласовывает закупку, кто принимает товар или услугу, где хранятся первичные документы, как расход обозначается в учете проекта и кто готовит отчет. Конкретный порядок зависит от договора и действующих правил программы.

Практический минимум для внутреннего контроля:

• отдельный реестр бюджета «план — обязательства — оплачено — остаток»;
• единый код проекта для договоров, счетов, актов и складских операций;
• связь каждого расхода с этапом и результатом;
• реестр версий сметы и согласованных изменений;
• календарь отчетных дат и ответственных;
• архив подтверждающих документов с контролируемым доступом.

Если учет ведется в BAS или 1С, не обязательно сразу перестраивать всю систему. Часто достаточно аналитики по проекту, статье бюджета, этапу и договору, а также отчета, который сопоставляет данные учета с утвержденной сметой. Но такую модель нужно протестировать на условной закупке до подписания грантового договора.

Реалистичный план подготовки за шесть недель

Неделя 1: соответствие и границы

Выберите конкретную программу, прочитайте действующее положение, составьте перечень формальных требований и стоп-факторов. Зафиксируйте продукт, версию, целевой результат и сумму, которую реально обосновать.

Неделя 2: доказательства и пробелы

Проведите инвентаризацию протоколов, тестов, фото, технических документов и обратной связи. Не создавайте доказательства задним числом: обозначьте пробелы и запланируйте дополнительные проверки.

Неделя 3: работы, риски и команда

Выстройте этапы, контрольные точки, реестр рисков и матрицу ответственности. Проверьте доступность людей, лаборатории, полигона, компонентов и внешних исполнителей.

Неделя 4: смета и календарь

Соберите рыночные подтверждения цен, уточните налоги и сроки поставки, свяжите расходы с работами. Финансовая и техническая версии плана должны совпадать.

Неделя 5: черновик и независимое чтение

Пусть заявку прочитает человек, который не участвовал в ее написании, но понимает технологические проекты. Его задача — отметить неподтвержденные утверждения, разрывы в логике и термины, понятные только команде.

Неделя 6: контрольная сборка

Проверьте формы, подписи, форматы файлов, допустимый объем, названия приложений и срок подачи. Сохраните финальную копию всего пакета и подтверждение отправки. Не откладывайте загрузку на последний час.

Типичные ошибки, из-за которых сильный продукт выглядит слабо

• Заявка начинается с технологии, а не с потребности. Читателю приходится догадываться, зачем нужен продукт.
• Будущие характеристики представлены как уже достигнутые. Это разрушает доверие ко всем доказательствам.
• Сумма выбрана по принципу «сколько дают». Нет связи между деньгами и переходом продукта на новый уровень.
• Смета живет отдельно от календаря. Закупки запаздывают относительно тестов или не покрывают заявленное количество образцов.
• Риски скрыты. Эксперты все равно видят зависимости, но не видят способности команды ими управлять.
• Нет владельца финансовой отчетности. После победы техническая команда тратит время на восстановление документов.
• Использованы устаревшие условия. Суммы, приоритеты или формы берут из давней публикации вместо действующего положения.

Финальный чек-лист перед подачей

• Выбранная программа соответствует продукту, стадии и статусу заявителя.
• Условия, суммы и сроки проверены по действующим документам на дату подачи.
• Текущий уровень готовности подтвержден материалами, а не самооценкой.
• Цель проекта описывает один понятный технологический переход.
• Каждый этап имеет результат, критерий приемки, срок и ответственного.
• Каждый расход связан с работой и разрешен правилами программы.
• Количество образцов одинаково в техническом описании, календаре и смете.
• У рисков есть владельцы, ранние индикаторы и план реагирования.
• Команда понимает порядок закупок, учета, хранения документов и отчетности.
• Пакет не содержит лишних чувствительных сведений и соответствует требованиям доступа.
• Заявку перечитал независимый человек, а финальная версия сохранена отдельно.

Вывод

Подготовка к DefTech-гранту — это полезная диагностика бизнеса даже без гарантии победы. Она заставляет отделить факты от предположений, проверить техническую зрелость, увидеть реальную себестоимость следующего этапа и назначить ответственных. Сильная заявка не пытается произвести впечатление масштабом обещаний. Она показывает контролируемый переход от уже подтвержденного состояния к результату, который можно принять, учесть и применить на практике.