Wednesday, April 9, 2008

Case for Enterprise Risk Management (Enterprise Business Continuity)

Over the several years I have been creating risk management/business continuity plans, I have developed enterprise plans, key business unit plans, and IT-specific plans.

All plans have their place.

But . . .

The only plan that has a chance to succeed when things go bump in the night is an enterprise plan.

In an ideal world, each functional unit will have its own mini-plan. Each mini-plan is complete and has all the components found in the enterprise plan; the difference is that a mini-plan must be escalated if a risk cannot be contained to the specific functional unit covered by the plan.

Best example: If a server fails and InfoTech can get it operational before any service level agreements (SLAs) are violated, then only the InfoTech mini-plan is invoked. If that same server fails and one or more business unit SLAs are missed, the issue is escalated to the next higher level (e.g., facility, campus, enterprise).

Enterprise plans offer several advantages over mini-plans.

First, they identify unit interdependencies.

When thinking of interdependencies think of a spider's web - or the World Wide Web. Points connecting to points connecting to points; rarely is there a point with only one input and no output. Sometimes the dependencies are obvious, e.g., the normal business requirement for InfoTech services, sometimes less obvious, e.g., Shipping and Receiving.

In a "best case" situation, a focused plan will connect from the covered unit only to the functional units which feed it or which are fed by the covered unit. Nothing goes beyond the initial contact.

In techno babble, that's known as a "got'cha."

Second, they provide "benefits of scale."

When business SLAs are missed, sometimes even just in danger, people both inside and outside the organization need to know. That means someone with decent communication skills needs to employ those skills, especially when dealing with The Media Octopus with tentacles labeled "Newspaper," "Electronic," "Financial," "Government," "Regulators," "Customers," "Vendors," and others.

Does equipment need to be replaced or supplemental staffing need to be brought in? Look to vendor management, accounting, shipping/receiving, HR, . . .

To paraphrase John Donne1, no functional unit is an island. All have relationships to others within the organization and many have connection to external organizations - clients, vendors, regulators, lenders, etc.

Enterprise risk management (ERM) is, I think, a better name for what is needed than "business continuity," although that name is certainly valid. "Risk management" seems to present a mental picture of an all-encompassing, holistic effort were "business continuity" apparently seems to some to be limited in scope.

Properly done, ERM and business continuity examine all potential risks to an organization and extend outward not only to vendors but to vendors' vendors; to the financial sector; to main clients' well-being. Even things such as "what if the flight is delayed" are fair game for the planner. While making a flight may seem "out of scope" for an ERM plan, the "action to take in the event of" certainly is within the scope and should be covered by both policy and procedure.

Unlike functional unit plans, everything is "within scope" for an enterprise plan.


1 "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

John Glenn, MBCI, SRP
Enterprise Risk Management/Business Continuity
Planner @

No comments: