【導讀】inferred.owners.What’sNew?

　　

【正文】 lan with timescales. ? Backout plan including triggers and decisionmaker contact details. ? Impact on business continuity and contingency plans. ? Risk involved in making the change. The change initiator might also need to provide supporting documentation, such as the business case, costbenefit analysis, or proposed implementation plan, to the change manager and others involved in the change approval process. Two of the RFC items in the change initiator’s list—the remended or proposed change priority and category—merit further explanation. Change Priority There is often a degree of confusion surrounding the definition of priority。 the dictionary definition states: “Precedence, especially established by order of importance or urgency.” In the change management process, the urgency is determined by how quickly a change is required by the business. There are four remended levels of priorities: ? Emergency. A change that, if not implemented immediately, will leave the anization open to huge risk—for example, applying a security patch. ? High. A change that is important for the anization and must be implemented soon—for example, an upgrade in line with new legislation requirements. ? Medium. A change that should be implemented to gain benefit from the changed service—for example, between versions upgrade to a customer feedback service. ? Low. A change that is not pressing but would be advantageous—for example, a “nice to have” addition to a user profile. Service Management Function 13 These priority levels have been defined according to industry best practice. However, depending on anizational size, anizational structure, and the underlying SLAs existing between the IT department and the business it serves, anizations might need to modify their own priority definitions. In some anizations, for instance, if the individual who wants to add the “nice to have” addition to his or her user profile works in a businesscritical area, then the change may be perceived as being a high priority. Conversely, if that same change is requested for a business area that is being phased out, the change may be perceived as a low priority. It is essential that each anization consider the correct use of these priorities for its own environment, since these priorities determine when and how the change is to be implemented. They also determine the order in which change requests are reviewed. It is important to note, however, that an emergency priority change differs from the other change priorities in that it takes a different path through the review process in order to implement the change as quickly as possible. This priority is reserved for only those changes that, if not implemented quickly, might seriously affect service levels or result in a large cost to the business. Emergency changes must be kept to an absolute minimum due to the increased risk involved in implementing them。 their use should not replace good planning practices. Change Category Whereas the priority of a change indicates how urgently a change is required to be implemented, the category of a change is used to define the change’s impact on the infrastructure, users, or business. For example, does the change affect one user, a department, or every user in the anization? Does the change involve updating a single switch, or is it a plete overhaul of the work? The answers to such questions determine the category of the change. As with priorities, the decision of what constitutes each category of change is determined by the individual anization. As a suggestion, the following categories have been used effectively in other anizations. ? Major. A change where the impact on the group could be massive—for example, a departmental or corporatewide change, or a workwide or servicewide change. ? Significant. A change where the effect is widespread, but not massive—for example, a change affecting a group within a department or a specific group of CIs. ? Minor. A change affecting small numbers of individuals or CIs—for example, a change to a printer used by a department consisting of just a few members. ? Standard. A change that has been performed before and is part of the operational practice of the business—for example, an update to a user profile. As with the change priority, the change category is also tied to the specific anization. A change affecting a particular department may be deemed significant in some anizations but may only be considered a standard category in another anization in which that department is regarded as less critical to the business. The same is true for changes to the delivery of specific services or the use of certain products. The information for defining the categories should be gathered from the Service Role Cluster, service catalog, and Service Level Management SMF. One category of change that needs special attention, however, is called a standard change in this guide. A standard change falls at the bottom of the category scale in that its impact is low in terms of effect on users or infrastructure. The effort required to implement it is also relatively small and its risk to the environment is correspondingly low. 14 C hange Management A set of standard changes and standard procedures for implementing them is normally predefined by the change advisory board (CAB). This set of standard changes can be automatically approved without needing to be voted upon by the CAB or the change manager, thereby taking a shorter route through the change approval process. Only changes that fall into the predefined standard set can be classified as such. Examples of standard changes include regularly scheduled maintenance, frequently performed administrative tasks (such as profile changes), and lesser service requests. Submit the RFC for Approval The change initiator documents a