Home > Adaptive Case Management > Links Aug 2010

Links Aug 2010

Some say that ACM is just BPM except with unstructured processes. That is like saying starvation is like eating, except without any food.

While doing a review of the tweet-jam coverage, it hit me that many people want so much to categorize all work as being process oriented, that when they see work that does not fit that mold, they invoke something called an “unstructured process”.  It is fine to talk about unstructured (or unpredictable processes) but you should not think that an unstructured process acts in any way like a structured one. You can’t simulate.  You can’t measure performance.  You can’t do activity based costing.  You can’t even assess whether it is correct or not.  An unstructured process is a non-process with respect to any process tools you might have.  If you mindset is that you have to describe every work situation as a process, then of course the unstructured process is the description of there not being any predefined process — but all the benefit that can be gained from a BPM approach, is gained on processes that are predictable, and are structured.  While it is true that “starvation” might be considered a kind of cuisine, it is the one cuisine for which you have no need of a cook, no need of a kitchen, or anything else that might normally go with a cuisine.  Starvation is a non-cuisine, in the same way that ACM is a non-process way of supporting work.   (Now I am just waiting for the clever pundit who will say that ACM is starving for process.  Some people don’t get analogies.  But I take this step knowingly.)

I am surprised at how often some people take offense when I point out the limitations of BPM.  It is almost as if these people have a presupposition that BPM must handle all kinds of work.  I have been accused of unfairly criticizing the field of BPM.  Those who have taken the time to understand my point know that is simply not true.  I have repeatedly reconfirmed that BPM is good some things, and that those things are very important.  However, any approach that is based on the idea that a process can be expressed separately from the situation, that a process can be defined and used multiple times, will never be suitable for unpredictable processes.  Saying this is not an insult to BPM at all.  Saying that my car can not drive across the ocean is not an insult to the car at all — it was never designed to do that, and the same with BPM.  As a result I really don’t understand the insistence that BPM represents all work support, and ACM must be a part of it.  I have been accused of making up a new TLA purely to make an end run around other vendors.  Some say this is all just marketing hype, but that statement in itself might be hype.  You, the reader, are left with the unsavory task of determining which side is hyping more.  What I can say is that it really is not that hard to understand ACM if you try – and make an informed decision to cut through the hype.

Beyond my own summaries part one, two, and three there is this ACM Tweet Jam Followup:

In other areas

Finally, Peter Schooff asks an interesting question:  “Are Business Processes Detected or Invented?”  There are a number of responses, mine is:

Most business processes are neither detected nor invented. It is important to keep this perspective, though I know you mean something else.

You have clarified that you are only talking about the tiny percentage of business processes which are actually representable with BPMN or other programming language.

Scientific Management tells us that there is a separation between the “thinkers” and the “doers”. The thinkers come up with the precise way that work is to be done, and the doers are like cogs in the machine. For certain types of very routine work, (e.g. factory work with unskilled labor) this is appropriate. In these situations automated process discovery will tell you only how imperfectly the managers in the past have realized their directions in the organization. Of course, if you have lost the original designs, such discovery can be helpful.

When such a process is discovered, it almost always needs some improvement before it is automated. Simply adding visibility to what is going on always evokes suggestions for improving it, from every level of the organization. Thus it is inappropriate to say that any automated process is purely discovered. There is always a follow-on design job.

The difficulty I have with the question is the restriction only to automated processes. So much of business depends upon knowledge work, which includes processes which are invented on the fly by the person doing the work. There is no separation between “thinkers” and “doers” — the work itself involves planning which is a kind of invention of the process. These processes can rarely be represented by BPMN or any other programming language. My experience is that process discovery is a valuable tool for improving these processes, even though they are not automated. The visibility can cause changes in practice to eliminate inefficiencies even though the process is not automated. And this visibility helps even in the cases where the processes are purely invented.

I know this is not the question that you asked, but we should be aware that in many ways BPM practitioners are locking themselves into a box, and addressing only business processes which can be programmed. This was the important low-hanging fruit a decade ago, but today it is less and less relevant, and we need to start thinking outside the “can I program it” box.

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: