Blog Posts Case Management Process Management Process Modeling

Time to Stop Using Business Process Models

Blog: Collaborative Planning & Social Business

Whew! It has been a few months since my last post in October on my way to the EDOC conference in Stockholm. Presentations and papers went very well there, and I have been working on an entirely new concept. It all centers around realizing that having to tie an organization down to a fixed, manually drawn process is the main problem. Instead, a completely new approach is needed for supporting business processes: Emergent Synthetic Processes.

It will take a number of posts to explain fully, and I will try to update the links here so it is easy to navigate. But first, I want to explain the problems that are inherent in the process model.

The Problem with Process Models

It seems like only yesterday that the entire tech industry was clambering after the holy grail of modeling in any form: data modeling, software modeling, and business process modeling.

Models have served their role in history but now we are seeing a new trend we have seen the limit to what process models can offer. We’re now finding the business process models are holding organizations back. Organizations are not able to move forward with a hard-coded business process models. Those organizations that are moving forward sometimes incur costs of maintaining the model that are too high. This book will cover many of the reasons for this. It will clarify which aspects of a model are valuable and worth keeping, and which should be left behind and discarded. Because it is now time to move beyond the process model.

What Modeling Is and Isn’t

The attraction of modeling was that a model is not a program. Programming is difficult. Programming requires highly trained individuals. Programs have to be debugged. So the dream was that a model would allow you to escape having to program things.

The irony is that a model is still a program. It is far easier to read for a new person to understand, but it’s still a program.

A model still defines a set of steps that need to be executed to accomplish a goal.
If the model lists the steps in the wrong order turn the model will not be correct and the correct results will not be produced.
The model has to include the definition of process relevant data which is carried by the business process. When you define this data, it needs to be defined in terms of variables which are acceptable to the process model.
If you don’t define the process variables correctly, or you don’t define the formulas that update those process variables, then the model is wrong and it will not produce the correct results.

The point I’m trying to make here is that the process model does not free you from most of the tasks that a programmer is engaged in while automating work at the office. Modeling is still programming and like any programming the result must be carefully tested, it must be debugged, it must be carefully introduced into production use, and it must be maintained.

While it is certainly true that drawing of a sequence of steps for a business process is a better representation of the process than Java-language program. It is easier for average business person to look at and understand the sequence of activities. For this reason a business process model is certainly more useful than the text-oriented source code which traditional programming would use. There is no question that it would be harder to show a group of business people the source code of a traditional program and have them understand it. It is clear that the representation of the business process as a graphical diagram is an advantage over source code.

But do not think that this means that there is no programming involved. The process modeler must assure that the actions are in the right order, that the actions complement each other, that the right data variables are used at each step. The process modeler must use good programming techniques to assure that the model is correct and debugged.

Internalization Required

A graphical model can only easily represent a program to a certain limited level of complexity.

A process model with 5 to 10 steps can easily fit on one page. A single page process model is a diagram that can be easily reviewed and digested.
If your process model has 40 to 60 different activities with all the various conditions that direct the flow between them, the model has to extend across multiple pages. When it does so, it is no longer easy to see and understand.
A large complex model such as is needed for a typical real life organization today extends across too many pages.
To understand what one page does you need to see and understand and learn the steps that are on the other pages. It’s no longer the case that you can show a one-page diagram to someone and they can pick up what the diagrams about.
You have to go through all the diagrams and internalize key aspects of the overall flow. Only after that work is done can you look at a given page and really understand what’s going on.

It is still the case that drawing a diagram is easier for the average person to understand send a text oriented source code which would be used otherwise but when your model extends to many pages it can be just as large a challenge to understand the macro scale model as it would be to understand it in the original source text. This is not to say that text oriented-programming is easier when the project gets large, rather to say that a large multi-page model can be just as hard for someone to understand as a large program.

So a business process model is still a program. It is simply a program that is a bit easier to read and understand for non-programmers but still requires the skills of a programmer.