Process Mapping – all you need to know about it

constructionThis is a consolidation (I, II, III, IV) of posts on BPM process mapping in graphic environments.

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)?

We need

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).

This leaves

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.

Option: “Checked”

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:

l. Yes
2. No
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.


 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:

  1. 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.
  1. 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.



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, major crimes case management, healthcare services delivery, and b2b/b2c/b2d transactions. (C) 2010-2019 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, Operational Planning, Process Management, Process Mapping and tagged . Bookmark the permalink.

3 Responses to Process Mapping – all you need to know about it

  1. Hi Walter
    I rate your article very highly. Was it your intention to limit the consolidation to the flow and graphic representation of process modelling? Within the context of my own skills and experience, I found missing such components as trigger events, variants, business rules, etc.


  2. Thanks, Kenneth…

    I should have done I,II, III, IV and V to cover these things but too much info would have the effect of scaring people off (i.e. we cannot very well say it’s easy if it it looks complicated). A lot of these “features” are kept “under the hood”, or is it “bonnet” in Australia?

    We probably should include “wait” nodes as an additional construct these really are ordinary process steps that have “system” as a routing. When they execute it’s not that much different from a person step in that they get committed when pre-requisites have been attended to it and when the performing resource makes a contribution.

    However, the different ways in which “wait” nodes acquire their data are many:

    1. another user records some data that “connects-the-dots”. (with 100 forms, the user may not be aware that some input that they make is what a “wait” node on some template instance has been waiting for.
    2.some local or remote system messages the BPMs and the data goes where it is supposed to go but mirrors a copy of the data to the control form that “wait” node is pointing to.
    3. . . .

    Clearly, when a “wait” node becomes current, a timer starts and the system rolls around ever so often and tests its control form to see if it can get back a response of TRUE. Only then does the node fire.

    We have two types of rules,

    a) Rules at forms which have been made to be attributes at nodes/steps, giving the impression that nodes have rules but they do not

    b) global rules at remote forms (i.e. they don’t belong to any node in a process map but are pointed to by process nodes), again, giving the impression that we have rules at nodes.

    In each industry area/application area encapsulation of our engines etc. we do have special “tasks”, one of which for healthcare is a diagnostic algorithm. It basically has a rule set for each disease/condition that allows it to tell a user whether a diagnostic threshold has / has not been met. Users never have to do battle with these.

    There are times when we wonder if the software has not taken on a mindset of its own.

    With 1,500,000 lines of code, every once in a while someone does something no one else has done, reports this to our tech support who sometimes feel the behavior the user has just experienced is “impossible” (not very logical). They would typically have to retract, it’s just that they forget they put in a feature.

    We do discover things the software cannot do and we decide on a case by case basis if we should/should not put in a feature to handle this.


  3. Boris sobocan says:

    I really like this blog. It covers all relevant aspects in consistent and coherent manner.


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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s