BPMN Potential Is Yet To Be Unlocked
- Published: April 27, 2016
- Written by Anatoly Belaychuk
Lloyd Dugan from BPM.com has proposed a simplified CMMN at the recent bpmNEXT conference in Santa Barbara. The initial point of his presentation was the statement that BPMN isn’t well suited for modeling event-intensive scenarios. They require event subprocesses and ad-hoc subprocesses that are obscure for users and aren’t well supported by BPM vendors.
Here is the case description that Lloyd has used to illustrate the problem:
A claim package is received, which start a claim case. Efforts are made to gather claim information, beginning with a case worker that will record the claim, and a set of procedural activities to request any documents that may be missing. Once all relevant information is recorded and received (if initially missing), then the claim is said to be established, allowing additional or missing information to be received later.
At this point, the next phase is to perform the set of collaborative activities that evaluate the claim, the outcome of which under normal circumstances will be that the case worker determines the case is closed.
At any time of the case, a case worker may create a letter to communicate anything about a case as needed. Also at any time of the case, it may be terminated based on certain circumstances determined by the case worker.
While agreeing event- and ad-hoc subprocesses criticism, I dare to disagree that BPMN isn’t an adequate tool for this case by proposing the following solution:
The main process pool is called “Process claim”. A case worker starts the process, records the claim and then “Evaluate claim” task follows. The task name doesn’t fully reflect what it does – in fact, three options are available to the case worker: evaluate the case and close it (“Done” branch), postpone evaluation and request additional information (“Request and wait”) or just wait for additional information to become available (“Wait for info”). The parallel control flow initiated from the start event lets the case to be terminated any time by a message.
Three other pools handle unsolicited events: case worker’s decision to terminate the case, his/her decision to request additional case documents (“Request claim info”) and arrival of case documents (“Record claim info”).
All handler pools start with a similar task “Select/Identify claim” that looks up the claims stored in the database by the main process. This task is quite straightforward to business users because this is what they do in the real life. E.g. when a client brings a requested document to the office the clerk looks up the records to find the client’s case file. It isn’t a trivial task by the way: it may happen for example that the client doesn’t know the case number so that a database query should be performed on the case client’s name. Since the main process instance isn’t known when the task is initiated, we are unable to use the event subprocess here.
It may also happen that the client was brought the document after the case has expired. This is another reason why the event subprocess isn’t an option: the main process has already ended at the moment of the visit. Only by utilizing a separate pool we are able to track that client visited the office, his documents were processed and he/she was properly informed that the case has terminated. The diagram above models this check via the “Valid claim found?” gateway. Only if the claim is found and is not void the message would be sent to the main process.
A message arrived to the main process requires the case worker to re-evaluate the case. Original case record and additional info are presented to the case worker to evaluate and make a decision.
More sophisticated business logic may be considered: e.g. the main process may track the list of documents requested/obtained and not bother the case worker until all requested info is obtained. Another option is adding a timer to establish a deadline for the client to submit the requested document. Both options aren’t difficult to model so we leave them to the reader.
The modeling technique presented utilizes no exotic BPMN elements, just plain message events and data based collaboration. Dozens of projects implemented have proved that it’s both comprehensible by business people and suitable for automation by virtually any BPMS.
This technique is elaborated on my blog:
- “Command vs. Respond” http://mainthing.ru/item/613/
- “Robots Don’t Talk To Humans” http://mainthing.ru/item/602/
- “Process Pattern: Tender” http://mainthing.ru/item/518/ and other posts tagged “pattern” http://mainthing.ru/tag/pattern/
- “BPMN In Outer Space” http://mainthing.ru/item/396/ is an example of BPMN usage far beyond business