Headline: Stop Reviewing Technical Details Alone — Every Change Should Start with Business Impact
The Context Problem
One common failing in change management is that the CAB lacks the context needed to make informed, risk-based decisions. The CAB cannot determine whether a change deserves priority over competing requests or whether the maintenance window is appropriate.
Business Context First
COBIT 2019's BAI06 practice recommends evaluating change requests against business case alignment before technical feasibility. Every change request should open with a business impact statement before any technical details appear.
Key questions:
- What business capability does this change affect?
- What happens if we do not make this change?
- What is the blast radius if this change fails?
Creating a Business Service Catalog
A business service catalog links technical components to business capabilities:
|
Business Capability |
Technical Components |
|
Order Processing |
CRM system, payment gateway, inventory DB |
|
Employee Onboarding |
Active Directory, HRIS, email system |
|
Customer Support |
Contact center, knowledge base, ticketing |
Linking Change Management to the CMDB
The CMDB should be the foundation of change impact analysis. When a change is proposed, the system should automatically:
- Identify affected CIs
- Show dependent services
- Assess business impact
- Identify stakeholders
Automating Business Context
Use automation to populate business context:
- Technical impact: Automatically pulled from CMDB
- Business impact: Derived from service relationships
- Stakeholders: Automatically identified from service ownership
Training Change Submitters
Change submitters need to understand what business context to provide:
Training topics:
- How to write business impact statements
- How to identify affected business capabilities
- What information the CAB needs
The Business Impact Statement Template
text
Change: [Brief description of the change]
Business Capability Affected: [What business function or service is impacted?]
Impact if Not Done: [What happens if we don't make this change?]
Blast Radius if Change Fails: [What is the potential business impact if the change fails?]
Business Priority: [High/Medium/Low]
Business Owner: [Who is accountable for the business impact?]
Conclusion
Prioritizing business context in change enablement ensures that changes are evaluated based on business impact, not just technical details. By linking change management to business capabilities, organizations can make better decisions about which changes to approve and prioritize.
Action Items for Your Organization
- Create a business service catalog
- Link change management to the CMDB
- Require business impact statements for all changes
- Train change submitters on business context
- Use automation to populate business context
