Use Cases - Business Continuity Planning

Business and Service Continuity plans ensure the availabilty and performance of a given service is maintained at sufficient levels in case of disaster.

The scope of Service Continuity Management includes:

1. Performing Business Impact Analysis to quantify the impact of service unavailability to the service provider and service consumers.

2. Developing service continuity strategies and integrating them into the business continuity management strategy, if relevant. This should include elements of risk-mitigation measures as well as the selection of appropriate and comprehensive recovery options.

3. Developing and managing service continuity plans and providing a clear interface to business continuity plans, if relevant.

4. Performing exercises and testing the service continuity plans invocation in case of disaster.

In ASM - You can create a Business Continuity Plan Document (Request) that will both invoke and propose plans. These can be set to the services to which they apply and then will in turn, invoke the correct Service Continuity plan based on the details. This will also work in reverse. Below are some examples of this configuration.

Summary Steps for Implementing Business Continuity Planning

1. System Administration Tasks

   • Create Request screen Sets for Business Continuity Plan and Service Continuity Plan

   • Create CMDB Item Types for Business Continuity Plan and Service Continuity Plan

2. Screen Designer Tasks: Add fields to your new screens starting on the CMDB Items, then add the same fields to your request screens ("CP_" = Capacity Planning). Some Suggestions are:

   • CP_Recovery Risk (DD listing all anticipated Risks)

   • CP_Budget (Single Select for CI Type = Budget)

   • CP_Current Plan (Single Select CI for CI Type = Business or Service Continuity Plan)

   • CP_Designation Name (For proposing new plans - what will the name be - text/String field)

   • CP_Invoke a Plan (Check Box)

   • CP_Propose a Plan (Check Box

   • CP_Plan Owner (Single Search to Person table)

   • CP_RPO (DD with established RPO values)

   • CP_RTO (DD with established RTO values)

   • CP_Recovery Strategy - Overall (Memo Field)

   • CP_Recovery Strategy - Initial (Memo Field)

   • CP_Recovery Team (Single Search to IPK or Workflow Group)

   • CP_Recovery Team Dependencies (Memo Field)

   • CP_Recovery Team Responsibility(Memo Field)

   • CP_Expected Response Time SLA (Single Lookup to Service Level Agreements)

   • CP_Return to Operations Strategy (Memo Field)

   • CP_Triggering Incident (Single value lookup to Call)

   An example of the screen configuration can be found here:

https://docs.alemba.com/asm/setup-and-configure-asm/designing-configuring-your-system/configuring-screens/dynamic-screens#one-screen-multiple-processesdocs.alemba.com

1. Workflow Administration Tasks: Build a workflow for each screen set according to your own processes. Below is an example of the workflow:

To communicate and Notify when plans have been enacted

https://docs.alemba.com/asm/use-asm/using-asm-core/the-bulletin-board/managing-bulletinsdocs.alemba.com

See Also

https://docs.alemba.com/asm/use-asm/using-asm-core/managing-your-cmdb/managing-your-service-portfolio/managing-service-actionsdocs.alemba.com

https://docs.alemba.com/asm/setup-and-configure-asm/designing-configuring-your-system/workflow-template-administrationdocs.alemba.com

https://docs.alemba.com/asm/setup-and-configure-asm/designing-configuring-your-system/configuring-screens/building-screens-in-asm-designerdocs.alemba.com