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:

  1. 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.
  2. Programming: Flow-diagrams are good for defining sequential wizards of information entry (interview mode)
  3. Interfacing: Orchestrating back-end service-calls to support data retrieval and updates.
  4. Overview: High-level representations of information flows in a value stream.
  5. 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.

A Papyrus BPMN View of a process/case being executed.

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:

  1. Unpredictable and goal-oriented work.
  2. A large number of process variants that depend on the actual data or content state.
  3. Events that disrupt the predefined execution of the process, causing complex (programming-like) recovery and rollback issues even with back-end systems.
  4. Supporting knowledge worker decision-making inside the process.
  5. Integrating decision-making with standalone rule-engines.
  6. Defining and ensuring the achievement of goals and customer outcomes.
  7. 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!

I am the founder and Chief Technology Officer of ISIS Papyrus Software, a medium size software company specializing in communications and process management. I wrote several books and hold a number of patents. My quest is to bring common sense to IT, mostly by focusing in human quality issues rather than cost saving, outsourcing and automation. I am also Chief Architect at VIPorbit software which provides mobile relationship management.

Tagged with: , , ,
Posted in Adaptive Case Management, BPM
6 comments on “When to use a flow-diagram for process and when not.
  1. […] BPM and Flowcharting – Max J. Pucher Until scientific studies are done, BPM as a flowcharting exercise remain a […]

    Like

  2. kswenson says:

    >> “I propose to you that most of these successful projects are not BPM per-se but actually application programming implementations using flow-diagrams.”

    And what is the difference? There is an application which helps people get their work done. Yes, it is a frozen icicle, but it works better than paper and sneakers. It is based on a flow chart instead of Java code, and thus is easier to change than Java code. That is the key: it is easier to change than traditional programming. It might not be your idealized BPM, but it works and provides a measurable benefit.

    One BPM project I was involved in at a major bank was rigorously measured and found that the code of the implementation was recouped in the operational savings in just under 8 months. That is a success by any measure.

    Most of the market views application programming implementations using flow diagrams as actually being exactly what BPM is about. Defining BPM to to be something more useful to you won’t make your arguments stronger.

    Like

    • Hi Keith, one more thing: I am actually trying to explain my stance towards BPM and flow-diagrams in quite some detail in this post and therefore I am surprised that you seem somewhat agitated. I am trying to be quite reasonable here, but I will say what needs to be said. And you do not even disagree. It purely a matter of how the terms are interpreted by different people … one of the biggest issues in IT in the first place. Thanks again, Max

      Like

  3. Hi Keith, thanks for the comment. You are right – as most of the time – but you take your criticism to the wrong guy.

    I am not the one to idealize BPM. It is the BPM community who makes all these rash claims about the larger business benefits of BPM solutions by flowcharting all these processes. Look at the IBM, SAP or Oracle BPM presentations and those of many other BPM vendors. Analysts proposing complex governance infrastructures to rise through maturity levels. Yes, there are those who say that BPM is just an approach to look at the processes more effectively and it has nothing to do with software. Clearly, that is always a good way to look at it and I have said many times that I am not against it. I propose to look at processes too but through a goal-oriented, people empowerment lens.

    I have seen many of the same projects, where ROI was the key element and yes, I have said too that these short term benefits in cost cutting are the key reason to do BPM in the past and now. But they leave the long-term cost in change and governance out. They do not discuss what the consequences from a workplace psychology perspective are. They do not discuss lost people knowledge and motivation. With BPM-flows these processes get more difficult to change and that might not be an issue for some time. Plus, these are all point solutions (applications) and not larger BPM corporate improvement projects. If you say that is how the market sees the use of BPM and BPMS then we have a different perspective. When I say that processes are easier to change with Papyrus than with Java then I am told that this is not the point of BPM. They clearly want to have it ever which way.

    I am making people aware that BPM is not flowcharting anymore. It has to be said and unfortunately I have to live with the fact that this upsets the cart. I am pushing for a change in BPM and despite all the resistance it is happening.

    You may remember that I proposed that we should name adaptive processes as an advanced BPM domain but you and others felt that this would create confusion and preferred ACM. I do see ACM as an advanced form of BPM. As I said in my other comment, orthodox BPM with flowcharts as a management concept is outdated like many of those medieval medical procedures that were based on false beliefs.

    I have no idea how else I could phrase it. Thanks again, Max

    Like

  4. I worked for a number of years as an industrial process control engineer where humans only get involved in the management of a process as a result of alerts that post to a dashboard.

    It was a long journey from there to automation of business processes, then learning about ACM, finally reaching a stage where there are few remaining processes to worry about, a number of process fragments (some things have to be done in a particular order), with the rest being ad hoc interventions.

    My simplistic but possibly worthwhile conclusion is we start with the need for people to document what they do so that they and others can benefit from their conversion of inputs to outputs.

    Any organization has policy/procedure (what can be done/ how to do it) so it follows you can make a menu of all possible interventions that any person can make at a Case (including one that has a menu item consisting of a blank memo field with a label ‘none of the above”).

    You can then leave it entirely up to users to decide what next to do as and when they finish any task (no forms, no linked tasks, no flows, just documented work plus periodic assessments of progress toward Case objectives).

    If, through data mining, we find that one task typically follows another, we can add to our menu a “process fragment” that starts with one task/step and automatically calls the next step. if the number of linked steps is sufficient,we can call this a “process”.

    Since machines and software cannot go to user menus and pick things, we can achieve the same result by accommodating daisy chain on data.

    Users presumably can daisy chain on data plus experience plus judgement at menu items.

    I agree totally with you that “ACM is an advanced form of BPM”

    Why can’t the BPM folks get this and bring over all of whatever they like to do and just do it in an ACM environment.?

    Over time as they focus on Case objectives they will drop “incantations” that are a distraction to this focus.

    I still get people trying to promote the use of whiteboards and sticky notes as opposed to drawing things an an e-canvas.

    Then we have others who say we need notations, presumably so they can slide a “specification’ under IT’s door so that IT can develop a application.

    When was the last time they wrote up a spec for a letter they wanted to write in MS Word and submitted that specification to Microsoft?

    Yesterday I was engaged in a chat where a consultant had users who “need starting templates”. I don’t get this – anyone in business presumably knows what they are doing and why, So why start with someone else’s workflows, someone else’s forms? Particularly if the time to edit starting templates takes longer than mapping out a process at a blank canvas.

    There is nothing wrong with mapping out As-Is. Forcing people to do their work that way, with no or little accommodation for deviation is what the problem is.

    When I go into a subway system,(about once every 2-3 years), I like to see a map where I can trace out which routes to take to get to a certain place.

    Nothing wrong with picking a different route from the obvious one. Nothing wrong going two subway stops, exiting to the street level and walking a couple of streets to a different subway line. The other choice is don’t take any route and walk to where you want to get to.

    As we tell our software customers, here is the system, do what you like.

    Like

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

Max J. Pucher
© 2007-16
by Max J. Pucher. All rights reserved.
Real World Statistics
  • 200,855 readers

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 8,157 other followers

%d bloggers like this: