We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Ground-Floor BPM

Scott Menter

Just Do It: Part I: The Fear

Vote 0 Votes

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.

1 Comment

| Leave a comment

I await Part 2 with interest

I do see many customers trying to fix the as-is instead of trying to rip it all up and focus on optimizing the to-be.

Like you say many people working in the process are too involved to give a detached view and suggestions. Crowdsourcing (internal and external) can be a powerful aid in that case to get the best suggestions

Twitter @souvikbonnerjee

Leave a comment

Scott covers ground-level BPM issues of interest to enterprise users who are tasked to do more with less while improving business processes.

Scott Menter

E. Scott Menter is the VP of Business Solutions for BP Logix, a provider of business process management (BPM) solutions to corporate, non-profit, and government organizations. In addition to technology leadership positions in financial services and higher education, Scott also spent over a decade leading his own identity management software firm. Contact Scott at Scott.Menter@bplogix.com
or http://twitter.com/ESMatBPL.

Recently Commented On

Recent Webinars

    Monthly Archives