Нормативно-правові акти у сфері цифровізації ЗСУ. Практика застосування
Тема 1: Стратегічні засади цифрової трансформації ЗСУ · Заняття 2
Довідково-інформаційний (опорний) конспект викладача
Матеріал призначений для викладача як змістовна основа семінару: тези для введення в кожне питання, еталонні формулювання для коригування відповідей слухачів і фактологічна база. Слухачам у повному обсязі не роздається.
А. Інститут CDTO і структура цифрової трансформації у Силах оборони
Що таке CDTO. CDTO (Chief Digital Transformation Officer) — керівник із цифрової трансформації. Інститут CDTO вибудуваний в Україні Міністерством цифрової трансформації: мережа керівників ЦТ у міністерствах, обласних адміністраціях і громадах, які стали рушійною силою системної цифровізації держави. Саме цю перевірену модель Сили оборони масштабують у війську з урахуванням швидкості й специфіки війни.
Структура ЦТ (IT-вертикаль). Це мережа військових посад фахівців із цифрової трансформації на всіх рівнях — від батальйону до Генерального штабу ЗСУ та Міністерства оборони. Мета — щоб корисні цифрові рішення з’являлися у підрозділах максимально швидко: скорочення бюрократії, оперативне тестування, впровадження й масштабування. Головний вимірюваний результат структури — швидкість впровадження інновацій (асиметрична перевага над противником).
Роль «містка». Підрозділ ЦТ — це інтерфейс між бойовими/функціональними підрозділами (носіями реальних потреб) і командами розробки (реалізаторами). Він збирає зворотний зв’язок і потреби, формує вимоги до продуктів, ініціює розробку, координує запуск і масштабування, розвиває цифрову культуру.
Нормативне закріплення структури ЦТ (для викладача):
- положення про підрозділ ЦТ — визначає завдання, підпорядкування, повноваження та звітність вашого підрозділу ЦТ. Точні пункти (завдання, підпорядкованість, порядок звітності, перелік посад) викладач цитує безпосередньо з чинної редакції документа;
- наказ МО № 38 від 13.01.2026 — унормовує функціонування структури цифрового розвитку, цифрових трансформацій і цифровізації МО;
- Положення про Директорат цифрової трансформації у сфері оборони — визначає повноваження й функції центрального органу вертикалі (зі змінами — наказ № 374 від 06.06.2025).
Рівні структури цифрової трансформації:
| Рівень | Роль у вертикалі ЦТ |
|---|---|
| Міністерство оборони (Директорат ЦТ у сфері оборони) | Формування політик ЦТ, стандартів, реєстрів; координація вертикалі; пріоритезація й нагляд за портфелем продуктів. |
| Генеральний штаб та апарат Головнокомандувача ЗСУ | Операціоналізація стратегії у щорічні завдання (директива НГШ); координація ЦТ видів/родів військ. |
| Види, роди військ, органи військового управління | Адаптація завдань під специфіку; збір потреб; впровадження й масштабування рішень у підпорядкованих частинах. |
| Військові частини та підрозділи (від батальйону) | Виявлення реальних потреб «на місці», пілотування, повсякденне використання, зворотний зв’язок розробникам. |
Ролі у підрозділі ЦТ і зони відповідальності:
| Роль | Основна зона відповідальності |
|---|---|
| Керівник підрозділу ЦТ (Digital Transformation Lead) | Узгодження цифрових ініціатив зі стратегічними цілями командування; реалізація політик ЦТ; впровадження продуктів і забезпечення їх повсякденного використання; управління стейкхолдерами; звітність. |
| Проєктний менеджер (Project Manager) | Планування, обсяг, строки, бюджет/ресурси; управління ризиками; координація команд і постачальників; статус-звітність. |
| Бізнес-аналітик (Business Analyst) | Виявлення потреб і болю підрозділів; формування та управління вимогами; підготовка/супровід ТЗ; приймальні критерії; трасування вимог. |
| Аналітик даних (Data Analyst) | Метрики продукту, дашборди, рішення на основі даних; вимірювання ефективності впровадження. |
| Фахівець із супроводження продукту (Product Support) | Повсякденна експлуатація, обробка інцидентів і звернень користувачів, канал зворотного зв’язку. |
| Технічний письменник (Technical Writer) | Документація, регламенти, інструкції користувача, звітні артефакти. |
Повноваження і відповідальність. Наказ наділяє офіцера ЦТ конкретними повноваженнями (ініціювати проєкт/НПА, погоджувати, вимагати відповідності стандартам) і водночас встановлює межі відповідальності (строки виконання, порядок звітності, дисциплінарна відповідальність за порушення). Знання цих меж — практична, а не теоретична компетентність.
Б. Ієрархія НПА у сфері цифровізації ЗСУ
Логіка вертикалі: документ нижчого рівня конкретизує вищий і не може йому суперечити. Офіцер ЦТ читає піраміду «згори вниз» (звідки повноваження) і «знизу вгору» (чи не суперечить моя дія вищому рівню).
| Рівень | Приклади документів | Що дає офіцеру ЦТ |
|---|---|---|
| Закони України | Про національну безпеку; Про кібербезпеку (2163-VIII); Про електронні комунікації (1089-IX); Про захист інформації в ІКС; Про захист персональних даних (2297-VI). | Рамкові вимоги: безпека, захист інформації та ПД, легітимність обробки даних. |
| Акти КМУ | ПКМУ «Деякі питання цифрової трансформації» № 945; акти щодо підрозділів ЦТ / інституту CDTO. | Загальнодержавні правила гри для ЦТ, у т.ч. модель CDTO. |
| Накази Міноборони | Наказ № 38 (функціонування структури ЦТ); Положення про Директорат ЦТ; положення про підрозділ; порядок впровадження ІКС і реєстр ІКС. | Конкретні процедури: хто, що, у які строки, кому підпорядкований і звітує. |
| Документи ГШ ЗСУ | Щорічна директива НГШ з питань цифрового розвитку. | Річні завдання й пріоритети — основа планування та OKR підрозділу. |
| Внутрішні акти підрозділу | Положення про підрозділ, регламенти, накази командира, інструкції. | Операційні правила «на місці», приведені у відповідність до вищих рівнів. |
В. Продуктовий і проєктний підхід. Роль PM/BA як «місток» між НПА і практикою
Структура ЦТ працює у продуктовій логіці: рішення створюють не «під звіт», а під реальну потребу користувача, з вимірюваним результатом і подальшим розвитком. Проєктний підхід при цьому лишається інструментом для дискретних робіт із чіткими межами (наприклад, впровадження конкретної ІКС).
| Ознака | Проєктний підхід | Продуктовий підхід |
|---|---|---|
| Фокус | Здати обсяг у строк і бюджет. | Створити цінність для користувача, що вимірюється. |
| Горизонт | Обмежений (є кінець проєкту). | Тривалий життєвий цикл із розвитком. |
| Успіх | Виконано ТЗ. | Рішення реально використовується і дає ефект. |
| Ключова роль | Project Manager. | Product owner / DT Lead + BA + Data Analyst. |
Життєвий цикл ІКС і відповідні НПА (ядро практики)
Кожен крок життєвого циклу «прив’язаний» до нормативної вимоги і породжує артефакт. Саме тут абстрактні НПА перетворюються на конкретні дії PM/BA. Детальна таблиця винесена у Додаток 2; нижче — ключова логіка.
- 1) Discovery (виявлення потреби): фіксуємо реальну потребу/біль підрозділу (роль BA/DT Lead). Артефакт: проблемна заява, попередні метрики.
- 2) Вимоги (requirements): перетворюємо потребу на вимоги різних рівнів (бізнес → стейкхолдер → рішення). Артефакт: специфікація вимог.
- 3) Технічне завдання: формалізуємо вимоги у ТЗ згідно з методичними рекомендаціями ВІТІ/МО; закладаємо ЗІ, ПД, рольову модель доступу. Артефакт: ТЗ і приймальні критерії.
- 4) Погодження й експертизи: юридична служба, орган захисту інформації/держтаємниці, ФЕО (за наявності фінансових наслідків). Артефакт: аркуш погодження.
- 5) Закупівля/розробка: за вимогами договірних НПА; закладаємо права на код/документацію, гарантії, аудит безпеки. Артефакт: договір/ТЗ на розробку.
- 6) Пілот / дослідна експлуатація: перевірка відповідності ТЗ і вимогам ЗІ у контрольованих умовах. Артефакт: акт/протокол випробувань.
- 7) Реєстрація: внесення ІКС до відповідного реєстру — умова легітимного використання. Артефакт: запис у реєстрі ІКС.
- 8) Промислова експлуатація і супровід: штатне використання; збір метрик і зворотного зв’язку; ітеративний розвиток. Артефакт: метрики, беклог доопрацювань.
Головний висновок для слухачів: пропуск будь-якого кроку (найчастіше — погодження, ЗІ/ПД, реєстрації) перетворює корисне рішення на джерело правового ризику.
Requirements engineering: як BA перетворює потребу на верифіковане ТЗ
- Рівні вимог: бізнес-вимоги (навіщо, який ефект) → стейкхолдер-вимоги (що потрібно користувачам) → вимоги до рішення (функціональні й нефункціональні: безпека, доступність, продуктивність) → перехідні вимоги (міграція, навчання).
- Критерії якості вимоги: однозначність, повнота, несуперечливість, верифіковність, трасовність (кожна вимога має джерело й приймальний критерій). Орієнтир для формулювань — принцип SMART.
- Приймальні критерії: для кожної суттєвої вимоги — умова, за якої вона вважається виконаною; це основа приймання ІКС і захисту підрозділу у спорі з підрядником.
OKR, метрики та управління стейкхолдерами
- OKR: директива НГШ і плани вищого рівня операціоналізуються у цілі та ключові результати (OKR) підрозділу ЦТ на рік; ігнорування директиви при плануванні — типова помилка, що виявляється під час інспекцій.
- Метрики: провідна метрика структури — швидкість впровадження інновацій; на рівні продукту — рівень використання, час обробки задачі, задоволеність користувачів.
- Стейкхолдери: командування (замовник ефекту), бойові/функціональні підрозділи (користувачі), розробники/постачальники (виконавці), юрслужба, орган ЗІ/ДТ, ФЕО (погоджувачі-контролери). Розподіл відповідальності зручно фіксувати матрицею RACI.
1. Структура та діяльність підрозділів ЦТ. Ключові накази МО і директиви ГШ: місце офіцера ЦТ у системі НПА (20 хв)
Методичні вказівки з проведення питання 1
Перед обговоренням викладач 2–3 хв нагадує ієрархію НПА (розділ Б) і структуру ЦТ (розділ А), наголошуючи: мета питання — не перелік документів, а розуміння, звідки в офіцера ЦТ повноваження, кому він підпорядкований, за що відповідає і як це закріплено у положенні про підрозділ та наказі № 38. На фліпчарті доцільно зобразити вертикаль «МО → ГШ → види/роди → частини → підрозділи».
Запитання 1.1
Який документ конституює ваш підрозділ ЦТ? Назвіть його завдання, кому підрозділ підпорядкований і як звітує. Чим повноваження офіцера ЦТ відрізняються від повноважень звичайного офіцера зв’язку/ІТ?
Очікувана відповідь: завдання, підпорядкування, повноваження та звітність підрозділу визначаються положенням про підрозділ ЦТ та наказом МО № 38 про функціонування структури ЦТ (конкретні пункти слухач має вміти назвати). Підрозділ ЦТ вбудований у вертикаль (від частини до Директорату ЦТ у сфері оборони) і працює як «місток» між користувачами й розробниками. Відмінність офіцера ЦТ: він не лише експлуатує ІТ, а й ініціює зміни — виявляє потреби, формує вимоги, ініціює розробку, координує впровадження й масштабування.
Додаткове запитання (за поверхневої відповіді): «Наведіть конкретний пункт положення про ваш підрозділ, який визначає, кому ви звітуєте і в які строки».
Запитання 1.2
Які ролі передбачені у структурі ЦТ і як між ними розподіляється відповідальність при впровадженні нового рішення? Хто відповідає за вимоги, хто — за строки й ресурси, хто — за метрики?
Очікувана відповідь: Digital Transformation Lead — стратегія й узгодження з цілями командування; Project Manager — строки, ресурси, ризики; Business Analyst — потреби, вимоги, ТЗ, приймальні критерії; Data Analyst — метрики й рішення на основі даних; Product Support — експлуатація і зворотний зв’язок; Technical Writer — документація. Слухач має показати, що впровадження — командна робота з чітким поділом зон відповідальності (доцільно згадати RACI).
Запитання 1.3
Яке практичне значення щорічної директиви НГШ з питань цифрового розвитку для планування роботи підрозділу ЦТ? Як вона пов’язана з наказами МО і з вашими OKR на рік?
Очікувана відповідь: директива НГШ — щорічний документ оперативного планування, який операціоналізує стратегічні положення наказів МО у конкретні завдання, строки й відповідальних на рік. Вона обов’язкова до виконання і має враховуватися при формуванні річного плану та OKR підрозділу. Ігнорування директиви призводить до невиконання планових показників, що перевіряються під час інспекцій ГШ.
Коментар викладача: підкреслити зв’язок «директива → річний план → OKR → беклог продуктів».
Запитання 1.4
Запропонуйте алгоритм систематичного моніторингу змін у НПА у підрозділі.
Очікувана відповідь: визначити офіційні джерела (сайти МО і ГШ, Верховна Рада — zakon.rada.gov.ua, Офіційний вісник України); призначити відповідального за реєстр НПА; встановити періодичність перевірки (нові НПА — не рідше 1 разу на місяць, наявні — щотижня); мати механізм інформування підлеглих і суміжних підрозділів; доводити нові вимоги до особового складу.
Підсумок з питання 1
Положення про підрозділ ЦТ — це «паспорт» офіцера ЦТ: воно одночасно наділяє його повноваженнями і встановлює межі відповідальності. Знання своєї ролі у вертикалі, підпорядкування, звітності й зв’язку з директивою НГШ — базова управлінська компетентність, без якої неможливе жодне легітимне впровадження.
2. Життєвий цикл ІКС і роль вимог/ТЗ. Порядок розробки та погодження НПА у підрозділі ЦТ (20 хв)
Методичні вказівки з проведення питання 2
Викладач записує на фліпчарті дві схеми: (1) життєвий цикл ІКС «Потреба → Вимоги → ТЗ → Погодження → Розробка → Пілот → Реєстрація → Експлуатація» (розділ В, Додаток 2) і (2) нормотворчий цикл «Ініціювання → Розробка → Погодження → Затвердження → Реєстрація». Слухачі наповнюють кожен етап конкретним змістом, викладач перевіряє повноту.
Запитання 2.1
Опишіть життєвий цикл ІКС від потреби до промислової експлуатації. На яких кроках і які НПА стають обов’язковими? Де саме «вмикається» реєстр ІКС і дослідна експлуатація?
Очікувана відповідь: discovery → вимоги → ТЗ (із закладеними вимогами ЗІ, ПД, рольовою моделлю) → погодження й експертизи → закупівля/розробка за договірними НПА → дослідна експлуатація (перевірка відповідності ТЗ і ЗІ) → реєстрація в реєстрі ІКС (умова легітимного використання) → промислова експлуатація і супровід. Пропуск кроку 4, вимог ЗІ/ПД на кроці 3 чи кроку 7 (реєстрація) — головні джерела ризику.
Запитання 2.2
Роль бізнес-аналітика: як потреба підрозділу перетворюється на верифіковане ТЗ? Які вимоги обов’язково закладаються у ТЗ на ІКС і навіщо потрібні приймальні критерії?
Очікувана відповідь: BA рухається рівнями вимог (бізнес → стейкхолдер → рішення → перехідні), забезпечуючи однозначність, повноту й трасовність. У ТЗ обов’язково закладаються нефункціональні вимоги: захист інформації, розмежування прав доступу (рольова модель), відповідність вимогам щодо ПД, а також гарантії, документація, права на код. Приймальні критерії фіксують, за якої умови вимога вважається виконаною — це основа приймання ІКС і захисту підрозділу у спорі з підрядником.
Запитання 2.3
Опишіть порядок ініціювання та погодження НПА у сфері ЦТ. Хто може бути ініціатором, хто погоджує проєкт і яких помилок найчастіше припускаються?
Очікувана відповідь (ініціювання): ініціатор — командування виду (Сили) ЗСУ, ОВУ, підрозділ МО, ГШ. Для ініціювання потрібні: службова записка/рапорт з обґрунтуванням; аналіз наявної бази (чому чинних документів недостатньо); попередній проєкт або концепція; оцінка ресурсних потреб.
Очікувана відповідь (погодження): підрозділ ЦТ погоджує НПА щодо впровадження ІКС/СКП, цифровізації процесів, захисту інформації, стандартів ІТ-рішень; перевіряє відповідність вищим НПА, технічну коректність, вимоги ЗІ, реальність строків. Також погоджують: юридична служба (правова експертиза), орган захисту держтаємниці (для інформації з обмеженим доступом), ФЕО (за фінансових наслідків).
Типові помилки: невідповідність вищому рівню; надмірна деталізація «під конкретний продукт» (vendor lock-in уже на рівні НПА); відсутність механізму контролю виконання; ігнорування вимог ЗІ/ПД; зрив строків погодження, що спонукає до формального підпису.
Підсумок з питання 2
Офіцер ЦТ — активний учасник і життєвого циклу ІКС, і нормотворчого процесу. Якість вимог і ТЗ на ранніх кроках визначає правову захищеність усього подальшого впровадження: дешевше «закласти» ЗІ, ПД і права на код у ТЗ, ніж усувати наслідки згодом.
3. Типові правові ризики при впровадженні ІКС: аналіз кейсів та шляхи мінімізації (15 хв)
Методичні вказівки з проведення питання 3
Питання проводиться методом аналізу ситуаційних завдань. Викладач роздає картки з кейсами (Додаток 1) по одному на 2–3 слухачів; на обговорення в парах/трійках — 3–4 хв. Представлення відповіді слухачі будують за єдиною структурою: (1) який ризик реалізувався; (2) наслідок для підрозділу/командира; (3) корінна причина; (4) захід із виправлення; (5) профілактика на майбутнє. Ця структура оцінюється за Додатком 3.
Кейс 1. «Впровадження без погодження і реєстрації»
Розбір: ризики — порушення порядку впровадження ІКС; використання незареєстрованої в реєстрі ІКС; можливе порушення вимог ЗІ (невідома класифікація). Наслідки — дисциплінарна відповідальність офіцера ЦТ і командира; можливе зупинення системи до реєстрації; репутаційні ризики. Корінна причина — відсутність процедури попередньої перевірки ПЗ. Заходи — невідкладно ініціювати погодження й реєстрацію; оцінити відповідність вимогам ЗІ; підготувати пояснювальну командиру. Профілактика — запровадити обов’язкову перевірку будь-якого нового ПЗ перед розгортанням (крок 4 життєвого циклу).
Кейс 2. «Персональні дані без підстав»
Розбір: порушення — Закон «Про захист персональних даних» (надмірний доступ без обґрунтованої мети) і вимог ЗІ (відсутнє розмежування прав доступу). Заходи — негайно обмежити доступ за принципом мінімальної необхідності; задокументувати зміни; у разі витоку — повідомити Уповноваженого й постраждалих. Корінна причина — відсутність рольової моделі доступу у ТЗ. Профілактика — обов’язкова вимога у ТЗ: рольова модель і відповідність законодавству про ПД ще на етапі проєктування (крок 3 життєвого циклу).
Кейс 3. «Постачальник без вимог»
Розбір: ризики — технологічна залежність від одного постачальника (vendor lock-in); неможливість незалежної підтримки й розвитку; невизначеність відповідності ІКС вимогам ЗІ (аудит не проводився). Обов’язкові вимоги до договору: передача вихідного коду й документації замовнику (або депонування/ескроу у незалежному репозиторії); відповідність вимогам ЗІ, підтверджена незалежним аудитом; гарантійні зобов’язання і строки підтримки; заборона нецільового використання ІКС; механізм передачі прав у разі припинення діяльності підрядника. Профілактика — закладати ці умови ще у ТЗ (крок 3) і договір (крок 5).
Кейс 4 (резервний). «Тіньова цифровізація» (Shadow IT)
Розбір: підрозділ використовує сторонні хмарні сервіси/месенджери для службових даних без погодження. Ризики — неконтрольований потік даних, порушення вимог ЗІ/держтаємниці, втрата даних при блокуванні сервісу. Заходи — інвентаризація застосовуваних сервісів, переведення на легітимні ІКС, регламент допустимих інструментів. Профілактика — політика допустимого ПЗ і навчання особового складу.
Підсумок з питання 3
Правові ризики — не абстрактна загроза, а реальний чинник, що може зупинити роботу підрозділу й зашкодити кар’єрі відповідальних. Основний інструмент мінімізації — системна робота з вимогами й НПА на ранніх кроках життєвого циклу (discovery, вимоги, ТЗ, погодження), до початку впровадження.
Завдання на самостійну підготовку
- Завдання 1. За положенням про ваш підрозділ ЦТ (та наказом № 38) скласти одну сторінку: завдання власного підрозділу ЦТ, підпорядкування, порядок звітності та ваша роль у команді (DT Lead/PM/BA/…).
- Завдання 2. Для типової потреби свого підрозділу оформити коротку специфікацію вимог (3–5 вимог різних рівнів) із приймальними критеріями та обов’язковими вимогами ЗІ/ПД (заготовка ТЗ).
- Завдання 3. Побудувати міні-мапу життєвого циклу ІКС для одного реального рішення свого підрозділу з позначенням НПА і артефакта на кожному кроці (за зразком Додатка 2).
Додаток 1. Картки ситуаційних завдань (роздатковий матеріал)
Кожна картка видається групі з 2–3 слухачів. Структура відповіді єдина: ризик → наслідок → корінна причина → захід із виправлення → профілактика.
| КЕЙС 1. «ВПРОВАДЖЕННЯ БЕЗ ПОГОДЖЕННЯ І РЕЄСТРАЦІЇ» |
|---|
| Підрозділ ЦТ бригади самостійно розгорнув програмний продукт для управління логістикою, не провівши погодження та не внісши систему до реєстру ІКС. Система використовується 3 місяці. Під час планової перевірки орган ГШ виявив незареєстровану ІКС. |
| Питання для обговорення: Які правові ризики реалізувалися? Які наслідки для підрозділу та командира? Яка корінна причина ситуації? Які заходи вжити для виправлення? Як запобігти подібному надалі? |
| КЕЙС 2. «ПЕРСОНАЛЬНІ ДАНІ БЕЗ ПІДСТАВ» |
|---|
| При впровадженні МІС підрозділ ЦТ надав лікарям доступ до медичних карток усього особового складу без диференціації прав. Будь-який лікар переглядає картки всіх військовослужбовців. Після скарги розпочато перевірку Уповноваженого із захисту персональних даних. |
| Питання для обговорення: Яке законодавство порушено? Які технічні та організаційні заходи потрібні? Яка корінна причина (де саме «прогалина» у ТЗ)? Як підрозділ ЦТ міг запобігти цьому при впровадженні? |
| КЕЙС 3. «ПОСТАЧАЛЬНИК БЕЗ ВИМОГ» |
|---|
| Підрозділ ЦТ уклав договір з ІТ-компанією на розробку програмного комплексу без вимог щодо: передачі вихідного коду, відповідності вимогам захисту інформації, незалежного аудиту безпеки. Через рік компанія припинила діяльність. Підрозділ залишився без можливості підтримки й розвитку системи. |
| Питання для обговорення: Які правові та операційні ризики реалізувалися? Які обов’язкові вимоги мали бути у ТЗ і договорі? На якому кроці життєвого циклу закладається профілактика? |
| КЕЙС 4 (РЕЗЕРВНИЙ). «ТІНЬОВА ЦИФРОВІЗАЦІЯ» (SHADOW IT) |
|---|
| Особовий склад використовує сторонні хмарні сервіси й месенджери для обробки службових даних без погодження з підрозділом ЦТ та органом захисту інформації. |
| Питання для обговорення: Які ризики створює така практика? Які заходи вжити негайно? Яка політика/регламент запобігає Shadow IT? |
Додаток 2. Опорна схема «Життєвий цикл ІКС ↔ НПА ↔ артефакт»
| Крок | Етап | Нормативна вимога / контроль | Артефакт |
|---|---|---|---|
| 1 | Discovery (виявлення потреби) | Завдання підрозділу ЦТ (положення про підрозділ; наказ № 38); директива НГШ. | Проблемна заява, попередні метрики. |
| 2 | Вимоги (requirements) | Вимоги ЗІ та ПД; стандарти ІТ-рішень. | Специфікація вимог (рівні + критерії). |
| 3 | Технічне завдання | Метод. рекомендації щодо ТЗ на ІКС; рольова модель доступу; ПД. | ТЗ + приймальні критерії. |
| 4 | Погодження й експертизи | Юрслужба; орган ЗІ/держтаємниці; ФЕО. | Аркуш погодження. |
| 5 | Закупівля / розробка | Договірні НПА; права на код; гарантії; аудит. | Договір / ТЗ на розробку. |
| 6 | Пілот / дослідна експлуатація | Порядок впровадження ІКС; перевірка ЗІ. | Акт/протокол випробувань. |
| 7 | Реєстрація | Ведення реєстру ІКС/СКП — умова легітимності. | Запис у реєстрі ІКС. |
| 8 | Промислова експлуатація і супровід | Регламенти експлуатації; захист даних; звітність. | Метрики, беклог доопрацювань. |
Додаток 3. Критерії оцінювання роботи слухача на семінарі
| Критерій | Бали | Орієнтир |
|---|---|---|
| Знання структури ЦТ і своєї ролі (завдання, підпорядкування, звітність) | 0–3 | Називає конкретні положення, а не загальні фрази. |
| Зв’язок НПА з кроками життєвого циклу ІКС | 0–3 | Показує, який НПА «вмикається» на кожному кроці. |
| Якість аналізу кейсу (5 елементів структури) | 0–3 | Ризик → наслідок → причина → захід → профілактика. |
| Аргументованість і активність у дискусії | 0–1 | Логіка, посилання на НПА, коректність. |
| Разом | 0–10 | 9–10 — «відмінно»; 7–8 — «добре»; 5–6 — «задовільно». |
Додаток 4. Глосарій ключових термінів
- CDTO (Chief Digital Transformation Officer) — керівник із цифрової трансформації; інститут, вибудуваний в органах влади й масштабований у Силах оборони як структура ЦТ (IT-вертикаль).
- Структура ЦТ / IT-вертикаль — мережа військових посад фахівців із цифрової трансформації від батальйону до ГШ і МО.
- ІКС — інформаційно-комунікаційна система.
- СКП — система(и) ситуаційної обізнаності / командування й управління (за термінологією відповідного НПА).
- Реєстр ІКС — перелік легітимних систем; внесення до реєстру — умова правомірного використання ІКС.
- ТЗ — технічне завдання — формалізовані вимоги до ІКС, основа розробки й приймання.
- Requirements engineering — інженерія вимог: виявлення, аналіз, специфікація та управління вимогами (рівні: бізнес, стейкхолдер, рішення, перехідні).
- Приймальні критерії — умови, за яких вимога вважається виконаною; основа приймання ІКС.
- MVP — мінімально життєздатний продукт — найменша версія рішення, що дає перевірювану цінність.
- OKR — Objectives and Key Results — цілі та вимірювані ключові результати; інструмент річного планування підрозділу.
- RACI — матриця розподілу відповідальності: Responsible, Accountable, Consulted, Informed.
- Vendor lock-in — технологічна залежність від одного постачальника через відсутність прав на код/документацію та альтернатив.
- Shadow IT — використання непогоджених ІТ-сервісів для службових завдань поза контролем підрозділу ЦТ.
- ЗІ / ПД — захист інформації / персональні дані — обов’язкові нефункціональні вимоги до будь-якої ІКС.