领域：学术论文 · 自然科学

5.2.4   Change control
The scope of change control is defined by each organization. It will typically include all IT infrastructure, applications, documentation, processes, supplier relationships, and anything else that might directly or indirectly impact a product or service.
It is important to distinguish change control from organizational change management. Organizational change management manages the people aspects of   changes to ensure that improvements and organizational transformation initiatives are implemented successfully. Change control is usually focused on changes in products and services.
Change control must balance the need to make beneficial changes that will deliver additional value with the need to protect customers and users from the adverse effect of changes. All changes should be assessed by people who are able to understand the risks and the expected benefits; the changes must then be    authorized before they are deployed. This assessment, however, should not introduce unnecessary delay.
The person or group who authorizes a change is known as a change authority. It is essential that the correct change authority is assigned to each type of change to ensure that change control is both efficient and effective. In high-velocity organizations, it is a common practice to decentralize change approval, making the peer review a top predictor of high performance.
There are three types of change that are each managed in different ways:
•Standard changes These are low-risk, pre-authorized changes that are well understood and fully documented, and can be implemented without needing additional authorization. They are often initiated as service requests, but may also be operational changes. When the procedure for a standard change is created or modified, there should be a full risk assessment and authorization as for any other change. This risk assessment does not need to be repeated each time the standard change is implemented; it only needs to be done if there is a  modification to the way it is carried out.
•Normal changes These are changes that need to be scheduled, assessed, and authorized following a process. Change models based on the type of change determine the roles for assessment and authorization. Some normal changes are low risk, and the change authority for these is usually someone who can make rapid decisions, often using automation to speed up the change. Other normal changes are very major and the change authority could be as high as the management board (or equivalent). Initiation of a normal change is triggered by the creation of a change request. This may be created manually, but organizations that have an automated pipeline for continuous integration and continuous deployment often automate most steps of the change control process.
•   Emergency changes These are changes that must be implemented as soon as possible; for example, to resolve an incident or implement a security patch.
Emergency changes are not typically included in a change schedule, and the process for assessment and authorization is expedited to ensure they can be implemented quickly. As far as possible, emergency changes should be subject to the same testing, assessment, and authorization as normal changes, but it may be acceptable to defer some documentation until after the change has been implemented, and sometimes it will be necessary to implement the change with less testing due to time constraints. There may also be a separate change authority for emergency changes, typically including a small number of senior managers who understand the business risks involved.
The change schedule is used to help plan changes, assist in communication, avoid conflicts, and assign resources. It can also be used after changes have been deployed to provide information needed for incident management, problem management, and improvement planning. Regardless of who the change authority is, they may need to communicate widely across the organization. Risk assessment, for instance, may require them to gather input from many people with specialist knowledge. Additionally, there is usually a need to communicate information about the change to ensure people are fully prepared before the change is deployed.
Figure 5.19 shows the contribution of change control to the service value chain, with the practice being involved in all value chain activities:
•   Plan Changes to product and service portfolios, policies, and practices all require a certain level of control, and the change control practice is used to provide it.
•   Improve Many improvements will require changes to be made, and these should be assessed and authorized in the same way as all other changes.
•   Engage Customers and users may need to be consulted or informed about changes, depending on the nature of the change.
•   Design and transition Many changes are initiated as a result of new or changed services. Change control activity is a major contributor to transition.
•   Obtain/build Changes to components are subject to change control, whether they are built in house or obtained from suppliers.
•   Deliver and support Changes may have an impact on delivery and support, and information about changes must be communicated to personnel who carry out this value chain activity. These people may also play a part in assessing and authorizing changes.
 
Figure 5.19 Heat map of the contribution of change control to value chain activities

The IT IL story: Change control
Henri: The car hire market is developingfaster than ever. To make sure that Axle meets customer demands and capitalizes on opportunities, we need to  have speed–to–market and to experiment with new ideas. Our new service
oferings will see a lot of change at Axle. Some teams will need to double, while others may reduce. We need to bring everyone at Axle on board.
Radhika: The change control practice at Axle makes sure that our services achieve the right balance of flexibility and reliability.
Marco: Some of our processes are highly automated and designedfor the fast deployment of changes. These are perfectfor changes to our booking app and some of our lT systems.
Su: ln other cases, such as when we update our vehicles, we use a mix of
manual and automated testing. For example, the Axle Aware road monitoring  and safety system requires consultation and approval before we can update it.
Marco: Systems such as Axle Aware can’t be altered like the booking app. The priorityfor those changes is that we act safely and comply with appropriate regulations. That’s more important than time to market.
5.2.5 Incident management
Key message
The purpose of the incident management practice is to minimize the negative impact of incidents by restoring normal service operation as quickly as possible.
Incident management can have an enormous impact on customer and user satisfaction, and on how customers and users perceive the service provider. Every incident should be logged and managed to ensure that it is resolved in a time that meets the expectations of the customer and user. Target resolution times are agreed, documented, and communicated to ensure that expectations are realistic. Incidents are prioritized based on an agreed classification to ensure that incidents  with the highest business impact are resolved first.
Organizations should design their incident management practice to provide appropriate management and resource allocation to different types of incident.
Incidents with a low impact must be managed efficiently to ensure that they do not consume too many resources. Incidents with a larger impact may require more resources and more complex management. There are usually separate processes for managing major incidents, and for managing information security incidents.
Information about incidents should be stored in incident records in a suitable tool. Ideally, this tool should also provide links to related CIs, changes, problems, known errors, and other knowledge to enable quick and efficient diagnosis and recovery. Modern IT service management tools can provide automated matching of incidents to other incidents, problems, or known errors, and can even provide intelligent analysis of incident data to generate recommendations for helping with future incidents.
It is important that people working on an incident provide good-quality updates in a  timely fashion. These updates should include information about symptoms, business impact, CIs affected, actions completed, and actions planned. Each of these should    have a timestamp and information about the people involved, so that the people involved or interested can be kept informed. There may also be a need for good collaboration tools so that people working on an incident can collaborate effectively.
Incidents may be diagnosed and resolved by people in many different groups, depending on the complexity of the issue or the incident type. All of these groups need to understand the incident management process, and how their contribution to this helps to manage the value, outcomes, costs, and risks of t he services provided:
•   Some incidents will be resolved by the users themselves, using self-help. Use of specific self-help records should be captured for use in measurement and improvement activities.
•   Some incidents will be resolved by the service desk.
•   More complex incidents will usually be escalated to a support team for resolution. Typically, the routing is based on the incident category, which should help to identify the correct team.
•   Incidents can be escalated to suppliers or partners, who offer support for their products and services.
•   The most complex incidents, and all major incidents, often require a temporary team to work together to identify the resolution. This team may include representatives of many stakeholders, including the service provider, suppliers, users, etc.
•   In some extreme cases, disaster recovery plans may be invoked to resolve an  incident. Disaster recovery is described in the service continuity management practice (section 5.2.12).
Effective incident management often requires a high level of collaboration within and between teams. These teams may include the service desk, technical support, application support, and vendors. Collaboration can facilitate information-sharing and learning, as well as helping to solve the incident more efficiently and effectively.

Third-party products and services that are used as components of a service require support agreements which align the obligations of the supplier with the commitments made by the service provider to customers. Incident management may require frequent interaction with these suppliers, and routine management of this aspect of supplier contracts is often part of the incident management practice. A supplier can also act as a service desk, logging and managing all incidents and escalating them to subject matter experts or other parties as required.
There should be a formal process for logging and managing incidents. This process     does not usually include detailed procedures for how to diagnose, investigate, and    resolve incidents, but can provide techniques for making investigation and diagnosis more efficient. There may be scripts for collecting information from users during initial contact, and this may lead directly to diagnosis and resolution of simple incidents. Investigation of more complicated incidents often requires knowledge and expertise, rather than procedural steps.
Dealing with incidents is possible in every value chain activity, though t he most visible (due to effect on users) are incidents in an operational environment.
Figure 5.20 shows the contribution of incident management to the service value chain, with the practice being applied mainly to the engage, and deliver and support value chain activities. Except for plan, other activities may use information about
incidents to help set priorities:
•   Improve Incident records are a key input to improvement activities, and are prioritized both in terms of incident frequency and severity.
•   Engage Incidents are visible to users, and significant incidents are also visible to customers. Good incident management requires regular communication to understand the issues, set expectations, provide status updates, and agree that the issue has been resolved so the incident can be closed.
•   Design and transition Incidents may occur in test environments, as well as during service release and deployment. The practice ensures these incidents are resolved in a timely and controlled manner.
•   Obtain/build Incidents may occur in development environments. Incident management practice ensures these incidents are resolved in a timely and controlled manner.
•   Deliver and support Incident management makes a significant contribution to support. This value chain activity includes resolving incidents and problems.
Figure 5.20 Heat map of the contribution of incident management to value chain activities
The IT IL story: Axle’s incident management
Radhika: Axle faces many potential IT and non-IT incidents. Cars can break down, road accidents might occur, or our customers mightface challenges with unfamiliar road rules.
Marco: A car booking can be a fected by an error in our app, or by a user getting lost due to a navigation error with our software. When incidents occur, we have to be ready to restore normal services as soon as possible. We also have to make sure our team knows how and when to switchfrom pre-defined recovery procedures to swarming and collective analysis.
Radhika: We also make sure that such cases are followed by investigation and improvements.
Henri: Axle has developed clear processes for all types of incidents, with workarounds available for cases that happen frequently, such as a tyre puncture or loss of internet connectivity.
Radhika: Our teams work together with our suppliers and partners to ensure fast and efective incident response. We develop and test recovery procedures together with the partners involved in any incidents we experience.

翻译考点：
考点1：“IT infrastructure”推荐译为“IT基础架构”
考点2：“able to understand the risks and the expected benefits”必须译为“有能力理解风险和预期收益”，避免缩小为特定人群。
考点3：“a major contributor”必须译为“主要贡献者”，避免夸大为“核心”。
考点4：“based on an agreed classification”必须译为“根据商定的分类确定优先级”，不可省略“分类”。
考点5：“outcomes”必须译为“成果”，不可漏译。
考点6：“escalated to”必须译为“升级至”，避免泛化为“参与”。
考点7：“well understood and fully documented”必须译为“充分理解并完整记录”，避免限定为“流程”。
考点8：“specialist knowledge”必须译为“专业知识”，避免译为“专业人士的意见”。