Change Management (ITIL) is the controlled process of introducing changes to IT services and infrastructure to minimize risk and ensure business continuity. It ensures changes are evaluated, authorized, implemented and reviewed with clear accountability.

Goal: Enable beneficial changes while minimizing disruption and ensuring traceability and compliance.

• Standard Change — Pre-authorized, low-risk, well-documented (e.g., password reset workflow, routine patch for noncritical systems).
• Normal Change — Requires assessment and approval (RFC → CAB review). Can be planned or emergency-initiated as normal later.
• Emergency Change — Urgent change to restore service or prevent severe impact (e.g., security patch for active exploit). Often fast-tracked and retrospectively reviewed.
• Major Change / Project Change — Large scope changes requiring program-level oversight, scheduling, testing and possibly blackout windows.

ServiceNow typically supports these types via the Change table with attributes like change_type, risk_score, state and change_model.

Typical lifecycle stages:

1. RFC (Request for Change) creation: Requester submits RFC with business justification, impacted CIs (from CMDB), proposed schedule, and rollback plan.
2. Assessment: Change manager and technical SMEs assess risk, impact and required approvals.
3. Approval (CAB / Emergency CAB): Authorized approvers or CAB vote to approve or reject.
4. Scheduling & Implementation: Implementers carry out change within approved window.
5. Validation & Review: Post-implementation validation and closure; Post Implementation Review (PIR) for failed/major changes.

Key roles

• Change Requester — raises RFC with context and justification.
• Change Manager — coordinates assessment, schedules, CAB meetings, and governance.
• Change Implementer — technical owner who performs the implementation.
• Change Approver / CAB — group of stakeholders who approve or reject normal changes.
• Service Owner / CI Owner — provides technical approval and impact input.

Change models codify approvals, tasks and checks for recurring change types. Typical models:

• Standard change model: Auto-approve with defined checks and runbook tasks.
• Minor/Normal change model: Requires peer review, automated risk scoring and CAB approval if threshold met.
• Emergency change model: Fast-track approvals (E-CAB) and mandatory retrospective PIR.

In ServiceNow use Change Models + Change Tasks + Flow Designer to automate approvals, create implementation tasks and notify stakeholders. Use Change Advisory Board (CAB) calendars and scheduled meetings for governance.

Automated risk scoring helps decide approvals and routing. A simple risk model:

Risk Score = Impact (1-5) * Likelihood (1-5) * Business Criticality Weight
Example:
Impact = 4, Likelihood = 3, Criticality Weight = 2 => Risk Score = 24
Thresholds:
  - 1-10 Low (auto-approve)
  - 11-20 Medium (requires manager approval)
  - 21+ High (CAB approval required)
                        

Implement risk scoring in ServiceNow via Business Rules or Flow Designer actions to set risk_score and automatically route for approval.

• Change Request Form: Fields: short_description, description, ci (lookup to CMDB), change_type, planned_start, planned_end, risk_score, rollback_plan, test_plan, implementation_tasks, approvers.
• Automated CAB invite & calendar: Use scheduled jobs and CAB email templates; surface high-risk candidate RFCs for CAB agenda.
• Change Tasks & Runbooks: Use change_task records for each implementer (database-driven), linked to RFC.
• Approval Workflows: Use Flow Designer to manage approval flows including dynamic approvers (CI owner, service owner).
• PIR & Post-Change Analysis: Auto-create PIR tasks for high-risk or failed changes and link to Problem Records if needed.

Track these KPIs to measure change effectiveness and risk control:

<?php
// Example: compute change success and emergency rate from array
function compute_change_kpis(array $changes) {
    $total = count($changes);
    $successful = 0;
    $emergency = 0;
    $failed_causing_incidents = 0;
    $total_lead_minutes = 0;
    foreach($changes as $c) {
        if(!empty($c['status']) && $c['status'] === 'Successful') $successful++;
        if(!empty($c['change_type']) && strtolower($c['change_type']) === 'emergency') $emergency++;
        if(!empty($c['failed']) && !empty($c['caused_incident'])) $failed_causing_incidents++;
        if(!empty($c['created_at']) && !empty($c['implemented_at'])) {
            $total_lead_minutes += (strtotime($c['implemented_at']) - strtotime($c['created_at']))/60;
        }
    }
    $success_pct = $total ? ($successful/$total)*100 : null;
    $emergency_pct = $total ? ($emergency/$total)*100 : null;
    $avg_lead_minutes = $total ? ($total_lead_minutes/$total) : null;
    return [
        'total'=>$total,
        'success_pct'=>round($success_pct,2),
        'emergency_pct'=>round($emergency_pct,2),
        'avg_lead_minutes'=>round($avg_lead_minutes,2),
        'failed_causing_incidents'=>$failed_causing_incidents
    ];
}
?>

