But: What is Business Process Automation?
Figure 1 - Standard BPA Results
If Business Process Analysis is the Systems Analyst of the MBA world, then Business Process Automation would be the Systems Engineer of the IT world. I know that makes almost no sense whatsoever.
Some folks might say it (the latter of the two) is the practice of applying technology to execute tasks which normally require direct human involvement.
Some folks might say it is the practice of identifying which human-oriented processes can be handled by suitable application of technology.
Some folks might say it is the practice of applying technology to replace human labor to enable laying off human employees.
Other folks might say it's the culmination of hours and hours of studying to acquire yet another mysterious certification which nobody cares about besides them.
They are all correct. Ding! And they win what? I will tell you what: hours and hours and hours of work.
How is a BPA expert made? What are the necessary ingredients?
- Familiarity with the business on an operational level, from the bottom-most level to the top.
- Familiarity with the business culture, at all levels
- Common sense (okay. I'm just kidding)
- A keen sense of humor (I'm serious about that too)
- A healthy appreciation for caffeine and alcohol
- Solid skills using Microsoft Word, Excel, Outlook, PowerPoint and a web browser
- And, last but not least: an undying desire to stop any meeting, no matter how intense, and no matter who is in attendance, to ask "what the F**K are we doing here?!" (followed by an immediate return to playing with your phone)
You might think I'm joking. I'm not.
Most BPA efforts go off the rails and directly through an orphanage house within a few days of starting the engine. Why? Because they almost always focus on the HOW before the WHY. The WHAT before the WHEN and WHO before the WHERE. Okay, I made those last two up out of thin air. I couldn't mention just two of the W's (or a W and an H, or ughh, never mind).
BPA is really just a 2-stop process:
Step 1 - Analyze the living shit out of the process itself. Do NOT... I repeat DO NOT, start working on the HOW part before you exhaust every angle of making sure the WHY is covered. Is the process sound? Is it as efficient and reliable as it could be?
Step 2 - Go back to step 1. If in the efforts to refine step 1, you do not already trip over the optimal solution to the challenge, you didn't do step 1 properly.
Seriously: Of the last two dozen or so BPA-related projects I've been involved with, or was witness to in the past thirty years, I would say three of them actually followed this rule. This covers everything from small private businesses to municipal, state and federal governments, to multi-billion dollar corporate conglomerates. I've seen projects blow $50 million USD in the first three months before asking if the goals were really correct. That's not an exaggeration. In fact, the one person that did ask, was fired for asking. (no, it wasn't me, which is shocking, I know).
IT professionals are as vulnerable to this tendency as anyone else. Mainly because we are creatures of toy fascination. We like toys. Program code, gadgets, appliances, algorithms, encryption schemes, formulas, you name it. If it involves tinkering and refining, we're all in. A bag of crappy food and some sort of liquified stimulant and we're game-on. But that too often leads directly into the dreaded trap:
A new tool in search of a project. Walking around with a hammer, anxiously seeking out a screw or cotter pin to use it on.
Tools are awesome. But only as awesome as they fit with the task they're being used on.
Coming Soon - BPA Stupidity Part II - the Electric Boogaloo.
No comments:
Post a Comment