2 Replies Latest reply on Jul 18, 2017 10:58 AM by Nicolas Roome

    Emergency Change Request Approval Workflow

    Keith McNaught
      Share This:

      Good morning,

       

      As we prepare to bring in FootPrints and get things setup. I was wondering how other people handle the workflow of an Emergency Change as far as the approvers go.

       

      Are the approvals left out of the workflow, allowing the ticket to be generated and not held up awaiting multiple approvers?

       

      Are the approvals added in as a requirement for ticket closure rather then part of the ticket creation process?

       

      We currently have a very manual process, Emergency Changes are discuss as part of a small ECAB (Usually who ever can be found on the Change Management Team). If it happens to be outside of the core business hours the Emergency Changes are performed, and the RFC is submitted after the fact. With the ability to create the automated workflows in FootPrints, I'm curious as to how others in the industry handle the Emergency Change requests.

        • 1. Re: Emergency Change Request Approval Workflow

          In our environment we have 4 types of changes:

           

          - Routine

          - Normal

          - Expedited

          - Emergency

           

          Routine Changes:

               Well documented changes that occur pretty much everyday.  (hardware swaps, adding users to groups, etc. - basically grunt work around the environment)

           

                    - Self Review (noting the proceedures and assets involved)

                    - SCO Review ( ensuring the description matches the proceedure attached)

                    - Member of the CRB Approves outside of the bi-weekly window

           

          Normal Changes:

               Common changes but do not have the standard documentation / proceedures.  These follow our typical approval processes

           

                    - Self Review ( ensure that all CI's / Proceedures are attached )

                    - Security and Oversight Approval (ensure there are no compliance concerns)

                    - CRB review (2x's a week the CRB gets together and reviews the change, implementer needs to be on hand to discuss the change and answer any questions)

           

          Expedited Changes:

               These are changes that cannot wait for a CRB meeting and this needs to be done very quickly.  While we have more steps, everyone is typically aware these are coming and brought up to speed on the phone.  these get pushed usually with in 15-20 min.

           

                    - Self Review ( ensure that all CI's / Proceedures are attached )

                    - Manager Approval (to show that this has been discussed with at least one member of management and they are aware of the situation )

                    - Security and Oversight Approval ( again to ensure there are no compliance concerns)

                    - Member of the CRB Approves outside of the bi-weekly review.

           

          Emergency Changes:

               These types of changes are only done during a system down event.  The work is performed and system restored and then the ticket is created so everyone can see what was done and we have documentation.  These are a pretty big deal and get a lot of scrutiny so we do not get too many of these.

           

                    - Self Review

                    - Manager Approval

                    - Security and Oversight (this part is painful and help keeps the abuse of the Emergency Change process down)

                    - CRB review (since this is a ticket that is created 'after the fact' it will go to the normal CRB meeting and discussed)

           

           

          These actually all follow one workflow with 4 potential paths depending on what is selected.

          1 of 1 people found this helpful
          • 2. Re: Emergency Change Request Approval Workflow
            Nicolas Roome

            First question is it depends on your definition of an emergency change is.

             

            There are typically 2 definitions (neither is right or wrong, but personally I prefer the first option)

             

            1. Emergency changes are any changes which cannot follow the normal process (typically due to time constraints). This can include production system outages, or changes that cannot wait for a CAB meeting in a week due to late entry of the change or short lead time.

             

            2. Emergency changes are reserved exclusively for production system outages, and changes which cannot wait on the normal process are considered 'Expedited'.

             

            The reason I prefer the first option is because you still prioritize changes like you would any other ticket. So your combination of change type and priority (impact/urgency) will basically tell you whether it's a system down or a short lead time change.

             

            For emergency changes due to production system outages, it is perfectly acceptable to fight the fire first, and then file the paperwork after.

            1 of 1 people found this helpful