IT Led Business Process Improvement?

Business Process Improvement, Process Reengineering or Business Process Management -- by whatever name you call it, it's the same thing -- the systematic and continuous improvement and adoption of processes throughout an organization, aimed at efficiency, flexibility and adaptability. First introduced in the 1990s by Michael Hammer and James Champy, BPI had its time in the limelight, and faded like a fad. Under the new moniker of BPM however, the fad is back, as consulting and software vendors attempt to sell more products and services. BPM has its promises, but I'm a skeptic of its potential, as it aims to do something almost inhumane to people. That hasn't stopped the sales people from calling however.

One such salesperson is Roger Burlton, who seemed to have had his way with CIO Magazine's Meridth Levinson, because her article in the November 1st issue is nothing more than Burlton's sales pitch -- which Levinson backs up with selected evidence from successful CIOs. Burlton's pitch is that BPM initiatives should be led by IT because:

• so much technology is involved
• IT will have a hand in automation, and
• IT has the best vantage point (across business silos).

The reasonable answer of course, is that there is no one approach that will fit all companies. I'll give that in some (rare) organizations, where IT actually has credibility, trust and is treated as an equal partner, they can actually lead BPM initiatives. In most organizations however, this is not the case. A gulf still exists between the IT department and the rest of the organization. Even if the CIO is a business executive who reports to the CEO, the trust hardly ever filters down to the trenches of the organization. In most cases, IT continues to be viewed with suspicion -- and the perception that the department is staffed by technology dweebs with nary an ounce of business blood in their veins is hard to shake. And who can blame the business for having such perceptions? When most projects fail or fall short of expectations, who's at the forefront with that dazed look? IT. Who has to enforce the ever popular security and audit policies within an organization? IT. Who's there every time a damn system fails yet again? IT. The success doesn't matter, unless the IT organization does a good job of marketing themselves. People inevitably always remember the negatives. Let's face, we all like to whine, and IT makes for good fodder, whether they deserve it or not. So why would you ever want to put IT in charge of a major reengineering effort that BPM spells, when the odds of their success are stacked against them?

Then there are the business processes. Business processes are owned by the business organization. Who knows the processes, the levers and the measures? The business. IT doesn't. IT doesn't run the organization. IT is a service provider. Having IT lead BPM initiatives is just as silly as having an external consulting company (such as Process Renewal Group) with no knowledge of your organization's business processes, come in to reengineer those processes. Can you imagine the outcome of such an endeavour? An organization with lighter pockets and that WTF-just-happened look on their faces when the initiative is over. Then they scrap the results and go back to doing things the way they've always done them.

The business needs to lead BPM initiatives. From an organization change management perspective, who better to make the change a success than the very people who needs to accept it? Credibility and trust is already there. Who else should have that frank conversation than the people across the silos, who will have to adapt and change to the reengineered world? Who is responsible for generating the revenues from those very business processes that are changing? The business. The business letting anyone else lead a BPM initiative is abdicating responsibility because it's just too stomach churning to face.

IT is an enabling force -- not a process engineering force. Burlton uses the analogy of IT providing data storage as a service to demonstrate how IT can provide process analysis, modeling, design and automation services. It's a dumb analogy. Storing data on a server is not the same as process engineering. There is a business process in place that leads eventually to data (the what)being stored. That business process not only defines what needs to be stored, but also why -- among many other things. The level of complexity from data storage to business process modeling are vastly different -- and you do actually need to know the processes you're modeling.

In the supporting arguments that Levinson provides via four CIO stories of BPM successes, you will notice one very important thing. While they are CIOs and are responsible for an IT organization, their IT organizations are far different from the traditional IT organizations. Before you start buying into what Levinson and Burlton are selling, ask yourself this simple question: does your IT organization resemble any of the ones described in the article? Now check your answer with your business peers.