Practice_Change enablement 变更支持管理实践
本帖最后由 FYIRH 于 2022-8-10 17:40 编辑返回 ITIL 4理论与实践整体知识体系中文版发布文件汇总
最新消息：本实践最终中文翻译版已经发布，请点击 http://ITIL-foundation.cn/thread-140693-1-1.html 下载。
需要下载最新翻译版本请关注微信公众号：ITILXF，并回复“变更支持管理”即可。
关键信息
变更支持管理实践的目的是通过确保已正确评估风险，授权进行更改以及管理变更排程，来最大限度地增加成功的服务和生产更改的次数。
变更支持管理实践旨在确保对服务及其组件的更改进行控制，并确保它们符合组织与变更相关的需求。授权的更改应能实现预期的结果，并满足组织关于变更，吞吐量（更改的数量和变更实现的速度）和风险管理的要求。实践充满了灵活性和敏捷性，因为它们是现代组织的关键方面。
变更支持管理实践包含三个前提：
● 在价值流的背景中计划并实现了更改。实践集成到价值流中，并确保更改有效，安全且及时，以满足利益相关者的期望。
● 实践并非旨在将组织中计划和执行的所有更改统一为一个整体：在数字化环境中，可能同时发生数百个更改，这既不可能也不是必需的。
● 对于定义的范围中的所有更改，实践应该集中精力平衡效果，吞吐量，合规性和风险控制。
2.2 术语和概念
变更
添加，修改或删除可能对服务产生直接或间接影响的任何事物。
变更支持管理实践确保每个变更都能达到预期的结果。这与指导性原则'聚焦价值'保持一致。与变更的技术细节相比，利益相关者对变更启用的价值更感兴趣。以技术精度实施的更改却未能实现预期的结果，未达到预期的目标。此外，更改可能会产生意想不到的结果，包括对用户的负面影响，服务停机时间，降级和不稳定。对于控制这些结果很重要。
使用各种方法和方法来完成更改，每种方法和方法都代表不同级别的业务风险。软件更改通常是通过频繁且定期地对部署进行新功能和修改来进行的。这些更改可以通过持续集成/ 持续交付（CI / CD）交付，如DevOps和其他形式的实践中所述。
迭代/敏捷交付（有关CI / CD的更多信息，请参见ITIL专家：创建，交付和支持）。物理基础架构的变化可能较慢，需要分阶段的“瀑布式”方法。可以使用相关的项目管理技术和控件将这种类型的某些更改作为项目运行。
但是，在实践中，很少有组织完全处于另一个极端。组织具有多个价值流，其中大多数包含更改。变更支持管理实践必须是自适应的，才能满足变更开发各种方法的需求。
2.2.1 基于复杂性的变更方法
变更支持管理实践应该确保变更效果，变更吞吐量和风险控制之间保持平衡。这意味着需要仔细选择变更，规划授权和进行中的控制的方法。
从日常业务到灾难性的所有业务情况都可能发生变化（请参阅图片2.1）。组织应该能够在此范围内的任何情况下进行更改。
图片2.1在所有业务情况下都需要进行更改
业务正常情况相对可预测，不确定性较低。灾难性情况的不确定性最高。但是，任何情况下的变化都具有不同程度的复杂性和可预测性。
在不确定性较低的情况下，可以对变更进行标准化和自动化，这有助于降低成本并加速变更。在这些情况下，可以使用清单，模板和标准化的工作方式。这反映在标准变更的定义中。
标准变更
风险低版本，预先授权的更改，已被很好地理解和完整记录，无需额外授权即可实施。
标准更改的示例包括：
● 服务请求的实现
● 基础架构的维护
● 例行公事应急措施测试
● 例行公事软件更新。
About thisdocument
This document providespractical guidancefor the change enablement practice. It is split into five main sections, covering:
● general information about the practice
● the practice’s processes and activities and theirroles in the service value chain
● the organizations and people involved in the practice
● the information and technology supporting the practice
● considerationsfor partners and suppliers for the practice.
1.1 ITIL® 4 QUALIFICATION SCHEME
Selectedcontent of this document is examinable as a part of the following syllabus:
● ITIL Specialist:Create, deliver and support
● ITIL Specialist:High Velocity IT
Please refer tothe syllabus documents for details.
Generalinformation2.1PURPOSE ANDDESCRIPTION
Key message
The purpose of the change enablement practice is tomaximize the number of successful service and product changes by ensuringthat risks have been properly assessed, authorizing changes to proceed, andmanaging the change schedule.
The change enablement practice aims to ensure that changes toservices and their components are controlled and that they meet theorganization’s change-related needs. Authorized changes should enable thedesired outcomes and meet the organization’s requirements regarding changethroughput (the number of changes made and the speed of change realization) andrisk management. Flexibility and agility permeate this practice because theyare key aspects of a modern organization.
The changeenablement practice incorporates three premises:
● Changesare planned and realized in the context of value streams. The practice isintegrated into value streams and ensures that changes are effective, safe, andtimely in order to meet stakeholders’ expectations.
● The practicedoes not aim to unify all the changes planned and carried out in an organizationinto one big picture: in a digital environment, where hundreds of changes maybe happening simultaneously, this is neither possible nor required.
●Thepractice should focus onbalancing effectiveness, throughput, compliance, and riskcontrol for all changes in the definedscope.
2.2TERMS AND CONCEPTS
Change
The addition, modification, or removal ofanything that couldhave a direct or indirect effect on services.
The change enablement practice ensures that every change achievesthe intended outcomes. This aligns with the guiding principle ‘focus on value’.Stakeholders are more interested in the value that a change enables than in thetechnical details of the change. Changes that are implemented with technicalprecision, but which fail to enable the desired outcomes, fall short ofexpectations. Additionally, changes may have unintended outcomes, including negativeimpacts on users, service downtime, degradation, and destabilization. It isimportant to control these outcomes.
Changes are accomplished using various approaches and methodologies,each of which represents a different level of business risk. Changes insoftware are often made through frequent and regular deployment of new featuresand modifications. These changes can be delivered throughcontinuousintegration/continuous delivery (CI/CD),as practised in DevOps and other forms of iterative/Agile delivery (for more information on CI/CD, see ITILSpecialist: Create, Deliver and Support). Changes in physical infrastructuremay be slower, requiring a staged, ‘waterfall’ approach. Some changes of thistype may be run as projects, using relevant project management techniques andcontrols.
In practice, however, feworganizations are fully at one extreme or the other. Organizations havemultiple value streams, most of which include changes. The change enablementpractice must be adaptive to meet the needs of various approaches to changedevelopment.
2.2.1 Complexity-basedapproach to changes
The change enablement practice should ensure a balance betweenchange effectiveness, change throughput, and risk control. This means that the approachesto change planning authorization and ongoing control need to be selectedcarefully.
Changes are possible in all business situations, from business asusual to catastrophic (see Figure 2.1). Organizations should be able to makechanges in any situation on this spectrum.
Figure 2.1 Changes are needed in all businesssituations
Business-as-usual situations are relatively predictable, with lowlevels of uncertainty. Catastrophic situations have the highest levels ofuncertainty. Changes in any type of situation, however, have varying levels ofcomplexity and predictability.
Changes can be standardizedand automated where uncertainty is low, which helps to decrease the costs andaccelerate the changes. Check-lists, templates, and standardized ways ofworking can be used in these situations. This is reflected in the definition ofa standard change.
Standardchange
A low-risk, pre-authorized changethat is well understood and fullydocumented, and which canbe implemented without needing additional authorization.
Examples ofstandard changes include:
● fulfilment of aservice request
● maintenance of infrastructure
● routine testingof contingency measures
● routine software updates.
谢谢分享~~ 标准更改的示例包括：
● 服务请求的实现
● 基础架构的维护
● 例行公事应急措施测试
● 例行公事软件更新。
Practice_Change enablement 变更使能实践中文版【初译】
页:
[1]