2.1 集成作戰人員需求與保障

2.1.1 簡介

在考慮持續保障策略時，應始終保持相同的起點：識別作戰人員需求。產品保障的目標應為實施可交付可負擔的戰備完好性的持續保障計劃，從而以盡可能最低的成本保證作戰人員任務能力。制定產品保障策略的第一步應為針對所保障的系統識別使用需求——即使產品保障經理正在考慮在可以利用分解后的裝備可用性或作戰可用性作為指定指標的子系統或組件層級實施基于性能的保障。

在制定基于性能的保障協議時，第一步顯得尤為重要，因為其成果將來自作戰人員需求。確保項目管理辦公室、產品保障集成商和產品保障供應商目標一致的關鍵是了解作戰人員在系統性能方面的需求。大部分情況下，作戰人員的需求都會表現為項目分配給系統、子系統或組件層級的可用性和可靠性。

所有主要采辦類別項目都應使用持續保障關鍵性能參數（Key Performance Parameter, KPP）。該參數包含兩個要素：裝備可用性和作戰可用性。表2-1列出了所有的壽命周期持續保障要求。

裝備可用性以何種方式與作戰可用性相互關聯？如圖2-2所示，作戰可用性通常為裝備可用性的子集。作戰可用性指的是某個規定的時間點分配至某個單位的可執行任務的資產數量，而裝備可用性反映的則是整個計劃的使用壽命終止過程中，在規定的時間點從布置到操作服務的系統總庫存。裝備可用性通常用作表示作戰人員對裝備保障需求的合適指標。

2.1.2 過程

項目經理/產品保障經理應負責與產品保障集成商/產品保障供應商溝通作戰人員需求，并確定在基于性能的保障協議中分配需求的合適方法。

作戰需求由各作戰司令部或軍種需求辦公室通過聯合能力集成與研發系統過程制定，并通過聯合能力集成與研發系統需求文件正式化。項目經理處理上述事項的方式將在其與作戰司令部的協議中進一步說明。如果平臺或成品的持續保障目標未明確記錄，則平臺級別的產品保障經理應與作戰人員共同制定一份協議，確定合適的最高級持續保障成果和保障指標。

各項需求與相關的指標應在物資解決方案分析（Material Solution Analysis, MSA）階段做出明確規定，并最終記錄在能力發展文件（Capability Development Document, CDD）中。項目經理和服務需求軍官可隨著系統設計和持續保障策略的不斷成熟，共同協商對需求的修改意見。集成數據環境（Integrated Data Environment, IDE）是隨著項目設計的不斷變化而進行跟蹤和管理各項需求的有效工具。項目經理和產品保障經理應與各作戰司令部共同審核與驗證各類需求與閾值，以確定與指標相對應的閾值（例如，85%的裝備可用性）。在測試數據和使用性能數據可用時，重新驗證就變得尤為重要。

2.1.3 結論

項目經理/產品保障經理應配合作戰人員代表，共同確保識別和記錄產品保障需求，以及確定和更新各項閾值。

識別作戰人員需求是制定基于性能的保障協議的第一步。很多基于性能的保障協議都在子系統或組件級別執行，所以系統級需求應分解為適合產品保障集成商和產品保障供應商指定責任和風險級別的更低等級的指標。基于性能的保障協議也可能包含部分指標，這些協議的成果必須與整體的系統級需求相關聯。

2.1.4 通用子系統使用案例

通用子系統項目經理已決定調查基于性能的保障協議是否有助于實現子系統持續保障策略目標。在審核了第一部分的物資之后，項目經理準備開始第一個步驟：識別作戰人員需求。

通用子系統安裝在更大的平臺之上，對其的持續保障需求由該平臺的作戰需求推斷而來。平臺的作戰可用性目標為90%，其由平臺的部件數量確定。根據通用子系統的故障率和庫存規模，產品保障經理已計算出通用子系統的裝備可用性需求為85%。完整的通用子系統配件當前的庫存超過了平臺成品的機群規模。只要85%的庫存具有作戰可用性，就能滿足90%的系統級作戰可用性目標。此外，平均來看，通用子系統只對不到1%的不能執行任務的成品負責。如果通用子系統是成品的重要戰備完好性驅動因素，則產品保障經理可考慮制定更高的裝備可用性目標。有時，獨立子系統的可用性需求和平臺級需求之間很難建立連接，但如果獲得了合適的數據（也就是表明子系統正在影響系統可用性方式的數據），并與平臺級的產品保障經理（如果不同于子系統產品保障經理）合作，也可推斷出上述指標。