Цифрова армія: з якими проблемами зіткнеться міністр оборони Резніков

“Українська паперова армія має залишитися у минулому. Особливу увагу буде приділено організації оборонних закупівель” – такою була заява Міністра оборони Резнікова в день його призначення. Чи можна вірити словам високопосадовця в країні, де знецінена політична відповідальність? Ми це побачимо вже найближчим часом, після перших кроків. А поки що обіцянка міністра свідчить про кілька плюсів. По-перше, Олексій Резніков обізнаний у проблематиці ЗСУ. Другий позитив – його обізнаність сталася через аналітиків, а отже він має команду. Третій плюс – критичне мислення. Насамкінець, обнадіює його сміливість зайти у “авгієві стайні”, ризикуючи забруднити мундир. Аби зрозуміти, що доведеться розгрібати Міністру Резнікову, я започатковую цикл дискусій з учасниками IT-ринку, які автоматизують армію. 

Мій перший співрозмовник – Володимир Кург, керівник групи технічного розвитку (R&D) компанії "ІТ-Інтегратор". 

Ви дізнаєтесь: скільки коштує для США автоматизація армії і як їхній цінник відрізняється від українського; що продається у світовому “воєнторгу” і чому там ЗСУ не робить шоппінг. І головне: що заважає цифровізувати українську армію?

Віталій Манько (у подальшому Віталій): Військова цифровізація – одна з найцікавіших і найважливіших тем в час, коли армія активно трансформується. Проте інформації про неї вдень з вогнем не знайти. Чому?

Володимир Кург (у подальшому Володимир): Надмірно секретять. І не лише у нас. На першому Defense-хакатоні, який проходив в Україні, виступали представники групи управління FMN (Federation Mission Networks). 

Довідка: FMN (англ. NATO Federated Mission Networking) – Федеративна мережа місій, ініціатива НАТО, що спрямована на забезпечення оперативної сумісності, обмін інформацією та розвідувальними даними під час спільних операцій держав-членів НАТО та країн-партнерів.

Щоби натовська ініціатива FMN запрацювала, їм доводилося їздити країнами-членами НАТО і прибирати невиправдані грифи секретності з усього, що гальмувало.

Віталій: Коли говорять про перехід ЗСУ на стандарти НАТО в цифровізації, про які рівні та напрямки йдеться, що взагалі автоматизується?

Володимир: Військова машина – велика. Це різні види та роди військ. Сюди входять не тільки бойові частини, а й підтримуючі. Операційні завдання, які потрібно автоматизувати, перелічені в натівській моделі C3 Taxonomy (СіТри Таксономія). "Таксономія" визначає функціональні області автоматизації військового управління – фактично, групи процесів. Точніше, “C3 Taxonomy” визначає операційні блоки процесів, які виконуються на тактичному та оперативно-стратегічному рівнях та підлягають автоматизації. Представимо "C3 Taxonomy" у вигляді матриці процесів. Візьмемо, наприклад, групу процесів управління сухопутними військами – є процеси управління вогнем і артилерією, розвідкою, механізованими частинами. Аналогічно – щодо військово-повітряних та військово-морських сил, об'єднаного командування тощо. Автоматизуються завжди процеси.

Віталій: Все-таки не ясно: в Україні автоматизуються процеси по матриці натівської Таксономії чи по системі внутрішніх стандартів України?

Володимир: Є у НАТО AJP-6 – доктрина для комунікаційних та інформаційних систем, що визначає стратегічні та технологічні засади побудови будь-яких інформаційних систем. Це натівський стандарт STANAG 2525. Він вимагає використання “СіТри Таксономії”. Ми йдемо шляхом гармонізації зі стандартами НАТО. Україною у 2020 р прийнято доктрину “Зв'язок та інформаційні системи”, яка є українською адаптацією AJP-6. 

Віталій: Але ж українські розробки з автоматизації розпочалися раніше, наприклад у 16-му та 17-му роках, коли доктрини ще не було. Яких стандартів ми дотримувалися на той час?