Use SQL aggregations for production: GROUP BY change_type, state and computed flags; persist monthly aggregates for MSR and QBR visualization.

The CAB is the forum that reviews and approves significant changes. Best practices:

• Different CABs for different scopes: weekly CAB, emergency CAB (E-CAB), technical CAB for infrastructure-heavy changes and business CAB for services with high business impact.
• Agenda & pre-read: Publish RFC summaries and risk scores 48 hours before CAB to reduce meeting time.
• Use decision records: Capture votes, responsible approvers, and reasons in the change record.
• Automate invitations and minutes: Generate CAB agenda and automated invites from approved RFCs.

ServiceNow tip: Use the CAB workspace and Change Calendar to avoid scheduling conflicts and visualize change windows.

A good playbook makes change predictable. Key sections of a change playbook:

• Pre-change checklist: Backups verified, test plan executed, stakeholders notified, maintenance window reserved.
• Implementation steps: Step-by-step tasks for implementers with exact commands or runbook scripts.
• Rollback plan: Conditions to trigger rollback and exact rollback steps.
• Validation steps: Health checks and smoke tests to confirm success.
• Post-change tasks: Monitoring, cleanup, PIR scheduling, and documentation update.

Example: Database schema upgrade playbook includes: backup snapshot, stop app cluster, apply migration, run data sanity tests, start cluster, monitor errors for 30 mins, rollback on error threshold.

• Overly bureaucratic approvals: Use risk-based approval policies and change models to reduce delays.
• Poor CMDB quality: Inaccurate CI ownership leads to wrong approvers or missed impact analysis — run discovery & reconciliation.
• Not enforcing rollback plans: Always require a rollback plan for non-standard changes.
• Lack of post-implementation review: Skip PIRs and you won't learn from failures.
• Poor communication: Always notify business stakeholders and downstream teams about schedules and outages.

Case Study 1 — Bank: Preventing Production Outage

Context: A scheduled database patch caused intermittent outages in production. Root cause: skipped validation and outdated CMDB data. Remedy: Re-enforced pre-change testing, updated CMDB discovery, implemented automated pre-checks in Flow Designer. Result: 0 production outages from scheduled patches in next 6 months.

Case Study 2 — Telecom: Reducing Emergency Changes

Context: Frequent emergency changes were impacting SLAs. Approach: Introduced stricter monitoring, automated patch windows, and risk-based change models. Outcome: Emergency change rate fell by 60% and change success rate improved.

Case Study 3 — SaaS Company: Faster Time-to-Market

Context: Slow change approval cycles delayed feature releases. Approach: Implemented pre-approved standard change models for CI provisioning and automated approvals for low-risk changes. Outcome: Release cycle shortened by 30% while maintaining low failure rate.

Change reporting should feed monthly and quarterly reviews. Key inclusions:

• Monthly: total changes, success rate, emergency changes, failed changes & incidents due to change, trend charts (MoM).
• Quarterly: change backlog trends, major failed changes (PIR findings), automation gains (change models used), SLA impact and roadmap for process improvements.
• Dashboard widgets: change calendar, high-risk change list, change lead times, average approval time, CAB attendance and decisions.

• Change Policy: Define change categories, approval thresholds, roles, and required documentation.
• Change Calendar & blackout windows: Define maintenance windows and blackout periods for business-critical services.
• Automation & standardization: Use change models for repeatable changes and enforce runbook usage.
• Audit & compliance: Keep an immutable audit trail of change approvals, implementation notes and PIRs.
• Continuous improvement: Quarterly review of change metrics and top failure causes; update playbooks accordingly.

If you'd like, I can:

• Convert the sample KPI computations into SQL queries for your ticket/change tables.
• Add ServiceNow Flow Designer examples (XML or pseudo flow) and change model configuration snippets.
• Create an exportable PIR template (DOCX/PDF) and a change request form template you can import into ServiceNow.
• Build a change management dashboard example (Chart.js) and embed it in this page using your real data.

Pick one and I will extend this page accordingly — e.g., provide the SQL templates or Flow Designer pseudo-code next.