Business Continuity Disaster Recovery COOP Crisis Management John Glenn CRP MBCI
Bridging silos
Why enterprise?
John Glenn, MBCI
Certified Business Continuity Planner
Since InfoTech was perceived as "the" critical function of every organization, it had to be protected.
If InfoTech was up and running, all other operations would be up and running and everything was right with the world.
Over time it was discovered that even if InfoTech's machines were dealing data, the business functions for which the data was being dealt had to be around to use it.
Horror stories abound in the Business Continuity profession about InfoTech fully functioning while there was no one around to massage the data.
Having come to the conclusion that there is more to protect than just InfoTech - and make no mistake about it, InfoTech IS a critical component of almost all competitive organizations - planners began to look at the profit centers.
No center is an island
Paraphrasing a snippet of John Donne's famous phrase i, "No man is an island," no profit center is an island.
In all organizations - for profit business, government, non-profit, charity, even the family - no one function or person is totally isolated.
Everyone and every business function (profit center) has multiple dependencies. Often these dependencies daisy chain to others and on to still others.
A typical organization's interdependencies, if drawn out, will appear as complex as a spider's web.
No doubt that the profit center is the reason the organization exists, but without external (to the profit center) resources, its purpose will not be successfully, efficiently, and economically accomplished, if at all.
Unfortunately, for many organizations, the Business Continuity mentality moved from "save InfoTech and all is well" to "save the profit center (and InfoTech, of course) and all is well."
The interdependencies, even if all functional units had independent plans, were hidden.
Enter the enterprise plan.
The enterprise plan is at once a functional unit effort and a cross-unit exercise.
Follow the trail
Enterprise planners are one of the few people in any organization who (should) know the workings of the operation from beginning to end.
Enterprise planning forces planners to identify the beginning of a process - typically outside the organization engaging the planner - and to follow it to its end, also typically outside of the planner's organization.
The enterprise planner becomes a "bridge" between, and across, functional unit "silos." Few others at less than the executive management level have a similar comprehensive view of the organization.
As the process is tracked to a functional unit, the enterprise planner takes time out to become a unit planner. Here a unit-focused plan is developed to assure that the unit will be able to meet its Service Level Agreements (SLAs) with its internal and external "clients."
Each unit "mini-plan" will be designed to enjoy the advantages of the organization's scale (e.g. by having access to support functions such as HR, Purchasing, Vendor Management, etc.) as well as being incorporated into the organization's plan (or next highest level plan, depending on the organizational structure).
What, then, does this specific functional unit need to accomplish its tasks? What resources - both in and out of the organization - are required?
A couple of examples.
Vendors The functional unit depends on vendors for products and services. An airline, for example, depends on food server caterers to provide meals on international flights. If something prevents the caterer from meeting its SLA to the airline, flights are cancelled, revenue is lost, and the airline's reputation suffers, at least for awhile.
HR There is a requirement for supplemental professional staffing. Normally this function is handled by Human Resources, but it's flu season and there is only one over-worked person in the office. There is no way the person can handle all the work necessary to deal with vendors, interview prospects, confirm citizenship, and the myriad things required even for "temps."
InfoTech could have been cited as a functional unit resource, but everyone knows the impact on an organization when - not if - InfoTech services fail.
About external dependencies
External dependencies, and there are many, may seem out of the planner's control. Perhaps they are, but they should be considered risks which can, in most cases, be mitigated.
What falls into the "external dependencies" category?
Financial sources banks, lenders, stock and bond markets
Government Local, state/provincial, federal and all the agencies which might impact the organization such as regulators, planners, law enforcement, roads and highways, licensing
Vendors of all type, including utilities
Consider lenders to be "money vendors" and treat them as other vendor.
Which means?
Which means that the planner will assure any lending programs are secure, that if the lender fails, other resources are identified and prepared to step in.
All vendors should provide the organization with their own (sanitized) Business Continuity plan. The depth and scope of the plan will vary by the business - a Mom-n-Pop operation probably can't be expected to have as hefty a plan as Bank of America, but there should be a plan.
Organization management must decide how to handle vendor risks: will it look for replacement vendors, contract with alternate (back-up) vendors, encourage and support favored vendors to enhance their Business Continuity program, increase the stock of vendor products?
Identifying dependencies, especially external dependencies, sometimes is best done with a flow chart or block diagram
Typically, then considering a vendor's product, the planner looks at the vendor's plan, assuming there is a plan. If it is satisfactory, end of story.
Unfortunately there is a gapping hole the planner failed to consider.
Look again at the illustration. What sits between the vendor and Shipping/Receiving?
While there, look at what fills the gap between Shipping/Receiving and the client.
- Transportation
Depending on the vendor's location, transportation could be multi-modal and pass through multiple carriers, each carrier and each mode constituting a risk. If the vendor product comes from outside the country, add export and import controls to the risk mix.
Internal dependencies: easier to manage, but . . .
Internal dependencies should - operative word is "should" - be easier to manage, and unless the internal dependency tracks back to an external dependency, usually are easier to control.
Control of internal dependencies, such as production, will be based on each functional unit's own mini-Business Continuity plan.
Each functional unit's plan must consider all the factors considered in the profit center's plan. Resource plans also must consider how the resource may impact the profit center if only indirectly.
As an example, InfoTech prints checks for Accounts Payable. An InfoTech glitch prevents a check from being printed and delivered to Finance for signature and approval, then on to Accounts Payable for payment to the vendor.
Since the check is delayed, the vendor payment is delayed. In response, the vendor could - albeit not necessarily will - withhold additional shipments until the check is received - which delays production which delays shipment to clients which delays payment to the organization, which - a closed loop. Not a likely scenario, but a possible scenario all the same.
In addition to related-by-task functional units, internal dependencies also include shared functions such as Communications, Facilities, Finance, HR, Legal, and Purchasing.
Unlike external risks, the organization can implement means to avoid or mitigate internal risks - or occasionally decide to absorb a risk.
In the case of the check, the way to assure vendor payment is to have what used to be known as a "counter check" available, secured in a safe preferably off site, which can be signed and counter-signed by two of four "approved" executives. (Four? Certainly - primary and alternate for all positions; just like all other Business Continuity response functions.)
Bottom line
The bottom line for all the above is that with any plan less than an enterprise plan, relationships - particularly secondary relationship - can easily be missed, and that missed relationship, with its own risks, could bring the organization's operation to an expensive halt.
i "All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated...As therefore the bell that rings to a sermon, calls not upon the preacher only, but upon the congregation to come: so this bell calls us all: but how much more me, who am brought so near the door by this sickness....No man is an island, entire of itself...any man's death diminishes me, because I am involved in mankind; and therefore never send to know for whom the bell tolls; it tolls for thee."
John Donne (1572-1631), "Devotions Upon Emergent Occasions, Meditation XVII"
Return to text
John Glenn, MBCI, has been helping organizations of all types avoid or mitigate risks to their operations since 1994. Comments about this article, or others at http://JohnGlennMBCI.com/ may be sent to Planner @ JohnGlennMBCI. com.
