IT变更管理多年来一直是争论的重要来源。我可以说,变革管理是我职业生涯中最不舒服、最紧张、最恼火的时刻的头号来源。一方面,我们有IT服务管理(ITSM)思想,它主要关注定义良好的手动过程,以及记录系统中捕获的过程控制、策略和审计跟踪,用于证明对治理任务的遵从性。另一方面,我们已经看到了敏捷思维的影响,其中变更管理被嵌入到数字服务管道中,使用自动化来提高变更的速度和敏捷性。

大多数人会同意ITSM思想需要进化(在ITIL 4中很明显),以关注价值流和敏捷性。但是,许多组织都在努力发展现有的管理实践,以支持新采用的指导,如敏捷、DevOps和站点可靠性工程。

组织和人员需要愿意放弃(如果不是完全,那么至少减少他们的控制)关于变更管理的三个重要神话,以成功地实现这种转变。让我们逐一探讨一下。

误解一:更多的治理可以降低风险

治理模型是僵硬的,是门口的狗叫,吓唬每个人遵守。这些模型过度依赖于策略,并且不容易适应于支持自动化的使用,而现代产品团队需要增加发布频率。组织使用治理作为保护,以确保变更不会为业务带来计划外的风险或停机时间。审计人员和治理模型还停留在过去,不知道如何使用现代自动化方法。

治理团队需要认识到,变更管理的现代方法可以比当前的限制性政策更有效、更快地控制和减少与变更相关的风险。人们普遍不愿放弃长达169页的变更政策文档,以换取适当的自动化水平。我们之所以走到这一步,是因为每次我们的策略让我们失望时,我们决定添加更多的层、更多的门和更多的规则,以确保不再发生停机。相反,我们有一个单一的策略,既不服务于业务,也不支持敏捷性和转换。

误解二:定义良好的过程可以降低风险

大多数ITSM平台和变更管理流程都是基于20世纪90年代最初的ITIL发布的工作流程。虽然系统已经发展,但ITIL的主要功能是管理工作的主要方式。一个典型的变更管理过程充满了门:

  • 首先,根据变更的类型在系统中创建一个票据,分类并确定优先级[延迟)。
  • 接下来,使用所有关键和必需的信息完成记录延迟)。
  • 然后,用一组给定的问题来评估风险延迟)。
  • 附加所有相关文档(测试计划,退出计划等)延迟)。
  • 将更改发送给批准延迟)。

每个门的设计确保了工作的完成,有助于避免停机时间,最大限度地减少变更冲突,减少安全风险,并为审核员提供详细的书面记录——但它是否完全降低了风险?不是真的。策略的复杂性和固有的延迟给企业带来了额外的风险。

有人可能会说,你的流程门越复杂,你就越不可能管理风险。为什么?这是因为我们依赖人类在不共享信息或一起工作的团队中完成所有这些工作。我们没有管理风险,而是扼杀了变更,在防止中断或确保遵从性任务得到遵守和记录方面效果有限。为了转向更敏捷的工作方式,我们必须放松过度设计的过程,取而代之的是更多的自动化,在适当的地方,以最小化风险。

误解三:变更咨询委员会(CAB)可以降低风险

如果你从未参加过CAB会议,那你就算幸运了。整个组织的代表聚集在一起检查变更列表。允许每个团队成员检查变更,提出问题,并对记录的方法提出质疑。几个小时过去了,每个提议的变更都被评估,每个不成功的变更被剖析。为了使更改更敏捷地支持开发人员,这可能是一个每天的过程。它是累人的。但它能降低风险吗?

CAB的问题在于,在当今复杂的基础设施中,很难使用这种类型的权限结构。它是为问责制而设计的,以便跨团队和平台对基础设施具有可见性,从而充分理解和管理与特定变更相关的风险。如果您的组织将每个变更都发送给CAB,那么它可能会增加风险,而不是降低风险。CAB是检查更复杂变化的优秀工具。自动化应该用于标准更改和支持开发人员发布的版本。通过将基础设施作为代码、自动化测试和变更风险评分,组织可以支持开发人员的敏捷实践,并比通过CAB发送所有内容更有效地管理风险。

是改变拖了你的后腿

我个人曾听一位变更经理告诉我,由于治理团队和审计人员的存在,他们无法实现变更管理过程的现代化——他们的服务和支持基础设施对于组织来说太复杂了,无法继续依靠人力来控制变更以降低风险。但是,阻碍现代化的不仅仅是治理、流程或CAB。也是我们的人民抗拒新的思维方式。仅仅因为我们总是通过流程和政策来管理变更,并不意味着它是可扩展的或满足现代、有弹性的组织的需求。是时候放弃神话,拥抱新的思维和工作方式了。

要了解更多关于克服变革管理挑战的内容,请阅读我的报告,克服变革管理瘫痪

让我们联系

有问题吗?这太棒了。让我们联系并继续对话!请通过社交媒体联系我,或者r请求一次指导会议关注我的博客和研究Forrester.com