Process Is The Main Thing

@ Anatoly Belaychuk’s BPM Blog

Posts Tagged ‘FAQ’

On-the-Fly Process Modification

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.

02/09/09 | Notes | , , ,     Comments: 5

DBMS vs ECM vs BPMS

The same old question arose on a forum once again:

“In fact many BPM tasks could be solved with a document flow as well as with a DB. Yet results may not be very good…”

This is obviously a FAQ so I’m going to give a deailed answer, re-formulating the question for generality.

Question - What are the borders between DBMS, ECM and BPMS? How should they be combined?

Answer - Generally speaking we have:

  1. structured information where DBMS excels
  2. unstructured information (documents) is what ECM is for
  3. process information is BPMS target

(BPMS uses DBMS internally and ECM may use DBMS or file system for storage but it’s beyond our scope.)

Every member of DBMS-ECM-BPMS trio is able to replace any of two remaining brothers but only some more or less nasty way:

  • DBMS can store documents in text and binary fields yet it’s far from ECM functionality e.g. in navigation, content search, versioning, access control, MS Office integration.
  • DBMS is sometimes used to store process information, usually in a table where each rows defines the next step of document processing. Of course it’s very primitive if compared with BPMS process diagram.
  • ECM has a workflow or process engine yet it doesn’t match BPMS because of proprietary notation, platform, integration tools and what’s most important due to the lack of continuous process improvement methodology support. Simply speaking, a business process can be implemented in ECM but it’s hard to modify it with the speed required by business.
  • Structured data can be entered into Excel file and stored in ECM.
  • BPMS has typed attributes for structured data but clearly it’s for limited use only - the performance is nothing compared to that of DBMS.
  • BPMS lets you attach documents to a process instance yet as well as in DBMS case, the service will be very primitive if compared with ECM. Besides there is a question: how are you going to reach your documents when the process has ended?

So if you are planning the perspective infrastructure then you’ll need all three components. On the other hand, if you face a task limited by functionality, resources and/or timeframe then you may look for a poor-man’s solution by compensating missing components with present ones.

Make your strategy balanced over time. E.g. BPMS document capabilities may suffice for a pilot stage of a BPM project. A pilot project should answer the question - “do we need all this staff at all?” - in the shortest timeframe. In case of positive answer we can add ECM afterwards.

02/05/09 | Notes | , ,     Comments: 4

Copyright © 2008-2017 Anatoly Belychook. Thanks to Wordpress and Yahoo.  Content  Comments