Метод освоєного обсягу для програм оборонного програмного забезпечення

Автор: Corvus Intelligence Engineering Team · Про команду →

25 червня 2026 12 хв читання

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

Цей посібник охоплює повний життєвий цикл EVMS для оборонних програм з інтенсивним використанням ПЗ: математику, якою повинен володіти кожен CAM, 32 критерії ANSI/EIA-748, що структурують відповідність EVMS, побудову WBS відповідно до MIL-STD-881, підготовку та проведення IBR, ритм звітності CAM та аналіз відхилень, методи розрахунку EAC, а також екосистему інструментів для подання даних уряду. Щодо ширшого контексту виконання контракту, дивіться посібник з оборонного ринку, частина 4: виконання та EVM. Щодо структур ціноутворення, які визначають, які типи контрактів вимагають EVMS, дивіться моделі ціноутворення оборонного ПЗ. Щодо шляху закупівлі, що веде до контрактів з вимогою EVMS, дивіться оборонні закупівлі: від RFP до контракту.

Основи EVM для менеджерів оборонних програм

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

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

Освоєний обсяг (EV) — колишня BCWP (кошторисна вартість виконаних робіт) — це бюджетна вартість фактично завершеної роботи, виміряна відносно того самого базового плану. EV — це не те, у що обійшлась робота; це те, скільки за планом мала коштувати виконана робота. Модуль ПЗ з бюджетом $200 000 заробляє $200 000 EV після завершення — незалежно від того, чи фактично він коштував $180 000 чи $240 000.

Фактична вартість (AC) — колишня ACWP (фактична вартість виконаних робіт) — це те, що програма фактично витратила на виконану роботу. AC надходить із системи фінансового обліку, а не з оцінок. Вона включає прямі трудові витрати, прямі матеріали, інші прямі витрати та застосовані непрямі ставки.

З PV, EV та AC виводяться два основні показники відхилень:

Відхилення за вартістю (CV)   = EV - AC
Відхилення за графіком (SV)   = EV - PV

CV% = CV / EV × 100
SV% = SV / PV × 100

Від'ємне CV означає перевитрату коштів (роботи коштували більше, ніж передбачено планом). Від'ємне SV означає відставання від графіка (виконано менше робіт, ніж планувалось). Обидва відхилення виражаються в доларах і у відсотках — відсоткова форма використовується для порівняння з порогами.

Два індекси ефективності є показниками, до яких урядові рецензенти звертаються насамперед:

Індекс виконання вартості (CPI)   = EV / AC
Індекс виконання графіка (SPI)    = EV / PV

CPI вище 1,0 означає, що програма виконується ефективніше, ніж передбачено бюджетом; нижче 1,0 — перевищення вартості. Емпіричне спостереження Хамфрейса — що CPI у точці 20% виконання рідко суттєво покращується впродовж життя програми — є причиною того, чому урядові замовники розглядають стійкий CPI нижче 0,9 як системну проблему, а не виправний збій. SPI вище 1,0 означає випередження графіка; нижче 1,0 — відставання. Зауважте, що SPI сходиться до 1,0 після завершення програми незалежно від виконання графіка (оскільки EV зрештою дорівнює PV після виконання всіх робіт) — тому індекс виконання графіка сам по собі недостатній для оцінки графіка наприкінці програми і має доповнюватися Інтегрованим основним графіком.

Шостий показник, яким повинен володіти кожен CAM, — це Прогноз кінцевої вартості (EAC) — загальна очікувана вартість усіх робіт програми. EAC = AC + Прогноз витрат до завершення (ETC). Співвідношення між EAC та Бюджетом до завершення (BAC) розповідає всю картину: VAC = BAC - EAC. Від'ємне VAC — це прогнозоване перевищення вартості. VAC звітується щомісяця у Форматі CPR 1 і є одним із основних тригерів уваги з боку урядового офісу програми.

Настанови ANSI/EIA-748: 32 критерії

ANSI/EIA-748 — це консенсусний стандарт, що визначає вимоги до відповідної системи EVMS. Він не приписує конкретних програмних інструментів або форматів звітності — він встановлює 32 критерії, організовані у п'ять груп настанов. Опис системи EVMS підрядника повинен демонструвати, як реалізований кожен критерій, а DCMA перевіряє цю реалізацію шляхом нагляду та IBR.

