The transition BPM aficionados are going through today, moving from neat-looking structured workflows (end-to-end processes) to arbitrary clusters of small workflows (process fragments) and pure ad hoc interventions, is proving to be a difficult one.
It all begins with discovery that once you embrace process fragments, there is no convenient “process-end-node”.
The result is you no longer have, plan side, a place to park process objective(s).
Like it or not, objectives need to move from plan-side to run-time side.
Fortunately, someone/somewhere, figured out that in order to be able to thread together process fragments you need a workspace.
They figured “Case” was the right place to host background BPM (workflow), the right place to host three-tier scheduling (workload), and the right place to position algorithms for assessing progress toward meeting Case objectives (i.e. measures).
As indicated above, Case is a workspace. If you are modeling, it’s a sandbox. Technically it’s just a cursor position in an RDBMS.
If you can navigate to a Case, you can get at everything relating to that Case and this includes structured data (entryfield, checkbox, radio button, list, grid, etc.) plus unstructured data (memo, image, and video/audio). The secret sauce is to put everything IN the Case, not all over the place with “links” to objects.
Objectives are easily accommodated at Cases.
Sold on Case? If yes, then let’s do a stress test.
The thing is I have been telling folks for years that Case lets you manage a mix of structured/ unstructured data and that the mix can be 5/95% or 95/5%, but, can we go to 0/100% or 100%/0%.?
And, if we can go to 0/100% structured/unstructured, are we still practicing BPM?
I say, yes, today.
The reason is has taken 8 years at this blog to “take it to the limit” is that we only recently started to see, in the real world, Cases where BPM can continue to be core in the absence of any workflows (i.e. all of the process fragments are “processes” of one step).
You can visualize this by taking any process you may have and proceeding to delete all of directional arrows.
Such is the starting scenario for the electronic version of Practical Homicide Investigation – Checklist and Field Guide (e-Checklist), where we are taking on the task of “improving investigative outcomes” using “smart software” at smartphones and tablets.
Facts are, the “smartphones/tablets” really aren’t that “smart” in this app.
It’s the investigators who are smart and these folks are more than capable of deciding, across the crime scene investigation team, who should do what, when, how, and why.
Except that we cannot have two different accounts from the same witness re the same event and we cannot have support staff putting down chalk lines and markers before the cs photographer has done his/her initial walkabout.
The command and control center laptop (e-hub) actually has a lot of “smarts” that guide workflow and help to reduce errors and omissions.
If one investigator ‘takes’ a checklist (i.e. a best practice protocol), the software shows the checklist as busy but grants read-only access to others.
The fact that the “system” accommodates near real-time data consolidation means that dynamic decision making at crime scenes is enhanced. Parking a generic data exchanger near the e-hub allows an investigator to send a facial image to a remote facial recognition database and get back “hits”.
In the area of evidence-gathering, it helps to have ready access to finding, collecting, bagging and tagging evidence because there are more than 60 evidence protocols and any errors or omissions routinely result in the evidence getting thrown out of court.
Take a look . . .
I won’t go on, because most of you are not into homicide investigations, so your task for today is to try to identify references to BPM in the 10-minute overview to “e-Checklist”.
You won’t find any.
However, BPM is absolutely core to this app and police departments, as they adapt e-Checklist to filter out checklists that are not relevant to a particular crime scene case (i.e the victim is an adult, no need to consult the “Sudden Infant Death Syndrome” checklist), will gradually put in place process fragments of more than one step each and will evolve rules for preserving, for example, “chains of custody” for evidence.
Another thing you need to know is that “e-Checklist” (an encapsulation of 1,500,000 lines of complex computer code across four interconnected modules) required little more than minor changes in terminology – the workflows were built with the standard version of our process mapping environment; the Case dbms is standard; the checklists were built with the standard CiverIncident Form Painter; the Portal forms that post at smartphones/tablets are pushouts of back end server forms; the Generic Data Exchanger, as you might have guessed, did not need other than a few minor enhancements, so what you have here is a low-code BPM app, where, nominally, 100% of the workflow is unstructured.
Did we take BPM to the limit in this app?
Let us know if you agree. Let us know if you disagree.
“Take it to the Limit”, The Eagles -, “Live at the Summit: Houston, 1976”