Read Blog Post

Read Blog Post

Contributed on April 20, 2012

2.8K

787

Just Do It: Part I: The Fear

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.