Change Management (ITIL)

from Wikipedia, the free encyclopedia

Change management is a topic from the IT Infrastructure Library (ITIL) and is defined there in the book Service Transition as a process that has the goal of controlling all adjustments to the IT infrastructure efficiently and while minimizing risks for the operation of existing ones Business services are carried out.

In addition, the term change management exists in business administration as an independent discipline for the implementation of far-reaching changes in organizations (see change management ).

background

A high proportion of cost-intensive IT service disruptions can often be traced back to poorly coordinated or insufficiently controlled changes to the IT service landscape. These disruptions can result in enormous costs due to the current dependence of company processes on IT. This justifies investments in IT processes in which every change in terms of needs and benefits as well as possible negative effects is checked and the disruptions are reduced to an acceptable minimum by appropriate measures.

It is therefore the task of change management to ensure that standardized methods and procedures for implementing changes exist and that these are used efficiently and consistently.

Change management tasks

Change management is responsible for creating and managing the change process. The process includes capturing, documenting, approving and monitoring and ensures that changes are planned, efficiently, cost-effectively and implemented with minimal risk.

In order to be able to assess the risk of every change, you need detailed information about the individual CIs (configuration items) and their relationships to one another. The components of the IT infrastructure, so-called configuration items, are managed within the framework of configuration management with a configuration management database (CMDB). Change management typically includes:

  • Initiate, document and authorize changes
  • Assess the effects, costs, benefits and risks of the changes being considered
  • Justification and approval of changes
  • Plan and coordinate the implementation of Changes ~ Monitor and report on the implementation
  • Review and final processing of Request for Changes (RfCs)

It is important that changes are planned well in advance. Only changes that have been planned and provided with an appropriate schedule can be effectively controlled, as this ensures that there is enough time to get an overview of what is planned and what still needs to be done.

Communication is the key to a successful change process. Too little communication is often the reason that changes are not carried out correctly and incidents occur. The more employees are informed, the greater the chance that the change will be appropriately analyzed and monitored so that the implementation is error-free. A communication structure (e.g. the CAB, Change Advisory Board) is therefore necessary. Reports are also important. These help to announce the changes themselves and how they are carried out.

Mission statement

Within the strategic objective (mission statement), the term "authorized changes" has a very strong meaning and is precisely defined. But good change management practices do justice to both the small, everyday changes and the changes that are required to immediately restore a critical service or that have an impact on a large number of customers. For example, if a user wants to change their password, a complete request for change including a subsequent discussion of the change advisory board for approval would be inappropriate. A change that has to take place immediately in order to restore a critical service should also go through a faster processing path than normal changes.

Some see additional bureaucracy in implementing comprehensive cross-functional change management processes with formal documentation, meetings, and approvals . At first glance, one might think that this all-encompassing change management process will hinder those who have to make the changes in order to keep the IT environment running. In fact, however, appropriate change management (and configuration management) processes should reduce the need for constant ad hoc changes that are found in environments that have no or insufficient change and configuration management procedures. A well thought-out change and configuration management process should process and approve necessary changes quickly. These approved changes are supported by IT management and have been examined for risk, cost and impact.

Process implementation

In today's business world, the dependence of IT systems and technology on management requires enough time to be invested in assessing the impact of business changes on IT and the impact of IT changes on the business. Managing changes has become a full-time task. If changes are managed in such a way that the risk, severity of impact, and potential disruption are optimized, and changes are successful the first time, it is essential for the organization to implement this process quickly.

terminology

The definitions of the terms are:

Change

Modification or expansion of an existing specification, product or service. This includes adding, changing or removing approved, supported or frozen hardware, network components, software, applications, environmental components, systems, desktop builds, any configuration required or related to their use, or related documentation.

Request for Change (RfC)

A change request or its form (paper or online) that is used to record details of a change request that relates to any CI ( Configuration Item ) within the infrastructure or to processes or devices connected to the infrastructure.

Forward Schedule of Changes (FSC)

Schedule that contains details of the changes approved for implementation and their intended implementation date.

Change management process

The basic process is independent of whether it is a small change, such as expanding the main memory of a server, or a project with a significant impact on the existing operation. The urgency also has no influence on the process itself, but the process speeds and priorities are different. Crucial blocks in the change management process are:

Request for Change

RfC - in German amendment. The life cycle of a change begins with the formal registration of the application. The RfC is the actual logbook, i.e. the collection of all activities in this life cycle. All activities, discussions, descriptions, analyzes, documentation and decisions regarding a change are recorded in it.

Registration and classification

