Організаційна структура підрозділів ЦТ. Зони відповідальності. Цикл управлінських рішень

Тема 1: Стратегічні засади цифрової трансформації ЗСУ · Заняття 3

1. Принципи формування та розгортання підрозділів ЦТ ЗСУ

1.1. IT-вертикаль: сутність і призначення

Структура цифрової трансформації (IT-вертикаль) — це мережа військових посад фахівців із ЦТ на всіх рівнях: від батальйону до Генерального штабу ЗСУ та Міністерства оборони. Її призначення — щоб корисні цифрові рішення з’являлися у підрозділах максимально швидко, а бюрократія не гальмувала впровадження. Ключова функція підрозділу ЦТ — бути «містком» між користувачами (бойові та функціональні підрозділи) і розробниками рішень.

1.2. Рівні структури

Рівень	Роль у вертикалі
МО (Директорат ЦТ у сфері оборони)	Політики, стандарти, реєстри; координація вертикалі; нагляд за портфелем продуктів.
ГШ та апарат Головнокомандувача ЗСУ	Операціоналізація стратегії у щорічні завдання (директива НГШ); координація ЦТ видів/родів військ.
Види, роди військ, ОВУ	Адаптація завдань; збір потреб; впровадження й масштабування у підпорядкованих частинах.
Військові частини та підрозділи	Виявлення потреб «на місці», пілотування, повсякденне використання, зворотний зв’язок.

1.3. Принципи формування

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

1.4. Етапи розгортання підрозділу

Визначення потреби й штатної структури, набір за ролями (DT Lead, PM, BA, Data Analyst, Product Support, Technical Writer).
Підготовка й навчання фахівців (зокрема через CDTO Campus та навчальні програми у ВВНЗ).
Інтеграція у штат частини та у мережу вертикалі; налагодження звітності й взаємодії.
Запуск перших продуктових ініціатив, збір зворотного зв’язку, масштабування.

1.5. Зв’язок з інститутом CDTO

Модель структури ЦТ масштабує перевірений інститут CDTO, вибудуваний Міністерством цифрової трансформації в органах влади (керівники ЦТ у міністерствах, ОДА, громадах). Сили оборони переносять цю модель у військо з урахуванням швидкості й специфіки війни.

1.6. Основні функції підрозділу ЦТ

Незалежно від рівня, підрозділ ЦТ виконує повторюваний набір функцій, що відрізняє його від технічних служб:

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

Типові помилки:

сприйняття підрозділу ЦТ як «ще одного ІТ-відділу» для обслуговування техніки;
ізоляція від вертикалі — рішення «для себе» без обміну й масштабування;
набір «під людину», а не під роль і потребу.

Проміжний висновок: підрозділ ЦТ — це елемент єдиної вертикалі й «місток» між користувачами й розробниками, а не автономний ІТ-відділ.

2. Зони відповідальності та розподіл функцій між ролями структури ЦТ

2.1. Базовий принцип

Ефективність підрозділу залежить від чіткого розмежування «хто за що відповідає». Базовий принцип — «одна зона відповідальності має рівно одного відповідального (accountable)». Розмиті або подвійні зони відповідальності — головна причина зривів і конфліктів у команді.

2.2. Ролі та їх зони відповідальності

Роль	Зона відповідальності
Digital Transformation Lead	Стратегія й узгодження ініціатив із цілями командування; політики ЦТ; впровадження й масштабування; стейкхолдери; звітність.
Project Manager	Планування, обсяг, строки, ресурси, бюджет; ризики; координація команд і постачальників.
Business Analyst	Виявлення потреб; вимоги; ТЗ; приймальні критерії; трасування вимог.
Data Analyst	Метрики, дашборди, рішення на основі даних; вимірювання ефекту.
Product Support	Повсякденна експлуатація, інциденти, звернення користувачів, зворотний зв’язок.
Technical Writer	Документація, регламенти, інструкції користувача, звітні артефакти.

2.3. Матриця RACI

RACI — інструмент розподілу відповідальності за кожним завданням: Responsible (виконує), Accountable (відповідає за результат, лише один), Consulted (консультують), Informed (інформують). Приклад для типового завдання впровадження ІКС:

Завдання	DT Lead	PM	BA	Support
Формування вимог і ТЗ	C	A	R	I
Планування впровадження	A	R	C	I
Підтримка після запуску	I	C	I	A/R

2.4. Розмежування ЦТ та служб зв’язку / ІТ-експлуатації

