Архітектура цифровізації СОУ

💡 Усі статті, обговорення, новини про оборонні технології — в одному місці. Приєднуйтесь до DefTech спільноти!

Архітектура цифровізації СОУ

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

Існує закон Конвея (Conway’s Law), сформульований у 1967 року (відносно недавно за нього дізнався): організація, яка проєктує системи, приречена створювати системи, що копіюватимуть структуру організації; перефразую: система відображає організацію, яка її створює. Правило працює, у війську ще яскравіше ніж у корпоративному світі. Достатньо подивитися на будь-яку конкретну систему, щоб побачити цей закон в дії.

Будь-яка ІКС (інформаційно-комунікаційна система) неминуче відтворює ієрархію, етапи, канали ухвалення рішень, управлінську культуру (або її брак), то ж відповідь як система буде працювати завжди ховається у відповіді на питання як працює сама організація, тому розробляючи та трансформуючи — ти трансформуєш організацію, а софт лише ілюстрація. Один із перших маркерів, за яким це видно, — залученість.

Отож, «залученість» стає мірилом на конкретному рівні: чи вносить дані о/c, екіпаж, відділення, рота, технік? чи це штабний діловод компонує звіт постфактум? Якщо перше, це успіх — тобто, система перестала бути інструментом контролю і стала інструментом де солдат став співавтором. Щоб досягти цього, то на старті варто чесно розуміти наскільки військовий відрізняється від звичайного користувача комерційного застосунку.

Бо між цивільними та військовими рішеннями — неймовірна прірва. Користувач комерційної аппки бачить конкуренцією та має свободу вибору в appstore, його зваблюють маркетинг та фічі, з ним намагаються спілкватися; а у військовослужбовця є обов’язки та командир, які не залежать від того, наскільки він хоче тицяє в екран чи по клавіатурі.

Тому коли архітектура системи сприймає бійця тільки як джерело даних, через «НАКАЗУЮ залучити для звітності!», це генерує великий ризик втратити мету цифровізації. Бо систему, яка має допомагати командиру ухвалювати рішення спирають на хитку базу — на зобов’язання, які не підкріпленні практичною користю у бійця. В цій парадигмі побудувати сервіс буде, ой, як складно. Тому практична порада, зрозуміла в бізнесі, але майже ігнорується в армії — давати користь на всіх рівнях, а не лише штабу. Саме ця логіка — користь замість наказу — працюватиме коли йдеться вже не про окремого бійця, а про цілий підрозділ чи навіть корпус.

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

Спочатку у пілота швидка перемога: решта структури готує службові записки, а пілот показує результат, але що швидше масштабується нова підсистема, то частіше впирається в межі та блокери, під які не була розрахована. Остання починає реагувати на підсистему як на щось чужорідне та чинити супротив через неузгодженість, до прикладу:

а) паралельні розпорядження різних рівнів, які ніхто не звів докупи

б) облікові рамки, побудовані на різних базах, ніж закладена в платформі

в) лінії звітності, що пропускають щаблі, які система досі вважає обов’язковими

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

Деталізуючи приклад далі, щоб конкретніше — це конфлікт нормативки між собою: облік майна в Нацгвардії водночас регулюється наказом Міноборони № 440 і профільним наказом МВС № 646, які виходять із різних методологій та не стикуються між собою. І якщо система, розрахована на один із них, то автоматично виглядає «неправильною» з паралельного погляду.

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

В СОУ існує багато проєктів, але їх неможливо масштабувати, бо будували їх не як масштабовані enterprise рішення, а на батальйон закриваючи локальну боль. Гарно закриваючи, але це їх стеля. І це біда, бо є чимала кількість класних речей так і лишається там де є...

Тут от яка справа: щойно дані потрапляють в ІКС, вони одразу починають жити у 2х паралельних режимах:

а) технічному (що система здатна зробити) і

б) нормативному (що їй дозволено зробити з цими даними).

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

І перше, з чим стикаєшся, — це питання: «а чи маємо ми взагалі право збирати такі дані?»

Бо все має спиратися на конкретну норму, ЗВДТ, Міністерські накази, розпорядження по ЗСУ чи НГУ, і так далі. Поле, яке легко додати технічно (геолокація бійця, стан здоров’я, персональні дані, маршрут, whatever), може вийти за межі дозволеного, і створити проблему.

Якщо з цим розібралися, лишається друге — а під яким грифом дані взагалі мають жити?

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

Гриф треба окремо визначати для сирого запису, для зведення, для експорту, для дашборда. І тут знову працює закон Конвея, тільки в новому розрізі: хто саме має право бачити зведену картину? Це та сама розстановка повноважень, просто перенесена в архітектуру ABAC. І тоді ми переходимо від governance до самого способу мислення.

Проєктне мислення це про результат: знайти вузьке місце, прибрати зайвий крок, перезібрати процес, створити сервіс, масштабувати. У розробці продукту це чеснота, але військовий наказ не бек-лог задач. Його сенс саме в тому, щоб максимально точно розписати, хто за що відповідає, у які терміни, кому і як ескалює проблема, — так, щоб у разі втрати, зриву чи аварії можна було однозначно встановити, на якому рівні й чому це сталося. Що станеться, якщо цю точність принести в жертву швидкості?

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

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

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

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

Підписуйтеся на WhatsApp-канал DefTech спільноти!