PROCESS MAPPING – Basic Constructs
Since the objective in a BPM process mapping software suite should be to empower functional units to develop, own and manage their own processes, it is important to avoid encumbering users with complex constructs.
Forget languages, notations and complex node types.
The facts are, the number of needed constructs needed to build a flow graph is surprisingly low.
How about four (4)?
1. Nodes as process steps.
2. Directional arrows to interconnect nodes.
3. Loopback arrows.
Imposed delays and alarms can be accommodated as node attributes. Daisy-chaining of processes and process fragments can be accommodated at node forms.
We need various other node attributes such as skill categories (who), instruction forms (how), data collection forms (to capture run-time performance data) and durations (when).
4. branching decision boxes
PROCESS MAPPING II – Branching decision boxes along pathways instances.
Branching Decision Boxes are essential constructs for all process mapping initiatives except for linear, straight-through processes.
The following selection options can be configured at decision boxes in a mapping environment such as CiverMed or CiverSupplier.
1. Single pick, manual select.
2. Multi pick, manual select.
3. Single pick, auto-select.
4. Multi pick, auto-select.
Decision boxes of type #3 and #4 require a rule set at each option within a decision box.
Consider the scenario where a user encounters a checkbox at some form upstream from a decision box. Checkboxes can only be checked or unchecked. Accordingly, a simple rule set is sufficient at each of the two options Checked/Unchecked in the Decision Box.
Since Decision Box options rules usually “fire” when they evaluate to TRUE, the easy way to build rules for a Decision Box option is to consolidate all required data values at forms that are parked at each option (otherwise ordinary nodes), carry out any required calculations at the form, then test data values at one or more rules to yield a Form Value of TRUE/ FALSE.
For our checkbox example, we can define a calculation variable called “i”, give it a starting value of 0, and then set up a calculation rule at the checkbox that reads
if checked then i = 1
At the form we now set up a Form Value variable called “j” and then write a Form Value rule that reads
if i=l then j=TRUE
Option: “Not Checked”
The other option needs a rule that goes like this:
if not checked then i=1
Not all rule sets are this easy to build.
Consider a YES/NO question on a healthcare data collection form. Here, it would be unwise to rely on, say, a simple radio button set because the range of responses could extend to:
3. Patient did not understand the question
4. Provider did not understand the answer
5. Patient refused to answer
6. Patient was unable to answer
In the normal course of events, non-technical process mappers will need assistance from IT with rule-set building.
If you’re interested in keeping things simple, you can build a decision box in my environments simply by dropping two or more nodes on a sheet and lassoing them.
Strictly speaking, it follows that node, arc, loopback arc are the only basic constructs you need to build a flow graph.
PROCESS MAPPING III – Run Time Issues
Once you compile a “best practice” workflow you can begin to generate instances of the resulting workflow template and engage processing along these.
Each record in the entity database can have one and only one active instance of the template except when your source process map has been designated as a multi-instance map.
The starting step along any instance immediately becomes current and posts to all user In Trays where there is a match on routing attributes. When the starting step is committed, the next-in-line step (s) become current.
When a single form process step becomes current, a performing user may “save” the step, instead of directly committing the step. If a step has more than one attached form, the user will typically want to “save” forms individually and later “commit all” at the step.
PROCESS MAPPING IV – Versioning of Process Maps
From time to time it becomes necessary or desirable to edit process maps (i.e. adding nodes\arcs, changing logic connections, changing mode attributes, updating forms).
The “do-not” list includes:
- Deleting form fields – if you have recorded data at a field and you delete the field, you will no longer be able to see the data in the History. Better to retire the old form and roll out an updated version that does not include the field. The old form will continue to be needed used to display data collected prior to your change but the act of retiring the old version will prevent users from creating new process template instances that reference that form version.
- Making certain changes to calculation rules without consideration of the consequences – if at step three (3) along a process instance you introduce a new data element and contemporaneously change a calculation rule at, say, step eight (8) that refers to the new data element, your rule, depending on how you configured it, may have a problem. Better to take the patient off the instance and put them on a new workflow template instance.
PROCESS MAPPING “n” – The Downside
Looking at the above, process building, for the most part, seems to be pretty easy and straightforward.
Does ½ an hour sound about right to learn most of all you need to learn about process mapping?
Except that before you “take the plunge” you probably need to decide whether you should be building processes or, maybe, what you should be building are “process fragments”.
For highly automated, end-to-end processes, process maps are what you need.
The problem is most of the end-to-end processes have been automated (“the low-hanging fruit”) and what is left is work that needs to be performed by a mix of people, machines and software.
Here, “the map is no longer the app” because there is no telling in advance what your process is going to end up being.
A user may invoke processing by creating an instance of a process fragment but we cannot predict what is likely to happen after the first step is committed (i.e. follow the flow, skip steps, insert steps, daisy-chain to another process fragment based on run time data values).
So, the Case ends up being the app and many times the only indication a manager is likely to have that a Case is about to close is “when the fat lady sings”, unless the manager orders closure him/herself.
Not to worry, the good news is Case Managers know how to manage Cases. Let them do their job.
If interventions wander too far away from policy/procedure/practice, environment level global rule sets will “rein in” unwanted activity.
Contrary to a need to basically “follow the flow” as is the case (sorry) with BPM workflows, in Case, users do what they like. The presumption is they know what to do, how, why, what data needs to be collected, and the environment helps them with when and where.
Reducing rigidity allows Case users to focus on reaching Case objectives via periodic assessment of progress toward meeting Case objectives.
We should have made it easy for them to do this from way back, except that we had to wait for ACM (Adaptive Case Management) to make this possible.