Анатомія Робочих пакетів у Horizon Europe: WP, Deliverables, Milestones

У 2025 році загальний відсоток схвалених заявок Horizon Europe впав до приблизно 12% (за попередніми даними Science|Business). Кожну восьму заявку фінансують, решта повертається з коментарями рецензентів. І якщо уважно подивитися у відгуках оцінювачів (Evaluation Summary Reports), один патерн повторюється з неприємною регулярністю: слабкий розділ про реалізацію проєкту, і зокрема неправильно сформовані робочі пакети (Work Packages, скорочено WP).

Але є і менш очевидний бік цієї проблеми. Якщо заявку все ж таки схвалять, та сама таблиця робочих пакетів, яку ви готували для рецензентів, стане Додатком 1 до грантової угоди, юридично зобов’язуючим документом. WP, Tasks, Deliverables і Milestones перетворюються на контрактні зобов’язання. Якщо ви занадто оптимістично розподілили людино-місяці або описали нереалістичні завдання: труднощі почнуться вже на фазі виконання, а не після відхилення.

У цьому матеріалі ми розбираємо практичну анатомію структури робочих пакетів для проєктів RIA та IA: дослідницьких та інноваційних дій (Research and Innovation Actions і Innovation Actions): від ієрархії елементів до розподілу людино-місяців (Person-Months) між партнерами без роздуття бюджету.

Як влаштований робочий пакет: від завдань до контрольних точок

Work Package (WP, або робочий пакет) є автономною одиницею роботи зі своєю метою, бюджетом і часовими рамками. Кожен робочий пакет поділяється на Tasks (конкретні роботи всередині пакету). Саме Tasks породжують Deliverables та Milestones.

Deliverable (результат або звіт, що підлягає здачі до ЄК): це документ, який ваша команда надсилає до Єврокомісії або відповідного агентства ЄС. Офіційний анотований шаблон пропозиції Horizon Europe (RIA/IA, версія 5.0, квітень 2025) визначає deliverable як «звіт, що надсилається до Комісії для забезпечення ефективного моніторингу проєкту». Навіть якщо ваш deliverable, як-от прототип або набір даних, до нього все одно додається письмовий звіт з описом характеристик і процесу.

Milestone (контрольна точка проєкту). Офіційне визначення: «контрольні точки у проєкті, що допомагають відстежувати прогрес виконання». Milestone може відповідати ключовому результату або критичному рішенню, наприклад, вибору технологічної платформи для подальшої розробки. Головна вимога до milestone: його досягнення має бути підтвердженим.

Між ними є принципова різниця. Deliverable завжди прив’язаний до конкретного WP і бажано до конкретного Task. Milestone натомість може охоплювати кілька WP одночасно, що зручно для міжпакетних контрольних точок, де результати кількох паралельних напрямів збігаються.

Структура робочих пакетів виконує дві функції. Під час оцінювання рецензенти перевіряють її на логіку, реалістичність і обґрунтованість бюджету. Після підписання грантова угода набирає чинності, а WP перетворюється на частину Опису дій (Description of Action, DoA), Додаток 1 до угоди. У проєктах із моделлю фіксованих виплат це ще критичніше: завершення WP є єдиною підставою для виплати фіксованої суми ЄК.

Стандартна структура пакетів для RIA та IA: чого очікують рецензенти

Типовий RIA або IA проєкт містить 6-8 WP. Офіційний анотований шаблон HE (версія 5.0) прямо зазначає: «типовий проєкт має 6-8 WP, збалансованих за розміром бюджету і людино-місяців».

структура робочих пакетів відображає концепцію та ідею проєкту, сформовані до написання заявки. Якщо концепція нечітка, жодна красива WP-таблиця ситуацію не врятує.

Стандартна схема: перший пакет: Управління проєктом (WP1): адміністративне і фінансове управління, відповідає координатор. Далі йдуть технічні пакети WP2-WPx із дослідницьким і науковим навантаженням. і останній пакет: Поширення та комунікація результатів.

