Jim Sinur wrote a couple of interesting blog posts recently mentioning two distinct approached for supporting work processes:
- Doing by Design is the pre-planned definition of a predictable, routine process as traditional BPM suggests. It involves a life-cycle that starts with process discovery, process definition, application development, simulation, testing, and ultimately deploying it. This works if the process is predictable.
- Design by Doing is an approach that works when the process is not predictable, and can not be written down ahead of time. Since you can not predict it, you have to elaborate it as you go along. You design it, as you are doing it. There is no development life-cycle. This works on unpredictable emergent process.
I really like this characterization, because it helps people understand these two very different approaches to supporting office work. This is a large part of the subject of the book “Mastering the Unpredictable“.
Jim argues that the definition of “BPM” should be expanded to include both of these approaches. I disagree for a number of reasons. Traditional BPM is clearly “doing by design.” You can read in any number of sources how your starting point is to draw up a process. Look at the work at OMG on BPMN is purely in this predictable process approach.
However, what do you do about companies like Fujitsu and HandySoft which have offered for many years a “design by doing” approach? My experience and frustration is that people a grossly confused if you try to explain to them that design by doing is BPM. They will tell you flat out that a business person will never use a BPMN modeler — and they are right! Who says that BPM requires a BPMN modeler? Everyone! There is an overwhelming preponderance of opinion in this regard. Can you imagine a doctor sitting in their office drawing a BPMN diagram for a patient’s treatment plan? Not on your life.
I honestly hope that Jim and Gartner can convince the world that BPM can be done without modeling, without WSDL, without simulation, without complex data manipulation, and without all the other things that a business person designing by doing would ever do. Few analysts are as open minded as Jim Sinur, and most pundits consider all of that a necessary part of BPM per se.
Look at any ad for “BPM Training” will almost always involve BPMN training. I would challenge anyone to find BPM training which is relevant for a business person, a doctor, a lawyer, or a judge.
It does not really matter what term we use, as long as we all agree on the definition. If we want to call both approaches BPM, I would be happy with that as long as the public understands that meaning. My experience has been decidedly that people do NOT understand that a “design by doing” requires a completely different approach from “doing by design”. I believe the public will be confused by putting the same label on both these approaches. This would be a harmful disservice to muddy conversations with blending these terms with so many meanings.
Instead, a clear term is needed for “design by doing” and that is Case Management — particularly a newly enable technical approach known as Adaptive Case Management. By having a clear label for “design by doing”, we will help people understand what we are talking about, what is required, what is not required, and will help this emerging market form.
Keith, I have had this confrontation with BPM pundits years ago. Design by doing – especially when one does not even offer a flowcharter – was clearly not considered BPM. We have offered the state/event driven and tool/material controlled processes mostly focused on content with Papyrus since 2001: That’s not BPM I was told. It was not yet Design by Doing then, but processes could dynamically changed at runtime. We added to that user-definable business rules in 2003, but no, that was not BPM either, but clearly it was Design by Doing. In 2007 we introduced the User-Trained Agent that would kick off activities based on a machine learning principle and that is Design by Doing ALL THE WAY. Nope, we were told by analysts and customers – no flowcharts means it is not BPM.
So why is everyone trying to expand BPM now? Simple. Because they do not want to be part of an outgoing era! They do not want to admit that possibly BPM is not the final wisdom as it was proposed for so long. The BPM pundits know as they have added methodologies to manage the methodology of managing processes that they have crossed the line. Now that there is a movement that they know in their guts will kill old-style BPM, they at least want to retain the name because then they won’t have to admit defeat. Also ACM builds to some extent on the management concepts of BPM methodology, because it does require a capability map to assign process owners.
I for my part don’t really care whether Papyrus is considered BPM, ACM or the most powerful application development platform available. Selling it will be hard work either way.
Pingback: links for 2010-04-29 « steinarcarlsen
Pingback: Process for the Enterprise » Blog Archive » Doing by Design vs. Design by Doing
I think the future will blend the two… In many (perhaps most) cases you will capture the process by doing the process.
Once the design has been captured, you’ll most likely use modelling and simulation tools to improve the design.
Regardless… We’re concerned with Processes that happen repeatedly, and with Processes that can benefit from Management, and most of those Processes involve Business… so the BPM moniker still fits.
I am going to help you Manage your Business Processes through the use of software. The nature of your Business and the nature of your Process is going to determine the best approach to tak.
Pingback: BPM Quotes of the week « Adam Deane
Pingback: Social BPM Update | Collaborative Planning & Social Business
Pingback: Adaptive Work Patterns in SAP Jam | Collaborative Planning & Social Business
Pingback: Design by Doing with Activiti6 | activiti-crystalball