Група 1: Організація (критерії 1-5). Система EVMS повинна бути організована навколо Ієрархічної структури робіт (WBS), що охоплює 100% авторизованого обсягу робіт, з кожним елементом, призначеним єдиному відповідальному організаційному підрозділу. Внутрішні субпідряди та значні субпідрядники повинні бути інтегровані до EVMS на рівні, що забезпечує змістовний нагляд за вартістю та графіком. Організаційна структура повинна бути задокументована та відображена в інструменті EVMS. Критерій 5 — інтеграція WBS з Організаційною структурою (OBS) для визначення рахунків управління — є ключовим: рахунок управління є перетином WBS та OBS, і кожен долар бюджету програми знаходиться рівно в одному рахунку управління.

Група 2: Планування, складання графіків і бюджетування (критерії 6-14). Це найбільша група, і саме вона визначає, чи є базовий план вимірювання ефективності достовірним. Всі авторизовані роботи повинні бути розподілені в часі від початку до завершення контракту. Найближчі роботи перебувають у пакетах робіт із об'єктивними критеріями початку/завершення; роботи на перспективу знаходяться в планових пакетах до включення їх у ковзний горизонт. Управлінський резерв утримується на рівні програми та авторизується лише для непередбачених робіт у рамках контракту. Нерозподілений бюджет покриває авторизовані роботи, ще не призначені рахункам управління. Зміни бюджетного базового плану вимагають формального документування в журналі бюджету. Критерій 12 — узгодження структури непрямих витрат з системою обліку — є тим місцем, де програми ПЗ найчастіше мають труднощі, оскільки множинні пули непрямих ставок (надбавки, накладні витрати, G&A) повинні узгоджено агрегуватися між EVMS та фінансовою системою.

Група 3: Питання обліку (критерії 15-18). Фактичні витрати повинні реєструватися на рівні рахунку управління, у тому самому часовому періоді, в якому виконувалися роботи, з використанням тієї самої структури елементів WBS. Критерії забороняють оцінювати фактичні витрати (тобто нарахування або оцінки замість реальних рахунків-фактур не можуть замінювати реальні дані про витрати більш ніж на один звітний період). Витрати на матеріали повинні реєструватися при отриманні або споживанні — залежно від того, що відповідає системі витрат програми, — застосовуючись послідовно.

Група 4: Аналіз та управлінські звіти (критерії 19-27). Ця група регулює аналітичні результати: пороги відхилень, наративи VAR, методи EAC, нагляд за субпідрядниками та урядову звітність. Критерій 22 — виявлення значних відхилень та підготовка звітів аналізу відхилень — є найбільш операційно інтенсивним критерієм для CAM. Критерій 27 — розробка EAC щонайменше щоквартально або частіше, коли відхилення перевищують поріг — є тим місцем, де встановлюється або втрачається достовірність прогнозів програми.

Група 5: Перегляди та ведення даних (критерії 28-32). Зміни базового плану повинні включатися формально та своєчасно. Журнал бюджету відстежує кожен долар переміщення бюджету, авторизованого керівництвом, з кодами причин. Ретроактивні зміни до EV — нарахування кредитів за роботи після дати статусу — заборонені. Сам опис системи повинен підтримуватися в актуальному стані. Критерій 32 — заборона ретроактивних коригувань, що не відображають фактичну ефективність — є критерієм, що найчастіше цитується в Запитах на коригувальні дії DCMA, оскільки ретроактивне маніпулювання EV є найбільш спокусливим короткостроковим виправленням для від'ємних відхилень.

Ієрархічна структура робіт для оборонного програмного забезпечення

WBS для оборонної програми з інтенсивним використанням ПЗ — це не список завдань і не ієрархія управління проектом. Це продуктово-орієнтована декомпозиція всього контрактного deliverable, узгоджена з MIL-STD-881, щоб звітність відображалася безпосередньо в моделі витрат офісу програми.

MIL-STD-881 надає стандартні визначення елементів WBS для програм оборонних систем. Для системи з інтенсивним використанням ПЗ відповідні елементи зазвичай включають: Систему (рівень 1), Програмне забезпечення (SE 03 на рівні 2), декомпозоване на Конфігураційні елементи комп'ютерного ПЗ (CSCI) на рівні 3. Кожна CSCI відповідає основному компоненту ПЗ — комплексу програмного забезпечення системи місії, елементу обробки комунікацій, службі управління даними — відповідно до архітектури розподіленого базового плану. Рахунки управління зазвичай встановлюються на рівні 3 (CSCI) або рівні 4 (Компонент комп'ютерного ПЗ, CSC) залежно від розміру програми та складності ПЗ.