Gather the information needed to make decisions about what needs to be changed, what category the change falls into, and what impact it will have in order to properly execute approval. A priority and category is assigned to the change based on its impact. Risk assessment is critical at this stage.

Monitoring and planning

All changes are planned under the responsibility of change management and if this is necessary for optimal control of the change (s), a complete schedule (with milestones, FSC) is provided.

Approval

Decide whether the change will be carried out or not.

Elaboration and testing

Approved changes are passed on to the appropriate technical groups for elaboration. Change management - supported by release management and normal line management - takes on the coordination to ensure that the activities are given the necessary resources and are carried out within the given schedule. In order to prevent the changes from having a serious impact on the quality of service, it is recommended that the changes be thoroughly tested before implementation and that back-out plans are in place.

Approval of the implementation

After a suitable test and verification that all necessary actions have been carried out, for example checking for the existence of a back-out plan, the change can be released for implementation.

implementation

It is the task of change management to ensure that the changes are implemented in the planned time frame. However, this will mostly mean coordinating the change, as the actual execution is the responsibility of others (e.g. hardware changes are carried out by technicians).

evaluation

Change management must evaluate all changes carried out after a specified period of time. This is done through a "Post Implementation Review" (PIR).

The aim is to examine the efficiency of the measures taken and the associated process. Both the changes made and the methods and processes used should be subjected to an actual / target analysis. In the case of major changes, cost-benefit comparisons, the return on investment (ROI) calculation and the measurement of target achievement from a business perspective also play a role. A general evaluation catalog from the PIR allows an objective evaluation and can, in total, over a longer period of time, also provide a trend statement as to whether the resources used contribute efficiently to solving problems.

The evaluation catalog includes questions such as:

  • Have the set goals been achieved within the given limits?
  • Does the result achieved correspond to the previous expectations?
  • Have the agreed project times (milestones) been adhered to?
  • Was the process carried out with the given budget and the intended resources?
  • Did you encounter any unforeseen problems?

During this process, depending on the scope of the original change, it may be necessary for CAB, MB and / or EC members as well as appropriate consultants to participate. Change management sets the dates and the agenda and requests support for this. Change management should also carry out the agreed evaluations and initiate appropriate measures to eliminate any deficiencies in the change management process, even as a result of ineffective changes.

Scope of the Request for Change (RfC)

The request for change is a request or an order to change management to make a change or expansion in the IT environment. Complete services and CIs are added or existing services and CIs are adapted. Requests for change are made by many different requesters for many different reasons. This is the beginning of the change life cycle. RfCs can refer to any part of the infrastructure and any service or activity. RfCs can be on paper or - as is increasingly the case - electronically, perhaps on the company's intranet. All RfCs should be recorded and clearly identifiable by assigning a number.

The following fields should be included in an RfC form, regardless of paper or electronic version:

  • RfC number (also a cross reference to the problem number, where necessary)
  • Description and identity of the elements to be changed (including the CI identification if a config management system is used)
  • the reason for the change
  • Impact if change is not implemented
  • Version of the item to be changed
  • Name, office and phone number of the person who proposed the change
  • Date on which the change was proposed
  • Priority of the change
  • Assessment of the impact and required resources (which can also be listed on a separate form if required)
  • If appropriate, CAB recommendations (which can also be listed separately if necessary, with an assessment of the impact and required resources)
  • Signature for approval (could also be electronic)
  • Date and time of approval
  • Implementation schedule (release identification and / or date / time)
  • Storage location of the release / implementation plan
  • Details of the change designer / implementer
  • Back-out plan
  • Current date and time of implementation
  • Review date
  • Review results (including cross-reference to new RfC if necessary)
  • Risk analysis and management
  • Influence on incident and disaster plans in business
  • Status of the RfC - e.g. B. 'accepted', 'estimated', 'rejected', 'approved', 'waiting'

While the change continues in its lifecycle, the request for change should be updated so that the person who initiated the change is informed of the status. Current resources used and the accrued costs should be entered as part of the data set.

prioritization

Once the change is accepted, priority and category are assigned. The priority shows the importance of the change and is made up of the impact of the problem and the urgency of the resolution. The problem manager may have already determined a priority, but the final prioritization for the change is made in change management, taking into account all other RfCs that are under discussion. The change manager assigns the category. This classification determines how the matter will be dealt with and is therefore determined by the "severity" of the adjustment.

Examples of priority levels are:

Urgent

Highest priority; the RfC concerns a problem that causes an immense impairment of the use of essential services, or it concerns an urgent adaptation of the IT (for example new functionalities due to business considerations or new legal guidelines). Urgent changes differ from the normal procedures because the necessary resources for this type must be made available immediately. An emergency meeting of the CAB (CAB / EC) or the IT steering committee may be required. All other planned activities may be temporarily suspended.

High

Resolves serious technical difficulties for a large group or number of users, or affects other important situations. This change is given the highest priority in the allocation of resources for development, testing and implementation of the change.

medium

Normal priority: not immense urgency or high impact, but the change cannot be postponed until the next planned release or maintenance window. The change is given an average priority in the allocation of resources.

Low

A justified and necessary change, which can, however, be postponed to a more suitable time. For example, until the next release or a planned maintenance window. Resources are allocated according to the point in time.

Categorization

Subdivision of the category.
Categories are assigned by the change manager, if necessary in cooperation with the CAB. The categories give an indication of the impact of the change on the company and the burden on the IT organization. Below is an example of a breakdown of categories:

default

Standard changes to the infrastructure for which precise procedural instructions exist and which have been approved in advance by the change manager. The procedural instructions mentioned ensure that risks can be neglected or managed well. The change can be carried out without having to contact a change manager again.

normal

Category 1

Low risk for ongoing business processes. A change that doesn't require a lot of work. The change manager can approve this type of change without discussing it with the CAB.

Category 2

Significant risk for ongoing business processes. Changes that require greater effort and have a greater impact on the services. Such changes will be discussed in the next planned meeting of the CAB in order to predict the required effort and possible consequences. Before the meeting, some required documents will be sent to the CAB members and possibly some specialists and developers. The CAB / EC is responsible for changes with the priority "Urgent".

Category 3

Significant risk for ongoing business processes. A change that requires a lot of effort and resources to implement. In the case of a change of this type, the change manager needs the approval of IT management, an IT steering committee or management (MB) and must then discuss it with the CAB.

Emergency

A special case of the change that does not go through the usual process, but is carried out immediately, if necessary at a considerable risk and without further approval from stakeholders, mostly to avert greater damage. For a change of this kind, the change manager only needs the approval of the Emergency Committee (EC). The priority here is to be able to react to an emergency situation; corresponding further approvals and tests are only carried out after the change.

Most changes can be assigned to the first two categories.

The Change Advisory Board (CAB)

“Change Advisory Board” is an ITIL role. Some understand the term “board” as very formal, regular meetings of the same group of top managers. A CAB meeting can be both formal and informal. In today's business world, the term “team” could more accurately describe the typical shape of a CAB. The CAB “team” can meet regularly, according to ITIL recommendations at least every 20 days. The CAB meetings can also take place several times a week, and special meetings can be called at any time. Some CAB members will likely attend the CAB meetings regularly; others, on the other hand, may be asked to attend individual meetings to provide input on a particular request for change under discussion.

The CAB supports the change manager in assessing and prioritizing changes in terms of business impact. When a CAB is convened, the selected members must be able to assess the change from both a business and a technical standpoint. To achieve this mix, people with a clear understanding of the customer's business requirements as well as users and representatives from the technical development and support areas must be represented in the CAB.

In addition to the change manager, members of the CAB can be: customers, users at management level, representatives of users, application developers or administrators (if appropriate), experts / technical consultants, service employees (if required), employees in building services ( if changes affect the office installations and vice versa), representatives of subcontractors and other manufacturers (if required, for example in the case of outsourcing procedures).

It is important to emphasize that the CAB

  • Consists of permanent members (chair - change manager) and temporary members
  • Is composed according to the changes to be processed
  • Can differ significantly in composition even within a single meeting
  • Consult suppliers if this is helpful
  • Both the user and the customer perspective should be considered
  • At least temporarily, the Problem Manager / Service Level Manager and Customer Relations staff should be involved

If Category 2 changes occur that need to be assessed in the shortest possible time ( urgent priority ), it is necessary to set up a smaller organization that has the authority to make urgent decisions. Such a body is called the ITIL CAB Emergency Committee (CAB / EC) . Change procedures should define how the composition of the CAB and CAB / EC is determined based on the above. Criteria and all other criteria that are important for the business. This will also ensure that the composition of the CAB allows for appropriate decisions to be made in any eventuality eventuality, both from a business perspective and from a technical standpoint.

Relationships with other ITIL processes

Configuration management

Change and configuration management are two very closely interlinked processes. Configuration management cannot exist without change management, as it is dependent on the current information about the IT infrastructure from change management. Conversely, change management without configuration management has no way of assessing the effects of a change on the rest of the IT infrastructure, IT services and thus on the business. If the Configuration Manager - after checking - has found CIs ( Configuration Item ) in the configuration that are not in the database, there are two options:

  1. the database is not up-to-date, which can indicate that configuration management was not informed of a change
  2. someone made an illegal - unapproved - change

