Last year, ebizQ Forum managing editor Peter Schooff asked his readers and contributors if processes should "be fixed" before migrating them to a BPM platform. At first I thought he was asking if processes should be rendered incapable of reproducing, but then I realized the question was going somewhere else entirely. My bad.
It's been difficult for me to understand the mindset that leads to this question. To me, it's like asking if you should cook a meal before leaving for the restaurant. But I've been thinking about the way process automation has evolved, and I'm developing a clearer understanding of what might lead somebody to think they should go through the pain and effort of process improvement before implementing BPM.
Time was when automating a manual process was an expensive affair, involving analysts, programmers, project managers, database administrators, and a cast of others. The advent of SOX and the persistent tightening of the regulatory tourniquet only contributed to the problem. As a result, a substantial amount of resources and funds were tied up in these efforts. Technically naive managers (rightly) feared the expense and complexity of the projects, and suspected that, left to themselves, the techies would simply run amok.
It didn't help that a huge number of these development programs failed completely. And so a variety of methodologies were unleashed on the world, all designed to ensure that IT stayed true to the requirements of the business.
And yet, development projects continued to fail. There are two primary reasons for that:» Business users rarely had a good grasp of their own processes, so transmitting requirements was challenging at best.
» Even where users understood their processes well, they were rarely able to envision how such processes might be enhanced, improved, or even transformed by technology.
It's not surprising, then, that this depressing cycle of expense and failure would give rise to a culture in which you would try everything and anything before automating. But it doesn't have to be that way.
Next time I'll talk about how BPM helps close this sorry chapter, leading to a new cycle of innovation and success.
PS: If you've got some time on Thursday, April 26, please tune in to DMRadio to hear "Cloud Computing and the Evolution of Business Process Management", a discussion featuring your humble blogger, Forrester analyst Clay Richardson, and others.