Ковзне хвильове планування — це механізм, що підтримує реалістичність WBS впродовж багаторічної програми. Роботи в межах наступних 90 днів (або двох-трьох звітних періодів) декомпозовані до дискретних пакетів робіт із об'єктивними критеріями. Роботи за межами горизонту ковзної хвилі існують як планові пакети — з виділеним бюджетом, але ще не повністю декомпозовані. У міру просування програми планові пакети перетворюються на пакети робіт через формальний процес конвертації, що оновлює IMS, створює документ авторизації робіт та реєструє конвертацію в журналі бюджету.

Типові помилки WBS у програмах ПЗ:

Організація за спринтами або agile-командами замість за продуктовим елементом. Agile-розробка може співіснувати з EVM, але структура рахунків управління повинна відповідати WBS (продукту), а не ритму поставок (процесу). Пакети робіт agile отримують кредити EV після завершення спринту на основі об'єктивних критеріїв прийняття.
Пропуск робіт із системної інженерії та інтеграції. Системна інженерія (SE 01), інтеграція/збирання/тестування та прийняття (SE 10) та управління програмою (SE 12) є окремими елементами MIL-STD-881, кожен з яких повинен мати свої рахунки управління. Програми, які об'єднують ці роботи в рахунки ПЗ, створюють менеджерів рахунків зі змішаною відповідальністю та незакривними відхиленнями.
Нерозширення WBS на субпідрядників. Від значних субпідрядників за критерієм 4 ANSI/EIA-748 вимагається звітувати дані EVM на рівні, що дозволяє нагляд основного підрядника. Основний підрядник, який веде великий субпідряд ПЗ як єдиний рядковий пакет робіт з EV від досягнення контрольних точок, не відповідає критерію 4.

Словник WBS — це документ, який робить WBS операційним: для кожного елемента словник визначає обсяг роботи, відповідального CAM, відповідальну організацію, бюджет та метод отримання кредиту. Словник фіксується на початку контракту, оновлюється через процес контролю змін та перевіряється під час оглядів IBR.

Підготовка до інтегрованого огляду базового плану (IBR)

IBR — це формальна перевірка урядом достовірності базового плану вимірювання ефективності підрядника — того, що обсяг робіт, графік та бюджет є узгодженими та досяжними. Для програм вище порогу EVMS IBR вимагається протягом 180 днів після укладення контракту (Інструкція DoD 5000.02 встановлює політику; окремі офіси програми можуть скоротити цей термін). IBR не є одноразовою подією: він повторюється після значних змін контракту та після будь-якого формального перегляду базового плану.

Цілі IBR з точки зору уряду. Урядова команда IBR оцінює чотири речі: технічну повноту (чи охоплює WBS 100% технічного завдання контракту?), досяжність графіка (чи можна виконати контрольні точки з виділеними ресурсами?), реалістичність бюджету (чи обґрунтовані бюджети законними оцінками, а не просто підігнані до загальної суми контракту?) та ефективність управління (чи дійсно CAM контролюють свої рахунки та розуміють свою роботу?).

Оцінка ризиків графіка. Перед IBR підрядник повинен провести кількісний аналіз ризиків графіка IMS — зазвичай моделювання Монте-Карло з використанням Primavera Risk Analysis або аналогічного інструменту. Аналіз ризиків графіка визначає критичний шлях, майже критичні шляхи та рівень впевненості для ключових дат контрольних точок. Урядові команди IBR запитуватимуть конкретно про резерв графіка: яка затримка на контрольних точках поставки і які ризики можуть поглинути цей резерв? Програми, які приходять на IBR з нульовою затримкою на критичному шляху і без резерву графіка, мають проблему з достовірністю.

Огляди ризиків CAM. Основою IBR є індивідуальний огляд між кожним CAM та урядовою командою IBR. CAM представляє свій рахунок управління: обсяг робіт, графік, бюджет, ресурсне навантаження, ключові ризики та прогноз витрат до завершення. Урядова команда оскаржує припущення CAM та виявляє прогалини. Шість питань, на які кожен CAM повинен відповідати без вагань:

