Numara change & approval mgmt
Download as PPT, PDF0 likes428 views
The document discusses the importance of integrated change management for IT organizations. It outlines key aspects of establishing an effective change management process, including defining what constitutes a change, developing policies and procedures, determining review and approval processes, tracking change requests and statuses, and addressing cultural acceptance. The primary objectives are to ensure standardized and efficient handling of all changes while minimizing disruptions to IT services.
Numara change & approval mgmt
- 1. David Coffey Senior Solutions Engineer Numara Software Change & Approval Management Why is it important to have an integrated change solution?
- 2. Change Management – The Heart of the IT Universe
- 3. 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!!!
- 4. 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
- 5. 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
- 6. 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.
- 7. Reactive Change Reactive: 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!
- 8. 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.
- 9. 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!
- 10. ITIL V3 Service Delivery Wheel Change Management resides within the ‘Service Transition’ arrow of the wheel.
- 11. Typical Sources for Requests for Change Change Management
- 12. 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
- 13. 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
- 14. 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
- 15. 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
- 16. 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
- 17. 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
- 18. 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
- 19. Strategy Scope Assessment Continued RISK Ability to Back-Out of a Change High 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
- 20. 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
- 21. Strategy Determine 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
- 22. 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
- 23. Strategy Change 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
- 24. Strategy Completion/Closure Codes – Allows for Capture Results After Closure Status Success Change was implemented successfully AND achieved goal Success with 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
- 25. 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
- 26. 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
- 27. 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
- 28. 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
- 29. 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
- 31. 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!
- 32. Questions? Thank You For Attending