I think that BPM (discipline + tools + your enterprise system) is an enabler for evolving the business at the business pace. In a properly architected BPM system, it is easy and cheap to introduce small improvements; also the risk of big changes can be mitigated by some simulation.

I saw projects in which BPM was “eclipsing” a production system and I saw projects in which BPM is the core of a production system. The general conclusion is that the business and the IT (and sometimes a BPM vendor!) do not know yet how to use all power of BPM.

Cooking As A Process (CAAP) pattern illustrates "coordination by instances": as a typical culinary recipe comprises many "smaller" actions, they are modelled as instances of the sub-ordinated process. The main process is to follow the recipe.

Note that the same person can be in two roles: CHEF and sub-ordinate.

Obviously, monitoring of this process should be more "practical" than just following tokens within this diagram.

2010-03-06

Migration Instances to New Template (MINT) pattern illustrates an approach for moving running instances from one version of their template to another version. The idea is to allow such a migration at some control points of template.

The figure below shows a version of template v1 and a two its instances.

The figure below shows a new version if this template – template v2 and two its short versions: template v2’ and template v2’’.

When instance 2 has reached control point A1 then we have to instantiate template v2’ to continue this instance. When instance 1 has reached control point B1 then we have to instantiate template v2’’ to continue this instance. See the figure below.

Of course, all audit trails and KPIs should be externalized from the business process execution engine.

I am with Ralph – just priority is not enough and some performance (and other) information should be used at some control points.

Below is a fragment from my book (www.samarin.biz/book):
One of the possible interpretations of performance information is a proactive control of the SLA. As any process is a service, so it has to have an SLA, e.g. an agreed execution time. Typically, process engines are good for generating an alarm (e.g. an e-mail) that a particular process instance took more time than that agreed. But this is not sufficient because it addresses the effect and not the cause.

The imposition of a fixed SLA on all activities within a process template leads to a fussy BPM system which produces too many “false alarms”, e.g. if some execution time has been saved at the beginning of a process instance then the control on subsequent activities can be loosened somewhat; alternatively some activities may “catch up” the time lost by some preceding activities.

Ideally, the process owners have to be warned in advance about any potential non-respect of the SLA by a particular process instance. Control points are good places to run “health check-ups” of SLAs. These check-ups should evaluate the current situation and provide proactive control to achieve flexibility in the execution of the complete process, thus really helping business process managers. In addition to the process SLA, each activity is considered as a “spring” with some limits to stretch and to compress. The activity SLA needs to be defined to include both the nominal size of the “spring” together with its upper (stretched) and lower (compressed) limits.

Figure 7.3 provides an example of the dynamics of such a proactive control. As completion of the activity “Activity01” took more time than planned, then the SLAs for the other two activities were reduced (i.e. the springs were compressed). As completion of the activity “Activity02” again took more time than planned then the last activity needs to be compressed even more. It may happen that the last “spring” doesn’t reach its lower limit and thus the process instance may be completed within its SLA. Otherwise the process owner has to take some action because this process instance will break its SLA.

2010-03-04

I think that BPMS (BPM as software) is an enabler for disruptive changes on how IT deliver tools (currently applications) to the business. Each enterprise has a historical set of “solid” applications and each of those applications dilutes and mixes several business artefacts: processes, services, events, data structures, documents, rules, roles, activities, audit trails, KPIs. BPMS, by enabling explicit and executable processes, is a step forward to externalise (later virtualise and “send” to clouds) ALL those artefacts. Of course, with the help of many other technologies, e.g. ECM for documents, BRM for rules, MDM for data, etc.

This considerably increases flexibility – improving of processes will be assembling of better compositions from better artefacts; use of DSLs will simplify handling of artefacts, owners of business artefacts will be able to change them directly, etc. Because in many cases, processes are such compositions – this is the reason of the importance of BPMS.

Should we invent a name for it? Business Artefacts Development? Business Artefacts Provisioning? I think, that more important is to come up with a commonly agreed reference model and reference architectures to help everyone to move forward faster.