This is the final post on the problems of business process models for automating work, and one that sums it all up:  hand drawn business process models simply are not agile enough.

Review

The main points made in this sequence of blog posts are:

• Process Models are too much like programming
• besides that, organizations change more quickly than process models
• besides that, BPMN is too much of an imperative language for organizations
• besides that, CMMN is not declarative enough
• besides all that, a process model requires you be omniscient about your organization
• finally, besides all that, process models require agreement which is burdensome

The first couple represent the “dream” of process modeling, that a model would finally be effective where programming had become too difficult. Models were the rage!  But business process models make explicit what was once implicit, and therein lies the rub.

Buoyed by the dream, two modeling standards were developed, but still the problem is one of “fit”.  These modeling formalisms were defined in a command-and-control way, which really only works when you can micromanage everything.  Organizations are fractal, and in the end the detail defeats any attempt to make a complete picture.

More importantly, the problem lies not in failing the dream and not because the formalism is lacking, but quite simply: a command-and-control approach only works if the designer is  in a position to know everything that will ever need to be known about the process.  They have to bake into the process model every conceivable swerve and dodge.  I call this the omniscience problem, and in any organization with more than 100 people the details simply can not be gathered fast enough before they change.

Ultimately, if you could gather all that quickly and completely, and had an ideal formalism that allowed expression of all detail in an easy-to-maintain way, the biggest barrier is that people are invited to sign-off on a completed process.  After that, the model can only be changed if they sign-off on every change.  The completed process effects every worker in the organization, and because of that changes can not be allowed without a proper representative of every person in the organization. Some organizations delay months and years just because they can’t find anyone with enough time to approve the changes to the model.

Where Have We Seen This Before?

We have seen people try to make elaborate super detailed plans, only to have the attempt dashed, and that is in the software field.   The Waterfall Model of software development was popularized in the 1970’s in an article by Winston W. Royce — who incidentally was presenting it as an example of why it is a problem — and was broadly embraced by the IEEE and other professional organizations.   That model was largely discredited by the 1990’s because the effort to make the elaborate plans outweighed any benefit you got from them.  Herculean efforts would be spent to keep the plan up to date with discoveries about the problem space.  Or worse, the plans were not kept up to date, which greatly disrupted the ability to ship the product.

The Agile movement (starting in the late 1980s) showed that it was better to have simple cycles of doing and reflecting and improving than to cast an elaborate plan in concrete.  When it is easier to write the software, than it is to write a document about the software, the conclusion is that instead of writing a long design document for review, just write the software for review.  Then get the real customer input, and if necessary re-write the software, but you are almost always ahead because you did not need to write the large complicated design document.

Agile is not uncontrolled chaos.  It is, rather, controlled chaos.  It lets the software development move forward quickly, but at the same time uses reviews and introspection by the actual customers to make sure they are implementing the right things.

Summary: hand built business process models are simply not Agile!

Business process models need to be “minimum viable processes” – but that is not what you get with a hand built process model. The process model is a single canvas full of all the detail across the entire organization that is fixed in one place.  The review time is separate from the actual work time.  The people who review it are often not even the people who actually do the work.  A large investment is made before the process is rolled out, but then one must recoup that investment before the next organization change sends you back to the drawing board.

Instead, what you need is

• a multitude of canvasses which every participant can draw their own part
• an ability to assemble those into a single integrated process
• continue to updating the process to be fit to the organization as the details change
• a system to alert you to mis-matches, and address those in a way that remembers for the future.
• a system that learns over time what the members of the organizations need to get work done

What organizations are demanding is Agility in the business office.  An elaborated business process model ties the organization down in ways that hold the organization back.

In my next few posts, I will be finally elaborating Emergent Synthetic Processes (ESP) as a dramatically different approach that addresses the problem of agility in the office by moving beyond the business process model.