Keeping A BPM System In Tune

In very specific cases, a single person can cope with many distinct responsibilities.

But in general, it's easy to get out of tune that way and it's better to split up responsibilities in manageable pieces. The same goes for Business Process Management (BPM) tools. There are 2 very distinct aspects that are often mixed up. Especially traditional BPM solutions I believe are pretty bad at making the distinction between BPM as a management discipline and BPM as software engineering.

Keith Swenson already long time ago made a distinction between these aspects in BPM is not software engineering. In my opinion, these are 2 distinct aspects that are both valuable and they should not be mixed up. BPM as a management discipline can be practiced without the intention of automating them. Likewise, BPM as software engineering can be the most convenient technology way for a developer to implement certain technical requirements that don't have a meaning on a business level collaboration. Of course, the combination of both makes sense as well.

At Activiti, we don't want to end up with a single monolithic BPM System that takes on too much responsibilities and hence only becomes usable for specific nich cases. We clearly acknowledge the different nature of BPM as a management discipline and BPM as software engineering.

http://activiti.org/faq.html#WhatIsBpm

BPM as a management discipline is the responsibility of every strategic executive manager. It's to ensure that the organization performs well in their core business processes. This involves understanding what values the organization delivers and how those are achieved. This means analyzing, documenting and improving the way that people and systems work together. As part of that work, it's useful to work with models and diagrams. BPMN diagrams express the execution flow of the steps to accomplish a certain goal. Important to note that these models are used for people to people communication. They can be underspecified, which means that they can contain valuable high level information without including unnecessary details. Such underspecified process models are also known as abstract business processes.

BPM as software engineering means that executable business processes will be executed by a BPM System (BPMS). Executable business processes are based on a diagram that represents the different steps in an execution flow. The diagram can actually look exactly the same as the abstract business process. But executable business processes are different in some very fundamental ways. First of all they need more technical details. That part is generally accepted.

[read more...]

We believe that you should use the right tool for each job. And that collaboration should be facilitated on the Process Cycle Layer.

With the collaboration tool that we present there, you can see how we facilitate collaboration between business people, developers and system admins. And that without being intrusive. All of those people can't be forced to transition to a new single BPM system that does it all. But instead, with such a collaboration tool, we will facilitate the collaboration between those roles in a non intrusive way.