Removing risks
In the last chapter of this thread, we introduced the concept of risk management and started to look at services by asking three questions
1)What could wrong
2)What would be the impact of it going wrong
3)What is the likelihood of it going wrong
Hopefully from this, you would have developed your hit list of risks and are ready to start to consider what to do about them. To start you off, ITIL offers the following as some options:
1)Do nothing – I know it sounds both obvious and also somewhat defeatist, but doing nothing is always an option. Why? Because based on the risk, probability and cost of putting contingency in place, sometimes doing nothing is the most logical and cost effective option
2)Manual Workarounds – Most systems (and this is another area where SME’s may have an advantage) can survive a period of downtime with processes being done the “old fasion way”. Manual workaround’s normally include a set of written processes and sometimes paper based backup copies of data that allow the users to continue “in the spirit” of the computer system by mimicking the key processes on paper. Once the system is returned, the backlog is processes from the written records as if it is realtime data processing
3)Reciprocal Arrangements – This concept is a little bit left field but if successful can give you a low cost solution to a major system headache. In simple terms it involves finding another local company running the same software as yourself and entering into an agreement whereby if one of your systems fails, your “reciprocal arrangement” partner lends you their hardware at their site for an agreed period of time to load your data to keep on working whilst yours is fixed. To make it work, it needs regular data backups, the technical resource to implement the switch and a regular test routine but for major systems that are expensive to provide a back-up environment for, it can be a workable option
4)VBF (Vital Business Functionality) – This option is generally used for mid range systems where the nature of the failure means that a level of recovery is possible, but not a full system restoration. Understanding the VBF basically means agreeing with the users what is the “minimum” pieces of functionality are needed to keep the business going. For a supply chain system it may be seeing stock levels and sales so orders could be placed manually or for a finance system it may be the ability to raise purchase orders. All other systems requirements are secondary and not part of the restoration strategy. In the event of a system failure, the focus is purely on restoring the VBF aspects of the system
The four options listed above should be considered alongside any other creative idea’s that are generated by your continuity team. When tackling your hit list. Once completed, you will have the starting point of an IS Continuity strategy!
23rd March 2009
Click here for details of our FREE business healthcheck and join the rest of the companies using IT Service Management.
Providing Affordable IT Management to SME's