Володимир: Натівська доктрина була, української не було. Тут стоїть питання взаємовідносин "замовник-розробник". І той, і інший знали, що натівська доктрина існує. Обидва знали, що таке “СіТри Таксономія”. Під час “Knowledge Shared” сесій натівського фонду С4 TF представникам генштабу ЗСУ та розробникам надавався доступ до бібліотеки стандартів, практик та архітектур.

Довідка: С4 TF – Трастовий фонд Україна-НАТО з модернізації системи командування, управління, зв’язку та комп’ютеризації (С4). Фонд концентрується на 4 пріоритетних напрямках: 

• Проект з обміну знаннями (Knowledge Sharing);
• Програма безпеки регіонального повітряного простору (Regional Airspace Security Programme — RASP);
• Проект захищеного тактичного зв’язку (Secure Tactical Communications);
• Проект спільної ситуаційної обізнаності (Shared Situational Awareness).

Віталій: Коли це було?

Володимир: Знання доктрин та стандартів НАТО – ще до війни, робота C4 TF – з 2015 р. 

Віталій: Тоді чому журналісти нарікають, що армія веде розробки за застарілими стандартами?

Володимир: Потрібно розрізняти групи стандартів. Перші – стандарти на організацію процесів проектування та створення. Другі – технологічні та архітектурні стандарти. C3 Taxonomy, JC3IEDM/STANAG 5525, NISP (NATO Interoperability Standards and Profiles) – це технічні стандарти. 

Віталій: Хіба у кожної країни не свої стандарти? 

Володимир: Ні. Існує цивільний стандарт ISO/IEC 15288:2008 Systems Engineering – System Life Cycle Processes. На ньому і заснований військовий натівський стандарт AAP-48 "NATO Systems Life Cycle Process". По ньому працюють у всьому світі. Саме в нього внесено військову специфіку. 

Віталій: Тоді на чому у нас ґрунтуються “ДКР” (дослідно-конструкторські розробки)? Це старі радянські стандарти чи гібрид ГОСТ із ISO?

Володимир: ДКР – це галузь господарської діяльності, яка регулюється, хоч як це смішно, адміністративним кодексом і внутрішніми документами. Процес розробки ДКР та управління результатами розробки, як правило, оформлявся за 34-ю групою ГОСТів. Це стосується військових інформаційних автоматизованих систем або створення зразків будь-якої техніки за військовими стандартами. 

Віталій: Чи можна сказати, що ДКР – це про “винахід велосипеда”? 

Володимир: Ні. ДКР – це дослідно-конструкторська розробка, метою якої, в ході дослідження та конструкторської розробки, є дослідний зразок і пакет конструкторської документації.

Віталій: Все-таки йдеться про інновації?

Володимир: Фактично так. На виході отримуємо якийсь дослідний зразок, що має властивості, яких вимагає замовник. 

Віталій: Про ваші ДКР для армії Ви можете говорити публічно?

Володимир: Ні. Але, щодо несекретного – реалізація частини C3 Taxonomy – від апаратного забезпечення до базових сервісів включно. 

Віталій: Чи правильно розумію, що для армії Ви реалізовуєте те саме, що й раніше, у комерційній сфері? 

Володимир: У комерційному секторі не робився блок захисту інформації щодо КСЗІ. 

Віталій: А як же продукти для банківської сфери? 

Володимир: Вони також є, але інші. 

Віталій: Якісь особливі?

Володимир: Технології розвиваються... До того ж, на виході ДКР – не лише дослідний зразок, а ще й конструкторська документація (ред. для оборонних систем).

Віталій: А у комерційному секторі немає на виході розробки конструкторської документації?

Володимир: Там є експлуатаційна документація. У випадку системної інтеграції передбачається, що замовник і власник системи лише її масштабуватиме, але не тиражуватиме. Що стосується ДКР – це про можливість тиражування. 

Віталій: Готову ДКР зможе розтиражувати будь-який підрядник?

Володимир: Абсолютно! Якщо говорити про procurement-цикл (цикл закупівель), то за конструкторською документацією оголошується тендер і той, хто вміє це робити, вироблятиме нові вузли, ЦОДи (центри обробки даних).

