What is a change
By ITIL® from Experience©
ITIL® defines a change as: “The addition, modification or removal of anything that could have an effect on IT Services.”1
The most important element of this definition is that a change is a risk. The word "could" refers to a possibility and, "possibility" is a central notion ofrisk.2 Whether the impact is potentially negative or positive, like a move, it is still a risk.
The definition also refers to “The addition, modification or removal of anything...". By referring to "anything" instead of Configuration Items (CIs) means that Change Management is more than simply a process to maintain the accuracy of the CMDB.
To summarize, a change is: "any activity that is a risk to an IT service."
Based on this understanding the following are examples of changes:
- A hardware change, such as:
- Adding to capacity
- Replacing hardware that is being taken out of service (e.g. lifecycle)
- Installing new hardware to support a new or existing service
- Substituting an identical piece of equipment and configuration, even if the Configuration Item (CI) attributes are not changed (e.g. break-fix replacement of a router with an identical model and configuration)
- Decommissioning and/or removing/retiring end-of-life hardware
- Reboot (see Is a server reboot a change)
- A change to system software, such as:
- Patching the Operating System
- Security software rules or filters
- Anti-virus software or virus definition update
- A change to applications software:
- Using an administrator account to modify a setting that changes the behavior of the application that alters its functionality (e.g. quotas, handling of spam emails)
- Releasing additional functionality or a patch/hot fix
- Modifying the application's outcomes, like updating a tax table
- Loading data through an import function (see Is a bulk data load a change)
- Changes to a standard, a process, or documentation related to the production environment (since following a bad procedure could lead to incidents).
Let’s not get taken away and think that all of these changes must go though the CAB for approval before being implemented! Some of these changes can be Standard Changes (see How is a Standard Change Pre-Approved)
Some common activities that do not affect an IT Service and are not changes include Incidents, Problems and Service Requests such as:
- A service request to order standard hardware or software
- The creation of an additional user account
- Resolution of an incident which does not require a change (see Does an emergency change need an incident)
- Testing hardware to ensure that it is not defective (burn/bench testing prior to deploying (commissioning) the hardware in production.
Even though, by definition these examples may not be changes, they may result in an RFC; such as ordering non-standard hardware/software as these requests are risks to the organization.
Even with this explanation people may still be confused. Thus, a rule stating that "When in doubt, log an RFC" is helpful. If it turns out that a Request For Change (RFC) was not needed, people will be informed not to do so for this type of work. However, will usually be seriously criticized for not logging an RFC when one was nedded.
they can be criticized for not doing so when an RFC was needed. Therefore, might as well be safe than sorry and log an RFC.
Last updated on: 2015-04-15
"The 4 Ps for Change and Release: Planning Prevents Poor Performance."
Related:
- People are confused between a normal and a standard change. What is another name for it
- How to manage unauthorized changes
- What is the content of a standard change
- How to identify standard changes
- Is a reboot a change
- Is a bulk data load a change
- Who should log the RFC
From Around the Web:
Category:
ITIL Process > Change Management
Copyright 2012, 2016 - ITIL® from Experience - D.Matte