Business analysts aren't business analysts anymore. At least, they shouldn't be.
Or maybe it's that they should be, but haven't been. The bottom line is that business analysts should be the folks who analyze the business, helping managers figure out how to make things work better. But as the job's traditional responsibilities have been to determine what software is supposed to do -- what the "requirements" are -- there's no point fighting a vocabulary battle.
[ Also on InfoWorld.com: Get Bob Lewis's continuing IT management wisdom in his Advice Line blog and newsletter. | Find out why running IT as a business is a train wreck waiting to happen. ]
And so, as proposed last week, the new title for true business analysts is "internal business consultant," or IBC. It's the pivotal role in building a next-generation IT organization because it lives on the fuzzy boundary where IT and the rest of the business either work together or at cross-purposes.
Which makes it the role that alters "IT" (another name that has to change, but we'll leave that for another day and another post) from an organization that delivers and runs software to an organization that collaborates with everyone else in the business to make things run better.
New role, new title, new skills -- what are they? Last week's column listed three core concepts and three areas of technique. The core concepts were value (revenue, cost, and/or risk), optimization (fixed cost, incremental cost, cycle time, throughput, quality, and excellence), and the distinction between process and practice (processes clearly describe how to perform each step; practices list the steps but rely on the expertise of the practitioners for performing them).
The techniques were facilitation (getting people to talk with one another, understand what one another are trying to say, and bring these folks into some semblance of consensus), process management (how to manage the process that manages the work, instead of managing the work itself), and culture change (changing the shared attitudes, assumptions, and responses to situations they drive).
That's just the start, though. Here are two more:
IBC technique No. 4: Process improvement frameworks. Just because practices will gain in importance doesn't mean there's no place for process. Quite the opposite -- many areas of practice, especially single-actor practices, will rely on the existence of reliable behind-the-scenes business processes for much of what they have to accomplish.
There will be no substitute for learning enough about each of the four well-developed process improvement disciplines to be able to provide useful guidance. There's danger in doing so because each has, to one extent or another, taken on the trappings of religious sects -- each has, to many of its practitioners, become the answer. That's "the answer" as in "it doesn't matter what the question is."
To avoid this pitfall, memorize a dictum ascribed to the great architect Louis Sullivan and make it your mantra: Form follows function. When it comes to process optimization, function means knowing how the six parameters of optimization (fixed cost, incremental cost, and so on, as listed above) rank in importance. Once you know how they stack up, you'll know which process improvement discipline -- which form -- is best suited to the situation.
Here's a quick guide -- somewhat oversimplified, but not badly so:
- Lean: Lean's goal is to find and eliminate waste. If your top goal is to reduce incremental cost, it's the right choice. Along the way, lean provides techniques that can help improve quality and reduce cycle time as well.
- Six Sigma: Six Sigma has deep roots in two predecessors -- statistical process control and total quality management. Its primary purpose is reducing variability -- in other words, improving quality. Along the way, it provides useful techniques for reducing incremental cost and cycle time.
- Theory of Constraints: ToC's core mission is to improve throughput. Its core method is to find and eliminate bottlenecks. Its techniques are likely to reduce incremental costs and improve quality along the way.
- Process reengineering: Lean, Six Sigma, and Theory of Constraints all rely on incremental process improvement. Process reengineering is more of a rip-and-replace approach. As such, it is optimized for maximizing consultant revenue. As an IBC, what's most important for you to know about process reengineering is to avoid it whenever you can. Incremental process improvement is almost always the superior choice.
IBC technique No. 5: Process characterization. Before you can improve a process or practice, you have to be able to describe it. IBCs should know how to make use of three complementary descriptions: black-box analysis, white-box analysis, and a cheesy but very effective trick.
Black-box analysis
Black-box analysis doesn't care how a business function gets the work done. All it cares about is what the process does. Black-box analysis lists its:
- Inputs: What the function chews on to create its ...
- Outputs: What the function exists to create, along with any by-products. A car is an example of a primary output, management reports are examples of useful (one hopes) by-products.
- Resources: What the business function makes use of in transforming inputs into outputs. The distinction between resources and inputs is that a function operates on inputs to create outputs, but makes use of resources. It's the difference, when baking bread, between flour and yeast (inputs) and a recipe and the oven (resources).
- Constraints: Imposed conditions that limit both how the process operates and ways the process may change. Regulations, license terms, budgets, human frailties, and for that matter, the physical laws of the universe can all constrain a process.
White-box analysis
By contrast, white-box analysis doesn't care what the function is for. It cares about how it works; describing its motor, gears, levers, pulleys, and controls; and how they're hooked together.
Probably the most useful tool in the IBC arsenal for white-box analysis is the Rummler Brache diagram, though most people call these "swim-lane diagrams" because that's what they look like and it's easier to pronounce.
Swim-lane diagrams are flow charts in which each process actor gets a separate row. That's what makes them superior to standard flow charts -- they display both the sequence of actions and who is responsible for each of them.
Cheesy but effective trick
If you're the sort who liked Rodney Dangerfield's approach to business class in "Back to School," this trick is for you. It's a technique you can use to demonstrate how superior your process improvements are when compared to the current state.
What you do is to cram every step and every loop in the current workflow into a single megacomplex swim-lane diagram. The result will look like a plate of spaghetti that would earn you a chef's hat in any Italian restaurant.
That's the current-state description. The future state? You describe it with a layered set of individually simple and straightforward swim lanes, one per case, which means your flowcharts have few if-then branches. Ideally, each has no more than about seven steps on it.
Even if you haven't figured out any actual improvements, the future state will look so much cleaner, everyone will be sure you've streamlined what used to be a mess -- everyone, that is, except the employees on the ground who do the actual work. They'll know nothing has changed.
Just make sure they like you. Otherwise, they might blow your cover.
This story, "How to succeed as IT's new business analyst," was originally published at InfoWorld.com. Read more of Bob Lewis's Advice Line blog on InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.