Управління залежностями та міжвідомча інтеграція

Тема 2: Управління проєктами у військовому середовищі · Заняття 7

1. Dependency map: класифікація залежностей

1.1. Поняття залежності та dependency map

Залежність — зв’язок, за якого виконання однієї роботи, доступність ресурсу чи результат проєкту залежить від іншої сторони (роботи, системи, підрозділу, рішення). Dependency map — карта залежностей проєкту, що показує, від чого і від кого залежить кожен ключовий результат.

1.2. Класифікація залежностей

Тип	Приклад	Хто узгоджує
Технічні	Інтеграція з іншою ІКС, спільний формат даних.	Технічні команди систем.
Організаційні	Готовність суміжного підрозділу, рішення командування.	Керівники підрозділів.
Нормативні	Погодження, реєстрація, дозволи.	Юрслужба, орган ЗІ.
Ресурсні	Спільні фахівці, інфраструктура, бюджет.	Власники ресурсів.

1.3. Напрям і критичність залежності

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

1.4. Приклад виявлення залежностей

Для проєкту інтеграції системи обліку з кадровою системою карта залежностей може виглядати так:

Залежність	Тип	Чому критична
Готовність API кадрової системи	Технічна	Без неї інтеграція неможлива (критичний шлях).
Погодження обміну даними органом ЗІ	Нормативна	Без нього обмін нелегітимний.
Рішення командування про доступ	Організаційна	Блокує старт робіт.
Виділення інтеграційного фахівця	Ресурсна	Немає кому виконувати інтеграцію.

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

облік лише технічних залежностей, ігнорування нормативних і організаційних;
залежність без власника з обох боків;
відсутність узгодженого строку виконання залежності.

Проміжний висновок: dependency map робить видимими всі типи залежностей; критичні (на критичному шляху) потребують найпильнішого контролю.

2. Міжвідомчі залежності у проєктах ЦТ ЗСУ: виявлення, планування, моніторинг

2.1. Специфіка міжвідомчих залежностей

Проєкти ЦТ у ЗСУ майже завжди залежать від інших відомств, органів військового управління, суміжних систем. Такі залежності складніше контролювати: інша сторона має власні пріоритети, строки й процедури.

2.2. Виявлення, планування, моніторинг

Виявлення — виявлення: під час планування пройти по кожному результату й спитати «від кого/чого це залежить»;
Планування — планування: узгодити строки з іншою стороною, зафіксувати домовленість, визначити власників;
Моніторинг — моніторинг: регулярно перевіряти статус залежностей (у RAID-log), не покладаючись на «само вирішиться».

Приклад. Інтеграція системи обліку з системою кадрового обліку залежить від готовності API суміжної системи — це міжвідомча технічна залежність, яку треба узгодити й моніторити з власником тієї системи.

2.3. Формалізація домовленості про залежність

Щоб залежність була керованою, домовленість фіксують письмово. Мінімальний склад домовленості:

що саме має бути надано (конкретний результат/дані/рішення);
до якого строку;
власник з нашого боку і з боку суміжної сторони;
формат/умови передачі та критерій прийняття;
канал і періодичність моніторингу статусу.

Залежності переглядають регулярно (у RAID-log): статус, зміна строку, нові залежності. «Мовчання» суміжної сторони — привід перевірити, а не заспокоїтися.

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

припущення, що суміжна сторона «встигне сама»;
усні домовленості без фіксації строку й власника;
виявлення міжвідомчої залежності вже під час інтеграції.

Проміжний висновок: міжвідомчі залежності виявляють завчасно, узгоджують письмово й регулярно моніторять.

3. Interface points: де виникають інтеграційні ризики

3.1. Поняття interface point

Interface point — точка з’єднання (стику) між системами, командами або процесами. Саме на стиках виникає більшість інтеграційних ризиків: несумісність форматів, різні припущення сторін, «нічия зона» відповідальності.

3.2. Типи стиків і ризики

Стик	Типовий ризик
Система ↔ система	Несумісність форматів даних, версій, протоколів.
Команда ↔ команда	Різні припущення, «нічия зона» відповідальності.
Процес ↔ процес	Розрив у потоці (хтось не передав результат далі).

3.3. Як знижувати інтеграційні ризики

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

3.4. Особливості інтеграції даних

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

