In Case Management Tips & Tricks I, we explored various means of scheduling work across Cases and across Case workers.
This post describes the range of decision-support and work performance facilities available to users in a typical workflow management environment.
Decision-Support options at Cases range from seeking advice and assistance at process steps to carrying out data mining across similar Cases.
A first consideration when visiting a Case is determination of the current status of the Case and identification of in-progress initiatives capable of providing the greatest advancement toward the Case Objective\Sub-Objectives.
Case -> Case History
You will probably want to review Case History and then talk to one or several Case workers who are contributing to in-progress initiatives.
“Will your proposed added contribution help or hold back progress?” is a question that you and others will need to ask.
Case -> Case History-> Kbase
If a clear plan to attaining the Objectives of the Case is not discernible at the Case, it may be helpful to consult the Corporate KnowledgeBase to see initiatives undertaken at similar Cases at the time these were in a similar state of advancement.
Case -> Case History-> Kbase -> Pathway Hx
A visit to the Process Instance Pathway History will allow you to simultaneously view completed steps, current steps and forward steps. You can view data, as it was, at the time it was collected, on the form versions that were in service at the time. It is not unusual to find several instances of a pathway in progress at various stages of advancement plus several instances of other pathways in progress.
Case -> Case History-> Kbase -> Pathway Hx -> Current Steps along Instances
The logical place to start contributing to a Case is at current steps along one or more pathway instances. Look for low–hanging fruit – instances that are close to completion.
Many BPMs environments can provide context-situation specific HELP at steps. HELP can be in the form of plain text, text plus images, even a video recording.
In respect of Forms parked at steps, Integrity Rule sets are likely to trigger pop ups if, as, and when there are data irregularities (bad date format, proposed end date later than a recorded start date; out of range data, etc.).
Calculation rules can trigger when, for instance, the sum of a series of clustered percent observations exceeds 100.
If steps you wish to undertake are “blocked”, a visit to e-gatekeeper rule sets may give insight to ways and means of unblocking such steps.
Sometimes new data that has not found its way into a Case can be added to advance the status of a Case.
Whereas this data will only impact current and forward steps along a pathway, at times it may be practical to “rewind”, record the new data and re-work several steps (i.e. test results from a prototype indicate that it may be more cost-effective to scrap the current design, roll back and adopt a different approach).
An important consideration in improving the performance of work is to recognize that the time to process steps along pathways is the sum of time spent at steps plus wait time between steps.
Some of the wait time is the result of worker multi-tasking, some the result of handoffs, and some the result of constraints between steps.
Auto-scheduling using RALB (Resource Allocation, Leveling and Balancing) reduces handoff time when skills are encoded to steps. If the organization has, say, five people capable of taking on a step and the step is broadcast to all five, the first available person will “take” the step.
At individual user InTrays, users need to have the ability to micro-schedule their workloads.
This requires a UI that includes a calendar plus a to-do list so that workers can view their fixed-time appointments and micro-schedule to-do list steps in between appointments.
You can avoid buildup of steps for TODAY by automatically tagging steps as Past Due if these are not completed on the day they post to InTrays. It is generally not a good idea to automatically “roll over” Past Due tasks. Users quickly understand that if they allow a buildup of work, a supervisor will level and balance their workload for them.
Supervisors can benefit from inspection of workload across workers at a “dashboard” – if key process points (KPPs) have been assigned late alarms, a supervisor may be able to determine how to accelerate work along pathways to avoid late arrival at KPPs.
At a higher level, supervisors may often need to level and balance workload across Cases.
Most BPMs workflow management environments do not have embedded CPM algorithms, for the simple reason that in an environment where there is a mix of unstructured and structured work with many branching decision boxes, the number of permutations and combinations make it difficult to project Case completion dates.
The author recommends the use of mind maps at Case states where it seems difficult for a group of Case workers to agree on what needs to be done to advance the status of the Case.
A Case will normally close when its Objectives have been met. Not all objectives have the same weight nor it is essential all of the time to attain all of these.
This brings us to the question of how to consolidate multiple sub-objectives to a single top-level objective.
I have found Figure Of Merit matrices to be extremely helpful.
See a post on these at
The only hard and fast rules that work for closure of complex Cases are
- “It ain’t over until the fat lady sings”.
- “At the end, it’s usually just a new beginning”
List of Posts in this set:
Tips & Tricks I – Work Scheduling
Tips & Tricks II – Decision Support/Work Performance at Cases
Tips & Tricks III – Data Exchange
Tips & Tricks IV- Consolidation of Summary Case Data to Executive Dashboards and Corporate Dashboards.