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:
- Tom Shepherd wrote up “Tweetjam on Adaptive Case Management last week” including some of the highlighted posts.
- Jacob Ukelson wrote “Adaptive Case Management Tweetjam Synopsis Part 1 – Defining ACM” which focuses on the many different attempts to define Adaptive Case Management.
- Jacob Ukelson outlines another topic from the tweet jam in “Adaptive Case Management Use Case – Executive Decision Tracking” where he goes into depth about the decision and follow actions of an executive board.
- Frank Michael Kraft did a summary of his favorite posts in “ACM TweetJam wrap-up“.
- Deb Miller posted her assessment of the tweet jam in “Mastering the Unpredictable – A Great Idea and Awesome Conversation!” as well as a follow on post “What you should know about Improving Knowledge Work” with more top picks.
- Chuck Webster was a contributor to the tweet jam wrote up his summary “Zowie! Tweets of Week Ending July 18, 2010: Tweetjam #acmjam, adaptive case management, Herbert Simon, EMR/EHR Usability“. Browsing the rest of his site gives insight into how the medical user might be interested in workflow, BPM, or ACM.
- Another summary “BPM, ACM, ECM… At Its Core, Your Company Simply has Process Needs” – a rather predictable conclusion from a BPM company. Strange given that so many examples were given that do not have any process involved. This is representative of the kind of confusions that surrounds this field, especially from entrenched representatives who want to express everything as simply different kinds of process.
- Barb Mosher of CMS Wire writes “What is Adaptive Case Management?” with a summary of intriguing tweets.
In other areas
- Jacob Ukelson wrote “The ACM Guide to House Renovation” which is an excellent example of how real work requires flexibility that a pre-defined process could never afford.
- Frank Michael Kraft did a write and response to my long discussion with Jean-Jacques Dubray in two posts: “Does unpredictable work exist? – My opinion” and “Does Unpredictable Work Exist – continued“. Very interesting.
- John Mettraux with a “Review of Mastering the Unpredictable“.
- Max Purcher covers “The Art of Strategy” – important because some thing that strategy can be hard-coded into automated business processes, but that would leave you with an inflexible and ultimately outdated organization. But then, Sun Tsu knew this 2500 years ago. This post is long, and well worth the read.
- Max Pucher also covers “Are Adaptive Processes Chaotic?” and “The Texas Two-Step of BPM and ACM“.
- Oh Nooooo, it can’t be! Google says goodbye to Wave.
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.
Pingback: Tweets that mention ACM Links for 8-4-2009 « Thoughts on Collaborative Planning -- Topsy.com
Thanks for the ACM Links Keith! Here’s one more of my own: http://debsg360.wordpress.com/2010/07/21/what-you-should-know-about-improving-knowledge-work/
Keith, how about zero with respect to numbers. Rather than starvation with respect to food. You run the same logic, zero is pretty darn useful, but it is also “just a feature” of the numbering system. And, it had to be “discovered” as a mathematical concept by several different civilizations, so at one point in time it was a rather non-obvious concept.
Its easy to make the arguments if we cherry-pick the analogies and we stray pretty far from the software world to do it.
Pingback: Column 2 : links for 2010-08-06