Analysis, Risk and Impact

The most important area in which the processes are connected is the analysis of the impact and risk of a change. Most of this has to be done with the assistance of the CMDB. After receiving an RfC, one of the first things to do is find out which CI or CIs need to be changed and what the impact is on the existing infrastructure. Change management must also determine whether this one RfC amounts to several different RfCs, as several CIs must be changed as a result of the RfC. It must also be found out whether this change affects one or more users, one or more organizations or one or more services in order to be able to assign the correct degree of impact. Based on this, the change manager can decide whether the CAB needs to be convened, who is invited and at what level it needs to be discussed.

Capacity management

Capacity management must assess the impact of changes on the existing capacities and identify any additional capacities required. Additional capacity requirements must be included in the capacity plan and, as such, must also be treated as RfCs.

Release management

Release management is the process that is responsible for planning the timing and controlling the transition from releases to test and live environments. The primary goal of release management is to ensure that the integrity of the live environment is maintained and that the correct components are included in the release. Release management is part of the release and deployment management process.

Summary of RfCs

The combination of linked RfCs not only helps with a more realistic assessment of the effects, but also reduces the bureaucratic effort of change management.

Summary

Request for Change (RfC)

A change is any change to one or more CIs. It can vary from severe (such as replacing a control server) to simple (replacing a printer driver) and can affect any of the components in the CMDB. In order for the adaptations to be carried out, customers, as well as problem management, can submit requests for change (RfC) to the change manager. Internal IT requirements (service planning, development, etc.) can also result in an RfC.

The change manager

The change manager is responsible for implementing a change in a systematic manner after weighing the known risks. He also monitors the progress of the change. The change manager assesses the Requests for Change (RfC) together with the Change Advisory Board (CAB). This committee consists of experienced employees from the disciplines concerned.

The process

The change manager receives the request for change (RfC), checks it for completeness, records it and classifies it based on the estimated risks. If the change has been approved in principle, the consequences in terms of capacity are recorded. Availability and costs are analyzed in the service planning process. The proposal can then, after approval by change management, be passed on to the development department for design, development and testing.

The change manager decides, if necessary with advice from the CAB, on the schedule of the release ("release") on the basis of the test results and a well-developed back-out plan. The back-out plan ensures that the organization can revert to the previous situation at any time if unforeseen problems arise. Only then is the person responsible for the release approved the implementation. If it is a "software release", the release is followed by a production test by the release management process before the software is distributed for use on a test basis. In addition, a Post Implementation Review (PIR) of the change and the way in which it was implemented must always follow.

Management reports

Change management must (ideally together with business management) determine metrics that have a certain meaning. It is relatively easy to count incidents that lead to problems and which in turn lead to changes. However, it is far more important to look at the underlying causes and identify trends. It is best to measure the impact of change management and to demonstrate fewer disruptions over time due to the introduction of change management, as well as to measure the speed and effectiveness with which the IT infrastructure reacts to changing business requirements. When practicable, metrics used should be tied to business goals - and to costs, services, availability, and reliability. All predictions should be compared with actual measurements.

Regular summaries of the changes should be made available to service management, customers and user management. Different levels of management typically require different types of information. This ranges from the service manager who may request a detailed weekly report, to senior management committees that typically only request a management summary on a quarterly basis. The following facts and statistics should be taken into account in the management reports:

  • The number of changes carried out in a period in total and according to CI, configuration type, service etc.
  • A breakdown of the reasons for changes (user orders, extensions, business requirements, service call / incident / problem fixes, procedures / training improvements, etc.)
  • The number of successful changes
  • The number of undone changes (back-out) together with the reasons for them (incorrect assessment, bad build)
  • The number of incidents that can be traced back to changes (broken down by severity of the problem) and the reasons for them (e.g. incorrect assessment, poor build)
  • The number of RfCs (and trends in future numbers)
  • The number of changes carried out that were checked and the number of checks still pending (broken down by time)
  • High number of RfCs that relate to a single CI (these CIs are worth looking at more closely) including the reasons (e.g. changed user requirements, unstable components, poor build)
  • Figures from previous periods (last period, last year) for comparison
  • The number of rejected RfCs
  • The ratio of changes made to changes that have failed (total and broken down by CI)
  • Pending changes, broken down by CI and the level in the change management process

Individual evidence

HP, ITIL Basics for IT Service Management, Student Workbook, Version D.00_DE-1