2.3 建立系统基准线
2.3.1 简介
该步骤主要用于评估“按现状的”产品保障策略、计划和协议,以及确定是否进一步的分析可确保变更计划的当前基准线。“按现状的”分析可确定可能存在的阻碍和改进机遇。
确定系统的基准线是一种快速的评估方式。这种方式有助于确定对于项目来说,基于性能的策略是否可行。此外,该评估可以为确定更详细的分析和审核的需求度提供充足的决策信息。
对于新系统来说,建立初始基准线需要获得工程和可保障性数据。初始基准线应在里程碑A阶段设定;但是,这只有在硬件或软件描述的等级更高时才有可能完成。项目对评估的信息会受限于其分配低于主要子系统(例如结构、推进器和任务设备)的性能措施的能力。在更早期的寿命周期阶段,设计系统的基准线需要获得来自类似系统的类似数据。随着项目进入后期里程碑阶段,就可使用来自系统工程和产品保障分析的补充数据,其中包括但不限于以下数据:可靠性、可维护性、诊断预测,故障模式、影响与危害性分析(Failure Mode, Effects &Criticality Analysis, FMECA),以及故障报告、分析与纠正措施系统(Failure Reporting Analysis and Corrective Action System, FRACAS)、维修级别分析(Level of Repair Analysis, LORA)、维护任务分析(Maintenance Task Analysis, MTA)、以可靠性为中心的维护(Reliability-Centered Maintenance, RCM)分析,以及可靠性、可用性和可维护性(Reliability, Availability, and Maintainability, RAM)与寿命周期成本分析。
对于已部署的系统,该步骤开始于将在替代方案分析范围内考虑的资产和服务库存。例如,产品保障管理集成产品小组应将评估限制在合适的级别(系统、子系统、组件,或者可能横跨多个项目或军种)范围内。此外,集成产品小组还应考虑需归入替代方案的产品保障要素。
产品保障管理集成产品小组和合适的装备司令部代表应考虑表2-3中给出的问题。对这些问题的解答可为小组成员提供初步了解基准线改进措施的机遇。
表2-3 有关成本、战备完好性与其他因素的初始问题
本步骤提供了有关项目使用与成本数据的见解。这些见解可决定是否需要对持续保障策略的变更进行持续分析。如果评估的结果表明基于性能的协议的替代策略能维持/改进性能或降低项目成本,则项目经理应继续开展商业案例分析(或合适的经济分析)。
2.3.2 过程——三阶段法
产品保障管理集成产品小组对当前产品保障策略的评估可分三个阶段实施:(1)数据收集;
(2)数据分析;
(3)生成见解/建议。
上述阶段可为集成产品小组提供指导,帮助其分析项目是否是某个备选持续保障策略的潜在候选项,特别是可能改善性能和/或降低成本的基于性能的策略。每个阶段的详情如下所示。
1.第1阶段:数据收集
数据收集阶段始于数据收集计划的制订。数据收集计划中将列出开展产品保障评估所需的数据。该初始阶段包括对“良好”数据的了解。在可能的情况下,收集的数据应与某个事件相关联(例如,需要某天填写基于活动的成本计算部分的申请)。此外,数据应尽可能以最原始的状态收集;避免生成会给新型分析和/或不同假定或运算带来困难的总数或预先计算的指标。
数据收集计划无须详细或复杂,但是必须全面。计划的复杂性取决于项目的特性和其所处的寿命周期阶段,其可以像一个表格或一份两页的大纲一样简单。数据收集计划应包含数据来源,以确保针对必要的跟进措施,确定管理责任和提高所收集数据的准确性和可跟踪性。图2-4(其依据是从存在故障到可用的修理过程)给出了数据收集表的样本。底部高亮显示的数据可以帮助产品保障管理集成产品小组分析现行的产品保障策略。
图2-4 数据收集模型样本
数据收集还包含与合适的利益相关方的面谈,以及对产品保障政策和其他保障文件的分析。产品保障经理集成产品小组应确保所有的数据准确、及时,且与接受评估的替代方案相关。
集成产品小组应记录每次会议、面谈和接收的数据,以确保未出席的个人可轻松获取和了解调查的结果。合同商和政府可分别完成一部分的数据生成和分析工作。根据合同交付的数据应包含各类标记,表明是否存在对政府使用、修改、复制、发布、执行、展示或披露数据能力的限制。Excel或其他建模平台中的数据软件都是合同数据和进行后续数据操作和分析的有用工具。无论来源如何,都应将数据置于所有成员都可获取的中心位置。
在开始下一阶段的工作之前,无须获得所有数据。在部分情况下,某些数据可能还无法获得。集成产品小组应继续监控在第1阶段和第2阶段收到的数据,然后尽可能在第2阶段结束之前获取剩余的数据。表2-4详细描述了完成数据收集阶段所需的工作。
表2-4 数据收集活动
2.第2阶段:数据分析
本阶段包含确定进一步分析和审核需求度的最高级评估。项目管理办公室应与利益相关方合作,确定物资流动关系、循环次数、劳动力需求,以及其他使用进程图的过程要素。进程图可以帮助集成产品小组将整个供应链视觉化和发现高等级的产品保障策略改进机遇。进程图应包含供应链所涉及的特定活动和活动所有者,包括供应保障、维护、修理、大修或其他合适的集成产品小组要素。如果不存在现有的进程图,则应与关键利益相关方共同制作进程图。即使已经记录详细的进程图,利益相关方还是可以在对其进行审核和验证时获益。
表2-5详细描述了完成数据分析阶段所需的工作。
表2-5 数据分析活动
在使用了第1阶段收集的数据之后,产品保障管理集成产品小组应设法通过数据驱动和基于证据的响应来回答下列问题。表2-6中给出了会对战备完好性和成本造成影响的关键考虑因素。
表2-6 评估战备完好性与成本时应考虑的因素
3.第3阶段:生成见解和建议
本阶段主要的工作是整合收集和分析的数据,形成与备选持续保障策略可行性和潜在改进机遇相关的见解。也就是说,在本阶段收集的见解依据的是以下问题:备选的持续保障策略是否能够改进战备完好性和/或成本成果?分析应从数据中获得见解,而不是通过生搬硬套已收集的信息来确定前进的方向。举例来说,相比简单记录规定年度内与某个部件相关的延期交货小时数,更恰当的做法应该是了解长期的趋势,或是与该部件相关的总延期交货小时数的百分比。上述见解可以提供工作的背景和以全新的方式形成的信息。这种方式可以帮助产品保障管理集成产品小组确定持续保障策略的变化是否有利和可行。
本过程将形成两个可能的建议:基于性能的保障协议是否可以改进成本或战备完好性成果。在上述案例中,如果基于性能的保障协议证明可行,就需要对其进行更详细的分析。如果采用基于性能的协议被视为是不恰当的行动方案,项目经理/产品保障经理仍应确保其当前所使用的持续保障策略可以尽可能最低的成本保障作战人员需求,并在寿命周期保障计划和其他文件(视具体情况而定)中记录其所做的决策。表2-7介绍了第3阶段的高级别活动。
表2-7 形成见解与建议的活动
2.3.3 结论
本步骤结尾将根据持续保障策略变更的潜在收益和基于性能的保障协议的可行性,提出有关持续分析的“继续/停止”建议。项目管理办公室应审核基于性能的保障策略可能提供的成本节约和战备完好性改进机遇,并在后续步骤中探索可能的替代方案。
2.3.4 通用子系统使用案例
产品保障经理通过数据收集计划确定了必要的信息,并与关键利益相关者面谈。产品保障经理与来自项目管理办公室、维护组织、供应保障部门、野战级保障单位和需求小组的代表进行了面谈。分析在使用了收集的数据之后完成,并形成了可与集成产品小组分享的关键见解。根据分析和获得的见解,产品保障经理能够形成对当前产品保障策略性能的认识。
总体上,产品保障经理确定了当前的产品保障策略应该是满足作战人员需求,但其也可能提高战备完好性和降低成本。正如之前所讨论的一样,通用子系统仅负责不到1%的系统级故障,这一比例与本平台其他子系统相当。但是,产品保障经理发现有六个组件正在导致维护和供应保障相应时间的延迟,而且其保障成本高于预期。通用子系统产品保障经理对上文第2阶段给出的因素进行了分析,然后形成了表2-8中所示的调查结果。
表2-8 通用子系统应考虑的关键事项
基于上述调查结果,通用子系统产品保障经理得出结论,项目管理办公室应开展更详细的分析,确定可能通过基于性能的保障协议节约的成本。目前不存在对基于性能的保障协议的阻碍:时机合适,利益相关方已达成一致,且项目管理办公室也正在寻求降低持续保障成本。此外,项目管理办公室也可通过协议提高供应绩效。