Monday, November 16, 2009

ERM-BC-COOP: Software vs. Brainware


I was just looking at a LinkedIn sub-group (a/k/a SIG) invitation list from a group to which I belong.

Many of the Special Interest Group (SIG) names included software types - not necessarily products (e.g., Oracle) but functions (e.g., ERP, or Enterprise Resource Planning).

While Enterprise Risk Management - Business Continuity (COOP) practitioners have a wealth of software available, from the high end applications to simple word processor templates, most experienced practitioners I know depend not on limited-functionality, fill-in-the-blanks, force-a-square-peg-into-a-round-hole application (or template).

We depend not on software, but brainware.

Software is OK to collect and store information.

Software is good for updating existing information, albeit it is a tad risky that there will be a temptation to only update what is stored rather than going out into the real world to confirm that the changes about to be made are the ONLY changes that need to be made.

Brainware and software are mutually compatible PROVIDING that brainware is superior to the bits-and-bytes application.

The problem for many organizations is that they honestly believe that software can replace brainware; that the organization can engage a tyro or second an already overworked administrative assistant (nee' secretary) to create a plan to save the organization when an interruption to "business as usual" occurs.

Understand, I am NOT disparaging secretaries and I certainly don't want to suggest that a secretary, overworked or not, cannot become a competent - even superior - risk management practitioner; only that to do the job correctly, professionally, the person needs guidance - mentoring - and an understanding that risk management is worthwhile.

At the same time, any organization that delegates risk management to a person with no background in the field shouts to the world that senior management either fails to understand the process and its value, or cares not a whit for the process.

Over the several years I have been doing risk management I have created list after list after list of threats. Each list is longer than the previous list.

Why? Simple. As I work in the field and as I associate with other practitioners, I realize there are risks I failed to previously perceive.

Mind, I usually am ahead of the curve. Planes into tall buildings? Covered that long before 9-11. Am I a seer able to presage the disaster? Hardly.

What I am is open-eyed and a reader of history.

Planes routinely land short of runways; sometimes on top of homes or, in my neighborhood, on the flat roofs of Publix supermarkets; why Publix and not Winn-Dixie I have no idea. In 1945, a US Army Air Corps bomber crashed into the Empire State Building; it had flown off course and too low in a fog.

On 9-11 then, aircraft smashing into the World Trade Center towers should not have come as a total surprise, there was precedent; the deliberate murder of innocents by Moslem terrorists, perhaps that was a surprise (as was Pearl Harbor - an event for which the U.S. apparently also had ample warning).

The financial meltdown also was predictable. It happens about once every 20 to 30 years and usually for the same reason - greed. Could it have been prevented? Probably. But prevented or not, the risk management practitioner, using brainware, would have been aware of the probability and prepared his, or her, client to withstand the "downturn."

Certainly risks can be built into software applications.

But, as I wrote earlier, I have been doing risk management for a bit more than a baker's dozen years and I still have the catch-all words "ubiquitous other" at the end of the list. "Ubiquitous other" is the threat that, so far, has escaped my attention.

My list is long and it gets longer as additional - I'm not sure that "new" is accurate - threats are identified.

I realize that I don't know all the threats to "business as usual" and I long ago learned that a risk management program needs input from everyone - from the janitor, a very "key" person, to the most senior executive (who, in some cases, is one and the same). Everyone has his or her unique perspective on the organization and that person's role in the organization; likewise each person has his or her own personal priorities that must be considered.

Bottom line: A risk management program cannot, if it is to be successful, be created in a vacuum.

I use software everyday in my work. I am heavily dependent on it.

Still, if need be, I can pick up a pencil (and sharpen it with my handy pocket knife) and scribble notes on scraps of paper for later "input" into software.

What I must have is brainware; the ability to think (both inside and outside the box, off the wall, and any other cliche' that comes to mind), to examine ALL the possibilities and ALL the ways to avoid or mitigate the threats, including "but not limited to" as the contract weasel words state, personnel (or personal) awareness.

Software might suggest things, and software might store things, but it takes brainware to create, sustain, and exercise a viable risk management program.

To this scrivener's mind, brainware trumps software every time.

John Glenn, MBCI
Enterprise Risk Management
Hollywood/Fort Lauderdale Florida


No comments: