Wiki源代码通用管理实践 - 25 风险
由 superadmin 于 2024/12/25, 15:36 最后修改
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | {{info}} | ||
| 2 | |||
| 3 | {{/info}} | ||
| 4 | |||
| 5 | |||
| 6 | **申明:** | ||
| 7 | |||
| 8 | 本系列ITIL 4中文版本由长河领导的ITIL先锋论坛专家委员会组织翻译,国内众多从事ITIL理论推广及落地实践的专家们参与。需要下载最新翻译版本请关注**微信公众号:ITILXF**,并回复“**风险管理**”即可。 | ||
| 9 | |||
| 10 | {{box cssClass="floatinginfobox" title="**Contents**"}} | ||
| 11 | {{toc/}} | ||
| 12 | {{/box}} | ||
| 13 | |||
| 14 | ((( | ||
| 15 | |||
| 16 | |||
| 17 | 请注意,ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作,我们并不拥有包括原著以及中文发行文件的任何版权,所有版权均为Axoles持有,读者在使用这些文件(含本中文翻译版本)时需完全遵守Axoles 和 TSO所申明的所有版权要求。 | ||
| 18 | |||
| 19 | |||
| 20 | **翻译**:史坦晶 **审校**:隗玉凯 **审核**:严宝龙 | ||
| 21 | |||
| 22 | ---- | ||
| 23 | |||
| 24 | |||
| 25 | ))) | ||
| 26 | |||
| 27 | = **1 关于本文档** = | ||
| 28 | |||
| 29 | |||
| 30 | 本文档为风险管理实践提供了实用指南。它分为五个主要部分,内容包括: | ||
| 31 | |||
| 32 | * 有关风险管理的一般信息 | ||
| 33 | * 风险管理的流程和活动及其在服务价值链中的作用 | ||
| 34 | * 风险管理中涉及的组织和人员 | ||
| 35 | * 支持风险管理的信息和技术 | ||
| 36 | * 合作伙伴和供应商在风险管理实践中的考虑 | ||
| 37 | |||
| 38 | == 1.1 ITIL®4 认证计划 == | ||
| 39 | |||
| 40 | |||
| 41 | 本文档中的部分内容可作为以下教学大纲的一部分以供检查: | ||
| 42 | |||
| 43 | * ITIL专家:创建,交付和支持 | ||
| 44 | * ITIL专家:指导,计划,改进 | ||
| 45 | |||
| 46 | 详情请参考各部分教学大纲。 | ||
| 47 | |||
| 48 | |||
| 49 | |||
| 50 | ---- | ||
| 51 | |||
| 52 | = **2 一般信息** = | ||
| 53 | |||
| 54 | |||
| 55 | |||
| 56 | == 2.1 目的和描述 == | ||
| 57 | |||
| 58 | 风险管理实践的目的是确保组织理解并有效地处置风险。管理风险对于确保组织的可持续性以及为其客户共同创建价值至关重要。风险管理是所有组织活动中不可缺少的一部分,因此对于组织的服务价值系统(SVS)至关重要。 | ||
| 59 | |||
| 60 | 风险管理在组织的所有层级上执行。战略性风险管理考虑了可能影响组织实现其使命能力的长期风险。项目群和项目的风险管理考虑了可能影响中期目标和目的的风险。运维相关的风险管理专注于短期目标和目的。这些层次的风险管理每一个都必须基于在组织治理的指引下进行。 | ||
| 61 | |||
| 62 | ITIL对服务的定义明确指出,代表服务消费者来管理风险是每个服务的必不可少的组成部分。 | ||
| 63 | |||
| 64 | |((( | ||
| 65 | **服务** | ||
| 66 | ))) | ||
| 67 | |((( | ||
| 68 | **一种通过促进产出客户想要的成果来实现价值共创的方法,而客户不必管理特定的成本和风险。** | ||
| 69 | ))) | ||
| 70 | |||
| 71 | 每个服务都消除了来自服务消费者的某些风险,但也对服务消费者施加了其他额外风险。服务提供者必须以受控的方式理解和管理这些风险。消除风险与施加风险之间的平衡正是服务价值主张的一部分。 | ||
| 72 | |||
| 73 | 风险管理实践提供了在服务管理四个维度上有效且高效地识别和管理风险所需资源的机制。 | ||
| 74 | |||
| 75 | |||
| 76 | == 2.2 术语和概念 == | ||
| 77 | |||
| 78 | |||
| 79 | |||
| 80 | |||
| 81 | === **2.2.1 风险** === | ||
| 82 | |||
| 83 | |**风险** | ||
| 84 | |**可能造成危害或损失,或阻碍目标实现的事件。也可以定义为成果的不确定性,并且可以用于测量正面结果和负面结果可能性的情形。** | ||
| 85 | |||
| 86 | 通常情况下风险是和威胁相关并应予以规避的,尽管这是一般事实,但风险也总是关联机会。 | ||
| 87 | |||
| 88 | 任何不确定的结果都是风险。当风险为负面的时,不确定的结果将导致危害或损失。但是,当风险为正面时,不确定的结果将为一个或多个利益相关者带来收益。例如,组织可能会投资新的服务,以期吸引客户并产生收益。但是,结果并不能保证是正面的,而是不确定的或有风险的。正面的风险有时称之为机会。 | ||
| 89 | |||
| 90 | 没有抓住机会可能成为风险。不投资于服务或发展客户关系的组织将无法保持其市场地位。组织运营的环境一直在发展,而无法跟上发展可能对组织构成风险。 | ||
| 91 | |||
| 92 | |||
| 93 | === **2.2.2 风险容量** === | ||
| 94 | |||
| 95 | 风险容量由组织治理定义。风险管理活动必须确保风险保持在风险容量以下。 | ||
| 96 | |||
| 97 | 如果组织中的风险级别太高,则可能对其持续运营能力产生重要的影响。组织的风险容量是组织可以忍受风险的最大值,并且通常基于诸如对声誉和资产的损害等因素。 | ||
| 98 | |||
| 99 | |||
| 100 | |||
| 101 | === **2.2.3 风险偏好** === | ||
| 102 | |||
| 103 | 风险偏好由组织治理定义,用于促进决策和风险管理活动。 | ||
| 104 | |||
| 105 | 一些组织选择承担重大风险以取得重大收益。其他组织更愿意少冒风险,但这也减少了机会。组织的风险偏好是组织愿意接受的风险数量。它应始终小于组织的风险容量。 | ||
| 106 | |||
| 107 | |||
| 108 | === **2.2.4 风险登记册** === | ||
| 109 | |||
| 110 | 保留已识别风险的记录很重要,它记录风险的当前状态和历史。该记录被称为风险登记册。风险登记册中的每个条目都显示了单个风险的历史记录和状态。通常应将包括以下信息(但可能会有所不同,具体取决于组织实际需要): | ||
| 111 | |||
| 112 | * 唯一标识 | ||
| 113 | * 类别(将相似类型的风险分组) | ||
| 114 | * 描述 | ||
| 115 | * 可能性 | ||
| 116 | * 影响 | ||
| 117 | * 总体评级或评分 | ||
| 118 | * 所有者 | ||
| 119 | * 处置措施 | ||
| 120 | * 处置后更新的评级或评分(残余风险) | ||
| 121 | * 记录的日期 | ||
| 122 | |||
| 123 | 一个组织可能具有多个风险登记册,具体取决于组织的大小和结构以及所管理风险的数量和类型 | ||
| 124 | |||
| 125 | |||
| 126 | === **2.2.5 风险所有者** === | ||
| 127 | |||
| 128 | 风险所有者可能不负责管理风险所需的操作,但是他们必须确保这些操作是适当的并且已被实际采取。 | ||
| 129 | |||
| 130 | 每个风险必须分配一个所有者,负责确保风险已被理解和适当地管理。一旦确定了风险,就应立即分配风险所有者,并应将其记录在风险登记册中。 | ||
| 131 | |||
| 132 | |||
| 133 | === **2.2.6 风险处置** === | ||
| 134 | |||
| 135 | 风险有时可以被消除,但这一般不常见。在了解了风险发生的概率和影响之后,风险所有者必须就处置风险的合适方法达成一致。表2.1中显示了可用来处置风险的操作。 | ||
| 136 | |||
| 137 | |||
| 138 | 表2.1 风险处置选项 | ||
| 139 | |||
| 140 | (% style="width:814px" %) | ||
| 141 | |(% style="width:172px" %)**处置**|(% style="width:277px" %)**描述**|(% style="width:363px" %)**示例** | ||
| 142 | |(% style="width:172px" %)风险规避|(% style="width:277px" %)通过不执行危险的活动来防止风险|(% style="width:363px" %)通过拒绝商业投资建议,避免无法交付预期价值的投资风险 | ||
| 143 | |(% style="width:172px" %)风险修正(或风险降低)|(% style="width:277px" %)实施控制以减少风险的可能性或影响|(% style="width:363px" %)在网络上传输敏感信息时对其进行加密,以减少被破译的可能性 | ||
| 144 | |(% style="width:172px" %)风险分担|(% style="width:277px" %)通过将一些风险传递给第三方来减少影响|(% style="width:363px" %)为火灾或网络攻击购买保险 | ||
| 145 | |(% style="width:172px" %)风险残留(或风险接受)|(% style="width:277px" %)主观上决定接受风险,因为它低于可接受的阈值(并且在组织的风险偏好范围之内)|(% style="width:363px" %)通过接受商业投资建议,接受未能交付预期价值的投资风险 | ||
| 146 | |||
| 147 | 在涉及正面风险(机会)时,术语通常略有不同。“风险规避“变成“风险利用“,而”风险降低”变成”风险增强“。然而,术语”风险修正”已经涵盖了正面风险和负面风险的意思。 | ||
| 148 | |||
| 149 | |||
| 150 | === **2.2.7 控制** === | ||
| 151 | |||
| 152 | |**控制** | ||
| 153 | |**管理风险的方法,确保实现业务目标或遵循流程的要求。** | ||
| 154 | |||
| 155 | 风险的调整要求实施控制以减少风险的可能性或影响。 | ||
| 156 | |||
| 157 | 控制可以基于技术,例如防火墙或弹性网络配置,但它也可以与服务管理的其他维度有关。表2.2中显示了每个维度的一些控制示例 | ||
| 158 | |||
| 159 | |||
| 160 | 表2.2 控制示例 | ||
| 161 | |||
| 162 | (% style="width:533px" %) | ||
| 163 | |(% style="width:163px" %)**维度**|(% style="width:368px" %)**控制示例** | ||
| 164 | |(% style="width:163px" %)组织和人员|(% style="width:368px" %)((( | ||
| 165 | * 整洁办公桌策略 | ||
| 166 | * 安全意识培训 | ||
| 167 | ))) | ||
| 168 | |(% style="width:163px" %)信息和技术|(% style="width:368px" %)((( | ||
| 169 | * 网络防火墙 | ||
| 170 | * 审计记录 | ||
| 171 | ))) | ||
| 172 | |(% style="width:163px" %)供应商和合作伙伴|(% style="width:368px" %)((( | ||
| 173 | * 将供应商认证作为质量管理体系标准的合同要求 | ||
| 174 | * 供应商活动的日常审计 | ||
| 175 | ))) | ||
| 176 | |(% style="width:163px" %)价值流和流程|(% style="width:368px" %)((( | ||
| 177 | * 部署之前的变更评估 | ||
| 178 | * 员工招聘期间的背景调查 | ||
| 179 | ))) | ||
| 180 | |||
| 181 | === **2.2.8 剩余风险** === | ||
| 182 | |||
| 183 | 风险处置通常不能完全消除风险。因此,在应用控制之后有必要执行新的风险评估。这是为了了解新的可能性和影响,然后计算剩余风险。组织然后可以选择应用更多控制来进一步减小风险。或者,组织可以接受剩余风险,并将其记录在风险登记册中,像其他保留的风险一样以相同的方式传递给利益相关者。 | ||
| 184 | |||
| 185 | |||
| 186 | == **2.3 范围** == | ||
| 187 | |||
| 188 | |||
| 189 | 风险管理的范围非常广泛。大多数活动和组织中的所有人员在风险管理中都可以起到一定做用。服务提供者必须理解和管理与每个服务和每个客户相关的诸多风险。ITIL 4中描述的许多管理实践要求将风险管理作为其活动的一部分。这些包括: | ||
| 190 | |||
| 191 | * 项目管理 | ||
| 192 | * 信息安全管理 | ||
| 193 | * 组合管理 | ||
| 194 | * 问题管理 | ||
| 195 | * 事件管理 | ||
| 196 | * 服务连续性管理 | ||
| 197 | * 持续改进 | ||
| 198 | * 服务级别管理 | ||
| 199 | |||
| 200 | 尽管与风险管理密切相关,但仍有多个活动和职责范围未包含在风险管理实践中。表2.3中列出了这些内容,并提供了对相关实践指南的引用。重要的是要记住,ITIL实践只是在价值流的上下文中使用的工具集,应根据实际情况将它们组合在一起。 | ||
| 201 | |||
| 202 | |||
| 203 | 表2.3 其他实践指南中与风险管理实践相关的活动 | ||
| 204 | |||
| 205 | (% style="width:346px" %) | ||
| 206 | |(% style="width:169px" %)活动|(% style="width:174px" %)实践指南 | ||
| 207 | |(% style="width:169px" %)特定风险的管理|(% style="width:174px" %)所有实践 | ||
| 208 | |(% style="width:169px" %)实施变更以减轻风险|(% style="width:174px" %)((( | ||
| 209 | 组织变更管理 | ||
| 210 | |||
| 211 | 变更使能 | ||
| 212 | |||
| 213 | 发布管理 | ||
| 214 | |||
| 215 | 部署管理 | ||
| 216 | |||
| 217 | 软件开发和管理 | ||
| 218 | |||
| 219 | 服务验证和测试 | ||
| 220 | |||
| 221 | 基础设施和平台管理 | ||
| 222 | |||
| 223 | 劳动力和人才管理 | ||
| 224 | |||
| 225 | 项目管理 | ||
| 226 | ))) | ||
| 227 | |(% style="width:169px" %)成本控制,风险的财务评价和风险减轻选项|(% style="width:174px" %)服务财务管理 | ||
| 228 | |(% style="width:169px" %)愿景的定义和风险管理的战略目标|(% style="width:174px" %)战略管理 | ||
| 229 | |||
| 230 | === **2.3.1 项目管理** === | ||
| 231 | |||
| 232 | 项目管理中的一个重要部分是管理项目风险。应根据与战略目标、成本、风险、收益和进度的一致性来分析每个项目。这样做的结果将会创建一个项目风险登记册,该登记簿将在整个项目生命周期中进行维护,并用于确保项目风险得到妥善管理。 | ||
| 233 | |||
| 234 | 某些项目风险可能需要在项目之外进行管理,因此可能会将其记录在其他风险登记册中。 | ||
| 235 | |||
| 236 | |||
| 237 | === **2.3.2 信息安全管理** === | ||
| 238 | |||
| 239 | 信息安全管理的目的是保护组织开展业务所需的信息。这包括了解和管理与信息的保密性,完整性和可用性以及信息安全的其他方面有关的风险,例如身份验证(确保某人是他声称的身份)和不可抵赖性(确保某人无法否认他所采取的行动)。这意味着风险管理在信息安全管理实践中扮演着非常重要的角色。理想情况下,这不应与风险管理的其他方面分开。组织可以选择为信息安全管理建立风险登记册,但是关于信息安全的重要风险也应出现在组织的风险登记册中。其中一些信息安全风险可能由信息安全经理、服务所有者或实践所有者拥有和管理,但有些风险则需要升级到高级管理层,因为它们可能对组织已经构成已存在的威胁。 | ||
| 240 | |||
| 241 | 信息安全管理通常会创建和管理许多控制,这些控制随着威胁和漏洞的发展而进行维护。 | ||
| 242 | |||
| 243 | |||
| 244 | === **2.3.3 组合管理** === | ||
| 245 | |||
| 246 | 组织的投资组合可以映射到风险管理的潜在组合中。当服务管理有效时,服务目录和流水线中的产品和服务将为客户、组织和其他利益相关者创造和捕获价值提供机会。否则,考虑到它们带来的需求模式可能失效、它们所需的承诺以及它们所花的成本,这些产品和服务反而可能构成威胁。战略的实施通常需要改变产品和服务组合并管理相关风险。 | ||
| 247 | |||
| 248 | |||
| 249 | === **2.3.4 问题管理** === | ||
| 250 | |||
| 251 | 问题管理通常与风险管理相关,问题管理实践的目的是通过识别事件的实际和潜在原因并管理规避措施和已知错误,以减少事件发生的可能性和影响。 | ||
| 252 | |||
| 253 | 造成事件的潜在原因是风险,降低事件发生的可能性和影响是一种风险管理活动。ITIL 4 Foundation指出,'问题管理活动可以被做为风险管理的特定情况:它们旨在从服务管理的四个维度来识别,评估和控制风险。问题管理中'采用风险管理工具和技术是很有用的。 | ||
| 254 | |||
| 255 | ITIL对待问题管理与风险管理的其他方面不同。这是由于问题的性质和频率以及管理这些问题所需的资源所致。但是,组织可以将所有问题都视为风险,并采用与其他风险完全相同的方式来管理这些问题,这也是可以接受的。 | ||
| 256 | |||
| 257 | |||
| 258 | === **2.3.5 事件管理** === | ||
| 259 | |||
| 260 | 尝试诊断和解决事件时采取的措施可能会导致风险。管理重大事件时采取的措施可能会对服务提供者和服务消费者带来巨大风险。这意味着涉及其中的每个人都需要风险管理实践来确保他们了解所涉及的风险,以便对这些风险进行适当的管理。 | ||
| 261 | |||
| 262 | |||
| 263 | === **2.3.6 服务连续性管理** === | ||
| 264 | |||
| 265 | 服务连续性管理是一种控制,用于管理可能影响服务的可用性或绩效的广泛的各种风险。有效的服务连续性管理实践可对风险管理提供重大帮助。 | ||
| 266 | |||
| 267 | |||
| 268 | === **2.3.7 持续改进** === | ||
| 269 | |||
| 270 | 持续改进优先考虑和管理改进机会。风险管理涉及正面风险(通常称为机会)以及负面风险。 | ||
| 271 | |||
| 272 | 许多组织将所有正面风险的管理视为持续改进活动,而仅将风险管理用于负面风险。结果在风险登记册中仅包含负面风险,而持续改进登记册中包含正面风险。其实只要控制好所有风险,这样的做法也完全可以接受。 | ||
| 273 | |||
| 274 | |||
| 275 | === **2.3.8 服务级别管理** === | ||
| 276 | |||
| 277 | 服务级别管理就是确保服务级别约定得以实现。这包括识别和管理可能影响服务级别的任何风险,并将这些风险报告给可能需要咨询或告知的客户和其他利益相关者。 | ||
| 278 | |||
| 279 | 好的服务级别报告包括识别将来可能影响服务的风险,以及如何管理这些风险的说明。通常,风险管理需要记录来自客户和用户的输入或他们采取的行动。 | ||
| 280 | |||
| 281 | |||
| 282 | == **2.4 实践成功因素 ** == | ||
| 283 | |||
| 284 | |||
| 285 | |((( | ||
| 286 | 实践成功因素(PSF) | ||
| 287 | |||
| 288 | 实现实践目标所必需的复杂的功能性组件。 | ||
| 289 | ))) | ||
| 290 | |||
| 291 | 实践的成功因素(PSF)不仅仅是一项任务或活动;它包括服务管理所有四个维度的组件。在实践中那个活动的性质和PSF的资源可能有所不同,但它们共同确保了实践有效。 | ||
| 292 | |||
| 293 | 风险管理实践包含以下PSF: | ||
| 294 | |||
| 295 | * 建立风险管理的治理 | ||
| 296 | * 培育风险管理文化并识别风险 | ||
| 297 | * 分析和评估风险 | ||
| 298 | * 处置、监控和评审风险 | ||
| 299 | |||
| 300 | === **2.4.1 建立风险管理的治理** === | ||
| 301 | |||
| 302 | 所有风险管理活动都需要清楚地了解组织的风险容量和风险偏好。这些活动不能由实践者定义,它们是组织治理的关键。这意味着风险管理依赖于组织的整体治理。 | ||
| 303 | |||
| 304 | 如果未提供此治理,则实践者需要做出响应,并确保管理董事会(或同等功能的机构)对此负责。如果在没有治理的情况下实施风险管理,将很难根据组织的长远需求做出决策。 | ||
| 305 | |||
| 306 | 某些风险会给组织带来现成的威胁。这些风险应由组织的治理主体拥有。理想情况下,应该在董事会会议上定期讨论风险管理的治理。此外,还应该在董事会会议上讨论、商定和定期评审风险容量、风险偏好和战略风险。 | ||
| 307 | |||
| 308 | |||
| 309 | === **2.4.2 培育风险管理文化并识别风险** === | ||
| 310 | |||
| 311 | 识别风险后,组织可以在风险登记册中对其进行记录并进行管理。然而,由于没有简单的流程或规程来识别风险,而且大多数组织都有大量未知风险,因此识别风险可能非常困难。 | ||
| 312 | |||
| 313 | 在3.2.1节中讨论了可以帮助识别风险的方法,但是支持这一点的最重要的管理活动是培育风险管理文化。组织中的每个人都应担负起识别和报告他们发现的任何风险的责任。这需要一种让人们可以心安理得地识别自己和他人所犯的错误的文化,而不用担心遭到报复。因此,管理者和领导者需要培育一个开放而诚实的文化。 | ||
| 314 | |||
| 315 | 当风险管理嵌入组织的文化中时,员工将能预见潜在的问题。然后,员工可以考虑如何减轻风险以及他们是在采取战略举措还是在执行例行的运维任务。 | ||
| 316 | |||
| 317 | |||
| 318 | === **2.4.3 分析和评估风险** === | ||
| 319 | |||
| 320 | 风险分析包括了解每个风险发生的可能性和潜在影响。分析可以是定性的或定量的。 | ||
| 321 | |||
| 322 | |||
| 323 | |||
| 324 | ==== 2.4.3.1 定性风险分析 ==== | ||
| 325 | |||
| 326 | 定性风险分析使用简单的度量(例如高,中或低)来区分可能性和影响的不同级别。定性风险分析通常会使用一个表格,该表格用于从影响级别和可能性级别两个维度中得出总体风险的级别,如图2.1 所示。 | ||
| 327 | |||
| 328 | [[image:1642583640886-103.png]] | ||
| 329 | |||
| 330 | 图2.1 用于定性风险分析的矩阵示例 | ||
| 331 | |||
| 332 | |||
| 333 | 风险分析的输出确定了风险的级别,该级别记录在风险登记册中,并用于决定所需的风险处置措施。在图2.1的示例中,具有中等可能性和高影响的风险将被评为高风险。此结果有其特定性,无法将来自不同组织的风险分析结果进行比较。 | ||
| 334 | |||
| 335 | 一些组织使用的是五点量表,而不是图2.1中所示的简单的三点量表(高,中或低),但是方法仍然相同。 | ||
| 336 | |||
| 337 | |||
| 338 | |||
| 339 | ==== 2.4.3.2 定量风险分析 ==== | ||
| 340 | |||
| 341 | 定量风险分析在财务基础以及其他量化基础上考虑风险影响。可能性以概率来衡量。这种风险分析用于支持商业案例中的预算,以证明管理风险可能需要的投资是合理的。 | ||
| 342 | |||
| 343 | |((( | ||
| 344 | 年发生率(ARO) | ||
| 345 | |||
| 346 | 待定风险将在一年内出现的可能性。 | ||
| 347 | |||
| 348 | 单一预期损失(SLE) | ||
| 349 | |||
| 350 | 每次发生风险时,由风险造成的预期财务损失。 | ||
| 351 | ))) | ||
| 352 | |||
| 353 | |((( | ||
| 354 | 年度预期损失(ALE) | ||
| 355 | |||
| 356 | 在平均为一年的时期内,风险造成的预期财务损失。ALE是通过将单一预期损失(SLE)乘以年发生率(ARO)来计算的。 | ||
| 357 | ))) | ||
| 358 | |||
| 359 | 每年的发生率是根据风险发生频率的预期得出的。例如,预期每五十年发生一次的事件的ARO为2%。 | ||
| 360 | |||
| 361 | 根据发生风险时产生的平均成本计算SLE。这通常以财务术语表示,但在某些组织中,可能以其他度量方式表示,例如销售亏损。 | ||
| 362 | |||
| 363 | ALE通过将SLE乘以ARO来计算。然后可以将此结果与控制的成本进行比较,以便决定在管理特定风险方面需要投入多少资金。 | ||
| 364 | |||
| 365 | |||
| 366 | |||
| 367 | ==== 2.4.3.3 风险定性和定量结合分析 ==== | ||
| 368 | |||
| 369 | 定量风险分析比定性风险分析要花费更多的时间,因此通常将两者结合在一起来优化分析数据的时间开销。这包括对每个已识别的风险进行定性风险分析,然后针对风险级别和降低风险的成本中超出特定阈值的那些风险执行定量风险分析。例如,组织的风险管理策略可能声明,如果控制的成本低于5,000英镑,则将使用控制来管理低级别风险。如果控制的成本高于5,000英镑,将执行定量风险分析。 | ||
| 370 | |||
| 371 | |||
| 372 | === **2.4.4 处置,监控和评审风险** === | ||
| 373 | |||
| 374 | 每个风险必须以相同的方式处置。即使已决定接受风险,也并不意味着不会采取行动。应当记录接受的风险,将其传达给相关的利益相关者,并定期进行评审以确保风险可能性、影响或控制成本的变化都已得到考虑。 | ||
| 375 | |||
| 376 | 在决定管理风险时,需要设计和实施合适的控制。必须维持这些控制措施,以确保它们保持相关性且得到正确实施以提供约定的保护级别。例如,如果组织有整洁办公桌策略,那么将其传达给所有可能在办公桌上留下文件的员工,并定期进行强调和审计,这些行动很重要。同样,一个需要所有计算机都要运行最新防病毒软件的控制必须通过适当的技术来识别出任何不符合要求的计算机。 | ||
| 377 | |||
| 378 | 如何定义控制的某些内容将在3.2.1节中描述,但处置、监控和评审风险要求在服务管理所有四个维度之间保持适当的平衡。这点不仅仅是一个流程事项。 | ||
| 379 | |||
| 380 | |||
| 381 | == **2.5 关键指标 ** == | ||
| 382 | |||
| 383 | |||
| 384 | 应在每个实践所贡献的价值流的情形中 评估ITIL实践的效果和绩效。与任何工具的绩效一样,只能在应用实践的上下文中评估实践的绩效。但是,在工具设计和质量方面可能会有很大差异,当根据工具的用途在使用时,这些差异决定了工具的潜力或有效性。有关测量标准和关键绩效指标(KPI)的进一步指南以及可以帮助您解决此问题的其他技术,请参见测量和报告实践指南。 | ||
| 385 | |||
| 386 | 风险管理实践的关键指标已映射到其实践成功因素中。它们可以用作价值流上下文中的KPI,以便评估实践对那些价值流的效果和效率的贡献。表2.4中给出了一些示例。 | ||
| 387 | |||
| 388 | |||
| 389 | 表2.4 实践成功因素的关键指标示例 | ||
| 390 | |||
| 391 | (% style="width:553px" %) | ||
| 392 | |(% style="width:146px" %)**实践成功因素**|(% style="width:405px" %)**关键指标** | ||
| 393 | |(% style="width:146px" %)建立风险管理的治理|(% style="width:405px" %)((( | ||
| 394 | * 自上次评审和更新风险偏好以来的时间 | ||
| 395 | * 明确记录了可能性、影响、所有者、处置计划和下一个行动日期的战略风险的百分比 | ||
| 396 | ))) | ||
| 397 | |(% style="width:146px" %)培育风险管理文化并识别风险|(% style="width:405px" %)((( | ||
| 398 | * 表示愿意在匿名调查中识别风险和错误的员工比例 | ||
| 399 | * 非指定风险管理角色的人员所识别的风险数量 | ||
| 400 | ))) | ||
| 401 | |(% style="width:146px" %)分析风险|(% style="width:405px" %)((( | ||
| 402 | * 在风险登记册上明确记录了可能性、影响和所有者的风险的百分比 | ||
| 403 | ))) | ||
| 404 | |(% style="width:146px" %)处置,监控和评审风险|(% style="width:405px" %)((( | ||
| 405 | * 在风险登记册上明确记录了处置计划和下一个行动日期的风险百分比 | ||
| 406 | * 风险登记册中最近六个月中已评审的风险百分比 | ||
| 407 | * 在最近六个月内通过控制评审和审计的控制的百分比 | ||
| 408 | ))) | ||
| 409 | |||
| 410 | 将简单指标合理整合到复杂指标中,将使数据更易于用于正在进行的价值流管理,以及用于风险管理实践的定期评估和持续改进。关于这点没有单一的最佳解决方案。指标将基于整体服务战略和组织的优先级,以及实践所支撑的价值流的目标。 | ||
| 411 | |||
| 412 | |||
| 413 | |||
| 414 | ---- | ||
| 415 | |||
| 416 | = **3 价值流和流程** = | ||
| 417 | |||
| 418 | |||
| 419 | |||
| 420 | |||
| 421 | |||
| 422 | == 3.1 价值流贡献 == | ||
| 423 | |||
| 424 | |||
| 425 | 像任何其他ITIL 管理实践一样,风险管理实践支撑多个价值流。重要的是要记住,价值流永远不会由单个实践形成。风险管理实践与其他实践相结合从而为消费者提供高质量服务。本实践为所有的价值链活动做出了重大贡献。 | ||
| 426 | |||
| 427 | 图3.1 中显示了风险管理实践对服务价值链的贡献。 | ||
| 428 | |||
| 429 | |||
| 430 | == 3.2 流程 == | ||
| 431 | |||
| 432 | |||
| 433 | 每个实践可能包含一个或多个流程和活动,它们对于实现该实践的目的可能是必需的。 | ||
| 434 | |||
| 435 | |((( | ||
| 436 | 流程 | ||
| 437 | |||
| 438 | 一组相互关联或相互作用的活动,可将输入转换为输出。流程接受一个或多个已定义的输入,并将其转换为已定义的输出。流程定义了活动的顺序及其依赖性。 | ||
| 439 | ))) | ||
| 440 | |||
| 441 | (% style="text-align:center" %) | ||
| 442 | [[image:1642584198311-223.png]] | ||
| 443 | |||
| 444 | **图3.1 风险管理实践对价值链活动的贡献热力图** | ||
| 445 | |||
| 446 | |||
| 447 | 风险管理活动构建了三个流程: | ||
| 448 | |||
| 449 | * 风险管理的治理 | ||
| 450 | * 风险的识别,分析和处置 | ||
| 451 | * 风险监控和评审 | ||
| 452 | |||
| 453 | === **3.2.1 风险管理的治理** === | ||
| 454 | |||
| 455 | 该流程包括表3.1中列出的活动,并将以下输入转换为输出。 | ||
| 456 | |||
| 457 | |||
| 458 | **表3.1 风险管理的治理流程的输入、活动和输出** | ||
| 459 | |||
| 460 | [[image:1642584384875-903.png]] | ||
| 461 | |||
| 462 | |||
| 463 | 图3.2 显示了流程的工作流图 | ||
| 464 | |||
| 465 | (% style="text-align:center" %) | ||
| 466 | [[image:1642584395108-576.png]] | ||
| 467 | |||
| 468 | **图3.2 风险管理的治理流程的工作流** | ||
| 469 | |||
| 470 | |||
| 471 | 成功的风险管理所需的许多治理活动都不特定用于风险管理实践。治理主体需要这些活动来对组织进行治理。 | ||
| 472 | |||
| 473 | |||
| 474 | **表3.2 风险管理的治理流程的活动** | ||
| 475 | |||
| 476 | [[image:1642584450731-804.png]] | ||
| 477 | |||
| 478 | [[image:1642584466717-342.png]] | ||
| 479 | |||
| 480 | |||
| 481 | |||
| 482 | === **3.2.2 风险的识别,分析和处置** === | ||
| 483 | |||
| 484 | 该流程包括表3.3 中列出的活动,并将输入转换为输出。 | ||
| 485 | |||
| 486 | |||
| 487 | **表3.3 标识,分析和处置流程的输入,活动和输出** | ||
| 488 | |||
| 489 | [[image:1642584492168-982.png]] | ||
| 490 | |||
| 491 | 图3.3 显示了流程的工作流图。 | ||
| 492 | |||
| 493 | (% style="text-align:center" %) | ||
| 494 | [[image:1642584503066-361.png]] | ||
| 495 | |||
| 496 | 图3.3 风险识别,分析和处置流程的工作流 | ||
| 497 | |||
| 498 | |||
| 499 | 这些活动可以由组织中的许多人以不同的形式级别来执行。如表3.4 所示: | ||
| 500 | |||
| 501 | |||
| 502 | **表3.4 风险识别、分析和处置流程的活动** | ||
| 503 | |||
| 504 | [[image:1642584543542-498.png]] | ||
| 505 | |||
| 506 | [[image:1642584594216-230.png]] | ||
| 507 | |||
| 508 | [[image:1642584607526-755.png]] | ||
| 509 | |||
| 510 | |||
| 511 | |||
| 512 | === **3.2.3 风险监控和评审** === | ||
| 513 | |||
| 514 | 该流程包括表3.5 中列出的活动,并将以下输入转换为输出。 | ||
| 515 | |||
| 516 | |||
| 517 | **表3.5 风险监控和评审流程的输入、活动和输出** | ||
| 518 | |||
| 519 | [[image:1642584631769-602.png]] | ||
| 520 | |||
| 521 | |||
| 522 | 图3.4 显示了风险监控和评审流程的工作流图 | ||
| 523 | |||
| 524 | (% style="text-align:center" %) | ||
| 525 | [[image:1642584640794-437.png]] | ||
| 526 | |||
| 527 | **图3.4 风险监控和评审流程的工作流** | ||
| 528 | |||
| 529 | |||
| 530 | **表3.6 风险监控和评审流程的活动** | ||
| 531 | |||
| 532 | [[image:1642584673251-422.png]] | ||
| 533 | |||
| 534 | |||
| 535 | |||
| 536 | ---- | ||
| 537 | |||
| 538 | = 4 组织和人员 = | ||
| 539 | |||
| 540 | |||
| 541 | |||
| 542 | == 4.1 角色,能力和责任 == | ||
| 543 | |||
| 544 | |||
| 545 | 实践指南没有描述实践管理的角色,例如实践所有者,实践领导者或实践教练。而是专注于每个实践特定的专业角色。每个角色的结构和命名在不同组织间各不相同,因此ITIL中定义的任何角色都不应被视为强制性的,甚至不能作为建议使用。 | ||
| 546 | |||
| 547 | 请记住,角色不是职务。一个人可以担任多个角色,一个角色也可以分配给多个人。 | ||
| 548 | |||
| 549 | 角色在流程和活动情形中描述。每个角色都具有基于表4.1中的模型所建立的能力类型。 | ||
| 550 | |||
| 551 | |||
| 552 | **表4.1 能力代码和概况** | ||
| 553 | |||
| 554 | (% style="width:575px" %) | ||
| 555 | |(% style="width:91px" %)**能力编码**|(% style="width:482px" %)**能力类型(活动和技能)** | ||
| 556 | |(% style="width:91px" %)**L**|(% style="width:482px" %)领导 Leader,决策、授权、监督其他活动,提供激励和动力,并评估结果 | ||
| 557 | |(% style="width:91px" %)**A**|(% style="width:482px" %)管理员 Administrator,分配任务并确定优先级,保存记录,持续报告,并启动基本改进 | ||
| 558 | |(% style="width:91px" %)**C**|(% style="width:482px" %)协调者/沟通者 Coordnator/Communicator,协调多方,维持利益相关者之间的沟通,并开展宣传活动 | ||
| 559 | |(% style="width:91px" %)**M**|(% style="width:482px" %)方法和技巧专家 Methods and techniques expert,设计和实施工作技巧,记录步骤,流程咨询、工作分析和持续改进 | ||
| 560 | |(% style="width:91px" %)**T**|(% style="width:482px" %)技术专家 Technical expert,提供技术(IT)专业知识并执行基于专家经验的作业 | ||
| 561 | |||
| 562 | 下表4.2 中列出了风险管理涉及的角色示例。 | ||
| 563 | |||
| 564 | |||
| 565 | **表4.2 负责风险管理活动的角色示例** | ||
| 566 | |||
| 567 | [[image:1642584956469-967.png]] | ||
| 568 | |||
| 569 | [[image:1642584973390-620.png]] | ||
| 570 | |||
| 571 | |||
| 572 | |||
| 573 | == 4.1 组织结构和团队 == | ||
| 574 | |||
| 575 | |||
| 576 | 风险管理实践是众多的实践之一,它为服务提供者实现价值共创所做的一切提供支撑。因此,此实践是每个人在其控制范围中应承担的责任。 | ||
| 577 | |||
| 578 | 在商业企业中,董事会(或另一个顶层治理主体)最终要负责为组织的利益相关者实施一个充足且令人满意的风险管理框架。这个风险管理框架的持续开发工作通常委派给一个或多个风险管理委员会,并在董事会监督之下进行。 | ||
| 579 | |||
| 580 | 风险管理委员会建立的风险管理框架定义了风险分析方法,范围和对象。角色描述(例如识别和监控)可以包含在框架中。根据有组织的设计风险管理活动的需要,甚至可以包含运维条线的员工。治理主体的主要目标是确保服务提供者组织中的所有管理层级都在其控制范围内实施风险管理框架。 | ||
| 581 | |||
| 582 | |||
| 583 | |||
| 584 | ---- | ||
| 585 | |||
| 586 | = 5 信息和技术 = | ||
| 587 | |||
| 588 | |||
| 589 | |||
| 590 | |||
| 591 | |||
| 592 | == 5.1 信息交换,输入/输出 == | ||
| 593 | |||
| 594 | 风险管理实践的效果基于所用信息的质量。该信息包括但不限于以下信息: | ||
| 595 | |||
| 596 | 1. 风险所有者拥有的风险 | ||
| 597 | 1. 提出一个新的风险记录 | ||
| 598 | 1. 一个易于识别和客观化的风险重要性 | ||
| 599 | 1. 预测并适当分配的任务 | ||
| 600 | |||
| 601 | 信息可以采用各种形式。本实践的关键输入和输出在第3节中列出。 | ||
| 602 | |||
| 603 | |||
| 604 | == 5.2 自动化和工具 == | ||
| 605 | |||
| 606 | |||
| 607 | 在大多数情况下,风险管理实践可以从自动化中受益显著(有关何时适用的详细信息,请参阅本指南的价值流和流程部分)。可行且有效的解决方案可能包括表5.1中所列。 | ||
| 608 | |||
| 609 | |||
| 610 | **表5.1 风险管理活动的自动化解决方案** | ||
| 611 | |||
| 612 | [[image:1642585074201-892.png]] | ||
| 613 | |||
| 614 | [[image:1642585123347-542.png]] | ||
| 615 | |||
| 616 | |||
| 617 | |||
| 618 | ---- | ||
| 619 | |||
| 620 | = | ||
| 621 | 6 合作伙伴和供应商 = | ||
| 622 | |||
| 623 | |||
| 624 | 组织内仅有很少的服务使用自己的资源来交付。大多数服务(如果不是全部)依赖于其他服务,这些服务通常由组织之外的第三方提供(服务关系模型请参阅//ITIL Foundation: ITIL 第4 版//的2.4章节)。由支持服务引入的关系和依赖性在供应商管理和服务级别管理的ITIL实践中描述。 | ||
| 625 | |||
| 626 | 服务提供者的合作伙伴和供应商可能会为现有服务提供和变更配置生成和减轻新的风险。当引入新合作伙伴和供应商时,服务提供者需要关注后者。 | ||
| 627 | |||
| 628 | 各方的风险管理框架必须相互保持一致,并在各个风险所有者之间建立适当的沟通渠道,这也是至关重要的。例如,供应商管理的基础设施部分的失效应触发针对服务提供者的风险降低的响应。服务模型中必须内置和供应商一起的风险识别和适当的信号提醒,并定期进行测试。 | ||
| 629 | |||
| 630 | 尽管实际的风险降低措施活动很可能包括在其他实践的流程中,但是风险管理实践保证了各相关方之间的风险管理框架一致性。实践还确保了各方在风险的识别和分析上投入适当的精力。 | ||
| 631 | |||
| 632 | 在组织旨在确保快速有效的风险管理实践的情况下,他们通常会尝试在与其合作伙伴和供应商紧密合作上达成一致,并消除沟通、协作和决策方面的正式的官僚式的障碍。此类关系中的所有各方都应力求将可能影响其他各方的变更共同加以透明化和可视化(有关更多信息参见供应商管理实践指南)。 | ||
| 633 | |||
| 634 | |||
| 635 | |||
| 636 | ---- | ||
| 637 | |||
| 638 | = 7 重要提醒 = | ||
| 639 | |||
| 640 | |||
| 641 | 实践指南的大部分内容都应作为组织在建立和培养自己的实践时可能考虑的领域的建议。实践指南是组织可能考虑事情的目录,而不是答案列表。使用ITIL 实践指南的内容时,组织应始终遵循ITIL 指导原则: | ||
| 642 | |||
| 643 | * 聚焦价值 | ||
| 644 | * 从你所处的地方开始 | ||
| 645 | * 基于反馈迭代推进 | ||
| 646 | * 协作和提升可视化程度 | ||
| 647 | * 从整体上思考和工作 | ||
| 648 | * 保持简单实用 | ||
| 649 | * 优化和自动化 | ||
| 650 | |||
| 651 | 有关指导原则及其应用的更多信息,请参见//ITIL®Foundation:ITIL 第4版印刷版 //的第4.3节//。// | ||
| 652 | |||
| 653 | |||
| 654 | |||
| 655 | ---- | ||
| 656 | |||
| 657 | |||
| 658 | = **8 致谢 ** = | ||
| 659 | |||
| 660 | |||
| 661 | AXELOS 公司非常感谢为本指南的开发做出贡献的每一个人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员 : | ||
| 662 | |||
| 663 | |||
| 664 | |||
| 665 | |||
| 666 | == 8.1 作者 == | ||
| 667 | |||
| 668 | |||
| 669 | 斯图尔特·兰斯(Stuart Rance),康斯坦丁·纳里兹尼(Konstantin Naryzhny) | ||
| 670 | |||
| 671 | |||
| 672 | |||
| 673 | |||
| 674 | == 8.1 审稿人 == | ||
| 675 | |||
| 676 | |||
| 677 | 罗曼·朱拉夫列夫(Roman Jouravlev) |