[Click here for the Lean BPM Manifesto.]

In 2001, software development was in a mini-crisis. Software projects were being specified in ever-more elaborate terms. Methods like the Rational Unified Process and Waterfall project planning were being utilized. And yet software projects were failing at increasing rates or being delivered late or being delivered with the wrong requirements. That year, a group of software developers came out with the Agile Manifesto http://www.agilemanifesto.org/. This manifesto based on Agile and Lean principles created a revolution in software development leading to much improved outcomes. Today it is not uncommon for software to be released to production on a daily or weekly basis in small valuable increments with rapid feedback and iteration. In the past quarterly releases to production would have been considered good.

Similarly, in 2011, Startups were being built with a long build phase followed by a big launch at which time it was hoped that the team had built what the market wanted. This approach led to a large number of failed startups that ended up building what nobody (or very few wanted). That year, Eric Ries proposed the Lean Startup Methodology .https://en.wikipedia.org/wiki/Lean_startup This approach went on to revolutionize how startups were built.

Of course the grand-daddy of the Lean Revolution was the Kanban system introduced by Toyota which went on to revolutionize manufacturing. https://en.wikipedia.org/wiki/Kanban

The common thread across all three Lean revolutions was

• Moving from long-lead times to rapid iteration
• Rapid feedback from the “market” to avoid building what the market did not want (i.e. avoiding waste and ‘pulling’ based on market feedback)
• Quick learning cycles that were incorporated into the next iteration.

Of course each lean methodology had nuances specific to the problem being solved, and yet the general principles held across all three.

We believe that Business Process Management or BPM is at a similar crossroads.

The core idea of BPM is summed up well in the wikipedia article https://en.wikipedia.org/wiki/Business_process_management

 Business process management (BPM) is a field in operations management that focuses on improving corporate performance by managing and optimising a company’s business processes. It can therefore be described as a “process optimization process.“

At its core, BPM is about process optimization. In other words constantly improving business processes. But just like in the Software Development, Startup and Manufacturing worlds prior to their lean revolutions, BPM as currently conceptualized is not conducive to process optimization.

The reason for this in turn is the same problem that plagued all the three aforementioned areas, viz. long lead times. The key element that revolutionized the areas above was a massive shortening of lead times which in turn allowed rapid iteration which in turn allowed rapid experimentation, reduced waste and massively increased optimization.

From the same wikipedia article cited above, the Business Process Lifecycle is defined as Design -> Modeling -> Execution -> Monitoring -> Optimization.

This looks suspiciously like the Waterfall software development lifecycle in use prior to the adoption of Agile software development methodologies.

A prime reason for the long lead times in BPM is the fact that the persons or knowledge workers who are in the best position to create and refine the process are different from the individuals and teams that can actually create the executable business process (typically I.T.)

A second reason for long lead times is the elaborate up-front design and modeling that needs to be done before one can even get started. In other words a high up-front cost. A high up-front cost also discourages rapid iteration and experimentation, one of the hallmarks of lean.

So BPM today is characterized by long lead times. This in turn leads to an identity crisis for BPM. If building business processes requires long lead times and requires software development skills, how is it really different from app development?

Yes, there are first-class entities called ‘processes’ which are typically lacking in ‘apps’. On the other hand, current app development methodologies are incredibly sophisticated and can lead to vastly better outcomes in usability and capability.

There have been two (largely opposite) reactions in the BPM vendor community to this identity crisis.

The first was to take languages like BPMN and put them into graphical form in the hope that this would once again put the power in the hands of the users and allow rapid experimentation and iteration. However, this has proven to be a false hope (see Zero Code BPM Systems by Keith Swenson).

Dragging and dropping symbols on a map to tell the system exactly what to do is still coding, and it is just as hard as typing the code in text, because the hard part is figuring out what should be done in what situation. You have not eliminated coding, you just disguised it.

In fact the general consensus in the industry seems to be that Zero-code BPM is not possible. See this discussion for the general consensus that Zero-code BPM is unrealistic.http://bpm.com/bpm-today/in-the-forum/is-zero-code… (see Zero-code BPM is not a myth for a contrarian viewpoint).

The second reaction was to essentially transform BPM into a particular type of application development platform while hoping to preserve some of the differentiating characteristics of BPM. This approach has been more successful and yet the question remains whether BPM is the right metaphor for an application development platform. This lively debate on whether BPM should form the basis for general application development is a worthwhile read.

The Lean BPM approach (described in the Lean BPM Manifesto) takes a different approach.

At its heart (like all lean methodologies) is the notion of rapid iteration and learning. This in turn means that the end users (i.e. knowledge workers) must be able to rapidly iterate over processes. This rapid iteration and learning by the actual end users is the best way to achieve the original goal of BPM, viz. process improvement.

Some of the additional tenets of Lean Processes include:

As a corollary to rapid iteration and learning, coding must not be required for Lean Processes. if code is required (say) for integration, it must not interfere with rapid iteration and learning.

On a related note, there should be no expensive up-front design and modeling required as this discourages iteration and experimentation. Instead, knowledge workers should be able to start with natural intuitive process precursors, iterate rapidly and evolve them into formalized processes only if and when needed.

A working process delivering customer value should be favored over models of processes not delivering immediate value.

In order to facilitate process optimization, guidance and support for knowledge workers should be emphasized over strict control over ‘task workers’. Goal management over detailed workflow.

Process variation is natural and should be embraced. Rather than trying to stamp out process variation, variation should be embraced and supported.

As a corollary, trying to embrace variation by ever-more complicated conditional, branching workflows is counterproductive and should be avoided. Instead, more flexible approaches such as goal management and knowledge-worker dynamic adjustment of process goals and steps should be embraced.

Where possible, a ‘forgiveness over permission‘ model should be employed. Strict permissions models again make it hard to experiment, learn and iterate. Of course there will remain some situations where permissions are critical.

Flexible Collaboration should be an intrinsic part of process management not something apart from it. Flexible collaboration built directly into a process makes processes more supple, flexible and powerful. Flexible collaboration within a process also encourages process improvement right within running processes.

With Lean BPM, the original promise of BPM, i.e. rapid organizational process improvement can be fulfilled.

Notes in the margin: There have been BPM Manifestos before. This seems to be one of the more popular ones http://www.bptrends.com/bpt/wp-content/manifesto/p…. As one can see the principles and concerns of traditional BPM, while having some overlap are quite different from those of Lean Processes.

And then there are the following “Laws of BPM” compiled by Alexander Samarin. http://improving-bpm-systems.blogspot.com/2015/07/… These are simultaneously tongue-in-cheek, entertaining and highly enlightening.

You can get started with Lean BPM for free by registering for TMail21.