Підрозділ ЦТ відповідає за зміни: виявлення потреб, формування вимог, ініціювання та впровадження рішень. Служби зв’язку та ІТ-експлуатації відповідають за рутинне обслуговування інфраструктури. Змішування цих ролей призводить до того, що підрозділ ЦТ «тоне» в поточній підтримці й не займається трансформацією.

2.5. Взаємодія ролей

PM–BA: PM надає BA контекст строків, залежностей та обмежень; отримує структуровані вимоги.
PM–DA: PM формулює data-запит; отримує метрики для управління delivery та оцінки ефекту.
PM–Support: PM отримує сигнали від підтримки (повторювані проблеми, ризики після запуску, рівень adoption).

Типові помилки:

дві ролі accountable за одне завдання (ніхто реально не відповідає);
розмиті зони — «всі за все»;
підрозділ ЦТ підмінює службу експлуатації й не встигає на трансформацію.

Проміжний висновок: чіткі зони відповідальності (RACI) перетворюють набір фахівців на керовану команду.

3. Цикл прийняття управлінських рішень: методи аналізу, синтезу та оцінки альтернатив

3.1. Навіщо свідомий цикл

Управлінське рішення офіцера ЦТ доцільно зробити свідомим і документованим процесом, а не інтуїтивним актом. Це підвищує якість рішень, дозволяє їх обґрунтувати перед командуванням і повернутися до логіки згодом.

3.2. Етапи циклу

Визначення проблеми/можливості: що саме вирішуємо і навіщо (у термінах outcome).
Збір даних та аналіз: розуміння причин і контексту.
Генерація альтернатив (синтез): кілька варіантів рішення, а не один «очевидний».
Оцінка альтернатив за критеріями: зважене порівняння.
Вибір і реалізація рішення.
Контроль результату та зворотний зв’язок: чи досягнуто outcome.

3.3. Методи аналізу

Декомпозиція — розкладання складної проблеми на частини для окремого аналізу.
Причинно-наслідковий аналіз — пошук першопричини методом «5 чому» та побудова діаграми Ішикави («риб’ячий скелет»).
Аналіз припущень — перевірка, які припущення лежать в основі проблеми і наскільки вони обґрунтовані.

3.4. Методи синтезу (генерація альтернатив)

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

3.5. Оцінка альтернатив: критеріальна матриця

Альтернативи порівнюють за зваженими критеріями (цінність, вартість, строк, ризик, безпека). Приклад (детальний шаблон — Додаток 2):

Критерій (вага)	Вага	Варіант А	Варіант Б	Варіант В
Оборонна цінність	0,4	5	3	4
Строк реалізації	0,3	2	5	3
Ризик / безпека	0,3	3	4	5
Зважена сума		3,5	3,9	4,0

3.6. Рішення в умовах невизначеності

Часто рішення ухвалюються за неповних даних. Тут допомагають фіксація припущень, сценарний підхід і ризик-менеджмент (детально — Тема 2, Заняття 4). Головне — свідомо розрізняти, що ми знаємо, а що припускаємо.

Типові помилки:

стрибок від проблеми одразу до єдиного рішення без альтернатив;
«аналіз-параліч» — нескінченний збір даних без рішення;
вибір «на емоціях» без критеріальної оцінки.

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

4. Підходи та методи постановки цілей: SMART, MBO, збалансована система показників

4.1. Навіщо методи постановки цілей

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

4.2. SMART

Specific — конкретна (що саме);
Measurable — вимірювана (за яким показником);
Achievable — досяжна (реалістична);
Relevant — релевантна (підтримує вищу ціль);
Time-bound — обмежена в часі (до якого строку).

Приклад. Погана ціль: «покращити облік». SMART-ціль: «скоротити час інвентаризації майна у частині з 3 днів до 1 дня до кінця ІІ кварталу».

4.3. MBO (управління за цілями)

MBO — підхід, за якого цілі каскадуються від організації до підрозділів і виконавців, узгоджуються «згори-вниз» і «знизу-вгору», а результати періодично переглядаються. У структурі ЦТ MBO реалізується через каскад завдань вертикалі.

4.4. Збалансована система показників (BSC)

BSC пропонує оцінювати діяльність через кілька збалансованих перспектив, щоб не оптимізувати одне на шкоду іншому. Адаптація для підрозділу ЦТ:

Перспектива	Приклад показника для підрозділу ЦТ
Результат / місія	Внесок в оборонну ефективність (швидкість, точність рішень).
Користувачі	Рівень використання рішень, задоволеність військових.
Процеси	Час від потреби до впровадження; частка успішних пілотів.
Розвиток	Компетенції команди, зрілість практик ЦТ.

4.5. Коли що застосовувати