Що саме входить в обсяг мого рахунку управління, і що явно виключено?
Які об'єктивні критерії завершення для моїх пакетів робіт?
Який метод нарахування кредиту я використовую, і чому він підходить для цих робіт?
Які два-три ризики найбільш імовірно спричинять відхилення за вартістю або графіком у моєму рахунку?
Чи достатній мій бюджет для завершення робіт? Якщо ні, де я зможу отримати додаткові кошти?
Яка моя ETC, і як я її розрахував?

Перелік перевірок урядового IBR. Урядова команда зазвичай оцінює: (1) матрицю простежуваності WBS до технічного завдання; (2) мережеву логіку IMS — відсутність незавершених дій, відсутність обмежень, що штучно прискорюють графік; (3) ресурсно-завантажений графік — чи узгоджені години в IMS з бюджетом праці в EVMS?; (4) інтеграцію реєстру ризиків — чи можна прослідкувати виявлені ризики до резерву графіка або управлінського резерву?; (5) статус IBR субпідрядника — чи завершили субпідрядники вище порогу делегування свої власні IBR?; (6) актуальність опису системи — чи відображає опис системи EVMS інструменти та процеси, що фактично використовуються?

IBR видає перелік Дій (AI) та Значних відхилень (SV). AI — це конкретні прогалини, виявлені під час оглядів, які підрядник повинен усунути, зазвичай протягом 30-60 днів. SV є серйознішими — вони вказують на те, що частина базового плану може бути недосяжною — і можуть вимагати формального перепланування. Чистий IBR (кілька AI, відсутність SV) є єдиним найважливішим раннім індикатором достовірності програми для урядового офісу програми.

Звітність менеджера рахунку управління (CAM)

CAM є фундаментальною одиницею виконання EVMS. У програмі ПЗ типовий CAM управляє 3-8 пакетами робіт, що охоплюють проектування, кодування, модульне тестування та інтеграційні роботи свого компонента ПЗ. Місячний цикл CAM визначає якість усіх даних EVM програми.

Ритм нарад статусу CAM. Найкращою практикою для програм ПЗ є щотижневий 30-хвилинний контакт щодо статусу CAM: аналітик програмного контролю (PCA) переглядає фактичні витрати поточного періоду за кожним рахунком, CAM підтверджує або коригує оцінки відсотка виконання, нові ризики позначаються, а відхилення, що виникають, обговорюються до появи у місячному звіті. Нарада із закриття місяця (зазвичай у першому тижні після закриття облікового періоду) — це місце, де фіксується формальний кредит EV, розраховуються відхилення та наративи аналізу відхилень призначаються CAM, які перевищили поріг. Програми, що стискають все це в одну місячну нараду статусу, виробляють дані нижчої якості та пропускають мету раннього попередження щотижневого ритму.

Пороги аналізу відхилень: правило 10%/10. Найпоширеніша контрактна порогова конвенція вимагає письмового звіту аналізу відхилень (VAR), коли накопичений відсоток відхилення за вартістю перевищує 10% накопиченого EV, або коли накопичений відсоток відхилення за графіком перевищує 10% накопиченого PV. У більшості контрактів також встановлюється абсолютна грошова підлога (наприклад, $10 000 на рівні рахунку управління, $100 000 на рівні програми), щоб малі рахунки з великими відхиленнями у відсотках, але малими сумами не генерували обов'язкових наративів. Коли рахунок управління одночасно перевищує поріг за відхиленням вартості та графіка, прийнятним є єдиний VAR, що охоплює обидва показники, але аналіз першопричин повинен окремо розглядати кожне відхилення.

Наратив відхилення до завершення (VAC). Окрім відхилень за поточний та накопичений період, критерій 27 ANSI/EIA-748 вимагає оновлення EAC щонайменше щоквартально, а Формат CPR 1 вимагає щомісячної звітності VAC на рівні рахунку управління. Коли VAC CAM стає від'ємним (прогнозоване перевищення вартості), наратив VAR повинен охоплювати не лише поточний період, але весь термін рахунку. Що сталося, чому це сталося, яка прогнозована дія до завершення контракту, і що конкретно CAM робить для відновлення — або, якщо відновлення неможливе, яке скорочення обсягу, коригування графіка або залучення управлінського резерву пропонується. Наративи VAC, що є копіями тексту попереднього місяця, є найпоширенішим тригером для урядових запитів про особисту нараду з програмою.

Ключовий висновок: Урядові рецензенти не очікують від програм нульових відхилень. Вони очікують CAM, які розуміють, чому відхилення існують, і мають реалістичні плани їх усунення. CAM, який може пояснити від'ємне відхилення вартості у $40 000 із конкретною першопричиною, достовірним графіком відновлення та обґрунтованою ETC, знаходиться в значно сильнішій позиції, ніж CAM, який звітує про позитивне відхилення вартості у $5 000 без наративу — оскільки перший CAM демонструє контроль управління, а другий піднімає питання: чи є позитивне відхилення реальним або артефактом якості даних.

Методи прогнозування кінцевої вартості (EAC)

EAC є найбільш ретельно перевіряваним результатом EVMS. Це найкраща оцінка підрядника щодо загальної вартості програми, що подається щомісяця уряду у Форматі CPR 1. EAC, що постійно є оптимістичнішим, ніж те, що передбачали б тенденції CPI, є сигналом цілісності даних, що спричиняє урядове розслідування. Щомісяця слід розраховувати кілька методів EAC для тріангуляції найбільш обґрунтованої цифри.

EAC = BAC / CPI (метод на основі ефективності). Найпростіший і часто найбільш статистично обґрунтований EAC для програм ПЗ: ділимо Бюджет до завершення на поточний накопичений CPI. Якщо BAC становить $10 000 000, а накопичений CPI — 0,87, то EAC = $10 000 000 / 0,87 = $11 494 253. Цей метод передбачає, що поточна ефективність витрат збережеться до завершення контракту. Дослідження великих баз даних програм послідовно показують, що цей метод перевершує EAC за судженням керівництва після того, як програма виконана на 20-25%.

EAC (тільки CPI)        = BAC / CPI
EAC (CPI x SPI)         = AC + (BAC - EV) / (CPI x SPI)
EAC (знизу вгору)       = AC + Сума(ETCи CAM)
EAC (судження кер-ва)   = AC + ETC за судженням менеджера

TCPI (до BAC)           = (BAC - EV) / (BAC - AC)
TCPI (до EAC)           = (BAC - EV) / (EAC - AC)
VAC                     = BAC - EAC

Комбіновані методи EAC (CPI x SPI). Для програм, де відставання від графіка саме по собі є драйвером зростання вартості — оскільки тривале відставання від графіка збільшує трудові витрати на додаткові періоди — комбінований метод застосовує як CPI, так і SPI як знаменник ефективності: EAC = AC + (BAC - EV) / (CPI x SPI). Цей метод є агресивнішим за метод тільки CPI (дає більший EAC) та часто використовується урядовими незалежними оцінювачами вартості як перехресна перевірка. Комбінований метод має тенденцію завищувати EAC для програм, де відставання від графіка відображає передзавантаження ризику, а не систематичну неефективність.

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

Індекс ефективності до завершення (TCPI) є перевіркою внутрішньої узгодженості: TCPI до BAC = (BAC - EV) / (BAC - AC). Якщо TCPI до BAC становить 1,15, а поточний CPI — 0,88, програма прогнозує покращення ефективності на 31 пункт без продемонстрованої основи. Це математична ознака нереалістичного EAC, і урядові рецензенти негайно її відзначать. Практичне правило: коли TCPI до BAC перевищує 1,10, підрядник потребує або ETC знизу вгору, що пояснює покращення, або переглянутого EAC, що визнає тенденцію до перевищення вартості.

Вибір інструментів EVMS та подання даних

Вибір інструменту EVMS визначає не лише аналітичні можливості, але й практичну простоту подання даних уряду. Уряд тепер вимагає IPMDAR (Інтегрований звіт управління програмою та аналізу даних) у структурованому цифровому форматі, і інструмент повинен експортувати відповідні файли.

Deltek Cobra. Домінуючий інструмент EVMS у програмах DoD. Cobra здійснює управління базовим планом вимірювання ефективності, конфігурацію методів нарахування кредиту, розрахунок відхилень, ведення журналу бюджету та експорт CPR/IPMDAR. Cobra нативно інтегрується з Primavera P6 для інтеграції графіка та вартості та з Deltek Costpoint для імпорту фактичних даних. Його основною перевагою є нативний модуль експорту IPMDAR, який безпосередньо з бази даних Cobra генерує необхідний урядом пакет даних JSON. Для програм вище порогу IPMDAR (від $20 млн із відшкодуванням витрат) Cobra є фактичним стандартом.