Приклад. Якщо і система обліку, і кадрова система ведуть звання військовослужбовця, треба визначити «джерело істини» (кадрова), інакше дані розійдуться.

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

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

Проміжний висновок: більшість інтеграційних ризиків живе на стиках; їх знижують чітким контрактом стику, власниками й раннім тестуванням.

4. Залежності від суміжних проєктів, зовнішніх систем і підрядників: план дій при невиконанні

4.1. Ризик невиконання залежності

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

4.2. Варіанти дій при невиконанні

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

Приклад. Якщо API суміжної системи не готове вчасно, обхідне рішення — тимчасовий імпорт даних файлом; паралельно ескалація до власника системи.

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

відсутність плану Б для критичних зовнішніх залежностей;
повна зупинка проєкту через одну невиконану залежність;
пізня ескалація, коли час уже втрачено.

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

5. Внутрішні обмеження: ДСК, секретність, доступи, потоки погоджень

5.1. Внутрішні обмеження як особливий вид залежностей

У ЗСУ проєкт залежить не лише від зовнішніх сторін, а й від внутрішніх обмежень: вимог захисту інформації та секретності (ДСК), надання доступів, обов’язкових потоків погоджень. Ці обмеження часто стають прихованими залежностями, які зривають строки.

5.2. Як враховувати

закладати строки надання доступів і погоджень у план як окремі залежності з власниками;
залучати орган ЗІ завчасно (класифікація, вимоги);
не планувати роботи, що потребують доступів, до їх фактичного отримання;
враховувати обмеження ДСК на обмін даними між системами.

Орієнтовні внутрішні обмеження та їх планування:

Обмеження	Хто відповідає	Як планувати
Класифікація / ДСК	Орган ЗІ/ДТ	Визначити на етапі ТЗ; закласти вимоги обміну.
Надання доступів	Адміністратори, командування	Запит завчасно; не планувати роботи до отримання.
Потоки погоджень	Юрслужба, ЗІ, ФЕО	Окремі віхи з запасом часу.

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

ігнорування строків надання доступів;
планування інтеграції без урахування обмежень ДСК;
залучення органу ЗІ постфактум.

Проміжний висновок: внутрішні обмеження (ЗІ, доступи, погодження) — це теж залежності; їх планують і моніторять нарівні із зовнішніми.

6. Передумови для тестування, впровадження та приймання результату ІКС

6.1. Поняття передумови

Передумова — умова, без якої неможливо перейти до наступного етапу (тестування, впровадження, приймання). Невиконана передумова блокує етап так само, як невиконана залежність.

6.2. Типові передумови по етапах

Етап	Передумови
Тестування	Готове тестове середовище, доступи, тестові дані, критерії тестування.
Впровадження	Пройдені випробування, погодження, реєстрація ІКС, навчання користувачів.
Приймання	Виконані приймальні критерії, документація, відповідність вимогам ЗІ.

6.3. Управління передумовами

Передумови фіксують заздалегідь (як залежності), призначають власників і перевіряють готовність перед переходом до етапу (аналог release readiness). Це запобігає ситуації «почали тестування, а середовища немає».

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

перехід до етапу без перевірки передумов;
передумови без власників і строків;
виявлення невиконаної передумови вже на етапі.

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

7. Практична вправа: побудова dependency map для інтеграції ІКС

Мета вправи: для типового проєкту інтеграції ІКС слухачі будують dependency map: виявляють залежності всіх типів, визначають власників, строки, критичність і план дій для критичних.

Вихідні дані: опис проєкту інтеграції (наприклад, система обліку майна ↔ кадрова система); шаблони (Додатки 1–2).

Форма роботи: у парах/трійках, з подальшою презентацією 2–3 карт.

Порядок виконання

Виявити залежності всіх типів (технічні, організаційні, нормативні, ресурсні) — ≥6 — 15 хв.
Для кожної визначити напрям, власників (з обох боків), строк і критичність — 15 хв.
Для 2–3 критичних залежностей скласти план дій при невиконанні — 10 хв.
Взаємна перевірка та презентація 2–3 карт із розбором — 5 хв.

Еталонне проходження (зразок для викладача)

Залежності. Технічна — готовність API кадрової системи (власники: наша команда + власник кадрової системи); нормативна — погодження обміну даними органом ЗІ; організаційна — рішення командування про доступ; ресурсна — виділення інтеграційного фахівця; передумова — тестове середовище.

