Another frequently asked question from a forum.
Question - When a business process template is modified (activity added/removed), what happens with process instances started by this template (previous version). What happens with analytics?
Answer - Most BPMS will finish running instances by following old template and will create new instances based on new teplate. It’s acceptable only if the template modification was planned. If - like it happens in most cases - the process became stuck because the template doesn’t have a desired gateway or a flow then you have nothing to do but abort the process instance and start it again by new template making the analytics inconsitent.
Yet there are systems allowing process scheme modification “on the fly”. Recommended reading:
- ebizq.net article by Glen Smith from Appian explains why this functionality is important from methodology perspective. You can launch the process into operations faster if you don’t have to discover details of all possible exceptions.
- Keith Svenson from Fujitsu notes that implementing process modification on the fly is hard to implement in a system that uses BPEL for excution. Fujtsu Interstage BPM lets you edit the scheme of a running instance the same way you edit a template; you can save the new instance scheme as a new version of the template if you wish.
Please refer to BPTrends report for the information about specific BPMS.
It’s hard to implement on the fly modification if a business process editor (modeler) is implemented as a desktop application which is the case for most systems. If a process instance stuck one should be able to correct scheme online promptly. Hence the modeler must be implemented as a thin client. Fujitsu Interstage for example has both desctop and online (java applet) modelers.
Oracle BPMS (aka BEA AquaLogic aka Fuego) took another way. The modeler pallette of this system has a special “magic” activity which can get control from any activity and/or pass it to any other acitivity. It solves the major part of the problem - absence of a desired flow on a scheme.
But you shouldn’t rely on a tool only - the process sheme should be designed the right way.
Let’s consider a long-term contract with a customer for example. We are going to deliver goods, obtain money and also renew contract’s terms and re-negotiate its conditions many times during several years. If we tried to implement it technically by a single process then for sure its scheme will be changed many times. Better solution is to create a long-living yet very simple process on the top level - a kind of a state machine keeping the state of our relations with the customer: “contract is beeing agreed”, “contract is in effect”, “contract is being agreed” etc. Every action starting from contract negotiations should be implemented by a workflow-like process. This workflow can be started if the contract is at some specific state and it can send a message to the contract process which will bring it from one state to another. Since the state machine is strictly passive one can modify a workflow scheme freely and/or create several alternative versions of e.g. delivery workflow.