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%的不能执行任务的成品负责。如果通用子系统是成品的重要战备完好性驱动因素，则产品保障经理可考虑制定更高的装备可用性目标。有时，独立子系统的可用性需求和平台级需求之间很难建立连接，但如果获得了合适的数据（也就是表明子系统正在影响系统可用性方式的数据），并与平台级的产品保障经理（如果不同于子系统产品保障经理）合作，也可推断出上述指标。