SMART — для формулювання окремих цілей і ключових результатів;
MBO — для каскаду цілей у вертикалі;
BSC — для комплексної, збалансованої оцінки діяльності підрозділу.

4.6. Зв’язок з OKR

OKR (Заняття 4) поєднує сильні сторони цих підходів: амбітну якісну ціль (Objective) і вимірювані результати (Key Results, за критеріями SMART), з регулярним переглядом (як у MBO). Це заняття готує до практичної роботи з OKR.

Типові помилки:

ціль-гасло без вимірюваного показника;
ціль у форматі завдання («провести навчання») замість результату;
оптимізація одного показника на шкоду іншим (відсутність балансу).

Проміжний висновок: SMART, MBO та BSC — взаємодоповнювані інструменти, що роблять цілі підрозділу вимірюваними, узгодженими й збалансованими.

5. Value prioritization: принципи визначення пріоритетності цифрових ініціатив

5.1. Чому пріоритезація — щоденна дія

Ресурси підрозділу ЦТ (люди, час, кошти) завжди обмежені, а потреб більше, ніж можливостей. Тому пріоритезація — не разовий, а щоденний управлінський процес. Відсутність явних пріоритетів означає, що їх стихійно визначає той, хто голосніше вимагає.

5.2. Складові пріоритету

Пріоритет ініціативи визначається співвідношенням: цінність (ефект) × терміновість, поділене на зусилля/ризик. Висока цінність за малих зусиль — найвищий пріоритет; низька цінність за великих зусиль — найнижчий.

5.3. MoSCoW

Must — критично необхідне (без цього рішення не працює/незаконне);
Should — важливе, але не критичне;
Could — бажане, якщо є ресурс;
Won’t (this time) — свідомо відкладене.

5.4. Матриця «цінність / зусилля»

	Малі зусилля	Великі зусилля
Висока цінність	Швидкі перемоги (робити першими)	Великі ставки (планувати)
Низька цінність	Заповнювачі (за наявності часу)	Уникати

5.5. WSJF (Weighted Shortest Job First)

Для черги великих ініціатив застосовують WSJF: пріоритет = (цінність + терміновість + зниження ризику) / тривалість роботи. Метод віддає перевагу коротким роботам з високою цінністю, максимізуючи сумарний ефект за одиницю часу.

5.6. Пріоритезація в оборонному контексті

В обороні до цінності додаються критичність (вплив на боєздатність) і безпека (вимоги ЗІ). Ініціативи, що усувають правовий чи безпековий ризик, часто мають статус Must незалежно від «зручності».

Типові помилки:

пріоритезація «за гучністю вимоги», а не за цінністю;
усе позначено як Must — фактично пріоритетів немає;
ігнорування зусиль/ризику при оцінці цінності.

Проміжний висновок: пріоритезація — щоденна дисципліна вибору; її інструменти (MoSCoW, value/effort, WSJF) захищають ресурс підрозділу від розпорошення.

6. Trade-off logic та cost of delay: як оцінити ціну зволікання

6.1. Трикутник проєктних обмежень

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

6.2. Trade-off як свідомий вибір

Trade-off (компроміс) — свідоме рішення, чим саме поступитися заради важливішого. Приховані, неусвідомлені компроміси — джерело конфліктів зі стейкхолдерами («ми думали, буде і швидко, і повний обсяг»). Офіцер ЦТ має проговорювати компроміси явно.

6.3. Cost of delay: означення та оцінка

Cost of delay (вартість зволікання) — ефект, який втрачається за кожну одиницю часу зволікання з рішенням або впровадженням. Невпроваджене корисне рішення — це не «нейтральний нуль», а щоденна втрата оборонної ефективності (часу, ресурсу, іноді життя). Оцінюється як розмір ефекту, помножений на час затримки.

6.4. Cost of delay як аргумент

Cost of delay переводить дискусію з площини «це дорого/довго» у площину «скільки коштує НЕ зробити зараз». Це найсильніший аргумент для пріоритезації та для ескалації (коли затримка погодження чи ресурсу щодня коштує підрозділу ефекту).

6.5. Наскрізний приклад

Приклад. Два рішення дають однаковий ефект, але рішення А впроваджується за місяць, рішення Б — за три. Якщо ефект — економія 100 год/тиждень особового складу, то кожен тиждень затримки Б коштує 100 год. За WSJF і cost of delay рішення А пріоритетніше, навіть якщо трохи дорожче.

Типові помилки:

приховані компроміси, не проговорені зі стейкхолдерами;
ігнорування cost of delay («почекаємо ще квартал») без оцінки втрат;
спроба максимізувати обсяг, строки і якість одночасно.