Microsoft Project з надбудовами EVM. У менших програмах (до $20 млн, з фіксованою ціною та добровільним EVM або внутрішнього використання) широко використовується Microsoft Project з модулем EVM (Steelray або нативні поля EVM в Project). MS Project не генерує нативно IPMDAR-відповідний експорт і потребує додаткового інструментарію або ручного перетворення даних для урядового подання. Його перевага — знайомість: практично кожен менеджер програми знає його — та щільна інтеграція з середовищами Microsoft 365, поширеними у підрядників оборонної галузі.

Oracle Primavera P6. P6 є авторитетом з графіків у більшості великих програм. Це не нативний інструмент EVMS — він не обробляє бюджетування, нарахування EV або аналіз відхилень на рівні глибини, що вимагає ANSI/EIA-748 — але це платформа Інтегрованого основного графіка (IMS), що передає дані графіка до Cobra або інших інструментів EVMS. Інтеграція P6 з Cobra, належним чином налаштована, дозволяє IMS та EVMS спільно використовувати єдиний авторитетний графік, усуваючи режим збою "відокремленого графіка", що є одним із найпоширеніших результатів аудиту DCMA.

Формати даних IPMDAR та CPR. Звіт про ефективність підрядника (CPR) має п'ять форматів:

Формат 1 — ефективність за елементами WBS: PV, EV, AC, BAC, EAC, VAC за елементом WBS
Формат 2 — ефективність за організаційними підрозділами: ті самі дані, організовані за організаційним елементом
Формат 3 — журнал базового плану: запис усіх змін базового плану вимірювання ефективності за звітний період
Формат 4 — укомплектованість персоналом: фактичні та планові людино-години за спеціальністю
Формат 5 — пояснення та аналіз проблем: наративний розділ, що охоплює значні відхилення, обґрунтування EAC та обговорення ризиків

IPMDAR замінює застарілий формат IPMR та подається як структурований пакет JSON/XML. Перед поданням вимагається перевірка відповідності схемі IPMDAR — інструменти, що генерують невідповідний схемі вивід, призводять до відхилення урядовою системою даних. Подання зазвичай здійснюється через систему Wide Area Workflow (WAWF) або портал EVM Central DoD, залежно від призначеного офісу отримання даних програми. CDRL контракту (Перелік вимог до контрактних даних) встановлює терміни — зазвичай 25 днів після закриття звітного періоду для місячної звітності.

Вибір інструменту слід здійснювати на основі трьох факторів: прийнятності для уряду (опис системи EVMS повинен описувати інструмент, і DCMA повинна мати доступ до його конфігурації), інтеграції з існуючими фінансовими системами та системами графіків (ручне повторне введення даних між фінансовою системою, інструментом графіка та EVMS є джерелом помилок і сигналом тривоги при нагляді) та організаційної експертизи (команда, яка добре знає Cobra, перевершує команду, що вивчає теоретично досконалий інструмент посеред програми). Для нових запусків програм інвестиція в інтеграцію Cobra + Primavera P6 виправдовується скороченням щомісячного навантаження зі звітності та якістю генерованих нею IPMDAR-експортів.

Часті запитання

Що таке метод освоєного обсягу (EVM) і чому він вимагається в оборонних програмах?

Метод освоєного обсягу — це кількісна методологія інтеграції вартості та графіка, що вимірює ефективність програми шляхом порівняння кошторисної вартості запланованих робіт (PV), кошторисної вартості виконаних робіт (EV) та фактичної вартості виконаних робіт (AC). Різниця між EV та AC є відхиленням за вартістю; різниця між EV та PV — відхиленням за графіком. DoD вимагає відповідності EVMS за DoDI 5000.02 та DFARS 252.234-7002 для контрактів із відшкодуванням витрат вище приблизно $20 мільйонів на рівні програми. Вимога виникла з десятиліть досвіду, що свідчить про те, що програми без структурованої інтеграції вартості та графіка послідовно виявляють перевищення вартості пізно, коли коригувальні дії є найбільш дорогими. Відповідність EVMS перевіряється щодо 32 критеріїв ANSI/EIA-748 через формальний огляд опису системи EVMS та процес інтегрованого огляду базового плану.

На що розподілені 32 критерії ANSI/EIA-748?

