Blog Posts Case Management Process Management Process Modeling

Business Process Models are Not Agile

Blog: Collaborative Planning & Social Business

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


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

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 models make explicit what was once implicit, and therein lies the rub.

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

But ultimately the problem not lies is failing the dream and not because the formalism is lacking, but quite simply: a command-and-control approach only works if you are in a position to know everything that you will ever need to know about the process.  You 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, though, if you could gather instantly and completely, and had the best modeling formalism that allowed expression of all detail in an easy to change way, the biggest barrier is that people are invited to sign-off on a completed process.  After that, it can only be changed if they sign-off on the 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

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.


Leave a Comment

Get the BPI Web Feed

Using the HTML code below, you can display this Business Process Incubator page content with the current filter and sorting inside your web site for FREE.

Copy/Paste this code in your website html code:

<iframe src="" frameborder="0" scrolling="auto" width="100%" height="700">

Customizing your BPI Web Feed

You can click on the Get the BPI Web Feed link on any of our page to create the best possible feed for your site. Here are a few tips to customize your BPI Web Feed.

Customizing the Content Filter
On any page, you can add filter criteria using the MORE FILTERS interface:

Customizing the Content Filter

Customizing the Content Sorting
Clicking on the sorting options will also change the way your BPI Web Feed will be ordered on your site:

Get the BPI Web Feed

Some integration examples