|
ITIL 4变更支持实践的目的 为了使组织在当今的数字世界中蓬勃发展，向客户交付令人兴奋的新产品和服务并迅速交付的能力至关重要。 也就是说，我们在交付这些产品和服务时必须确保的一件事就是在进行变更时，我们要非常清楚有把握的同时（并保护自己）。 ITIL 4中的变更支持实践提供了许多有关如何进行频繁变更的建议和想法，同时减少了我们将真正重要的事情付诸实践的机会。 这就像在汽车上休息一下； 我们不会一直需要休息，但是在需要时它们很关键。 首先，让我们首先看看"变更"的含义。 这是新的ITIL 4实践的定义（括号内添加了我自己的注释）： 变更：添加，修改或删除可能对技术支持的产品和服务产生直接或间接影响的任何内容 在我们经常联系紧密的组织中进行变更时，我们有可能影响其他团队，服务，应用程序，客户等。在这里，变革支持实践可以为您提供帮助。 变更支持的目的：通过确保正确评估风险，授权变更和管理变更计划，最大程度地增加成功的产品和服务变更的次数 现在，让我们深入了解这种新的ITIL 4实践的细节。 变更支持实践的三个前提 归根结底，我们管理变更的方式需要使我们的组织受益，最终使我们的客户受益。 我们不应该引入粉碎的官僚机构或强迫团队等待批准，从而减慢组织的发展速度。 此外，我们只需要关注那些直接影响向客户提供产品和服务的变更。 我们的客户需要告诉我们变化应该多快发生； 而且我们不必设立传统的变更咨询委员会（CAB）来一起讨论我们所有的变更。 变更可以并且应该由分散的团队进行审查，以便可以继续安全快速地完成工作。 下一节将对此进行更多介绍。 这是新ITIL 4实践中详细介绍的三个前提（强调和注释已添加）： · 在价值流的上下文中计划和实现更改（在此处熟悉价值流）。 变更支持已集成到价值流中，并确保变更有效，安全且及时，以满足利益相关者的期望。 · 变更支持并非旨在将一个组织中计划和执行的所有变更统一为一个整体，即一个数字环境，其中可能同时发生数百个变更。 这既不可能也不是必需的。 · 变更启用应重点关注已定义范围内所有变更的有效性，吞吐量，合规性和风险控制之间的平衡。 变更支持的表现 以下是国外的一个高级顾问Mark Hillyard提出的一些简短示例，内容涉及变更支持如何转换和增强变更管理流程。如果我们考虑将行业转移到IT领域中的高速发展（从而实现更高的速度变化），那么变更支持实践提出的想法与软件开发团队的工作方式保持一致。 以一个功能全面的DevOps环境为例，该环境已经包含了持续集成/持续部署（CI / CD）。此模型消除了将代码发布到生产环境中涉及的几乎100％的人为交互。在ITIL v3的变更管理流程中，这几乎是不可能适应的。 CAB将需要几乎连续地开会，以审查，授权和安排每个变更。这个想法很疯狂。相反，通过创建量身定制的变更权限，每个自治开发团队都可以建立自己的授权方法。如果部署确实是连续的（每天多次），则描述即将发布的版本的日常维护工作可以用作授权和计划的基准。团队负责人将担任变更授权，每个版本中包含的用户案例（以及他们的接受标准）将作为文档，以满足运营团队对透明度和知识共享的需求。 这种改进实践的不太极端的例子可能包括敏捷的开发团队，该团队的变更频率稳定（每两周发布一次）。这似乎是一个很容易融入CAB模型的系统，但是由于变更支持的目标是确保更大数量的成功变更，使开发团队陷入CAB会议的沉闷状态可能会影响整个项目，并实际上减慢了发展速度（如果不是变化的频率）。这不能很好地为我们的客户服务，迫使他们等待批准，而不是按时交付。此外，最适合提供有意义的风险评估的人员可能是开发人员自己。因此，在开发团队中创建可以快速分析和安排每个变更的变更授权将是有意义的。在这里，部署之前的冲刺审核将为评估和授权提供良好的背景。 如您所见，变更支持有可能在您的组织内创造显着的效率。 变更支持实践中弱化的内容– CAB CAB的想法在变更支持实践中没有得到强调。 实际上，它对CAB所做的陈述如下： 变更需要资源，并且会带来风险。 有时这会导致组织建立复杂的，通常是官僚的变更授权系统，而正式的委员会会定期开会，以概述和授权在此期间累积的变更。 这些被称为变更顾问委员会（CAB）。 CAB经常成为组织价值流的瓶颈。 它们会引入延迟并限制变更支持的吞吐量。 没那么讨人喜欢。 在大多数情况下，CAB的想法已被具有某种"变更权限"的想法所取代。 这似乎是一个很小的变化，但实际上是一个很大的转变。 组织正在摆脱强迫员工填写2485条信息，等待每周一次CAB会议，然后必须捍卫自己的变更才能实现这一想法的想法（难怪每个人都讨厌提交变更）。 CAB的概念已被同行评审，自动化测试和授权以及每天的站台式会议批准，以批准团队级别的变更。 现在，授权变更的人员称为变更权限。 变更授权：负责授权变更的个人或团体。 该定义为变更的授权方式和授权人敞开了大门。 此外，实践建议将变更分解成较小的部分，以从一开始就减少风险。 因此，变更可以按照客户需要的速度进行，而不是相反（客户正在等待CAB批准变更）。 实践中还提到： 在以产品为中心的组织中，变更支持通常不采用职位和职务，因为这种做法已集成到产品开发团队的日常活动中，并在可能的情况下自动进行。 变更支持实践的其他出色补充 这是我真正喜欢的新ITIL 4实践中提到的一些其他想法，这些想法在处理变更管理方式时会有所帮助： · 尽可能进行失败测试，自动化和同行评审 · 缩小变更范围，从而降低引入环境的风险 · 以用户故事格式编写变更请求 · 使用"积压管理工具"来捕获，确定优先级和管理变更以及对实践本身的改进（有关此方面的更多详细信息，请参阅下面的部分） · 使用看板来捕获和计划变更，使工作可见。 我还喜欢这种做法，其中包括用于处理不同类型的变更（当处理自动软件更改等时）的简单工作流示例，以及有关定义"实践成功因素"或PSF的想法。 实践成功因素（PSF）–实践必须具备的复杂功能组成部分，才能实现其目标。 增加了变更优化重点 最后，我喜欢有一个名为"变更优化"的部分，讨论了如何重点关注"变更支持实践，变更模型和标准变更程序的持续改进"，这是我们一直在建议的内容。顾客一直做。我强烈建议您经常查看您的变更实践，并接续改进，看看您的变更如何顺利进行，并始终在寻找使它更好的方法。 需要注意的是，管理和变更支持的方式应取决于对团队最有效的选择，变更的类型（风险或背后的复杂性等），以及最终对客户最有效的选择。和整体组织。它不应基于ITIL书籍中所说的内容或在其他组织中所做的事情。实际上，在ITIL实践文档的末尾是免责声明，"……实践指南是组织可能考虑的事情的目录，而不是答案的列表。"与其对自己说："这就是ITIL书中所说的，所以让我们完全按照此工作流中记录的方式做事，"我们每个人都应该问自己："我们的组织应该如何工作？ "这对我们有意义吗？有没有更好的办法？" 从ITIL v3到ITIL 4的名称更改 如果您在2019年2月之前接受了ITIL培训，则该过程称为变更管理。 这是大多数人仍然使用的语言。 但是，围绕与IT相关的变更管理和组织变更管理之间的差异存在混淆。 当ITIL 4在2019年2月发布时，其名称从变更管理流程更改为变更控制实践（此处将术语从"流程"更改为"实践"）。 ITIL 4中的名称更改 如果您在2019年2月至2019年8月之间的某个时间参加了ITIL 4基础课程，您将学到术语``变更控制''。 然而当在全球范围内测试ITIL 4术语时，"变更控制"一词给大家带来了很多的困惑。 这个名称在许多组织中并没有引起共鸣，特别是那些采用了更快工作方式的组织，例如敏捷和DevOps，并且认为变更控制有可能使组织变慢。 因此，该名称已更改为"变更支持"，以更准确地反映该实践的真实意图。 进行有效的变更支持实践实际上可以帮助组织加快完成工作的速度，并且仍然可以保护我们免受停机和变更造成的问题的影响。 |
|
|
