Recycling BPM

Peter Evans-Greenwood has written a post called BPM over promised and under delivered that is a clear description of a historic shift in the BPM space.

Peter refers to Taylor to indicate we've been looking at automation and BPM in basically an old school way.

The [Taylor] idea is that by driving our workers to follow optimal business processes we can ensure that we minimise costs while improving quality.

The early software applications and later BPM has been centered around that approach.

Departmental applications were first deployed to automate small repudiative tasks, such as tracking stock levels or calculating payrolls. Then we looked at the interactions between these tasks, giving birth to enterprise software in the process. Business Process Management (BPM) is the pinnacle of our efforts...

The Taylor historic context is great to get the picture. In the past, there were just a few people had the knowledge to break down goals into tasks for workers. Workers were little informed and just had to do as they were told. BPM systems took the same approach. BPM systems orchestrate and dump workers just have to perform small, simple, repetitive tasks.

That is indeed an aspect of BPM that I've always found problematic. In practice, it turns out to be very hard to find business processes in which the orchestration part can be totally automated. Human judgement is very hard to capture in predefined paths in a process flow.

With previously jBPM and now Activiti, we always took a very pragmatic approach. Over time it has become clear that embeddable BPM is a sweet spot. Enriching applications with the capability to combine human task forms with automatic steps has turned out to be a very valid proposition. Only in big banks we've seen usage that comes close to the traditional orchestration automation promise of BPM.

I also agree with Peter that

There has been some half steps in the right direction, with the emergence of Adaptive Case Management (ACM)

I think this trend is becoming clear by now, but it's Peter's post that made me think of an important potential reason for this: The democratization of information. Where in the past (read more then 10 years ago) only managers are informed and needed to break goals into tasks, now a lot more information has become freely accessible in organisations so that average workers become better informed and can make better decisions.

Also I've seen in most practical situations that processes grow organically. When people get asked a similar task multiple times, they tend to organise themselves better for dealing with these repetitive tasks. That way a business process grows bottom-up. There is not always a central, complete view of the process. It's often a very big challenge to establishing this central view of a business process. It usually takes a lot of interviews and conflict resolution to get to that central view. And you know what... this bottoms-up approach actually works well in most cases. Most often the optimizations that can be found in the central view of a process do not outweigh the effort to build the centralized process view.

In conclusion I think the top down aspect that aims at top down business process modeling the orchestration is ready for the scrapyard. Let's get rid of the BPM promise that business agility can be obtained by purchasing a BPM system. And let's recycle those bits and enhance case management with that expertise. By default people should be able to collaborate in an ad-hoc fashion. And when people spot repetitive patterns, everyone should be able to create their own small process flows for simplifying their own work. That form of process automation as an add-on to case management matches a lot better with the common needs of todays web and knowledge workers.