sfhdi presents: numara software - change & approval management
DESCRIPTION
SFHDI Meeting - presentation by Numara SoftwareTRANSCRIPT
David CoffeySenior Solutions Engineer
Numara Software
Change & Approval Management
Why is it important to have an integrated change solution?
Change Management – The Heart of the IT Universe
Change Management –
The Heart of the IT universe?
• The heart is critical for survival.
• It should be maintained with healthy habits
• Impacts many systems within the body
Change Management is the same!!!
Notes
• This Presentation is Intended as a Guideline Only• Numerous ways to implement Change Management• Suggests Good Practice Methodology
• Not All Inclusive• Different organizations may opt for different
steps/statuses/etc.• Process Perspective not Tool Perspective
• Process Must be in Place in Order to Properly Leverage any Change Management Software Solution
What is Change Management?
• Definitions:• Wiki - a structured approach to
shifting/transitioning individuals, teams, and organizations from a current state to a desired future state.
• ITIL - (Change) The addition, modification or removal of anything that could have an effect on IT Services.
• ITIL - The primary objective of Change Management is to enable beneficial Changes to be made, with minimum disruption to IT Services
Change Management Objective
•To ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to controlled IT infrastructure, in order to minimize the number and impact of any related incidents caused by the change, upon service.
Reactive ChangeReactive: • 60 to 80 percent of failures in the IT infrastructure come from changes introduced by the IT department — many of which are not approved or authorized.
So…Change Management shouldn’t be an after-thought!
Don’t Be Naive• So it is negligent – or possibly just naïve – when many
software vendors separate “the heart” out of Service Support and imply that Change Management is not needed or necessary.
• This is analogous to saying that the body does not need a circulatory system – or is something that you can “tack on” later.
• Having an integrated Change Management is crucial for a healthy IT organization.
Why Change Management?
Change Management can:• Ensure standardized methods, processes and procedures are
used for all changes, • Facilitate efficient and prompt handling of all changes• Maintain the proper balance between the need for change and
the potential detrimental impact of changes.
Change Management acts as the control function for the CMDB. Without it, the CMDB will become inaccurate
quickly!
ITIL V3 Service Delivery Wheel
Change Management resides within the
‘Service Transition’ arrow of the wheel.
Typical Sources for Requests for Change
Change Management
Where to Start?• Start by defining ‘What is a Change’?
• Each company may view this differently• Commonly, Change Requests are filed for any modifications or
Status Changes to any item tracked in the CMDB, including:• Servers
• This includes Planned Reboots!• Middleware • Services such as IIS• New Servers/Services
• Network Components• Applications - License Adds/Removes• Databases• Storage Arrays• Desktops• Monitoring Tools• Anticipated Workloads
What is NOT a Change?• Sometimes an easier approach
• Remaining artifacts will by default, require RFC’s (Requests for Change)
• Minor modifications to desktops (Unless tracked in CMDB)• Adds/subtracts to users• Password Resets• Office Moves (unless locations are tracked as part of CMDB)• Phone/monitor/keyboard changes• Automatic (Machine Controlled) alterations/updates
Check Your Environment• Is anything in place now?
• Activities that can be leveraged• Focus on Repeat-ability of existing practices
• Interview existing users/actors in existing activities• Distribute the results of these interviews as ‘Findings’ to help
enlist support• Remember: Just because you’ve always done it this way
doesn’t mean it’s the right way• Use this as an opportunity to create much needed cultural
change
Strategy• Assign Owner
• Change Manager Role• Acts as the CAB for ‘Standard Changes’• Should review Changes for accuracy and compliance with policy as
first step• Is the ‘Accountable’ party for the Change Process
• Additional staff as needed based on volume• Place Governance within a “Controls” Environment
• Security• Audit
• Avoid • Placement within Infrastructure or other support groups
• No impetus to enforce process• Fox in the Hen House syndrome
Strategy• Develop Policy
• Enforceable ‘laws’ that Change Manager can use as indicator of compliance
• Develop Process Steps• Map to RACI for clear Responsibility, Accountability• Also indicates where Consultation is required
• Consultation typically implies Approval• Shows which parties should be Informed of upcoming Change• Map to Swim-lane Diagram
• Select CAB Members• Fixed Members could include:
• Security• Infrastructure Support• Operations• Customer Representative(s)• Network
Strategy• RFC’s Content
• Dates/Times• Type of Change• Goal of Change• Impacted CI’s (What is actually being changed?)• Business Justification• Description (Details of Change)• Plans
• Back-Out Plan• Implementation Plan• Testing Plan • Communication Plan
• Resources
Strategy• RFC Content - Scope Assessment
• Scope of Change is Typically Considered to be Based on 2 factors
• Risk• Impact
• Typical Scope Terminology Includes:• Major – For High Risk and Impacts• Significant – For Substantive Risks and Impacts• Minor – For Low Risk and Impacts
Strategy• Scope Assessment ContinuedRISK Ability to Back-Out of a ChangeHigh Impossible or Unproven
Medium Difficult or Time-consuming
Low Direct or Straightforward
IMPACT Impingement upon Systems or Services During or After the Change
High Critical (Revenue Stream) Systems or Services Unavailable or Possibly Rendered Non-Functional
Medium Important Systems or Services Unavailable or Possibly Rendered Non-Functional
Low Non-Critical or Redundant Systems or Services Unavailable or Possibly Rendered Non Functional
Strategy• Determine Change Meeting Schedule
• Change Management Facilitates• Bring up for discussion:
• Changes that are fully Reviewed• Offline Reviewers• May include Technical Review Board Members
• Changes “Pended” in previous CAB session• Change Calendar showing Scheduled, Approved Changes 2 weeks out• Changes must be represented to be Approved by the CAB
• Identify Emergency CAB Member(s)• Often Executive Role• Consider a Back-Up or Proxy
StrategyDetermine Change Type
Standard Changes•Highly Repeatable
•No Impact or Outage – VERY Low Risk
•Proven Successful (Zero Failures in X number of attempts!)
•Presented to CAB for Permission to Become Standard
•Minimal Review/Approval (Effectively Pre-Approved)
Normal Changes•Full Review Process (Sometimes Including CAB)
•Adheres to Lead Time Requirements
•Changes will have Higher Potential for Impact
•Driven by Incident Management
Emergency Changes•For Break-Fix Only!
•Driven by Incident Management
•Not Intended to Cover for Poor Planning
Strategy Other Change Types to Consider
Unscheduled Changes• For Changes that do not
Meet Lead Time Requirements
• Approved by Emergency CAB
• Enables Clear Reporting of Poorly Planned Changes
• Differentiates True Emergency Work from Poor Planning
• Becomes a Goal to Reduce their Frequency and Volume
Latent Changes• For Break-fix Work Done ‘On
the Fly’
• Done in the Heat of an Outage where the ’Fix’ won’t cause Additional downtime
• Filed ‘After the Fact’ as a Documentation/Paper Trail
• Should always be Tied to an Incident Record
• Never to be Used if Adequate Time for an Emergency Change
StrategyChange Statuses
Draft • Still Being Built
Submitted • Ready for Review – Begins Review/Approval Cycle
In Review • May be a Separate ‘Review’ Status for Each Review Step
Reviewed• Indicates all ‘Approvals’ have taken place (Typically
Offline)• Precondition for Appear on CAB Agenda
Pending• Supply Pending reason• Typically used for additional clarification• Not ‘Intended’ to be halted
On Hold• Change is still ‘valid’ but may be timed inappropriately• An ‘Intentional’ halt to the Change
Rejected • Cannot be performed – A ‘Dead’ Status
Withdrawn • Opted not to perform due to changes in conditions
Approved • Only CAB, E-Cab or Change Manager
Strategy
Completion/Closure Codes – Allows for Capture Results After Closure Status
Success • Change was implemented successfully AND achieved goal
Successwith Issues
• Change was implemented and achieved its goal but encountered issues during implementation
Failure• Change did NOT achieve goal• Even if implemented successfully
• Patch to correct application errors
Backed Out • Change caused an issue and had to be removed
Withdrawn • For Changes that were Withdrawn during the process
Cultural Acceptance• If starting from a largely ‘Blank Slate’ this will be your
biggest hurdle!• Even attempts to make the existing process more ‘formal’ can be
viewed with scorn by some groups/individuals• Enlist ‘Debunkers’ as Reviewers
• Brings them into the process• Can become strongest advocates
• Do you have Executive Support?• Absolutely necessary for success and acceptance• Debunkers will use Executives to skirt process
• Consider CMDB!• Very difficult to Scope Change Management without it• Oversized Scope can make acceptance more difficult
Planning• Who can Review and How Many Reviewers?
• Different for each change• Change Manager should perform initial review
• Who can Reject?• May Vary by Change Type and Scope• Does 1 detractor cancel (Reject) the Change?
• Determine Processes• At which points are Reviews/Approvals necessary?• What criteria triggers the Review/Approval?
• If SOX Compliance is a concern• All Approvals may be Required• One ‘No’ Vote Could Become the ‘I Told You So’ Vote from an
Audit Perspective
Planning• Determine Lead Times
• Minimum of 3 weeks for Major Changes• At least 2 weeks for Significant Changes• 1 Week for Minor• “Standard” Changes typically have a low lead time requirement• Changes that do not meet lead times are ‘Unscheduled’
• Develop “Appeals Process”• For Changes that do not comply with Lead Times• Typically an ‘Unscheduled’ Change• Leverage Emergency CAB for this Process
Operation• Stay Consistent
• Flexing of rules will lead to violations
• Take Attendance at CAB Meetings• Develop Reporting
• Demonstrate• Number of Changes Processed• Number of Successes• Number of Failures• Number Backed-Out• Number of Emergencies• Failed Changes by Implementation Team
Operation
• Perform Post-Mortems (Post Implementation Review)• Target Failures and Successes• Lessons Learned
• Develop CIP (Continuous Improvement Plan)• Observe weaknesses in process• Use Lessons Learned• Leverage Reporting
• Be ‘Diplomatically Intolerant”• Don’t let violations of policy go un-responded• Stress importance of Change Process
Critical Success Factors
Summary• Change is often complex – but it doesn’t have to be.
• The greatest ROI an organization can have with the automation and implementation of an effective Service Desk solution is in the area of seamlessly integrated Change Management.
• Change Management is more than an after-thought, it is the end goal and…
The Heart of the IT universe!
Questions?
Thank You For Attending