Автоматизація поточної оцінки: підтримання обізнаності штабу в реальному часі

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

Що таке поточна оцінка і чому вона старіє

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

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

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

Від ручних схем до живих даних: архітектура

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

Основою є модель стану, визначена для кожної функції бойових дій. Для оцінки операцій модель містить бойову потужність за підрозділами — зазвичай виражену як відсоток від затвердженої чисельності в особовому складі та ключовій техніці. Для МТЗ — рівні за класами постачання, залишок днів постачання та стан готовності критичних систем. Для захисту — індикатори ризику та стан заходів захисту сил. Кожне поле моделі називає своє авторитетне джерело, очікуваний цикл оновлення і — для будь-якого похідного показника — формулу, що його породжує. Ця модель є контрактом, від якого залежить кожен наступний етап; помилка в ній поширює похибки на всі панелі.

Вище моделі знаходяться адаптери введення, по одному на джерело. Стрічка відстеження своїх сил надає позиції підрозділів і статус, як правило, у вигляді повідомлень NFFI або CoT. МТЗ надходить у вигляді донесень LOGSTAT або їхніх національних еквівалентів. Дані технічного обслуговування та виходу з ладу, донесення про втрати та розвідувальна оцінка сил противника мають кожна свій формат і цикл. Завдання кожного адаптера вузьке і суворе: перекласти вихідний формат у модель стану, перевірити на достовірність та карантинувати все деформоване, а не дозволяти зіпсованому донесенню отруювати агрегат. Одна неправильно введена цифра кількості боєприпасів, яка мовчки зменшує наполовину задокументований базовий запас, гірша за відсутність донесення взагалі.

Безперервне обчислення бойової потужності та МТЗ

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

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

Кожен результат обчислення повинен нести своє походження. Показник бойової потужності 78% не має сенсу для командира без відповіді на два питання: станом на яку дату і з яких джерел. Система повинна позначати кожен похідний показник часовою міткою та ідентифікатором джерела донесень, на основі яких він обчислений, щоб походження супроводжувало число аж до екрана. Це різниця між оцінкою, яку командир може перевірити, і числом, якому командир просто мусить довіряти.

Агрегація та зведення вгору

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

Забезпечення надійності оцінки: застарілість, достовірність і перевизначення

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

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

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

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

Відображення оцінки: живі подання для командира та штабу

Фінальний етап перетворює обчислений стан на подання, якими люди дійсно користуються. Поточна оцінка — це не один екран, а кілька відфільтрованих за роллю: подання бойової потужності для офіцера операцій і командира, подання МТЗ для логістики, подання ризику та захисту, і зведене командне резюме. Кожне є проекцією лише для читання одного авторитетного стану, що гарантує: подання логістики та командне резюме ніколи не розходитимуться щодо стану пального одного й того самого підрозділу. Ця дисципліна єдиного джерела істини — та сама, що керує грамотною архітектурою панелей C2: дисплеї є споживачами, а не редакторами сховища стану.

Живі подання повинні надсилати зміни в момент їх виникнення, а не чекати на оновлення, і повинні привертати увагу до того, що змінилося. Панель, що перемальовує кожен показник при кожному оновленні, привчає командира її ігнорувати; та, що виділяє дельти — роту, чия бойова потужність щойно впала нижче 70%, клас постачання, що щойно перетнув поріг рішення, — спрямовує увагу на ті кілька фактів, що вимагають її. Мета — не показати все, що актуально, а показати, що щойно стало правдою і що це означає для плану.

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

Місце автоматизації в ширшій картині C2

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

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