风险管理的目的是 在产品或项目的整个生命周期中,在 潜在风险发生之前将其降低到可接受的水平。风险管理是一个持续的、前瞻性的过程,用于预测和避免可能对项目产生不利影响的风险,可以被视为项目管理和系统工程 过程。 每个项目必须在这两个顶级流程之间的总体风险管理所有权、实施和日常责任方面取得平衡。
对于 SEBoK,风险管理属于系统工程管理 的范畴,尽管下面探讨了更广泛的风险文献。
风险管理流程概述
风险是衡量在规定的成本、进度和技术限制范围内可能无法实现总体项目目标的度量。 它有以下两个组成部分(DAU 2003a):
- 未能实现特定结果的概率(或可能性)
- 未能实现该结果的后果(或影响)
在灾难性风险分析领域,风险有三个组成部分:(1)威胁,(2)漏洞,和(3)后果(Willis et al. 2005)。
风险管理包括定义风险管理战略、识别和分析风险、处理选定的风险以及监控将风险降低到可接受水平的进展(SEI 2010;DoD 2015;DAU 2003a;DAU 2003b;PMI2013)下面简要讨论)。
SE 风险管理流程包括以下活动:
ISO/IEC/IEEE 16085 提供了一套详细的风险管理活动和任务,可用于符合 ISO 31000:2009、风险管理 - 原则和指南以及 ISO 指南 73:2009 的风险管理流程,
风险管理——词汇。 ISO 9001:2008 标准在子条款 8.5.3 中提供了基于风险的预防措施要求。
INCOSE 系统工程手册的风险管理流程部分:系统生命周期流程和活动指南,第 4 版,提供了风险管理的全面概述,旨在与 ISO 15288 的风险管理流程部分保持一致。
风险计划
风险计划建立并维护用于识别、分析、处理和监控项目内风险的策略。 策略,包括过程及其实施,都记录在风险管理计划 (RMP) 中。
风险管理过程及其实施应针对每个项目量身定制,并在项目的整个生命周期中适当更新。RMP 应以适当的方式传递给项目团队和关键利益相关者。
风险管理策略必要时包括所有供应链供应商的风险管理流程,并描述如何将所有供应商的风险提升到下一个级别以纳入项目风险流程。
风险管理过程的背景应包括对利益相关者观点、风险类别的描述,以及对技术和管理目标、假设和约束的描述(可能通过引用)。 风险类别包括系统的相关技术领域,有助于识别系统生命周期中的风险。 正如 ISO 31000 中所述,此步骤的目的是根据可能产生、增强、预防、降低、加速或延迟目标实现的事件,生成一份全面的风险列表。
RMP 应包含关键风险管理信息; Conrow (2003) 将以下内容确定为 RMP 的关键组成部分:
- 项目总结
- 项目收购和承包战略
- 关键定义
- 关键文件清单
- 工艺步骤
- 每个流程步骤的输入、工具和技术以及输出
- 风险管理与其他项目过程之间的联系
- 关键基本规则和假设
- 风险类别
- 买方和卖方的角色和责任
- 组织和人事角色和职责
通常,RMP 中的详细程度是风险驱动的,针对低风险项目制定简单计划,针对高风险项目制定详细计划。
风险识别
风险识别是检查项目产品、过程和需求以识别和记录候选风险的过程。 风险识别应在个人层面以及通过以前的结构化事件定期进行,并在重大项目变更后(例如,项目启动、重新设定基准、采购阶段的变更等)持续进行。
Conrow (2009) 指出,系统工程师应该使用一种或多种顶级方法(例如,工作分解结构 (WBS)、关键流程评估、关键需求评估等)和一种或多种较低级别的方法(例如,亲和力、头脑风暴、清单和分类法、检查关键路径活动、专家判断、石川图等)在风险识别中。 例如,存在用于软件风险识别(Conrow and Shishido 1997, 83-89, p. 84; Boehm 1989, 115-125, Carr et al. 1993, p. A-2)和操作风险的较低级别的检查表和分类法识别(Gallagher et al. 2005, p. 4),并已用于各种程序。 顶层和底层方法是必不可少的,但没有单一的公认方法——所有方法都应检查并酌情使用。
如 Conrow (2003 p.198) 所述,候选风险文档应尽可能包括以下项目:
- 风险名称
- 结构化风险描述
- 适用的风险类别
- 潜在的根本原因
- 相关历史资料
- 负责人和经理
使用结构化风险描述非常重要,例如 if-then 格式: 如果 (事件发生——触发), 那么 (结果或影响发生)。 另一个有用的结构是导致潜在 后果(结果)的 条件 (存在) (Gluch 1994)。 这些方法有助于分析师更好地思考风险的潜在性质。
风险分析和风险处理活动应仅针对批准的风险进行,以确保最佳利用稀缺资源并保持对正确风险的关注。
风险分析
风险分析是系统地评估每个已识别、批准的风险以估计发生的概率(可能性)和发生的后果(影响),然后将结果转换为相应的风险级别或评级的过程。
对于给定的风险类别,没有 最佳 分析方法。 风险尺度和相应的矩阵、模拟和概率风险评估通常用于技术风险,而决策树、模拟和收益矩阵用于成本风险; 模拟用于进度风险。 风险分析方法有时分为定性和定量方法。 应使用结构化、可重复的方法,以提高分析准确性并随着时间的推移减少不确定性。
最常见的定性方法(通常)使用序数概率和后果量表以及风险矩阵(也称为风险立方体或映射矩阵)将结果值转换为风险级别。 在这里,通常使用一个或多个发生概率尺度,以及三个发生尺度的后果(成本、性能、进度)。 不应对序数比例值执行数学运算以防止错误结果(Conrow 2003, p. 187-364)。
一旦确定了每个风险的风险级别,就需要确定风险的优先级。 优先级通常由风险级别(例如,低、中、高)、风险评分(最大(概率)、最大(结果)值对)和其他考虑因素(例如时间范围、发生频率和相互关系)执行其他风险(Conrow 2003, pp. 187-364)。 另一种优先排序技术是将结果转换为估计的成本、性能和进度值(例如,概率预算结果)。 然而,结果只是一个点估计,而不是风险分布。
广泛使用的定量方法包括决策树和相关的预期货币价值分析 (Clemen and Reilly 2001)、建模和模拟 (Law 2007; Mun 2010; Vose 2000)、收益矩阵 (Kerzner 2009, p. 747-751)、概率风险评估(Kumamoto 和 Henley 1996;NASA 2002)和其他技术。 风险优先级可以直接来自所采用的定量方法。 对于定量方法,在开发模型结构时需要小心,因为结果只会与结构的准确性一样好,再加上用于建模风险的概率估计或分布的特征(Law 2007; Evans, Hastings,和孔雀 2011)。
如果给定项目存在多个风险方面(例如,成本风险、进度风险和技术风险),则应将不同的结果整合到一个有凝聚力的三维风险 图景 中。 敏感性分析可以应用于定性和定量方法,以试图了解潜在的可变性将如何影响结果。 应特别强调复合风险(例如,高度耦合的技术风险与不充分的固定预算和时间表)。
风险处理
风险处理是在给定项目限制(预算、其他资源)和目标(DAU 2003a, 20-23, 70-78)的情况下识别和选择选项并实施所需选项以将风险降低到可接受水平的过程。
对于给定 的感兴趣系统 (SoI),风险处理主要在两个级别上执行。 在系统级别,首先确定系统风险的整体集合并确定优先级,并准备第二级风险要素计划草案 (REP) 以处理风险。 对于更复杂的系统,重要的是,较高 SoI 级别的 REP 与较低 SoI 级别的系统 RMP 保持一致,并且顶级 RMP 保持整个 SoI 的持续风险可追溯性。
选择的风险处理策略是最理想的风险处理选项与该选项的合适实施方法的组合(Conrow 2003)。 风险处理选项包括假设、避免、控制(减轻)和转移。 应对所有四个选项进行评估,并为每种风险选择最佳选项。 然后为该选项选择适当的实施方法。 可以开发包含多个风险处理选项但采用单一实施方法的混合策略。 还可以针对给定的风险制定额外的风险处理策略,或者与主要策略并行实施,或者将其作为应急策略,如果在主要策略执行期间发生特定触发事件,则实施该策略。 经常, 由于风险概率和影响的不确定性,这种选择很困难。 在这种情况下,通过原型、基准测试、调查、建模等购买信息以减少风险不确定性将阐明风险处理决策(Boehm 1981)。
风险处理计划
应针对所有 高 风险和 中等 风险制定并实施风险处理计划(RHP - 系统级别的 REP),并根据需要选择 低 风险。
正如 Conrow (2003, 365-387) 所述,每个 RHP 应包括:
- 风险负责人和管理联系人
- 选择的选项
- 实施方式
- 每项活动开始和结束时发生水平的估计概率和后果
- 每个活动的具体可衡量的退出标准
- 适当的指标
- 实施 RHP 所需的资源
每个 RHP 中包含的指标应提供一种客观的方法来确定风险处理策略是否正常以及是否需要更新。 在较大的项目中,这些可能包括挣值、进度和技术绩效测量 (TPM) 的变化,以及风险水平与时间的变化。
每个 RHP 中存在的活动都应该整合到项目的综合主计划或等效项目中; 否则,风险监测和控制将无效。
风险监控
风险监控用于根据既定指标评估风险处理活动的有效性,并向其他风险管理流程步骤提供反馈。 风险监测结果还可以为更新 RHP、开发额外的风险处理选项和方法以及重新分析风险提供基础。 在某些情况下,监测结果也可用于识别新风险、从新方面修改现有风险或修改风险计划的某些方面(DAU 2003a,第 20 页)。 可以应用的一些风险监控方法包括挣值、计划指标、TPM、进度分析和风险级别的变化。 风险监控方法应与 WBS 级别同时更新和评估; 否则,结果可能不一致。
机会和机会管理
原则上,机会管理是风险管理的二元性,具有两个组成部分:(1)实现改进结果的概率和(2)实现结果的影响。 因此,两者都应该在风险管理计划和执行中得到解决。 然而,在实践中,正的机会暴露与效用空间中的负风险暴露不匹配,因为改善预期结果的正效用幅度远小于未能达到预期结果的负效用幅度(加拿大,1971 年;卡尼曼) ——特沃斯基 1979)。 此外,由于许多机会管理计划未能预见到严重的副作用,因此应彻底评估所有候选机会的潜在风险,以防止发生意外后果。
此外,虽然机会可能为系统或项目提供潜在的利益,但所追求的每个机会都可能具有相关的风险,从而减损预期的利益。 除了与不追求机会相关的任何限制之外,这可能会降低实现机会预期效果的能力。
与其他系统工程管理主题的联系
测量过程为风险分析提供了指标。 项目计划涉及风险识别和利益相关者参与计划。 项目评估和控制监控项目风险。 决策管理评估用于选择和处理已识别和分析风险的备选方案。
实际考虑
接下来的两节将描述与系统工程风险管理相关的关键缺陷和良好实践。
缺陷
执行风险管理时遇到的一些关键陷阱如下表 1 所示。
表 1. 风险管理缺陷。 (SEBoK 原创)
名称 | 描述 |
过程过度依赖 |
过度依赖风险管理的过程方面,而没有充分关注人类和组织行为方面的考虑。 |
缺乏连续性 |
未能将风险管理作为一个持续的过程来实施。 如果仅仅为了满足项目审查或其他离散标准而进行风险管理,那么风险管理将是无效的。 (Charette、Dwinnell 和 McGarry 2004、18-24 和 Scheinin 2008)。 |
工具和技术过度依赖 |
过度依赖工具和技术,在日常实施和运行流程上花费的思想和资源不足。 |
缺乏警惕 |
全面的风险识别通常不会涵盖所有风险; 一些风险总是会逃过检测,这加强了持续进行风险识别的必要性。 |
自动缓解选择 |
自动选择风险处理缓解选项,而不是以公正的方式评估所有四个选项并选择“最佳”选项。 |
Sea of Green |
跟踪风险处理计划的进度,而计划本身可能没有充分包括将风险降低到可接受水平的步骤。 与风险处理计划相关的进度指标可能显示为“绿色”(可接受):预算、人员配备、组织、数据收集、模型准备等。但是,如果处理策略和由此产生的计划不佳,风险本身可能在很大程度上不受影响没有解决潜在的根本原因,也没有采取有效解决风险的措施。 |
修补风险处理 |
通过修补每个实例来处理风险(例如,与外部系统更改的互操作性问题),而不是解决根本原因并降低未来实例的可能性。 |
良好实践
从参考文献中收集到的一些良好实践见下表 2。
表 2. 风险管理良好实践。 (SEBoK 原创)
名称 | 描述 |
自上而下和自下而上 |
为了有效,风险管理应该是“自上而下”和“自下而上”的。 项目经理或副手需要拥有最高级别的流程,但所有项目人员都应考虑和使用风险管理原则。 |
早期计划 |
在风险管理过程中包括计划过程步骤。 未能在项目阶段早期充分执行风险计划会导致风险管理无效。 |
风险分析限制 |
了解风险分析工具和技术的局限性。 风险分析结果应该受到质疑,因为可能存在相当大的输入不确定性和/或潜在错误。 |
稳健的风险处理策略 |
风险处理策略应尽量减少出现条款的概率和后果。 还必须及时提供正确实施所选策略所需的资源,否则风险处理策略和整个风险管理过程将被视为“纸老虎”。 |
结构化风险监控 |
风险监控应该是一种结构化的方法,用于比较与实施 RHP 相关的实际与预期成本、绩效、进度和风险结果。 当使用临时或非结构化方法时,或者当风险级别与时间是唯一跟踪的指标时,由此产生的风险监控有用性可能会大大降低。 |
更新风险数据库 |
风险管理数据库(注册表)应在整个项目过程中进行更新,在所需资源过多和执行更新不足之间取得平衡。 数据库更新应该在定制的、定期的时间间隔以及在主要程序更改之后进行。 |
|