Проміжний висновок: trade-off робить компроміси свідомими, а cost of delay — вимірює ціну зволікання й обґрунтовує пріоритети та ескалацію.

Контрольні питання

Назвіть принципи формування та розгортання підрозділів ЦТ і рівні IT-вертикалі.
Як розподіляються зони відповідальності між ролями структури ЦТ? Що дає матриця RACI?
Чим відповідальність підрозділу ЦТ відрізняється від служби ІТ-експлуатації?
Опишіть цикл прийняття управлінського рішення. Які методи аналізу й синтезу застосовуються?
Як працює критеріальна матриця оцінки альтернатив? Наведіть приклад.
Порівняйте SMART, MBO та BSC: коли який підхід застосовувати?
Якими методами пріоритезують цифрові ініціативи (MoSCoW, value/effort, WSJF)?
Поясніть трикутник обмежень і поняття trade-off.
Що таке cost of delay і як його використовувати для пріоритезації та ескалації?

Завдання для закріплення (підготовка до Заняття 4)

Побудувати матрицю RACI для одного реального завдання свого підрозділу.
Сформулювати 2–3 SMART-цілі підрозділу на квартал (заготовка для роботи з OKR на Занятті 4).
Пріоритезувати 5 ініціатив свого підрозділу за матрицею «цінність / зусилля».

Додаток 1. Шаблон матриці RACI

R — виконує; A — відповідає за результат (один!); C — консультують; I — інформують.

Завдання	Роль 1	Роль 2	Роль 3	Роль 4

Додаток 2. Критеріальна матриця оцінки альтернатив

Критерій	Вага	Варіант А	Варіант Б	Варіант В
Оборонна цінність
Строк
Ризик / безпека
Вартість
Зважена сума

Додаток 3. Інструменти пріоритезації

MoSCoW

Категорія	Ініціативи підрозділу
Must
Should
Could
Won’t (this time)

Матриця «цінність / зусилля»

	Малі зусилля	Великі зусилля
Висока цінність	Швидкі перемоги	Великі ставки
Низька цінність	Заповнювачі	Уникати

Додаток 4. Глосарій ключових термінів

RACI — матриця розподілу відповідальності: Responsible, Accountable, Consulted, Informed.
Accountable — єдиний відповідальний за результат завдання.
SMART — критерії якісної цілі: Specific, Measurable, Achievable, Relevant, Time-bound.
MBO — управління за цілями (Management by Objectives) — каскад і узгодження цілей.
BSC — збалансована система показників (Balanced Scorecard) — оцінка через кілька перспектив.
MoSCoW — метод пріоритезації: Must, Should, Could, Won’t.
WSJF — Weighted Shortest Job First — пріоритезація за цінністю на одиницю часу.
Trade-off — свідомий компроміс між обсягом, строками та якістю.
Cost of delay — вартість зволікання — ефект, що втрачається за одиницю часу затримки.
Швидка перемога (quick win) — ініціатива з високою цінністю та малими зусиллями.

Додаток 5. Опорна схема циклу управлінського рішення

Проблема / можливість → збір даних і аналіз → генерація альтернатив (синтез) → оцінка за критеріями → вибір → реалізація → контроль результату (outcome) → зворотний зв’язок.

Додаток 6. Приклад застосування критеріальної матриці (розбір)

Ситуація: підрозділ обирає спосіб автоматизації обліку майна — три варіанти. Критерії зважуються за важливістю (сума ваг = 1,0), кожен варіант оцінюється за шкалою 1–5, підсумок — зважена сума.

Критерій	Вага	А (готове ПЗ)	Б (розробка)	В (таблиці)
Оборонна цінність (ефект)	0,4	4	5	2
Строк реалізації	0,3	5	2	5
Ризик / безпека	0,3	4	4	2
Зважена сума	1,0	4,3	3,8	2,9

Розрахунок для варіанта А: 0,4×4 + 0,3×5 + 0,3×4 = 1,6 + 1,5 + 1,2 = 4,3. Висновок: попри те, що розробка (Б) дає найвищу цінність, за сукупністю критеріїв (з урахуванням строку) перемагає готове ПЗ (А). Матриця робить вибір прозорим і захищеним від суб’єктивності; ваги критеріїв узгоджуються з командуванням заздалегідь.

Важливо: критеріальна матриця не «ухвалює рішення за керівника», а структурує аргументацію. Остаточне рішення залишається за офіцером ЦТ, але воно стає обґрунтованим і відтворюваним.