Prerequisites to providing functional unit end users with real-time decision-support include:
- Ability to roll out compiled process maps to a run-time environment (process steps post automatically to the attention of workers who have the appropriate operational skills and who are available to perform such steps).
- Real-time data collection at process steps.
- Auto-buildup of data (auto-posting of run-time data to a repository).
- Easy user access to current and historical data (data, organized intervention by intervention, in reverse chronological order).
- Easy access to algorithms that enrich data (internal as well as local and remote 3rd party algorithms).
The terminology is important – we are looking for “guidance” or assistance but without the burden of rigidity, the expectation being that users will want/need to deviate from best practices where appropriate. Any advice and assistance provided must not encumber users/software/robots.
Let’s see how Decision Support works at BPM process steps.
Decision Support at Process Steps
We need the ability to have decision support at all steps on pathways/sub-pathways.
The range of steps includes ordinary steps, gateway steps, special constructs called “Branching Decision Boxes”, loopback steps and BPM process merge points.
A Process step needs to know, plan side, when it should/can become “current” (BPM flowgraph logic takes care of this), what skill(s) are required for execution of the step, what data display/data collection forms are needed at the step and optionally, and what local instructions may be needed at the step for users who may be new to performance of a step.
Our starting point for this discussion on decision support for BPM will be data collection forms.
Here, rules local to a form at a process step can carry out range checks on data (end time is less than start time), block “bad” data (i.e. date “13/13/2014”), issue alerts when there is missing data, etc.
Routings (i.e. Nurse Practitioner, MD, civil engineer, solicitor) take care of performance skill requirements. It is important to point out that individuals can have several skills, some of which are exercised at specific locations.
Local instructions for processing steps can be plain text, a diagram or a video.
Decision Branching Boxes along Process Template Instances
Branching Decision Boxes accommodate selective branching to one or more downstream sub-pathways at certain steps along process map templates.
Not all Process Steps, need to be “performed” – some steps do nothing more than cause branching to one or more sub-pathways downstream – we call these steps “Branching Decision Boxes”. In some environments, a decision box can be formed simply by lassoing two or more ordinary process steps and making certain that each has the capability of resolving to TRUE under certain conditions.
Clearly you need a Boolean variable at each step that best starts off with a value of FALSE, with an ability to evaluate to TRUE under certain conditions as detailed in a Rule Set.
One easy setup involves parking a “Form Value” Boolean variable at a Form that is attached to a process step within a Branching Decision Box and relying on an embedded Rule Set to “fire” the step within the Decision Box (i.e. only step only, several steps, or all steps).
Here is a practical example:
If a>2 then j=j+1
If b > 5 then j=j+1
If j=2 then c=TRUE
Rule sets such as this one are used extensively during scoring of behavioral healthcare questionnaires. Individual questions can use forward, reverse or null scoring and thresholds i.e. values of 2 and 5 are used to determine whether responses at clusters of questions meet a threshold.
If Question “a” has a score of 3 or more, we increment a counter called “j”. If Question “b” has a score of 6 or more, we increment “j” again.
A final rule is needed to resolve “c” to TRUE if the responses to questions “a” and “b” both exceed their respective thresholds of “2” and “5”.
When you are constructing BPM process workflows you will not get far without Branching Decision Boxes. There are very few straight-through processes in the b2b world of today.
A relatively “simple” process map with only a few Branching Decision Boxes can easily yield hundreds/thousands of permutations and combinations. It’s important to “test drive” mapped rolled-out process templates thoroughly prior to production release.
Here are some practical tips.
There are three (3) types of Decision Boxes.
1. Enabling Decision Boxes (branching)
Enabling Decision Boxes have two or more options – if you have outcomes for two options i.e. #1, #2, it is always a good idea to include another, say, “#3 – Neither #1 nor #2” for modeling purposes.
Enabling Decision Boxes can be of the sub-type “manual” or “automatic” as well as “single-pick or “multi-pick”.
“Manual” requires that the user pick an option.
“Automatic” self-executes as and when a decision box becomes current along an instance of a template based on data collected upstream from the decision box.
As explained earlier in this article, a simple approach to Enabling Decision Box construction is to use ordinary nodes that you lasso to form a physical Decision Box.
When a Decision Box option or Node does not evaluate to TRUE, the entire sub-path downstream from that Node is dropped from the process template instance.
In order to avoid giving Case Managers the notion that certain pathways/sub-pathways are “disappearing”, make sure each Rule Set includes a Node that evaluates to TRUE when the condition “none of the above” is met. When such Nodes evaluate to TRUE your Case log will show termination of a pathway/sub-pathway.
A Rule Set that needs to cause branching for negative or positive values of a variable called “a” can function with the following:
If a <0 then engage sub-pathway “A”
If a >0 then engage sub-pathway “B”
but may cause confusion to users when a =0.
What is missing is
If a =0 then engage “EXIT”
Where EXIT is a “debug” sub-pathway of one step that posts a warning that reads “Exited at Node ___”
Some environments require special constructs for decision branching.
2. Gatekeeper “Decision Box” Steps (inhibiting)
Gatekeeper “decision boxes” have a routing of “system” (i.e. no users see ese).
Their sole purpose is to block processing along a pathway/sub-pathway until such time as a set of conditions have been fulfilled.
The quotes highlight the fact that Gatekeeper decision boxes have only one included step, accordingly there is no need to lasso/construct a physical decision box.
In most BPMs, gatekeeper steps have distinctive icons.
A reasonable question to ask here is what if the set of conditions never gets fulfilled?
One, you may optionally request that each time the rule set at a gatekeeper decision box is tested, an error message will post to the attention of the System Manager if the Rule Set resolves to FALSE.
Two, in the absence of such tracking, Case Managers typically will have set milestones along pathway/sub-pathway instances, with the result that the software system will track lack of progress along the path/sub-path and the manager will take corrective action.
Another question relating to gatekeeper decision boxes is how do they acquire the data that allows the rule set to resolve to TRUE?
The answers are a) direct data entry by some user, b) auto-enrichment of data by an algorithm and c) import of data to the BPMs.
3. Embedded (hidden) “Decision Boxes”
Embedded decision boxes are typically invisible, unless, for some reason, you want them to be otherwise.
In the normal course of events, there is no need to indicate to a user that a checkbox, for example, on a data collection form, causes a “link to pathway”.
If the initial step on the linked pathway has a routing that does not match that of the user at the step\ data collection form, the user will not see the effects of the processing they engage by clicking at the checkbox.
In some BPMs adding a new Case results in streaming of the Case onto a process template instance.
Here, the effect of setting a default pathway in the BPMs profile, causes the behavior, so we can include new Case streaming under hidden decision boxes.
The presumption is that BPM practitioners are motivated to guide their clients along a maturity path where complex processes are mapped, improved and rolled out to a run-time environment capable of providing orchestration & governance (Case level decision support).
Neither you nor your clients will get to this level by staring at paper process maps.
See “Check your Business Rules on the Way In and Out”