Критичність. API та погодження ЗІ — на критичному шляху (блокують інтеграцію) → найпильніший моніторинг.

План дій. Якщо API не готове — тимчасовий обмін файлом + ескалація; якщо затримка ЗІ — ранній старт узгодження, ескалація.

Методичні вказівки викладачу

Викладач перевіряє: (1) охоплено всі типи залежностей, а не лише технічні; (2) кожна залежність має власників з обох боків і строк; (3) визначено критичність; (4) для критичних є план дій. Для розбору обирає одну повну й одну неповну карту.

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

Що таке dependency map і які типи залежностей вона відображає?
Як виявляти, планувати та моніторити міжвідомчі залежності?
Що таке interface point і чому на стиках виникає більшість інтеграційних ризиків?
Які варіанти дій при невиконанні зовнішньої залежності?
Як враховувати внутрішні обмеження (ЗІ, доступи, погодження) у плані?
Що таке передумови етапів і як ними керувати?

Завдання для закріплення

Побудувати dependency map для реального проєкту свого підрозділу (усі типи залежностей).
Для 3 критичних залежностей скласти план дій при невиконанні.
Скласти чек-лист передумов для найближчого етапу свого проєкту.

Додаток 1. Шаблон dependency map

№	Залежність	Тип	Власники (обидва боки)	Строк	Критичність
1
2
3
4
5
6

Додаток 2. Шаблон плану дій при невиконанні залежності

Критична залежність	Ознака невиконання	План дій (обхід / ескалація / альтернатива)

Додаток 3. Чек-лист передумов етапів

Тестування:

Готове тестове середовище й доступи.
Підготовлені тестові дані та критерії тестування.

Впровадження:

Пройдені випробування; отримані погодження; ІКС зареєстровано.
Проведено навчання користувачів; забезпечено вимоги ЗІ.

Приймання:

Виконані приймальні критерії; готова документація.
Відповідність вимогам захисту інформації підтверджена.

Додаток 4. Критерії оцінювання dependency map

Критерій	Бали	Орієнтир
Охоплено всі типи залежностей (≥6)	0–3	Не лише технічні.
Власники з обох боків і строки	0–3	Кожна залежність керована.
Визначено критичність (критичний шлях)	0–2	Виділено блокуючі залежності.
План дій для критичних залежностей	0–2	Конкретний, не «бути уважним».
Разом	0–10	9–10 «відмінно»; 7–8 «добре»; 5–6 «задовільно».

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

Залежність — зв’язок, за якого результат залежить від іншої сторони.
Dependency map — карта залежностей проєкту.
Вхідна / вихідна залежність — ми чекаємо на когось / хтось чекає на нас.
Міжвідомча залежність — залежність від іншого відомства чи ОВУ.
Interface point — точка з’єднання систем, команд або процесів.
Контракт стику — узгоджений опис формату й порядку обміну на стику.
Передумова — умова, без якої неможливий перехід до етапу.
Нічия зона — ділянка відповідальності, не закріплена ні за ким.

Додаток 6. Приклад заповненої dependency map (для розбору)

№	Залежність	Тип	Власники	Крит.	План дій при невиконанні
1	API кадрової системи	Техн.	PM + власник системи	Вис.	Тимчас. обмін файлом + ескалація.
2	Погодження ЗІ обміну даними	Норм.	BA + орган ЗІ	Вис.	Ранній старт узгодження, ескалація.
3	Доступ до середовища	Орг.	DT Lead + командування	Сер.	Запит завчасно, резерв часу.
4	Інтеграційний фахівець	Ресурс.	PM + власник ресурсу	Сер.	Перепланування, залучення підрядника.

Додаток 7. Алгоритм роботи із залежністю (пам’ятка керівника)

Виявити залежність (пройти по кожному результату: «від кого/чого залежить?»).
Класифікувати (технічна / організаційна / нормативна / ресурсна) і визначити напрям.
Оцінити критичність (чи лежить на критичному шляху).
Призначити власників з обох боків і письмово узгодити строк та формат.
Занести в RAID-log і моніторити статус регулярно.
Для критичних — підготувати план дій при невиконанні (обхід / ескалація / альтернатива).
За настання ознаки невиконання — діяти за планом і ескалювати вчасно.

Головне правило: залежність без власника, строку й плану дій — це не керована залежність, а прихований ризик зриву.