The described concepts are generalized so that can apply universally, regardless of the actual structure of the company. The intent is for organizations to develop their own processes and practices with the change management framework established by ITIL 4 in mind. Using ITIL 4's recommendations hand-in-hand with change risk prediction analytics can greatly accelerate release velocity while guiding product teams to start making lower-risk changes overall.
Changes are a standard part of daily IT Operations, no matter what category it may fit into. Decades ago, changes were relegated to rare patch events or configuration updates that happened just a few times a year, or less.
But now, some of the most popular applications, services, and platforms in the world receive thousands of change updates in a given year. Google famously reported in that it made over 3, changes to its search engine algorithms that year alone , averaging about 9 per day.
With so much change happening at such a rapid pace, IT organizations need a structured way to integrate and deploy changes in order to minimize the risks of service disruptions. At the same time, IT operations leaders need to remove any obstacles that stand in the way of change velocity. Any unnecessary delays or gatekeeping impedes the value production chain. This presents a paradox: we must implement changes in a safe way at a faster speed than ever before.
The recently updated ITIL change management process seeks to address this conundrum. ITIL 4 change management's main objective is to remove all barriers to change deployment while retaining efficient control over operational metrics and other change risk management goals. In this spirit, ITIL 4 proposes a change enablement framework rather than rigidly defining a prescriptive set of change management processes.
By adopting ITIL 4's ideals and customizing them to best-fit the organizational environment at hand, IT operations teams can accelerate the speed of change while minimizing inefficiencies — and disruptive threats — along the way.
The original versions of ITIL — with the first being published in the late s — rigidly mapped processes that could bring predictability and structure to an organization's IT-related activities. This guidance was vital for enterprises where IT requirements were either unfamiliar or led to unpredictability. It was a product of a world unfamiliar with emergent technology, and businesses as well as governmental organizations were hungry for this level of specific guidance.
However, a major shift in software development methodologies arose in the early s: Agile. With Agile, rigid " waterfall " development processes were done away with. This gave individual development teams more autonomy and control over their end results, which could be achieved in a significantly shorter time period.
Agile made popular the idea that applications and technology platforms could evolve continuously — as long as work was put in to make sure each new change added value to end users.
ITIL v3 built upon existing ITIL change processes and developed a model for continual change implementation that many organizations followed with the following steps:. Recording the right closure code makes an organization's metrics much more accurate and useful. Not all changes are the same, as some have different requirements. Some changes need to be implemented as soon as possible, some need approval from the organization's higher-ups, and some are just normal changes that are implemented on a weekly basis.
According to ITIL, changes can be broadly divided into three types: standard, normal, and emergency changes. These are preapproved changes that are low-impact, well-known, and documented. Standard changes require a risk assessment and authorization when implemented for the first time, but subsequent implementations can be done without these precautions as long as the change hasn't been modified. Example: Replacing a printer's ink cartridge. A normal change needs to follow the entire change process; it should be scheduled, have its risk assessed, and be authorized.
Normal changes include both minor low to medium impact and urgency and major changes high impact and urgency. All changes that aren't standard or emergency ones should be treated as normal changes and adhere to the change process. Example: Moving on-premises services to the cloud. Emergency changes have high impact and urgency, requiring expedited assessment, approval, and implementation to get services up and running as soon as possible.
Modifications to components that affect business operations, and therefore cause downtime, are treated as emergency changes. Examples: Primary server failure, data center disruption, emergency patch for security vulnerability. The change owner is accountable for the entire change management process, including its improvement. Since they're responsible for change management at their organization, they're usually a high-ranking official.
The change manager handles the implementation of the change and the activities related to it. They also manage the CAB and the various teams and stakeholders involved, and coordinate with them.
The change initiator is the one who initiates the change and adds the change plans, implementation plans, and other required details. They also organize the change implementation plan. A change initiator can either be a technician or an end user. The CAB is a collection of various members from different teams and job functions. Together they analyze the proposed change and give their approval and recommendations regarding the change and its implementation.
Some organizations use custom roles in addition to these four main ones to delegate work and break down responsibilities. Being able to create custom roles helps you tailor your change management to your organization's needs. A few commonly used additional roles are:. Changes take up quite an amount of resources, as a lot of time and research goes into planning changes.
A large number of failed changes can become expensive fast if left unchecked. In the case of infrastructural changes, a high failure rate can result in larger problems either during implementation or while implementing backout plans. Many failed changes is also an indicator of a poor change management process. Example: Zylker planned to upgrade its primary network infrastructure, so the company set up an alternate network with a third-party network provider; it planned to implement the change over a weekend.
During implementation, Zylker received tickets about services being down, which was surprising given that the company had set up an alternate network. Turns out that the alternate network provider was also performing scheduled maintenance that weekend, which meant both Zylker's primary and alternate networks were down, rendering Zylker's services unavailable. Since the change was not planned properly, it ultimately failed.
Unauthorized changes are the result of a lackluster approval mechanism and failure to include the right stakeholders in the approval stage. These changes bypass the necessary permissions and may end being implemented if not flagged in time. Unauthorized changes can lead to changes that your organization doesn't need or isn't ready to implement.
The bottom line is that unauthorized changes are bad and an unnecessary expense. As previously explained, emergency changes require expedited approval so they can be implemented as soon as possible. Treating too many changes as emergency changes may lead to delays in the event of a serious emergency change that needs to be implemented.
It's always good to exercise caution when classifying a change as an emergency change. Note: The popular story about the boy who cried wolf is a good analogy for why treating too many changes as emergency changes can backfire.
In the event of an actual emergency, your organization may not take the change with the seriousness it requires, and you may not have the required resources to handle the emergency. Poor planning can lead to change collisions. A change collision is when two or more changes are inadvertently planned to be implemented simultaneously, disrupting the implementation of either change. Utilizing a change calendar to plan your changes better can help prevent change collisions. Not all changes are the same.
Changes have varying levels of priority and different requirements, as explained under the types of changes section. Therefore, it's important to first identify the kinds of changes that your organization might perform, and then create different change types to effectively roll them out.
Since different change types have their own unique requirements, you need to design unique processes to fulfill those needs. Using the same change process for all change types will only lead to unnecessary delays and incomplete change implementations. Note: You can create different change workflows for each of your change types. Defining roles allows the change manager to delegate activities and responsibilities to others. Roles make it easier to manage changes, and they clearly define the activities that each person can perform.
It's a best practice to have an organized way to log your changes, as well as manage and prioritize them in one place. With better visibility into your organization's changes, you can prioritize which changes need to be performed ahead of others. All changes need to go through risk and impact analysis to understand the change better and allocate the necessary resources. The risk and impact details should be added at the planning stage so the CAB has a clear picture of the change and can give their recommendation.
Defining the approval process makes it easy to get the necessary permissions for a change to be implemented. It ensures that all key stakeholders are aware of changes and give their recommendation before a change is implemented. This helps curb unauthorized changes. Keeping stakeholders informed of planned changes reduces the number of incidents caused by changes. Delivering prompt information also ensures that no services are affected due to changes, and that the change can be carried out effectively.
As a bonus, management is also happier when they're informed throughout the change life cycle. Keeping an eye on a change throughout the entire change life cycle ensures that nothing goes wrong and that the change is implemented according to the change plan. Measuring key metrics gives you a clear picture of how effective your change process is and also lets you identify areas you can improve.
You can never be too prepared, so it's always a good idea to plan for the worst-case scenario and come up with a backout plan during the change planning stage. This in-depth planning can mean the difference between a run-of-the-mill failed change and irreversible damage to your IT infrastructure. Although firefighting is a crucial function of change management, changes have a wider scope in your organization. Using changes to improve technology and processes, and thereby continually enhance your organization's ability to provide better services, is becoming an important function of change management.
Change management doesn't end with just completing a change. Change management's ability to effectively roll out changes can greatly benefit from information collected in other ITSM processes , and vice versa. The ability to associate incidents with the changes they caused or were caused by, or update the CMDB based on IT infrastructural changes, are just the beginning of creating a wholesome ITSM practice that works together to help manage your organization better. Tracking the incidents causing a change and the ones caused by a change gives you a better understanding of how changes affect your organization.
For instance, when a router is being updated, you might get incident tickets reporting that the internet is down. Associating changes with the incidents they caused helps you quickly identify the cause of an incident and forego having to assign resources to fix that particular incident, as it will be fixed as soon as the change is completed. It's important to use changes for high-impact service requests to keep your IT infrastructure updated.
Without changes, a service request for a server upgrade or a request to upgrade the Azure storage space ends with the service being delivered. But when you use a change to implement the service request, you can collect more information like the reason for the change and the implementation plan, get the necessary approvals from all stakeholders, and update the CMDB with the new information.
Note: Using a change for request fulfillment works best for high-impact service requests and any service requests that require a change to the CMDB. If it requires the CMDB to be updated, then it needs a change!
Problem management requires creating a change to fix the root cause of a problem. Being able to create an RFC right from within a problem ticket makes it easy to track associated changes and problems. It also gives the CAB a better picture of why the change is required, and denotes the severity of the problem that initiated the change.
Release and deploy upgrades benefit from the structured approach that the change process brings. You can easily track the implementation plans, rollout plans, and the actual implementation of releases and deployments using changes.
The transparency and visibility changes offer also helps keep all stakeholders informed. Any updates to the CMDB should always be done with a change.
A change provides a lot of useful information on why, how, and when the update was done. The impact analysis performed alongside a change also ensures that any updates to the CMDB are properly analyzed and that the update does not create any disruptions to the rest of your organization. You can use change types to record CMDB updates of varying priority. Currently, all of the company's productivity applications and resources are in-house, so remote users are given VPN access to the network.
In order to provide faster access to data, Zylker decides to start using cloud applications. It chooses Zoho One for its productivity suite, and Office for email. Part of the company's resources, like its file servers and databases, are still on-premises, so remote users have to be given access to those as well.
Now end users, even remote users, can access cloud resources with their AD credentials. The first step is to raise a change ticket and collect the necessary information about the change, like the change type, change impact, and urgency, and set the change roles. The change initiator can easily raise a change ticket using their web portal and pick the relevant change template and change type.
The change template collects all the necessary information using mandatory fields. Here, the change initiator sets the change type as normal, selects the appropriate change template, assigns the change roles, and gives a description for why the change is required. Next, the change initiator adds the change information, such as the reason for the change, detailed information on its impact, rollout and backout plans, and scheduled downtime. The change initiator also adds all associated incidents and problems to better track the change and its impact.
Below are the various plans the change initiator came up with. The change manager sets up CABs to review the change plan and give their recommendation on whether the change needs to be implemented or if the plan needs to be modified. Since this is a large-scale change, approvals are required from various job roles spanning a variety of functions.
Here is a list of CABs and members involved in the approval process:. The coordinators will see if the request is valid in the first place. If it is practical they go ahead with the change. Change coordinators make plans when they receive requests. They keep a record of accepted and discarded requests. They check if the request is valid and give the go ahead.
Procedures are laid out for the new process workflows. Measures to handle failures are in place in case of failure. Change managers approve change requests. They make plans to execute changes. They are involved in procedures for building, testing and deployment of new changes.
The change is deployed across the service assets in the delivery process. The coordinators ensure transition of changes at the service level.
Standard Change: A standard change is easy to implement and common in an IT processe. The risk is low for a standard change and do not need prior approval from senior managers.
The workflow for a standard change is as follows:. Normal Change: A normal change needs approval from senior management for an IT process. The potential risk for service delivery is assessed before making this change. Change managers work on priority basis to achieve the end results. The workflow for a normal change is as follows:. Urgent Change: An urgent change happens during emergency situations and needs approval of senior managers.
They can vary from deadline expiry, client needs. The workflows are expedited in this stage to reach the desired targets. The workflow is the same as normal changes. Creating a change request: A team member raises a change request after proving its need. This is based on customer feedback and ideas from co-workers. Reviewing a request: The change requests are evaluated by coordinators or change managers.
They discard unwanted ideas and impractical solutions. The validity of making the new changes are verified at this stage.
0コメント