When to use a flow-diagram for process and when not.
As you might have noticed, I am an outspoken opponent of using flow-diagrams for designing the human interactions of business processes. In my previous post I said that processes are just one representation of what constitutes a ‘customer experience’. A customer experience has no end point except if the customer decides to end it.
Many will argue that there are all these ‘studies’ about the successes of BPM projects using flow-diagrams. First of all, this is so-called anecdotal evidence, just like the weight-loss and fitness schemes they advertise in late-night infomercials. There are still no scientific studies that proof that orthodox BPM is good for a business. BPM can prove short term cost cutting benefits or quality illusions through adherence to rigid execution. I have not found proof for an overall and long-term business benefit. As always I challenge anyone in the BPM community to come forward and deliver research that supports those claims! I will gracefully admit my wrong ways when that happens.
Until scientific studies are done, BPM as a flowcharting exercise remain a religious belief (much like human-caused global warming) and it can’t be discussed seriously and rationally. I propose to you that most of these successful projects are not BPM per-se but actually application programming implementations using flow-diagrams. That is fine in principle if they would admit what it is.
And clearly, I have been blasted with the following question: If the above is my perspective and opinion why would I go against it and offer flowcharting? Why did we add a BPMN-like (compatible but extended) flow-diagram to the Papyrus Platform in 2009?
There are several reasons:
- Market perspective: Before we had a flow-diagram view no one would accept (including analysts who should understand it) that Papyrus represents a process management environment.
- Programming: Flow-diagrams are good for defining sequential wizards of information entry (interview mode)
- Interfacing: Orchestrating back-end service-calls to support data retrieval and updates.
- Overview: High-level representations of information flows in a value stream.
- Model-retaining execution: What you see is what you are executing (right now!) and the flow is a representation of what has happened, but not what will happen.
So flow-diagrams are not evil in principle, but it is really about how they are being used in BPM. They are fine to define rigid sequences of execution (while there are many other ways to show those).
Flow-diagrams are not usable to represent and deal with:
- Unpredictable and goal-oriented work.
- A large number of process variants that depend on the actual data or content state.
- Events that disrupt the predefined execution of the process, causing complex (programming-like) recovery and rollback issues even with back-end systems.
- Supporting knowledge worker decision-making inside the process.
- Integrating decision-making with standalone rule-engines.
- Defining and ensuring the achievement of goals and customer outcomes.
- Allowing customer-focused, individualized people interaction.
The principles of Adaptive Case Management have been assimilated:
Clearly, also case studies about the use of ACM are just anecdotal evidence, such as the recent 2012 ACM Excellence Awards (not the Academy of Country Music Awards ;-). I was invited to participate as lead judge and defined a first set of judgment criteria. These studies are great information to show the wide range of use cases for ACM, but you will see that the use of ‘adaptive concepts’ varies substantially. Most solutions are either Case Management or BPM products with some added-on adaptiveness. It shows however how eager BPM vendors are to belong to the ACM arena. ‘Caveat Emptor’ (Buyer Beware) is as important for ACM as it is for BPM. Never buy ACM without a proof-of-concept installation! See for yourself what it can do for your business.
So I am not claiming that ACM has proven its benefits. I am proposing that it is now obvious that BPM is turning your business into a frozen process iceberg that can only be handled by substantial and slow bureaucracy (as recommended by BPM experts). ACM enables the potential long-term benefits by connecting business with IT without added bureaucracy.
But the process iceberg has already thawed a little. At the April 2012 Gartner BPM Summit in Baltimore, Maryland, ideas central to the ACM philosophy came up frequently in Gartner analysts’ talks about the direction in which BPM is heading.
In particular, analysts made the following points:
- Janelle Hill, Anthony Bradley, Andrew White, and Daryl Plummer discussed the need to expand our view of processes beyond predictable workflows into areas where human decision-making is vital to business success.
- Janelle Hill and Betsy Burton noted the need to tie such processes to larger goals and business strategies, rather than simply following prescribed procedures.
- Betsy Burton, Daryl Plummer, and Elise Olding emphasized the need for innovative thinking and emergent strategies—such as easier process changes performed by non-technical people—to help businesses adapt and thrive in today’s fast-changing environment.
- Janelle Hill and Bern Elliot discussed how case management, social collaboration, and management of both structured and unstructured content are becoming important aspects of BPM.
As BPM proponents embrace these new directions—supporting unpredictable, goal-oriented processes and adaptive strategies that combine process management with case management, content management, and social collaboration—ACM has been there for years to meet that need. Businesses will need to take a substantial step beyond the limited BPM mindset to gain its benefits. One can’t just add ‘adaptive’ or ‘social’ to an orthodox BPM product. ACM implemented with an orthodox BPM programming-project mindset remains BPM!