Fixing BPM – Out of the frying pan into the fire

When you transition from BPM to ACM/BPM the notion of “process” changes.

No longer do we have start-finish processes that ensure that a Case instance called “generator” or “patient” carries through to completion.

When constructing processes or process fragments for assemblies, patients, or b2b initiatives, it’s not prudent to rely on a “go to” or “return to services” construct as the final step along each process/process fragment/ad hoc step.  One missing construct across a daisy-chained sequence of interventions at the Case and your Case becomes an orphan.

Besides, who says any Case will go to the end of any open/active process fragment?  – in ACM and ACM/BPM users can do what they like, including exiting abruptly at any stage of the processing.

All of this added flexibility goes against the core objective of Case of ensuring continuity over time through to attaining Case objectives and Case closure.

The way to solve this problem is to incorporate a cross-Case query that tracks the following state indicators:

Cases not on any Pathway (i.e. process/process fragment/ad hoc step)
Open Cases
Archived Cases

Cases that have exceeded time limits

Completed Pathways
Suspended Pathways
Cancelled Pathways
Removed Pathways

The first three tags cover 100% of all eventualities (not on a pathway, on a pathway, archived).

Next, we need a qualifier for Open Cases (i.e. processes/fragments/ad hoc steps) that are not receiving services (e.g. we figured 8 weeks to case closure, it is now 10 weeks).

“Completed” is the usual expected outcome; “Suspended” means someone has put a hold on the process/fragment/step; “Cancelled” means a user terminated processing; “Removed” means a recall of a process\process fragment\step.

I would appreciate comments on any missing states.


Management consultant and process control engineer (MSc EE) with a focus on bridging the gap between operations and strategy in the areas of critical infrastructure protection, connect-the-dots law enforcement investigations, healthcare services delivery, job shop manufacturing and b2b/b2c/b2d transactions. (C) 2010-2018 Karl Walter Keirstead, P. Eng. All rights reserved. The opinions expressed here are those of the author, and are not connected with Jay-Kell Technologies Inc, Civerex Systems Inc. (Canada), Civerex Systems Inc. (USA) or CvX Productions.
This entry was posted in Adaptive Case Management, Business Process Management, Case Management, Process Management and tagged , , , , , . Bookmark the permalink.

2 Responses to Fixing BPM – Out of the frying pan into the fire

  1. Karl-Walter, while I completely understand where you are coming from and where you are heading with this, let me just point out that these issues are not there once the case/process fragments are not daisy-chained or user-triggered, but organized according to goals. Once goals are either fulfilled, changed, substituted or removed, so do all the connected work items may they be process fragments or ad-hoc. No need to manage pathway or (sub-)case states.


  2. kwkeirstead says:

    Thank you Max for your comment.

    This makes a lot of sense. I can see us transitioning from the current “menu of services” with manual assessment of progress toward objectives to where selecting an objective would link automatically to what would now be a hidden menu (if we were to keep the model we have been using) and from there to the execution of work.

    The listbox of objectives would become the central focus. This might take a while to implement the right way but it would probably improve the user interface.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s