План управління дослідницькими даними (УДД або DMP) — це вже не просто формальність для галочки, а обов'язкова умова сучасних грантових проєктів, зокрема в рамках Horizon Europe. Проте аналіз свіжих планів, що надходять на перевірку до Науково-технічної бібліотеки КПІ у 2026 році, показує: автори часто сприймають цей документ як анкету, а не як реальний управлінський інструмент.
Результат? Загальні декларації замість конкретики та закономірне повернення документа на доопрацювання.
Ми зібрали та систематизували найпоширеніші помилки дослідників — від критичних пропусків до глибинних системних прорахунків. Перевірте свій план перед подачею!
🔴 Топ-3 критичних помилок (є майже у всіх планах)
Відсутній або «іграшковий» розділ «Забезпечення якості» (QA) Жоден із розглянутих планів не містив повноцінного QA-розділу. Дослідники забувають описати версіонування файлів, перевірку цілісності даних (наприклад, через контрольні суми) та правила збереження незмінної головної копії (master copy) окремо від щоденних робочих матеріалів.
Архівування плутають із поточним зберіганням Поточна робота з файлами в хмарі та довгострокове архівування — це різні процеси. Типова помилка — не вказувати конкретний науковий репозитарій з DOI на початку (як-от Zenodo, що вимагається п.6.3 Положення КПІ).
«Обмін даними» без конкретики У планах катастрофічно бракує деталей: як саме отримуватиметься DOI, які точні терміни публікації даних після завершення ембарго, і чому ліцензія CC BY 4.0 не прив’язана безпосередньо до умов обміну.
🟡 Важливі деталі, про які забувають
Пропрієтарні формати без виправдання: Повсюдне використання XLSX та DOCX. Натомість Положення (п.4.2) вимагає відкритих форматів (
.csv,.odt,.txt) або чіткого обґрунтування, чому залишено закритий формат, із описом відкритої альтернативи.Де ліцензія? Ліцензія CC BY 4.0 для самих даних і CC0 для метаданих мають фігурувати у розділі про обмін даними. Натомість посилання на них або відсутнє, або з'являється аж наприкінці — в архівуванні.
Анонімні ролі: Розподіл обов'язків є, але без конкретних імен, матриці задач за етапами проєкту та без дати першого обов'язкового перегляду плану (а його треба переглядати щопівроку!).
🔵 Системні прогалини (паспортна частина та метадані)
Адміністративний вакуум: Дослідники забувають вказати номер теми/договору, версію самого DMP, джерело фінансування та контакти особи, відповідальної за запити щодо даних.
Винахід велосипеда: Шаблон вимагає зафіксувати, чи перевіряв автор наявність вже існуючих схожих наборів даних (у Re3data, Zenodo тощо) для їх повторного використання. Цей пункт зазвичай просто ігнорують.
Загальний Dublin Core: Стандарти метаданих або не згадуються взагалі, або копіюється загальна фраза «Dublin Core» без жодної прив'язки до конкретних полів.
🧠 4 типи мислення, які псують ваш DMP
Ці помилки виникають не через некомпетентність. Це наслідок неправильного сприйняття документу. Зазвичай автори потрапляють в одну з чотирьох пасток:
Тип 1. Декларативність без механізму
Симптом: Писати що буде зроблено, але не писати як.
Приклад: Вказати стандарт EngMeta, але без URI/версії. Згадати DataCite, але не написати, хто, коли і через який інтерфейс заповнює метадані. Згадати Nextcloud, але не уточнити, чиї це сервери.
Причина: Сприйняття DMP як форми для відписки, а не як інструкції для команди.
Тип 2. Ігнорування масштабу
Симптом: Технічні параметри проєкту суперечать обраним інструментам.
Приклад: Вказати загальний обсяг даних у 500 ГБ – 1 ТБ і обрати основним репозитарієм Zenodo, де безкоштовний ліміт становить 50 ГБ на датасет, і не пояснити, як дані будуть секціонуватися.
Причина: DMP заповнюється ізольовано від реального технічного планування та розрахунку бюджету.
Тип 3. Відсутність інституційного контексту
Симптом: Документ пишеться так, наче дослідник перебуває у вакуумі.
Приклад: Роль Data Steward прописана як абстрактна «відповідальна особа» без ПІБ та посади. Бібліотека КПІ (яка є офіційним RDM-центром університету - див. Положення про УДД) взагалі не згадується, а її послуги не включені як безпосередній нефінансовий внесок (non-financial contribution) у проєкт.
Причина: Брак інформованості про те, що в університеті вже є готова RDM-інфраструктура підтримки.
Тип 4. Плутання «подати DMP» з «вести DMP»
Симптом: Переконання, що план пишеться один раз на початку проєкту.
Приклад: Відсутність графіка планових оновлень (наприклад, на місяцях M6, M18, M30 для тривалих проєктів), повне ігнорування спеціалізованих платформ (DMPonline або ARGOS) та відсутність умов для позапланового апдейту (зміна складу партнерів, форс-мажори, нові умови ембарго).
Причина: Освітня прогалина щодо концепції Living DMP (живого документа), яка є базовою для Horizon Europe.
💡 Висновок для авторів та експертів: Найслабші місця планів — це точки конкретних зобов'язань: назва репозитарію, чітка ліцензія, терміни, імена. Фрази типу «дані будуть доступні» або «проєкт відповідає принципам FAIR» без операційного підтвердження більше не приймаються.
Як вирішити цю проблему системно?
В університеті розроблено деталізований університетський шаблон (див. додатки до Положення про УДД), рекомендації з інструктивними підказками для кожного поля. Це допоможе авторам проходити валідацію з першого разу.
У разі виникнення питань щодо ліцензування метаданих (CC0), вибору відкритих форматів чи інтеграції інфраструктури бібліотеки у ваш грант — звертайтеся за консультацією до Бібліотеки КПІ ім. Ігоря Сікорського!