2 речі, які рецензенти помічають одразу. По-перше: жоден партнер не повинен тягнути весь WP самотужки. Це сигнал про слабку співпрацю між партнерами: один з аргументів, що знижує оцінку в розділі про реалізацію. По-друге: не вписуйте всіх партнерів у всі WP без чіткого розподілу ролей. Якщо консорціум присутній скрізь однаково, структура виглядає штучно. Виняток становлять «горизонтальні» пакети для поширення результатів, де участь усіх виправдана логікою поширення результатів.

Найкращий спосіб продемонструвати справжню співпрацю: показати ланцюжок завдань. Наприклад: Task 3.2 у WP2 (партнер B збирає дані) безпосередньо подає результати до Task 1.1 WP4, де їх опрацьовують партнери A і C. Така взаємозалежність показує рецензентам реальну структуру співпраці, а не просто перелік учасників у таблиці.

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

Щодо назв WP: уникайте розмитих формулювань. «Дослідницькі активності»: слабка назва. «Розробка і валідація модуля машинного навчання (ML) для аналізу даних клінічних іспитів»: конкретна і зрозуміла. Рецензенти читають назви WP ще до того, як заглиблюються в деталі.

Результати для ЄК і контрольні точки: оптимальна кількість і типові помилки

Загальна логіка: достатньо deliverables і milestones, щоб переконати рецензентів у серйозності проєкту, і водночас не настільки багато, щоб перевантажити команду на фазі виконання.

Для deliverables: мінімум 1 на Task, рекомендований орієнтир: 2-3 на WP. Якщо Task триває понад 18 місяців, варто додати проміжний deliverable. Кожен deliverable має бути пов’язаний з конкретним WP і, ідеально, з конкретним Task. Назва deliverable повинна відображати реальний результат, а не звучати як «Звіт про активності»: наприклад, «D2.1: Специфікації протоколу збору даних (12-й місяць від старту)»: зрозуміло і для рецензента, і для команди.

Для milestones: рекомендовано близько 5 на 3-річний проєкт; для довших додайте 1-2. Кожен milestone має бути підтвердженим: не «просуваємося у напрямку», а «прийнято рішення про технологічну платформу на засіданні Комітету управління проєктом (PMC) на 18-му місяці».

Таймінг має значення. Не ставте deliverables у серпні: ніхто не любить писати звіти у відпустці. Не плануйте їх і протягом 2 місяців перед звітним і безпосередньо під час звітного періоду. Якщо deliverable запізниться, у вас буде час виправити ситуацію до відправки звіту до ЄК.

Класична помилка: принцип «більше = краще». Довгий список deliverables виглядає амбіційно на папері. На практиці він означає адміністративний марафон і сигналізує рецензентам про погане планування. Рекомендовані 2-3 добре сформульованих deliverables на WP задовольнять рецензентів і залишать команді час на реальну роботу.

Важливо пам’ятати: deliverables і milestones після підписання грантова угода перетворює їх на контрактні зобов’язаннями. Тому реалістичність при плануванні має реальний фінансовий і операційний вимір.

Людино-місяці: як рахувати і не роздути бюджет

Що таке людино-місяць і як його порахувати

1 людино-місяць (person-month, скор. PM): час 1 повноцінного співробітника протягом 1 місяця. Або 2 співробітників по 50% кожен. Здається очевидним, але саме неправильне розуміння цього є однією з найбільш поширених помилок у заявках.

Починаючи з Horizon Europe, персональні витрати розраховуються через денну ставку: річні витрати на персонал ÷ 215 робочих днів = денна ставка. Ця ставка множиться на кількість відпрацьованих в проєкті днів. Практичний спосіб організувати розрахунок: додати колонку PM до діаграми Ганта (Gantt chart) для кожного партнера і кожного пакету. Це дає загальну картину персонального навантаження і допомагає уникнути ситуації, коли один дослідник одночасно фігурує у 4 пакетах із загальним навантаженням понад 100%.