ANSI/EIA-748 організовує 32 критерії EVMS у п'ять груп настанов. Група організації (критерії 1-5) охоплює декомпозицію WBS, організаційну структуру, інтеграцію рахунків витрат та виявлення вимог EVM субпідрядника. Група планування, складання графіків та бюджетування (критерії 6-14) регулює встановлення базового плану вимірювання ефективності, включаючи мережеву логіку графіка, розподіл бюджету та управлінський резерв. Група питань обліку (критерії 15-18) охоплює реєстрацію фактичних витрат та часово-розподілені фактичні дані. Група аналізу та управлінських звітів (критерії 19-27) охоплює пороги аналізу відхилень, методи EAC та формати урядової звітності. Група переглядів та ведення даних (критерії 28-32) регулює зміни базових планів, ведення журналів бюджету та контроль ретроактивних коригувань. Урядовий нагляд найінтенсивніше зосереджується на групах 2, 4 та 5, оскільки саме ці групи виявляють поведінку, що приховує перевищення вартості.

Що таке інтегрований огляд базового плану (IBR) і що його ініціює?

Інтегрований огляд базового плану — це формальна урядова перевірка базового плану вимірювання ефективності підрядника, яку спільно проводять представник контрактуючого офіцера, офіс програми та менеджери рахунків управління підрядника. IBR ініціюється укладенням контракту вище порогу EVMS (зазвичай протягом 180 днів після укладення), значною зміною контракту, що суттєво змінює обсяг або вартість, або подією перегляду базового плану після формального порушення відхилення до завершення. IBR перевіряє, що базовий план є технічно повним, досяжним за графіком та належним чином забезпечений ресурсами — тобто обсяг робіт, графік та бюджет є внутрішньо узгодженими, а CAM розуміють та контролюють свої рахунки. Невдалий IBR призводить до запиту на коригувальні дії та затримує здатність програми звітувати достовірні дані EVM уряду.

Що таке менеджер рахунку управління (CAM) і які його обов'язки в EVM?

Менеджер рахунку управління — це особа, відповідальна за управління конкретним рахунком управління — перетином елемента WBS та організаційного підрозділу — в рамках EVMS. Обов'язки CAM включають визначення обсягу робіт для свого рахунку управління в пакеті робіт або плановому пакеті, встановлення часово-розподіленого бюджету (кривої планової вартості), реєстрацію або перевірку фактичних витрат, нарахування освоєного обсягу за допомогою затвердженого методу (відсоток виконання, 0/100, 50/50, рівень трудовитрат або контрольні точки), аналіз відхилень за вартістю та графіком відносно порогу правила 10%/10, а також підготовку письмових наративів аналізу відхилень, коли відхилення перевищують поріг. CAM також повинні готувати прогноз витрат до завершення для свого рахунку за кожен звітний період та брати участь в IBR як основний тематичний експерт для свого обсягу робіт. У програмах ПЗ CAM зазвичай управляють 3-8 пакетами робіт у компонентах ПЗ, інтеграції та тестуванні.

Що таке індекс ефективності до завершення (TCPI) і як він використовується для перевірки достовірності EAC?

Індекс ефективності до завершення — це коефіцієнт ефективності, необхідний для залишку робіт для досягнення цілі (BAC або заданого EAC). TCPI до BAC = (BAC - EV) / (BAC - AC). TCPI до EAC = (BAC - EV) / (EAC - AC). Коли TCPI до BAC значно перевищує поточний CPI — наприклад, CPI 0,85, але TCPI 1,15 — програма прогнозує покращення ефективності, яке вона не продемонструвала, що робить EAC недостовірним. Урядові оцінювачі вартості використовують TCPI для оскарження EAC: якщо TCPI перевищує 1,10, вони зазвичай вимагають детальної оцінки знизу вгору для підтвердження претензії на покращення ефективності. TCPI є одним із перших показників, що переглядаються під час аналізу Звіту про ефективність підрядника та під час оглядів IBR логіки прогнозу витрат до завершення CAM.

Яка різниця між EAC, ETC та VAC у урядовій звітності EVM?

У термінології EVM, EAC (Прогноз кінцевої вартості) — це загальна очікувана вартість усіх авторизованих робіт — скільки коштуватиме програма від початку до кінця. ETC (Прогноз витрат до завершення) — це очікувана вартість усіх залишкових авторизованих робіт. Співвідношення: EAC = AC + ETC. VAC (Відхилення до завершення) — це різниця між Бюджетом до завершення та EAC: VAC = BAC - EAC. Від'ємне VAC вказує на перевищення вартості до завершення. EAC подається підрядником у Форматі 3 Звіту про ефективність підрядника; уряд незалежно розробляє IGCE та порівнює її з EAC підрядника. EAC підрядника, що є суттєво оптимістичнішим за IGCE, спричиняє урядовий контроль і може призвести до формальної наради-оскарження.

