在最近的一篇文章中，我们介绍了以下主题 减轻风险是IT变革管理中的一门学科.我们建议应用三方面的因素来评估风险。风险管理 概率 的情况下，可能出现的问题 影响 的问题，以及该问题的难易程度。 恢复 如果出现问题，请联系我们。
除了这些维度之外，风险管理部门还可以根据三个不同的范围级别来看待拟议的变化。
- 的相关风险。 标准变化，正如DevOps所称--一种常规的、预期的变化，理想情况下是自动化的，因为整体风险很低。
- 在连续体的另一端。 对企业声誉构成危害的重大的、未预期的风险譬如，一个数据中心瘫痪了，或者一个面向客户的关键应用程序失败了，或者被发现有一个关键的错误。对于这些风险，组织开发了多种冗余、模拟、桌面演习和其他复杂的风险管理和IT连续性程序。
- 中级风险 - 相关的风险 日常业务变化 不会使房子倒塌，但不能自动消除，因为它们是一次性的、修复错误的或复杂的，足以造成严重的麻烦、中断、延长停机时间和用户/客户的挫败感--这些变化可能会造成新的事件。
这个中间类别的风险经常被忽视或不被积极管理，因为它们不被看作是关键任务，也因为没有明显的方法通过自动化来消除它们。IT组织经常不能减轻这些中级风险--即使是那些在管理更关键的风险方面相对有效的组织。
这些中间风险在变革经理或CAB每天处理的事情中占了很大比例。事实上，变革管理者通常把可以自动化的标准变革和可能威胁到业务的关键任务风险视为例外情况。中间层次的变化--也就是CAB处理的其他一切--被认为是组织首先采用变化管理的原因。风险隐藏在众目睽睽之下。这并不是说CAB对这些风险感到自满，而是团队太忙于计划和实施变革，以至于实际评估和管理风险的需要常常被忽视。
这代表了一个重大的改进机会，以避免未来的事件。
改进包括在中间层面评估这些与三个维度有关的变化，并通过明确的问题陈述和根本原因使实际的风险可见，作为在原因和结果层面确定和选择缓解行动的基础。最后，分析结果被转化为一个明确拥有的行动计划。
我们可以进一步加强这种 "实践"，作为我们持续服务改进努力的一部分，将我们所谓的 "超越修复的思考 "应用到我们的问题管理工作中，通过扩展我们的RCA来寻找我们的修复可以应用到的其他领域，但也要关注我们的修复所带来的风险，因为修复只不过是另一种变化。
我们的一个金融服务客户最近估计，这种纪律使他们能够防止超过10,000个问题的发生。
底线：减轻风险不是一门艺术，它首先是一门操作学科。
KT为IT组织提供了为期一天的风险缓解研讨会，为在企业中建立基本的风险缓解提供了有用的基本纪律。