Типові помилки при розподілі ресурсів

Класичний приклад нереалістичного розподілу: 50 людино-місяців на управління проєктом у 2-річному проєкті. Математика проста: це 2 людей на повній ставці, зайнятих виключно адмініструванням 24 місяці. Рецензенти читають такий розподіл одразу як роздутий бюджет.

Ще один поширений підхід, який дає слабкий результат, це розподіл зверху-вниз (top-down): взяти загальний бюджет і порівну розділити між партнерами. Рецензенти сприймають такий розподіл як неопрацьований. Підхід знизу-вгору (bottom-up), де кожен партнер оцінює реальні зусилля по своїх завданнях, а потім цифри зводяться разом, дає точнішу картину і виглядає значно переконливіше.

Аналітична панель ЄК і неписані правила бюджету

Для заявок із моделлю фіксованих виплат оцінювачі використовують аналітична панель ЄК (аналітична панель ЄК (Horizon Dashboard)), інструмент порівняльного аналізу витрат на персонал. Він показує розподіл витрат від нижніх 20% до верхніх 80% типового діапазону, розбитий за країнами і типами організацій. Якщо ваші витрати виходять за межі 80% діапазону: потрібне додаткове обґрунтування. Рекомендуємо перевіряти свої цифри в аналітичній панелі ще під час підготовки пропозиції.

Крім офіційних правил, існують практичні орієнтири, які збалансований консорціум враховує. Уникайте концентрації понад 40% загального бюджету на партнерів з однієї країни: це сигнал про незбалансований консорціум. Підрядні роботи краще тримати в межах 15-20% загального бюджету, і в жодному разі вони не можуть замінити ключові завдання проєкту. Витрати на закупівлі, які перевищують 15% від персональних витрат партнера, потребують детального обґрунтування в окремій таблиці закупівель бюджету (Таблиця 3.1h у шаблоні заявки).

Ще одна деталь, яку часто ігнорують: всі партнери мають відповідати принаймні за 1 deliverable і брати участь у кількох. Незбалансований розподіл deliverables є прямою ознакою незбалансованого навантаження, і рецензенти це помічають.

Модель фіксованих виплат у 2026-2027: чому структура пакетів стає важливішою

До 2026-2027 років половина бюджету програми Horizon Europe переходить на модель фіксованих виплат (Lump Sum). Замість того щоб збирати рахунки і табелі обліку часу, достатньо підтвердити виконання пакету. Кожному пакету у грантовій угоді відповідає заздалегідь узгоджена фіксована сума.

За оцінкою ЄК 2024 року, модель знижує адміністративні витрати на 14-30% і вже заощадила понад €60 млн у перших пілотних проєктах. Єврокомісарка з досліджень Катерина Захарієва назвала цю модель «простішою і більш доступною для нових учасників» (Science|Business, лютий 2026). Але Європейський суд аудиторів нагадав: намір спростити фінансове управління ЄС не має відбуватися за рахунок підзвітності й ефективності.

На практиці це означає нову логіку ризику. Розмиті формулювання завдань у WP, які раніше могли «пройти» в умовах звичайного фінансування за фактичними витратами, тепер стають проблемою: якщо виконання WP неможливо підтвердити, ЄК може не підтвердити виплату.

Практичний висновок для тих, хто подає заявку на конкурс із фіксованими виплатами: структуруйте кожен WP так, щоб факт його завершення можна було однозначно продемонструвати. Кожен deliverable, milestone і Task мають описувати конкретний, верифікований результат, а не процес. «Провели дослідження»: це опис процесу, а не підтверджений результат. «Опублікований звіт D3.1 з результатами польових випробувань»: це конкретний, вимірний результат, що підтверджує виконання пакету.

Структура робочих пакетів завжди була аргументом для рецензентів і планом для команди. Тепер вона ще й пряма умова виплати. Це достатня причина витратити на неї додатковий час ще на етапі підготовки пропозиції.