What it is (plain English)
A controlled way to modify anything that could impact an IT service — updating a server, deploying an application, swapping network gear. Each change gets assessed for risk, approved by the right people, scheduled to avoid collisions, and reviewed afterward. The goal isn't bureaucracy; it's making beneficial changes with minimum disruption.
Problems it solves
- Outages caused by changes nobody knew about or assessed.
- Two teams changing related systems at the same time and breaking each other.
- No record of what changed when something starts misbehaving ("what changed last night?").
- Approvals happening in email threads with no audit trail.
What must exist first
Platform Core Setup is the hard prerequisite. CMDB Foundation is strongly recommended first — risk and impact assessment are far more meaningful when you know what a change touches and what depends on it — but Change Management can start with minimal or immature CI data and mature the CMDB alongside it.
What the customer needs to provide
- Your current approval reality: who signs off on changes today, however informal — and who should.
- Risk appetite decisions: which kinds of changes are routine enough to pre-approve (standard changes) vs. needing review.
- Maintenance windows and blackout periods that matter to the business (month-end close, retail seasons).
- Whether a Change Advisory Board (CAB) exists or is wanted, and who sits on it.
- For dev teams: which deployment pipelines/tools should raise changes automatically.
Where it can go next
DevOps Change Velocity automates change records from CI/CD pipelines so developer changes flow through governance without slowing down. Change success rates feed back into Problem Management when changes cause incidents.