Які інструменти EVMS використовуються для звітності оборонних програм?

Домінуючий набір інструментів EVMS для програм DoD — Deltek Cobra, який нативно обробляє базовий план вимірювання ефективності, управління методами нарахування кредиту, розрахунки відхилень та експорт CPR/IPMDAR. Oracle Primavera P6 є авторитетом з графіків, що передає дані IMS до Cobra. Microsoft Project з надбудовами EVM використовується у менших програмах нижче порогу IPMDAR. Формат IPMDAR — що замінив застарілий IPMR у 2019 році — є структурованою схемою JSON/XML, що подається до систем даних DoD. Звіт про ефективність підрядника (CPR) має п'ять форматів: ефективність WBS (Формат 1), ефективність організаційних підрозділів (Формат 2), журнал базового плану (Формат 3), укомплектованість персоналом (Формат 4) та пояснення/аналіз проблем (Формат 5). Всі повинні бути подані протягом 25 днів після закриття звітного періоду відповідно до CDRL контракту.

Що таке перегляд базового плану і коли він дозволений за ANSI/EIA-748?

Перегляд базового плану — це формальне скидання базового плану вимірювання ефективності, затверджене контрактуючим офіцером, що замінює поточний базовий план вимірювання ефективності новим часово-розподіленим бюджетним планом. Критерії 28-32 ANSI/EIA-748 регулюють зміни базового плану: рутинні зміни обсягу обробляються через журнал бюджету за допомогою зміни контракту; надпланові базові плани (OTB) затверджуються, коли накопичений EAC програми перевищив BAC і початковий базовий план більше не забезпечує змістовної управлінської інформації. OTB є значною подією — вона сигналізує офісу програми та спільноті нагляду про те, що первісний кошторис програми не був досяжним. DCMA та офіс програми зазвичай вимагають формального плану відновлення та повторного IBR перед затвердженням OTB. Підрядники повинні розрізняти формальні перегляди базового плану (що вимагають затвердження контрактуючого офіцера) та внутрішнє перепланування в рамках авторизованого бюджету (дозволене за критерієм 27 без затвердження контрактуючого офіцера).

Як узгодження MIL-STD-881 впливає на WBS для EVM програмного забезпечення?

MIL-STD-881 надає стандартні визначення елементів WBS для програм оборонних систем. Для програм з інтенсивним використанням ПЗ відповідні елементи включають Програмне забезпечення (SE 03), декомпозоване на Конфігураційні елементи комп'ютерного ПЗ (CSCI), що узгоджуються з архітектурою системи та є природним рівнем для встановлення рахунків управління. Узгодження WBS EVMS з MIL-STD-881 гарантує, що звіти CPR відображаються безпосередньо в WBS програми офісу програми, що дані про вартість агрегуються послідовно між фазами програми та що порівняння IGCE використовують єдиний словник. Програми, організовані за спринтами або командами, а не за CSCI, повинні надавати таблиці відповідності, що узгоджують їхню внутрішню структуру з WBS контракту під час звітування.

Які типові режими збою EVMS у оборонних програмах з інтенсивним використанням ПЗ?

Найпоширеніші режими збою EVMS у програмах ПЗ включають: гумовий базовий план — базовий план вимірювання ефективності коригується ретроактивно для поглинання відхилень замість їх звітування, що є порушенням критеріїв 28-32; завищення відсотка виконання — CAM звітують оптимістичні цифри без об'єктивних доказів, створюючи ілюзію EV, що руйнується при поставці; надмірне використання рівня трудовитрат — застосування нарахування LOE до дискретних завдань ПЗ робить ці завдання невидимими для аналізу відхилень; відокремлений графік — IMS ведеться окремо від EVMS і не інтегрований на рівні пакету робіт, тому відхилення графіка в IMS не з'являються в системі EVM; та відсутність досвіду CAM — призначення рахунків управління EVMS інженерам без навчання EVM призводить до збоїв якості наративів та оцінок ETC, не обґрунтованих реальними оцінками залишку робіт. Всі п'ять шаблонів ідентифікуються через нагляд DCMA та регулярно цитуються у повідомленнях про порушення програм до Конгресу за Поправкою Нанна-Маккарді.