A CIO’s guide to guiding business change

In the 1970s and ’80s, IT was the recognized driver of business change, albeit under the moniker “data processing,” followed by “management information systems,” followed by “information systems.”

Having automated the daylights out of general accounting, IT’s programmers and their friendly supplicants — business managers under constant pressure to cut costs — attacked business processes with glee to automate the daylights out of them.

The fun lasted until Joseph Juran invented the so-called “internal customer” and IT’s leadership role in helping the enterprise and everyone in it be more effective evaporated.

Instead, IT, in its role as “supplier,” sent out its business analyst emissaries to find out what these internal customers wanted from the products they were buying from IT.

That’s when we all fell headlong into perdition.

Hear me out: Business analysts in old-school, industrial-age, internal-customer-focused IT organizations asked business managers what their requirements were — what, that is, they needed an application to do.

Old-school, industrial-age business managers tried hard to provide useful answers, even though to their ears the question sounded a lot like “Explain the roles of dark matter and dark energy in keeping the universe from flying apart.”

You can see the problem: Business managers weren’t supposed to be experts in what software can do. The question they wanted to answer, if only the business analyst would have asked it, was, “How do you want your part of the business to run differently and better?” followed by “Would you like some help figuring that out?”

IT’s failure to ask the right questions led to its sad transition from business change leader to the dispiriting supplier-to-internal-customer perspective that continues to distort our industry.

It also led to the rise of business process optimization methodologies that promised business managers a route to making their part of the business run differently and better — without having to involve IT.

Sure, business managers, encouraged by business process optimization “belts” and supported by a bunch of spreadsheets that business users create when the IT they need isn’t the IT they have, can improve the business processes they follow.

But not as well as they can improve them when IT is integrated into business process optimization.

How? Start with a clear picture of what the leading business process optimization methodologies are for. Then, and only then, can you improve on them.

Making sense of process optimization methodologies

Four methodologies have come to dominate business process optimization efforts: Lean, Six Sigma, Theory of Constraints, and Business Process Reengineering. To succeed in today’s digital world, each should be second nature to IT’s business analysts.

Regrettably, however, these methodologies have become competing schools of thought (pick mine!) that evolved into religions (mine is better than yours!). It’s about as sensible as arguing about which works better, a screwdriver, a pliers, a soldering iron, or a lathe.

And you wonder why we consultants answer so many questions with, “It depends.”

When it comes to supporting business change, the “it depends answer” amounts to choosing the most suitable methodology, not the methodology the business analyst has the darkest belt in.

But on the other hand, the idea of having to earn belts of varying hue or their equivalent levels of expertise in several of these methodologies, just so you can choose the one that best fits a situation, might strike you as too intimidating to bother with. Picking one to use in all situations, and living with its limitations, is understandably tempting.

If adding to your belt collection isn’t high on your priority list, here’s what you need to know to limit your hold-your-pants-up apparel to suspenders, leaving the black belts to specialists you bring in for the job once you’ve decided which methodology fits your situation best.

Before you can be in a position to choose, keep in mind the six dimensions of process optimization: Fixed cost, incremental cost, cycle time, throughput, quality, and excellence (for a refresher, take a quick scan at “The hard truth about IT process success.”) You need to keep these center stage, because: You can only optimize around no more than three of them; the ones you choose have tradeoffs; and each methodology is designed to optimize different process dimensions.

One at a time:

Lean

Lean is Henry Ford by way of Toyota. Lean’s core focus is shrinking waste, which, when you boil it all down, means reducing incremental cost. Lean can deliver other benefits as well, like improving quality and reducing cycle time, but only insofar as they don’t impinge on waste reduction.

Lean’s proponents will be quick to point out that it emphasizes continuous improvement, too. And rightly so. Just keep in mind that Lean equates improvement to less waste.

If waste is your problem, Lean is just the ticket for you.

Six Sigma

Six Sigma is the heir to total quality management. Its focus is reducing variance, which it accomplishes by identifying and addressing the root causes of variability — the reasons process outputs fail to be identical and don’t meet the specifications.

Six Sigma’s focus, then, is on improving quality. To the extent defective outputs are discarded or funneled back into the process for correction, Six Sigma can, as a fringe benefit, reduce incremental cost, too.

But at its core, Six Sigma is your choice if quality is what matters most to you. Otherwise, you might find it disappointing.

Theory of Constraints

Theory of Constraints is the best process optimization methodology nobody’s ever heard of. That’s unfortunate.

Invented by former physicist Eliyahu Goldratt, ToC assumes insufficient throughput is your problem, and that your process has bottlenecks (constraints) that limit it. Speed up or eliminate process bottlenecks and you increase throughput — capacity, that is — and reduce cycle time in the bargain.

If a symptom of a business process’s shortcomings is that it can’t keep up with demand, look to Theory of Constraints for help.

And while it isn’t part of ToC’s official doctrine, you can apply the fundamental ToC loop — find bottleneck, fix bottleneck, rinse-and-repeat — to whichever process optimization goal you decide is most important. It doesn’t have to be a capacity bottleneck.

Business Process Reengineering

Michael Hammer’s and James Champy’s Reengineering the Corporation was the book that focused business leaders on the importance of well-designed processes. The focal point for Business Process Reengineering is that the right place to start is a blank sheet of paper.

So where Lean, Six Sigma, and Theory of Constraints look for the few bad process steps that cause the most mischief and go about fixing them so as to reduce waste, defects, or bottlenecks, BPR’s primary impact seems to be maximizing consultant billing hours.

Which isn’t entirely fair — there are situations where BPR is your only choice, for example when you’re in-sourcing a previously outsourced business process.

But of the four dominant process optimization methodologies, BPR is the riskiest.

Take the fifth

While Lean, Six Sigma, ToC, and BPR are the major business process optimization methodologies of choice, IT groups that want to lead business process improvement have another alternative available to them: To offer the process flows built into commercial applications as the logical places to start.

Software is an opinion. Commercial business applications are opinions about how a business process should flow. And while these opinions aren’t always a great fit, they’re usually a useful place to start.

And while starting with an application’s built-in processes makes both initial integration and ongoing maintenance easier for IT, this isn’t just a replay of the old, tired, plain-vanilla versus chocolate-sprinkles argument that so often derails application implementations.

The problem with arguing about ice cream varieties was … is … that they’re arguments about whether IT or “the business” gets its way.

But as there’s no such thing as an IT project, arguing about which flavor of software to use shouldn’t be allowed.

Starting with the built-in process? Yes, this is, as a happy fringe benefit, closer to accepting more vanilla-ish software for IT to maintain. But vanilla-ism isn’t the point. Effective processes are the point.

Going with the application vendor’s process design opinion has a business fringe benefit, too: Nobody has to design it.

And a second: It’s a workable place to start applying Lean, Six Sigma, or ToC if it isn’t good enough out of the box.