Віталій: Не всі ж розробки тиражуватимуть? Або по-іншому спитаю – навіщо кілька стратегічних систем управління військами, якщо достатньо однієї?

Володимир: Є дві частини. Номер один – це інфраструктурна частина (Core Services), включно User Collaboration Services. Розміщення функціональних систем та забезпечення роботи користувачів цих систем із додаванням стандартних сервісів підтримки робочих процесів. Це тиражується. Наше завдання – зробити, випробувати, видати документацію. А далі Міноборони нехай саме тиражує та закуповує. 

Номер два. Існують системи центрального рівня. Наприклад, системи рівня виду військ. Або стратегічні системи. 

Візьмемо логістику в тих же Штатах, там три види військ: US Army, Air Force, US Navy. І через специфіку у них – три види різних логістичних систем. На різних платформах. З різними завданнями. Всі вони живуть під парасольковою логістичною системою, що забезпечує розмежування процесів. Є процедура ”Force generation” – генерація сил та матеріальних ресурсів. 

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

Є ще й процедура “застосування сил”. 

Парасолькова система забезпечує матеріальну частину – Force generation. А системи логістики видів військ відповідають за забезпечення ресурсами під час застосування сили.

Тобто дійсно є центральні системи, які обслуговують великі блоки і не тиражуються. У тих самих американців чітко відокремлена інфраструктура від прикладних сервісів. В результаті: що є у них, і чого немає у явному вигляді у нас? Вони мають Defense Information Systems Agency (DISA), що обслуговує інфраструктуру, де споживачі замовляють собі блоки ресурсів. 

Віталій: Щоб читачі розуміли, це можна назвати військовим ЖЕКом? Експлуатаційною конторою.

Володимир: Фактично так. У НАТО це – NATO Communications and Information Agency (NCIA).

Віталій: Але ж у нас створено аналогічну службу J6?

Володимир: J6 – це підрозділ Генерального штабу. J6 визначає потребу в таких системах, наприклад, при плануванні оборонної спроможності. 

Віталій: J6 не є оператором, який експлуатує системи автоматизації?

Володимир: Ні, оператором є командування військ зв'язку. 

Віталій: Давайте поговоримо про "відмінний результат без переплат". Скільки у США, Франції та Німеччині коштують автоматизовані військові рішення? 

Володимир: Ось приклади. 

1. IaaS-система NCIA – модернізація двох ЦОДів, центру управління IaaS, 41 підключений вузол. Орієнтовна вартість – 187 млн ​​євро (5,6 млрд грн)
2. Програма модернізації логістики армії США Increment 2 (LMP Inc 2). Вартість придбання $418.7 млн ​​(близько 11 млрд грн), підтримки – $289.9 млн (7,6 млрд грн)

Віталій: Чим українські ціни відрізняються від світових за аналогічне? 

Володимир: Проблема порівняння у тому, що у відкритому доступі не публікують структурні показники вартості (скільки коштує одинична ліцензія СПЗ/комплексу СПЗ – і що вона дозволяє) і структуру ціни придбання та обслуговування системи (апаратне забезпечення, системне ПЗ, комерційне прикладне ПЗ – наприклад, GIS та ERP (компоненти, що входять до складу системи; вартість розробки/кастомізації). 

Віталій: Порівнюючи озвучені Вами цифри вартості іноземних систем, не можна не здивуватися галасу, здійнятому ЗМІ через нібито завищену ціну наших розробок. Тут видно, що українська розробка 600 млн грн – це в 10-20 разів дешевше за американську. 

Володимир: Давайте розділимо вартість розробки і вартість системи. З чого складається вартість системи? Номер один – вартість "заліза". Залізо у них і у нас практично те саме з одними і тими ж прайсами виробників. Номер два – вартість ліцензій на програмне забезпечення – те ж саме з цінами. Третє – робоча сила. Відрізняється. Відповідно, вартість розробки в нас нижча. Вона, у свою чергу, складається з вартості кодингу та вартості "Quality assurance". Нам же треба тестувати? Ще потрібно розробити якісну документацію. Додайте сюди вартість управління. 

Віталій: Я нещодавно спілкувався із проектним менеджером Electronic Arts. Він розповів, що вартість розробки документації може стягнути не менше половини витрат на кодинг. Хоча це далеко не військова тема, а лише комп'ютерні ігри. 

Володимир: Загалом так. Лише пояснювальна записка в пів тисячі сторінок до серйозного проекту – це типово. 

Віталій: Процеси документування розробки не менш трудомісткі, ніж кодинг. Їх ніяк не можна оминути? 

Володимир: Вони не менш важливі. Це – описані процеси, інструкції з експлуатації, конструкторська документація. Коли я займався розробкою, то мої коментарі в коді були не менше 100% від його обсягу, а то й значно більші. 

Віталій: Тобто українську ДКР вартістю 20 млн дол у Штатах оцінять у 400-500 млн? 

Володимир: Не готовий коментувати таке припущення. Але якщо дивитися не на вартість ДКР в цілому (розробка ПЗ + залізо + ліцензії на комерційний софт), а на вартість розробки спеціалізованого ПЗ, то в Штатах вона вище, ніж у нас, разів у п’ять. Що виходить у результаті? Можна замовити в Україні дешеву розробку, і отримаєте якийсь набір коду та дуже слабку документацію. В результаті виходить система, яку розвивати та підтримувати важко. Це, до речі, досить часто у нас відбувається не лише в оборонній сфері. Можна, звичайно, купити, якщо домовитися із західними постачальниками, програмну систему. Це не тільки "бінарники", а ще й, бажано, “першоджерела”. Але, на жаль, домовитися виходить вкрай рідко.

Віталій: Країнам НАТО чи Україні вигідніше купувати готові бойові системи у якомусь глобальному воєнторгу чи розробляти свої?

Володимир: Я не говоритиму з приводу українських бойових систем. Ми працюємо з Міноборони, а не з Генштабом та ЗСУ, тобто не займаємося бойовими системами. 

Головна вигода полягає в економії часу за умови, що готове рішення взаємно сумісне з іншими системами. Але й тут є проблема – закритість такого воєнторгу, а також відсутність у відкритому доступі цін виробників та зарегульованість (експортний контроль, угоди про ВТС та ін.). Є ще одна проблема – розрахунок вартості підтримки/обслуговування упродовж життєвого циклу.

Готові рішення є, наприклад, ЦОДи: 

• Контейнерні ЦОДи та ЦОДи, які можна розгортати – General Dynamics, Deployable Data Centers
• General Dynamics, командні мікровузли (без програмного забезпечення) – Small Form Factor Command & Control (SFF C2) Node
• Aselsan, стаціонарні Data Centers

АСУВ, тактичні, наприклад:

• Aselsan BATUR – сухопутні сили
• Haselsan ADVENT – військово-морські сили

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

Довідка: COTS (Commercial off-the-shelf або commercially available off-the-shelf) – комерційні готові або комерційно доступні готові до використання продукти. Це упаковані або консервовані (готові) апаратні чи програмні засоби, адаптовані для післяпродажного обслуговування до потреб організації-закупівлі. 

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

СПЗ може бути умовно готовим до використання. Тобто, для того, щоб використовувати, його необхідно доповнити алгоритмами, значеннями різних коефіцієнтів, складом та озброєнням військових частин та іншою інформацією – у форматі цього програмного забезпечення. Якщо ця інформація не є конфіденційною, то проблем немає. Але у разі систем планування операцій та бойових систем ця інформація, як правило, грифована. І тут постає питання її допуску до експлуатації секретниками – вимога наявності КСЗІ та експертних висновків ДСССЗІ. 

Ще живий приклад. У Німеччині замовили готову систему у SAP.

Віталій: Чому українська армія собі не замовила готовий військовий SAP?

Володимир: Інформація достатньо закрита. Навряд чи відповім на це запитання. Імовірно, через причини, які пояснив вище.

Віталій: Чим відрізняються підходи до автоматизації в Україні та країнах НАТО?

Володимир: Ступенем зрілості як процесів командування та управління, а також процесів автоматизації/розробки/управління життєвим циклом ІС. У них напрацьовано інституційне знання. У нас – ні. Вони мають кодифікацію вищеописаних процесів, ми не маємо. 

Зокрема, щодо “життєвого циклу”, у нас досі використовуються ГОСТи 34-ї серії та відповідні радянські військові стандарти, у них – STANAG 4728.

До речі, щоб зробити гарне технічне завдання, потрібно витратити чимало сил. Чим менш детальне техзавдання, тим сумнівніший результат. 

Віталій: Для таких робіт потрібен спеціалізований військовий дослідницький центр? Приміром, Центр Інновацій мав би цим займатися, якби його створили раніше.

Володимир: Правильно, щоби були відповідні фахівці у видах та родах військ. У командуваннях. Це оптимальний варіант. Так працюють у країнах НАТО, зокрема, у тих самих Штатах. Візьміть Systems Life Cycle Process, про який я згадував на початку розмови. Той, що розроблений на основі стандарту ISO. Там розписано стадії процесів, починаючи зі стадії визначення вимог. Далі Requirements management, архітектура і т. д. Ось тут у нас зараз слабко. 

От як приймається система? Вона перевіряється, наскільки відповідає технічному завданню. Чим розмитіше ТЗ, тим менше критеріїв, тим важче прийняти роботи. Це одна з проблем.

Щодо іншої проблеми... Зі спілкування на Defense-хакатонах із нашими західними друзями, випливає, що на заходи з розробниками інформаційних систем оборонного призначення дуже рідко ходять споживачі – командири.

Віталій: Це проблеми, які можна вирішити?

Володимир: Їх потрібно вирішити! У нас перший етап розробки функціональних систем – це сидіння протягом місяця-двох-трьох у військового споживача з фіксацією його потреб, процесів тощо. Вони, замовники, як правило, – люди зайняті, а витрачати час на чіткі формулювання потреб у них не завжди є бажання та можливості. Найчастіше нам кажуть: “Ось нормативка, накази, настанови, робіть нам автоматизацію відповідно до цього”. Але найцікавіше починається згодом. Ми бачимо настанови, але тут не зрозуміло, що це таке і як воно виконується. Найчастіше буває, що в нормативці є процес, а результат не описаний. Або потрібен результат, але як його досягти? Ось це все – робота з людьми, вилучення неявних знань із голів, фіксація та затвердження...

Віталій: Якщо одна з проблем проявлена нами ​​на початковому етапі, постановці задач, то яка ситуація на фінальній стадії? Де гарантія, що аудит та акти прийому підписують компетентні люди? Може через їхню некомпетентність навесні блокували розробки систем автоматизації ЗСУ, а восени розблокували?

Володимир: Я не сказав би, що слово “блокування” правильне. Найчастіше це – призупинення фінансування з тих чи інших організаційних причин. Але я хотів би звернути увагу на те, що будь-яка автоматизація – це автоматизація процесів. Наразі збройні сили перебувають у стані трансформації. Змінюються і процеси, і оргструктури, що їх виконують. Відповідно, якщо розробку розпочато раніше, треба переглядати якісь частини ТЗ, оскільки деякі процеси йдуть "у відвал", морально застаріли. Іноді такі паузи, про які кажете, для перегляду процесів – це добре, але за рахунок втрати темпу розробок та строків готовності.

Віталій: Хто та які служби відповідають сьогодні за цифровізацію української армії?

Володимир: За цифровізацію загалом – Директорат політики цифрової трансформації та інформаційної безпеки у сфері оборони.

Віталій: В youcontrol зазначено, що на державних тендерах Ваша компанія отримала понад два мільярди гривень, починаючи з 2017 року. Цій інформації можна довіряти?

Володимир: Це відкрита інформація.

Віталій: Яка частка цього тендерного пирога належить до військових розробок?

Володимир: По силовому сектору – близько 130 млн грн, включно поліцію та Нацгвардію. Якщо розглядати лише оборону, то близько 65 млн грн.

Віталій: У публічних джерелах Вашу компанію пов'язують із Олександром Кардаковим. Ви з ним радитесь при ухваленні рішень?

Володимир: Є відносини корпоративні, а є особисті та професійні. У нашому випадку це друге. З Олександром Кардаковим я знайомий і працюю з 2000-го року, це було за часів ICS, це було і в Датагруп. Ми працювали в одній волонтерській групі, яка розробляла варіанти ІТ-інфраструктури Міноборони у 2017-2018 р. Коли треба було робити щось на волонтерському рівні, Кардаков допомагав як організаційно, так і своїми знайомствами. Зараз по цих питаннях не взаємодіємо. Я з ним регулярно спілкуюсь, але це не корпоративне спілкування. 

Віталій: Ваша компанія може виконати будь-яке замовлення Міноборони щодо IT?

Володимир: Ні, ІТ – велике. Те, що стосується стандартної інфраструктури та базових сервісів, однозначно так, можемо. Це – центри обробки даних – те, чого ми не маємо, але до чого необхідно прийти. Це інфраструктура та система ідентифікації (Identity Management). Ось усі говорять про захист інформації. Що є фундаментом захисту? Є суб'єкт доступу, який має бути ідентифікований, є об'єкт доступу, який також має бути ідентифікований. Що є в американських та натівських збройних силах і чого немає у нас? Єдина система ідентифікації. Це достатньо стандартне програмне забезпечення – Directory Service (– ред. служба каталогів).

Довідка: Служба каталогів (Directory Service) – це засіб ієрархічного представлення ресурсів, що належать певній організації, а також інформації про ці ресурси. Під ресурсами можна розуміти матеріальні ресурси, персонал, мережеві ресурси і т. д.

Це також “public infrastructure”, її PKI-, DNS- і IP-менеджмент.

Віталій: Якщо це – стандартні рішення, знову назріває питання, навіщо їм потрібні ДКР?

Володимир: Будь-хто може продати окремі програмні та апаратні компоненти. Питання в тому, щоб побудувати систему, яка б надійно працювала і відповідала б функціональним вимогам замовника. І повністю та якісно описати для майбутніх користувачів та розробників.

Віталій: Йдеться про системи, що надійніші, ніж для банківської сфери?

Володимир: У такому ж класі надійності. І з вищою живучістю. Але є така річ, як операційні вимоги. Американці, з тих, хто відповідає за диджиталізацію, у міністерстві оборони мають CIO офіс – надбудову над DISA. І вони випускають такі чудові документи, як референсні архітектури. Вони замовляють розробки, наприклад ID-Management Reference Architecture, Data Centre Architecture, Security Access Control, Security Access Control Reference Architecture. Фактично – це функціональні завдання та описи референсних архітектур, що передаються розробникам для подальшої роботи. Вони передаються одночасно і видам військ, і військовим організаціям на зразок берегової охорони, Нацгвардії. Референсні архітектури передаються розробникам і постачальникам для того, щоб частини єдиної системи робилися за єдиною архітектурою та забезпечувалася інтероперабельність всього, що будується.

Ось у чому сильні американці і навіщо ми інтенсивно використовуємо їхню технічну документацію та нормативку – вони відкриті. Вони публікують FIELD MANUALS, що у нас називають “польовими настановами”. Публікують тактичні процедури. Наприклад до недавніх часів використовувалися польові мережеві вузли, а в FIELD MANUALS публікувалися схеми з розміщенням цього устаткування, схеми з'єднань, аж до фрагментів конфігурації маршрутизаторів. 

Віталій: Чого сьогодні чекає IT-сектор від співпраці з оборонним комплексом?

Володимир: Усі бажають підтягнути процес керування вимогами. До речі, як зараз працює оборонно-промисловий комплекс із своїм замовником? У темі озброєнь і військової техніки, найчастіше, вони (– ред. розробники) кажуть так: “У нас є така розробка, а давайте ви на неї подивіться і подумаєте, як використовувати”. Ось цей рух має бути двостороннім. Повинні бути зворотні запити військових: “Що нам треба”.

Віталій: У зв'язку зі зміною Міністра оборони прошу сказати те, що всіх цікавить. Яких змін слід чекати і на що – сподівання?