As you're thinking about your company and its critical functions, which we'll review following this section, you should keep a rating scale in mind. Later, after you've compiled your list, you can assign a "criticality rating" to each business function. It's important to have an idea of your rating system in mind before you review your business functions so you can spend the appropriate amount of time and energy on mission-critical functions and less time on minor functions. For example, when you sit down with the finance group, you want to keep them focused on defining the mission-critical business functions while listing all business functions that would be needed for business continuation.
You can develop any category system that works for you but as with all rating systems, be sure the categories are clearly defined and that there is a shared understanding of the proper use and scope of each. Here is one commonly used rating system for assessing criticality:
- Category 1: Critical Functions--Mission-Critical
- Category 2: Essential Functions--Vital
- Category 3: Necessary Functions--Important
- Category 4: Desirable Functions--Minor
Obviously, your business continuity plan will focus the most time and resources on analyzing the critical functions first, essential functions second. It's possible you will delay dealing with necessary and desirable functions until later
Mission-critical business processes and functions are those that have the greatest impact on your company's operations and potential for recovery. Almost everyone working in a company has an innate understanding of the mission-critical operations within their department. The key is to gather all that data and develop a comprehensive look at your mission-critical processes and functions from an organizational perspective. What are the processes that must be present for your company to do business? These are the mission-critical functions. One way to get people to focus on the mission-critical functions is to ask (whether through questionnaire, interview, or workshops) what the first three to five things people would do in their department following a business disruption once the emergency or imminent threat of a business disruption subsides. This often gives you the clearest view of the mission-critical business functions in each department.
From an IT perspective, the network, system, or application outage that is mission-critical would cause extreme disruption to the business. Such an outage often has serious legal and financial ramifications. This type of outage may threaten the health, well-being, and safety of individuals (hospital systems come to mind). These systems may require significant efforts to restore and these efforts are almost always disruptive to the rest of the business (in the case that any other parts of the business are actually able to function during such an outage). The tolerance for such an outage, whether from the IT system or the function/process it provides, is very low and the recovery time requirement is often described in terms of hours, not days.
Some business functions may fall somewhere between mission-critical and important, so you may choose to use a middle category that we've labeled "vital" or "essential." How can you distinguish between mission-critical and vital? If you can't, you may not need to use this category. However, you might decide that certain functions are absolutely mission-critical and others are extremely important but should be addressed immediately after the mission-critical functions. Vital functions might include things like payroll, which on the face of it might not be mission-critical in terms of being able to get the business back up and running immediately but which can be vital to the company's ability to function beyond the disaster recovery stage.
From an IT perspective, vital systems might include those that interface with mission-critical systems. Again, this distinction may not be helpful for you. If not, don't try to force your systems into this framework; simply don't use this category. You'll end up with just three categories -- mission-critical, important, and minor. If that works for you, that's fine. If you use this category, your recovery time requirement might be measured in terms of hours or a day or two.
Important business functions and processes won't stop the business from operating in the near-term but they usually have a longer-term impact if they're missing or disabled. When missing, these kinds of functions and processes cause some disruption to the business. They may have some legal or financial ramifications and they may also be related to access across functional units and across business systems.
From an IT perspective, these systems may include e-mail, Internet access, databases, and other business tools that are used in a support function, whether to support business functions or IT functions. If disabled, these systems take a moderate amount of time and effort (as compared to mission-critical) to restore to a fully functioning state. The recovery time requirement for important business processes often is measured in days or weeks.
Minor business processes are often those that have been developed over time to deal with small, recurring issues or functions. They will not be missed in the near-term and certainly not while business operations are being recovered. They will need to be recovered over the longer-term. Some minor business processes may be lost after a significant disruption and in some cases, that's just fine. Many companies develop numerous processes that should at some point be reviewed, revised, and often discarded, but that rarely occurs during normal business operations due to more demanding work. In some sense, a business disruption can be good for those small business functions and processes as they may be reworked or revised or simply pared down after a disruption. You may use the process of performing your BIA to recommend paring down these minor business functions as well, though your time is better spent focusing on the mission-critical and vital elements. You may make notes about which functions and processes could be pared down outside of the BC/DR planning process and hand this off to the appropriate SMEs for later action.
From an IT perspective, these types of system outages cause minor disruptions to the business and they can be easily restored. The recovery time requirement for these types of processes often is measured in weeks or perhaps even months.
Use the following table of contents to navigate to chapter excerpts.
|ABOUT THE BOOK:|
|Business Continuity Planning (BCP) and Disaster Recovery Planning (DRP) are emerging as the next big thing in corporate IT circles. With distributed networks, increasing demands for confidentiality, integrity and availability of data, and the widespread risks to the security of personal, confidential and sensitive data, no organization can afford to ignore the need for disaster planning. Business Continuity & Disaster Recovery for IT Professionals offers complete coverage of the three categories of disaster: natural hazards, human-caused hazards and accidental/technical hazards, as well as extensive disaster planning and readiness checklists for IT infrastructure, enterprise applications, servers and desktops – among other tools. Purchase the book from Syngress Publishing|
|ABOUT THE AUTHOR:|
|Susan Snedaker, Principal Consultant and founder of Virtual Team Consulting, LLC has over 20 years experience working in IT in both technical and executive positions including with Microsoft, Honeywell, and Logical Solutions. Her experience in executive roles at both Keane, Inc. and Apta Software, Inc. provided extensive strategic and operational experience in managing hardware, software and other IT projects involving both small and large teams. As a consultant, she and her team work with companies of all sizes to improve operations, which often entails auditing IT functions and building stronger project management skills, both in the IT department and company-wide. She has developed customized project management training for a number of clients and has taught project management in a variety of settings. Ms. Snedaker holds a Masters degree in Business Administration (MBA) and a Bachelors degree in Management. She is a Microsoft Certified Systems Engineer (MCSE), a Microsoft Certified Trainer (MCT), and has a certificate in Advanced Project Management from Stanford University.|
This was first published in January 2008