There are no vacuums in business (unless you’re in janitorial or restoration services). Within every organization, everything is connected – people, processes, technology, facilities, supply chains and more.
But some Business Continuity Plans are created as though the underlying function were a soloist – facing a lonely struggle to recover their precious business process. The probability of a single business process being crippled by a disruption is miniscule. Any disruptive impact (weather, man-made, geological, political, technological) is guaranteed to have a ripple effect through any organization. Yet organizations continue to develop plans in isolation – without regard to the web of organizational dependencies that will surely become apparent when business-as-usual is disrupted.
A clear picture of a Business Process’ or function’s dependencies improves the ability to develop viable BCM strategies and make the right decisions when a business disruption occurs.
Typical “dependencies” include:
- All the Locations where the function/process is performed
- The upstream Business Processes on which the function is dependent
- IT applications critical to the function’s operations
- Vendors who supply goods or services that facilitate the function’s activities
- Internal ‘customers’ (other Business Processes) who rely on the function’s output
- Regulatory requirements under which the function operate
- Specialized equipment or other Resources on which the function relies
- Cyclical and other period Events that may elevate the function’s criticality
By failing to consider the inward and outward dependencies of a Business Process or function, creating a viable Business Continuity Plan hasn’t must of a base to work from. That’s why so many BCP templates focus on loss of the most obvious, high-level dependent assets:where the function occurs (Loss of Building), its Information Management dependence (Loss of Technology), who performs the function (Loss of People), and in some organizations, on what major Supplier(s) the function relies (Loss of Vendor).
Clearly, loss or disruption of those, or any more granular dependency, could trigger the need to take ‘recovery’ action.
For example: The data center may not burn down – but a single server or database could malfunction, causing an Application failure – and disruption of all of the business processes which use it. And while a particular business process might not be directly impacted by that outage, the disruption of an upstream dependent business process which is impacted could have a secondary impact.
But more importantly, understanding the upstream and downstream dependencies of a Business Process or function makes it possible to develop a Business Continuity Plan that can react to any disruption. Because the people who perform the function clearly understand what they are dependent upon (and who is dependent upon them), strategies can be developed to respond to the loss of any critical asset – whether it’s one Application, an individual with specialized skilsl or knowledge, or any other asset.
While you begin to build response strategies for dependencies, you may begin to realize that those strategies can also be effective for overcoming day-to-day operational hurdles. Lights go out for an hour or two? You’ve got a manual process for that. Vendor delivery doesn’t arrive when expected? You’ve planned for that. It’ll take 3 days to get the parts to repair the MICR printer? You’ve got a strategy for that.
Mapping the dependencies of Business Processes or functions has real benefits to offer. Yes it takes time. But it doesn’t take a process engineer to make it happen. Organizations which use dependency mapping in their BCM program find that that acquired knowledge results in better, more viable BCM planning, and can also help improve day-to-day operations.
Nobody works in a vacuum. Why plan as if you did?
