A disaster will never ask for permission nor knock at an imaginary door. Disasters come in no time. Any hypothetical organization henceforth needs a disaster plan ready for any eventuality. In as much as most disaster plans focus on internet security, there is also need to give weight to physical security in case of a disaster; though in actual sense, one might find it tasking in trying to manage physical security.Cisco networks have displayed a disaster plan manual on their website. They have a hierarchy of activities that stipulate the order of events in case of a disaster. According to Cisco, there is a long process of looking at the cause of the problem rather than the solution. A disaster plan needs to be precise and manageable in the shortest time possible. This will enable quick recovery process.According to Leo A. Wrobel, there are essential in formations that the people coordinating the recovery process need to know beforehand. Such information include among others, the type of all equipments and their model number, all softwares attached, purpose of the software, version and license number. With this information at hand at the event of a disaster striking, will trigger easy decisions at the moment or lead to a clearer step to be taken. Looking at Cisco disaster plan, the first activity is identifying and analyzing the disaster risks. Such a step is not essential as it can be done later; or rather it might make the recovery process slow, hence causing more trouble. There is need for the panel in charge of attending to the disaster to find all other useful third party equipments. Wrobel sticks to the idea that it is very important for a company to keep in touch with vendors who always have the inner and outer structure of their equipments and services. This becomes cost friendly especially at the event of an earlier negotiation.
University of Toronto computing and networking services puts the idea of having an alternative running system in position as the main system is yet to be repaired. This saves the organization. Another essential component in a disaster plan is calling the executive management committee almost immediately after the problem strikes. Looking at the Cisco networking disaster plan, the executive committee is called long after the disaster strikes, something that might put earlier decisions at a risk of being rejected or casing harm to the company.
In an organization such as bank, in which customers are able to carry out online transactions, I would implement the Cisco disaster plan in a different way. To avoid malfunctioning that would cost the bank lots of losses, I would first of all shut or rather kill the LAN system. My second move would be to give a call to my vendors so that they can either act on the disaster or give vital information on their equipments in the event of the eventuality.As an operations manager, I would take it my responsibility to monitor the progress of the recovery process. My idea would be to put the recovery process my priority rather than the cause of the disaster, which can actually be done later. After a successful system recovery, I would carry out a damage assessment then go on to have the system activated. In conclusion, not all disasters can be resolved with any disaster plan. Specific plans go for certain types of disasters. For instance, a failure in a banking system cannot be recovered using the same procedure as to that one of a learning institution. Thus, there is need to scrutinize a disaster plan prior to using it to check whether it's convenient or not. Big companies need to enter into partial recovery planning software maintenance contracts with their vendors to reduce cost of disaster recovery.