Change: The ITIL definition of a change is ‘the addition, modification or removal of anything that could have an effect on IT services’.
Change Management is involved in 3 different activities –
1. Approving a Change submitted is one – more of a routine work as there are frequent changes to CI’s
2. Another one is granting approval to a New Service or a Package even before it is built based on the Project Charter Submitted by Service Portfolio Management – Basically Change Management Reviews a Critical output of Service Portfolio Management and gives a Go or No Go based on the inputs provided
3. Last one if approving the Permanent Fixes projected as an input from Problem Management Process
Change Management supports the three types of service changes ITIL describes —
Standard, emergency and normal. The change type determines which state model is invoked and the change process that must be followed.
Standard change
A standard change is a pre-authorized change that is low risk, relatively common and follows a specified procedure or work instruction.
A standard change is one that is frequently implemented, has repeatable implementation steps, and has a proven history of success. As Standard changes are pre-approved, they follow a stream lined process in which group level or peer approval and CAB authorization steps are not required.
Approved standard change requests can be predefined in a catalog of templates to make accessing and requesting a standard change more efficient. This ability also enables the Change Management team to control the changes that are authorized as standard.
Emergency change
A change that must be implemented as soon as possible, for example to resolve a major incident or implement a security patch. It is of such a high priority that it bypasses group and peer review and approval and goes straight to the Authorization state for approval by the CAB approval group.
Emergency changes cover the following types of emergencies:
1. Fix on fail or retroactive situations where the impact to service has already been experienced.
2. Fail or fail situations where the impact to service is imminent if action is not taken.
These changes do not follow the complete life cycle of a normal change due to the speed with which they must be authorized. Therefore, they progress directly to the Authorize state for approval from the CAB Approval group.
Normal change
Any service change that is not a standard change or an emergency change.
Normal change requests follow a prescriptive process which requires two levels of approval before being implemented, reviewed, and closed. These changes require a full range of assessments and authorizations such as peer or technical approval, change management, and Change Advisory Board (CAB) authorization, to ensure completeness, accuracy, and the least possible disruption to service. These changes are most often scheduled outside of defined change blackout windows or during defined maintenance windows. The normal type is used to implement beneficial change for any change to a service that is not a standard or emergency change.
Change Management is involved in 3 different activities –
1. Approving a Change submitted is one – more of a routine work as there are frequent changes to CI’s
2. Another one is granting approval to a New Service or a Package even before it is built based on the Project Charter Submitted by Service Portfolio Management – Basically Change Management Reviews a Critical output of Service Portfolio Management and gives a Go or No Go based on the inputs provided
3. Last one if approving the Permanent Fixes projected as an input from Problem Management Process
Change Management supports the three types of service changes ITIL describes —
Standard, emergency and normal. The change type determines which state model is invoked and the change process that must be followed.
Standard change
A standard change is a pre-authorized change that is low risk, relatively common and follows a specified procedure or work instruction.
A standard change is one that is frequently implemented, has repeatable implementation steps, and has a proven history of success. As Standard changes are pre-approved, they follow a stream lined process in which group level or peer approval and CAB authorization steps are not required.
Approved standard change requests can be predefined in a catalog of templates to make accessing and requesting a standard change more efficient. This ability also enables the Change Management team to control the changes that are authorized as standard.
Emergency change
A change that must be implemented as soon as possible, for example to resolve a major incident or implement a security patch. It is of such a high priority that it bypasses group and peer review and approval and goes straight to the Authorization state for approval by the CAB approval group.
Emergency changes cover the following types of emergencies:
1. Fix on fail or retroactive situations where the impact to service has already been experienced.
2. Fail or fail situations where the impact to service is imminent if action is not taken.
These changes do not follow the complete life cycle of a normal change due to the speed with which they must be authorized. Therefore, they progress directly to the Authorize state for approval from the CAB Approval group.
Normal change
Any service change that is not a standard change or an emergency change.
Normal change requests follow a prescriptive process which requires two levels of approval before being implemented, reviewed, and closed. These changes require a full range of assessments and authorizations such as peer or technical approval, change management, and Change Advisory Board (CAB) authorization, to ensure completeness, accuracy, and the least possible disruption to service. These changes are most often scheduled outside of defined change blackout windows or during defined maintenance windows. The normal type is used to implement beneficial change for any change to a service that is not a standard or emergency change.
This comment has been removed by a blog administrator.
ReplyDelete