变更管理一直是一个热门话题在社会媒体和客户调查。作为一个过程象征传统的IT服务管理和ITIL框架,它面临越来越大的压力反应敏捷和现代化DevOps的趋势。然而,变更管理出现是有原因的,我认为这是谨慎地看看,最好的,这种做法实际上,为什么那么多公司用这么久的原因。

这是我最近更新的主题研究,“克服变更管理瘫痪”。在这个报告中,我盖的原因改变的过程。合法的目标——协调,减少风险、审计跟踪不消失,因为敏捷或DevOps。现在的问题是,如何现代化、客户导向的数字组织实现这些目标?经典的“发出请求,并在每周两次的改变顾问委员会”一个方式来达到想要的结果,可能不是最有效的手段,因为我讨论。

我不相信变更管理会消失。我最近现代技术操作的状态研究表明,有效的变更管理是强烈与优越的可用性的结果——在报告中一些最强大的统计相关性。

但这种做法确实需要修改。组织仍然误用沉重的变更管理实践低风险的变化。在我们的研究中仍是重要的一部分所有改变改变顾问委员会(出租车),不管风险。在我们的研究结果,指所有以任何方式改变出租车是不相关的有更好的可用性、业务的结果,或改变失败率。(加速研究发现,在驾驶室与所有更改更糟糕的是软件交付性能。)

手动更改的文档;冗长的变更批准延误;大,两周一次的面对面的出租车;和审查所有更改,不管风险,不再是必要的或适合现代变化练习。组织追求敏捷和DevOps议程已经改变他们的方法。变化过程是越来越自动化;在某些情况下,发布自动化工具autocreate和更新改变门票通过api。当然固有的健壮的审计跟踪现代持续交付工具链使变更管理更严格的初衷比手动过程。采用产品团队的组织模型(与敏捷转换)不太可能看到一辆出租车是必要的。此外,我们发现,组织采取行动,简化他们的变化过程更有可能报告业务性能优越。

然而,变化过程本身保留的支持。组织进行敏捷转型的时期更有可能认为他们的变化过程是有效的风险识别。他们强烈的可能(p ~ = 0)认为他们的变化过程是必要的协调。

我们让这些有些矛盾的发现呢?最终,变更管理转变,变得更加透明和集成到整个软件交付管道,但其问题永远不会消失。一些我们的建议:

    • 质疑你的出租车。Forrester越来越听证会的组织减少或消除顾问委员会,但仍保持改变的过程。
    • 跟踪正确的变化指标。改变失败率一直是流行指标,与一些组织寻求零故障。孤立的,这可能是破坏性的(我们更进一步的原因在报告中)。
    • 转向现代的分析。自动化技术管道具有丰富数据请求进行分析。持续交付和发布自动化(其中供应商CloudBees等数字。ai, IBM Urbancode创新的标签下“发布准备。”企业服务管理(ESM)供应商如微焦点和ServiceNow正越来越多地应用先进的机器学习改变的风险评估。Evolven是一位著名的专家领域的供应商变化分析。最终,Forrester预测其中释放的融合与ESM准备变更管理(见下图)。

注意:人可能指向加速DevOps研究/状态为“证伪”的变更管理过程,但是这是不准确的。研究侧重于审批是否集中或分散,而不是改变过程是否应该存在。事实上,加速工作隐式地支持一个变化的过程,作为他们的一个基本性能标准是“失败的变化。“如果你是指标的跟踪,在我看来,你有一个变化过程。(见78 - 81页的书加速:构建和扩展高性能技术组织妮可Forsgren et al。博士,进入深度超出了DevOps的状态报告。)

本研究的范围与之关联的操作变更管理实践和数字组织,特别是在控制方面的技术资源。组织变更管理是一个不同的主题不是在这里解决。