Home > IT Service Management > Considerations for IT Service Continuity
Considerations for IT Service Continuity
User Rating: / 12
PoorBest 
Written by Philip L Yuson   

How do you go about determining or even starting an IT Service Continuity Plan? One of the difficulties of formulating a plan is to determine which applications are critical to your organization. The first place to begin is in your Service Level Agreements (SLA). Your SLA defines what is critical to your organization.

First thing to do is to determine the impact of an application to your SLA. The impact could be something measurable like cost or something not measurable like reputation. Whatever your criteria, your SLA will be able to help you determine the priorities.

One of the pitfalls in coming up with your ITSCM plan is one may look at the SLA and determine that just because an application is mentioned in it, that application is critical. Some SLA's do not even mention applications, instead mention business targets. These business targets often rely on the applications supporting specific business processes.

In this case, the application becomes more critical because it impacts business targets.

Formulating an ITSCM Plan

There are many ways of coming up with an ITSCM plan but here's some high level points that I would suggest. 

  1. Do an inventory of critical business processes based on the SLA.
  2. Prioritize these processes. You need to define a criteria to do this. As I mentioned, it can be cost - not only penalties, but also resources needed, time, effort, etc. Or it can be intangibles like company reputation or goodwill.
  3. Once you have prioritize your business processes, identify the applications that support these processes. Some processes may have more than one application supporting it. In this case, you will need to prioritize which application is more critical. The application is not only the programs but it should include the hardware, network and other infrastructure components.
  4. Do a risk assessment to determine acceptable risk level. If it will cost a company say, $1,000 should the application become unavailable, but it will cost $100,000 to make it robust, then the expense to make it robust outweighs the risk. Or if it will cost the company $1,000,000 for an application to become unavailable and it will cost another $1,000,000 to make it robust - but the probability of the application becoming unavailable is practically nil, then a decision needs to be made if the cost is acceptable or not.
  5. Once the applications had been prioritize, come up with a plan on how to ensure that your SLAs are met. Not all outages need to be resolved by adding more hardware. Perhaps you can have a plan to revert back to manual process. Maybe you can look at activities to prevent outages. Perhaps buying some software or additional equipment may help minimize the risk.
  6. Once the plan has been drawn up, you need to follow through with the plan. This assumes you already have management buy in.
  7. When you have implemented your plan, make sure to test it. When you test, you can either limit the scope of testing, say one component only, or you can do an end-to-end test. Applications today are very complicated. A lot of these interact with other applications. So do not treat your applications as silos. Make sure you consider the interfaces to your applications when you test.
  8. Update your plan regularly.

 

 
Copyright: © 2017 Philip Yuson