ITIL 4 Change Enablement flashcards
ITIL 4 Change Enablement · Build recall with a focused review session.
32 cards. Read the term and the definition here. The deck at the top of this page is optional.
- Change
- The addition, modification or removal of anything that could have a direct or indirect effect on services; the scope includes documentation, processes, roles, suppliers and data as well as technology.
- Change enablement purpose
- To maximize the number of successful service and product changes by ensuring that risks are properly assessed, authorizing changes to proceed, and managing the change schedule.
- Change schedule
- A calendar of planned changes and their dates, used to plan work, avoid collisions between changes, communicate planned changes to users, and assign resources.
- Unauthorized change
- A change implemented without the authorization its change model requires; it is a significant source of risk and is tracked as a control metric.
- Change enablement components
- The practice rests on three elements: change models, change authority, and the change schedule, also called the change calendar.
- Change enablement scope
- Any component that could affect services: hardware, software, cloud services, documentation, processes, roles, suppliers and data, across all service value chain activities.
- Standard change
- A pre-authorized, low-risk, well-understood and repeatable change performed under a documented procedure, needing no new authorization decision each time it is used.
- Normal change
- A change assessed and authorized through a change model; the assessed risk level sets the depth of assessment and which change authority decides.
- Emergency change
- A change that must be implemented as soon as possible, for example to restore service after a major incident or apply a security fix, using a pre-defined emergency authority.
- Change model
- A repeatable, predefined approach for a type or category of change, specifying triggers, steps, roles, timescales, authorization points and escalation paths.
- Risk-based categorization
- Placing each change into a risk tier based on assessed impact, complexity, novelty and dependencies; the tier determines the required authority and assessment depth.
- Change risk factors
- Impact on users and services, complexity, number of affected configuration items, novelty, regulatory or security exposure, timing, and dependencies on other changes.
- Change authority
- The person or group accountable for authorizing a change; it may be a named role, a team, or a change advisory board constituted for a defined scope.
- Change advisory board
- A formally constituted group that assesses and authorizes changes within a defined scope; ITIL 4 does not require every change to be reviewed by one.
- Delegated change authority
- Authorization responsibility passed to another role or team, such as an emergency authority or regional manager; the delegation must be documented and bounded.
- Change assessment inputs
- Risk and impact analysis, expected benefit, urgency, test evidence, capacity and resource needs, dependencies, compliance obligations and rollback capability.
- Approval decision options
- The change authority may authorize, authorize with conditions, defer, reject, or request further information; the decision and conditions are recorded in the change record.
- Separation of duties in change
- For high-risk changes the person authorizing should differ from the person implementing, so accountability and technical execution are not held by one individual.
- Change registration
- Recording the change with description, scope, justification, requestor, affected configuration items, applicable change model, risk assessment and planned dates.
- Change scheduling
- Entering the change in the change calendar after checking collisions with other changes, change freeze periods, business cycles and resource availability.
- Change authorization step
- The change authority reviews the assessment and records a decision; only authorized changes progress to build, test and deployment.
- Change closure
- Verifying the intended outcome was achieved, updating the configuration management database and documentation, closing the record, and capturing lessons learned.
- Post-implementation review
- A review after a significant, failed, emergency or unauthorized change that verifies outcomes, explains deviations and records corrective and improvement actions.
- Change and incident interface
- Emergency changes restore service after major incidents, while incidents caused by changes feed back into change assessment and continual improvement.
- Change and release interface
- Change enablement authorizes the change; release and deployment management build, test and deploy it; the practices are distinct but tightly coordinated.
- Change and configuration interface
- Change records are linked to configuration items, and the configuration management database is updated as part of change closure.
- Standard change via service request
- Standard changes are typically triggered through the service request management practice, using a pre-authorized model without a new authorization decision.
- Change enablement in value chain
- The practice primarily supports design and transition and obtain/build, and contributes to plan, engage, deliver and support, and improve activities.
- Change success rate
- The proportion of changes implemented without causing an incident, outage or unplanned rollback; a core measure of change enablement effectiveness.
- Percentage of unauthorized changes
- The share of changes made without the required authorization; a high value indicates the change model is too heavy or poorly communicated.
- Change lead time
- The elapsed time from change registration to implementation; long authorization waits reveal bottlenecks in the change value stream.
- Organizational change management for changes
- Addressing stakeholder engagement, communication, training and readiness so people adopt a change; it complements technical risk and authorization controls.