Change Enablement Across the Service Value Chain and Its Interfaces
Where it sits in the value chain
Change enablement is not confined to one value chain activity. It contributes most visibly to deliver and support (executing and authorizing changes), but it also supports engage (understanding demand and stakeholder impact), design and transition (approving and scheduling transitions into live service), obtain/build (changes to components and supplier arrangements), plan (portfolio and capacity decisions shaping the change pipeline) and improve (changes arising from improvement initiatives). A question that pins the practice to a single activity - usually design and transition - is a common distractor.
Interfaces to know
- Incident management: emergency changes to restore service; failed changes frequently appear as incidents.
- Problem management: known errors and root-cause fixes become changes; problem management supplies assessment input.
- Service request management: the trigger for many standard changes.
- Service configuration management: CI and relationship data underpin impact assessment and closure updates.
- Deployment management / release: a change may require deployment, but is not the same thing.
- Risk, information security, supplier, project and portfolio management: all supply constraints or assessment inputs.
- Continual improvement: registers and improves the change process itself.
Traps
Watch for answers implying change enablement owns deployment, owns the CMDB, or is responsible for resolving incidents. It coordinates and authorizes; other practices execute. Also beware of answers that treat the practice as a governance committee rather than a workflow embedded in each value stream - the flow should be as light as the risk allows.
Rule of thumb: map every interface by asking "what does this practice give change enablement, and what does change enablement give back?"