BPM stands for Business Process Management. There are 2 different aspects of BPM: BPM as management discipline and BPM as software engineering. The BPM vendors have long time tried to make abstraction of those 2 distinct aspects. That path lead to more confusion then anything else.
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.
But what is less understood is that executable processes only take the perspective of a single system, the BPMS. The BPMS can act as a coordinator, so steps in the process could be for example user tasks. Then the user task becomes a wait state for the BPMS. And when the external task is completed, then the BPMS acting as a coordinator should be informed about the completion. In that context, a BPMS often acts as a state machine. So it's clear that the BPMS, even as a coordinator, can not handle steps between 2 external parties. For example, warehouse clerk handing over an order to a packager that wraps the order package. Imagine none of that is automated, then there is no way of the BPMS to be informed about those steps. So they can't be modeled distinctly in the executable business process.
Another less known difference between abstract and executable business processes is that executable processes are part of the software development lifecycle. That implies they are under the control of the technical developers and that executable processes need unit testing just like any other piece of software.
Traditional BPM vendors try to abstract those differences with automagical round tripping between abstract process models and executable process models. But in general, that approach fails in practice. At Activiti, we've developed an innovative vision to deal with these differences. The Process Cycle Layer will be a cornerstone in this strategy.