EVOLUTION OF BPR

What is missing in the Business Process modeling and analysis process?

Posted on the June 23rd, 2008 under BPM, Business Risk by Gregory Yankelovich

It is very common to see a gap analysis as a very first deliverable in most Business Process optimization initiatives, regardless how these initiatives are branded. For that very reason, quality of the result for this exercise can either completely obliterate any chance for this investment to show any return, or give a reasonable opportunity for the initiative to succeed. Yet, many projects allocate a very small proportion of time and resources to this critical stage in the initiative’s life cycle.

To slightly paraphrase Sandy Kemsley (italic is mine)

The core of the BPX community gap analysis exercise is collaboration and collective learning on business scenarios, process lifecycles, change leadership, social responsibility, horizontal and vertical practices, modeling tools, methodologies and a variety of other topics.

I think it is often “assumed” that the “as is” state of the examined process is known and well understood by someone or everyone in the organization. That is often a very expensive assumption. The discovery methodology, commonly used, is similar to the one market researchers use to interview focus groups, which at the best yields statistically representative opinions rather than cognitive knowledge.

Large organizations that are engaged in current SOA initiatives, have great opportunities to significantly improve their chances of success by deployment of Business Process Modeling tools, that can dramatically enhance the quality of the learning process. These tools, often have valuable knowledge extraction methodologies built into their functionality. Sandy reviewed specific pros and cons for many of these tools over time in her blog, which became an invaluable resource for many practitioners.

Smaller companies are often not as motivated to formalize their business processes, or even document them. That makes their efforts, proportionally, even more wasteful, but not as noticeable because of the much smaller scales of their budgets. The size of project or small budgets are not a  good excuse for ignoring good practices, and inexpensive or even free tools. We wrote here before about Tibco Business Design Studio, as just one example of such a tool.

The point I am trying to make is that business process knowledge is a much more valuable commodity than the programming code, used to “enshrine” it in a software application. The reality of project budgets ignores this and the dismal success to failure ratio for these projects illustrate this point.