Your SlideShare is downloading. ×
Numara change & approval mgmt
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Numara change & approval mgmt

209
views

Published on

SFHDI November Meeting presentation by Numara Software

SFHDI November Meeting presentation by Numara Software

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
209
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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
  • 30. Critical Success Factors
  • 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