BPM, Optimization and Scrum

One of the goals of Business Process Management (BPM) is the continuous optimization of business processes.
In fact when we start analyzing existing processes, in most cases it turns out that those processes are far from being ideal.
Usually the first impulse is to say, all right let’s improve the processes while we automate them.
At first sight this seems to be reasonable, but practice shows that it is not.
Why not?
Usually the process knowledge is in the heads of the business users who live the processes every day.
Even if they have some sort of documentation, they feel that they own the process. And they do!

Once you start changing the existing processes you take the ownership and leave the real owners behind.
This can quickly turn into a acceptance problem cause the business users are a vital part of BPM as they have the process knowledge.

Practice shows that it is better to automate processes as is first and keep the business users involved.
Start small (and think big) for instance with partial processes. Then show the benefits and start the optimization loop.

This can be ideally done in an agile setting such as Scrum in which the idea of continuous improvement (Kaizen) is built-in.
A nice side-effect is that not only the business process is improved over time, but also the analysis and implementation process itself.

Rules, Processes or Services?

Together Services, Business Processes (BPM) and Business Rules (BRM) can be a powerful combination to keep the SOA promise of creating agile business applications.
I often hear questions about how those three can be combined in a reasonable way.
In their article Implementation of business rules and business processes in SOA Boris Lublinsky and Didier Le Tien give some practical advice.

SOA without BPM without SOA

Some people argue that SOA and BPM are two different things. That is probably right because it is possible to create a service landscape without having a business process representation. But if you look at the main reason for establishing a service oriented architecture the perspective changes.
The main reason for SOA is business agility. Every technology that helps to achieve that goal is welcome to be integrated in the SOA technology stack.
BPM makes perfect sense as it fosters better aligment on business and IT and helps to shorten development cycles.
Ok understood. But if that is true wouldn’t be be enough to use a BPM only without services? The answer is no because in order to create a flexible BPM solution it must be based on a sound service landscape. If that is not the case changing a business process would require new services to be created or existing to be altered. Sooner or later this would lead to service proliferation which would render the BPM approach useless over time. The result would be anything but hardly an agile system.

My conclusion: Using BPM as part of a SOA makes perfect sense if it is based on reliable and well designed services.