Change Management definitions
The following table defines terms that are related to change management and requests for change (RFCs).
Term | Definition |
|---|---|
Backout plan | A document that describes the steps needed to recover an environment to a known state after a failed change or release. The steps typically include backing out the change, patching, and redeploying. |
Change | The addition, modification, or removal of functionality that could affect your environments. Changes can include hardware, software, or code changes. The scope of a change should include the names of all affected IT services, configuration items (CIs) and related processes, and complete documentation of the proposed change. |
Change Advisory Board (CAB) | A group of BMC SaaS Operations representatives that advise the change management team about the risk and impact of changes |
Change Implementer | The Change Implementer is BMC SaaS Operations personnel responsible for implementing a change or components of a change. For lesser complex RFCs that do not involve multiple individual tasks, this role can be filled by the Change Owner. |
Change Management | Change Management (CM) is the process of submitting, documenting, reviewing, implementing, testing, and migrating changes. The purpose of CM is to implement changes in the most efficient manner while minimizing the negative impact on users when changes are implemented. |
Change Manager | The Change Manager is the person responsible for managing the Change Management process for a given area. The Change Manager's responsibilities include planning and coordinating all activities required to develop, monitor, and report on the process. There might be multiple Change Managers, such as those managing changes specific to a site or area.
|
Change Owner | The person with overall responsibility for the change |
Change relationship | Identifies the association that a change has with CIs, or with records such as incidents and problems:
|
Change request / Request for Change (RFC) | A formal proposal for a change, an RFC document (online form) describes details of the proposed change. An RFC must be authorized and approved by a customer Change Approver. |
Change Submitter | A Change Submitter is an individual who prepares and submits a change request needed for a change to a customer environment. The Change Submitter may be a customer or someone from the BMC SaaS Operations infrastructure or support teams. |
Change task | A change task may be included in the RFC. The status of tasks can be independent of the status of the parent RFC. Tasks can be staged to be developed in parallel or in sequential order. |
Change window | The agreed-upon deadline within which change can be implemented with minimal impact on services. |
Communication plan | The communication plan, usually in the form of an email, is a document that informs the requesters, implementers, customers, and users about changes being made in their environment. |
Configuration | A data-driven change with no impact on upgrades. Configuration controls the appearance and behavior of an application. For more information, see BMC-Helix-ITSM-customizations-configurations-and-changes. |
Configuration management database (CMDB) | A database that stores CIs throughout their lifecycles. The configuration management system maintains one or more CMDBs, and each CMDB stores CI attributes and their relationships with other CIs. |
Configuration item (CI) | Any component managed by the Change Manager to deliver the service. CIs are under the control of Change Management. CIs can include IT hardware and applications. The Change Manager records information about each CI in a configuration record within the CMDB. Configuration Management maintains the CI information throughout its lifecycle. |
Configuration record | A record that contains details about each CI. Each configuration record documents the life cycle of a single CI. |
Change Approver | The Change Approver is an individual who represents the customer, performs change impact analysis, and authorizes BMC SaaS Operations to carry out a change through their explicit approval. This role is required to ensure an effective collaboration for controlling unauthorized change in a customer’s environments. Change Approvers are responsible for approving all changes to your system although only one individual needs to approve each change for it to advance the change workflow. Approvals are initially communicated via email and for users of the BMC Support portal, in-application notifications are also provided under Approve a Change > My Approvals menu. A Change Submitter may also be a Change Approver. BMC requires that you provide a list of Change Approvers and keep it up to date. You may add or remove individuals from the Change Approver list by submitting a request to the BMC SaaS Service Desk. |
Customization | Changes that involve code changes or nonstandard integration changes. See BMC-Helix-ITSM-customizations-configurations-and-changes for additional details. See also BMC Helix Customization policy. |
Emergency change | A change that must occur outside of an approved change window to restore loss or severe degradation of service, or to prevent an inevitable loss of service. |
Emergency Change Advisory Board (e-CAB) | A subset of the CAB that makes decisions about emergency changes. Membership of the e-CAB can be determined at the time of a meeting, depending on the nature of the change. |
Environmental change log | After the initial environments are live, BMC SaaS Operations personnel gathers customer RFCs and starts the environmental change log and related processes. The log is really a folder of documents that represent the complete software development lifecycle of a customer's implementation. For example, it contains details of all requirements, project plans, and changes. The environmental change log is also the mechanism used by the CAB to track customization RFCs. |
Forward schedule of change (FSC) | A document that lists all approved changes and their planned implementation dates |
Golden image | A golden image is a compressed archive of a system. BMC SaaS Operations has a standard golden image that is used for the provisioning of all new customer environments. |
Governance model | A process that captures BMC SaaS Operations' decisions that are made as the environment is developed, edited, approved, implemented, and retired. It creates roles and assigns specific responsibilities and privileges to users in different departments in these roles. |
Impact | A measure of the effect of an incident, problem, or change on business processes. Impact is often based on how service levels will be affected. Impact and urgency are used to assign priority. |
Implementation plan | A document that describes the steps needed to implement a change, including scope, goals, scheduled activities, and duration |
Post-implementation review (PIR) | A review that occurs after a change or project has been implemented. The PIR determines if the change or project was successful and identifies opportunities for improvement. |
Priority | A category that identifies the relative importance of an incident, problem, or change. Priority is based on impact and urgency, and it identifies required times for actions to be taken. |
Release unit | The portion of a service or IT infrastructure that is released according to the organization's release policy. The unit depends on the service asset or service component types, such as software and hardware. |
Test plan | A document that identifies test items, features to be tested, testing tasks, and the person who will perform each task |
Timing | Identifies the time frame in which a change is to be implemented |
Urgency | A measure of how long it will be until an incident, problem, or change has a significant business impact. For example, a high-impact incident might have low urgency, if the impact will not affect the business until the end of the financial year. Impact and urgency are used to assign priority. |