My experience with resource allocation and leveling goes back to work I did for the Bechtel Corporation on a $1 BB hydroelectric project. We built a CPM software system that tracked actuals plus forecasts against plan to dynamically predict time overruns/underruns.
CPM has been around for many years (mid 1950s). It enjoys widespread usage in the construction industry and is applicable to many once-off projects where time, cost and resource allocation are the key variables.
Recently, as a result of building, compiling and running multi-instance workflows in various industries where 100% auditing is required at key process control points (PCPs), we solved a major problem which was how to detect evolving states of non-compliance within cases and take remedial action to avoid actually reaching states of non-compliance (i.e. avoid problems as opposed to fixing problems after the fact).
Our laboratory was a large healthcare organization where typically workflows include decision points that affect branching only at run-time and where timings for some steps are not known until steps become current and are in the process of being performed.
The solution to the problem overtaxed the capabilities of CPM where a) all sub-pathways in a workflow are traversed, where b) ‘plan’ durations are always known in advance and where c) ‘the critical path’ is simply the longest path through a network to a milestone.
With workflow instances that include in-line decision points, there is often no way to know in advance what sub-pathway(s) in a workflow will be engaged, so pathway instances by definition become dynamic. In the case of complex workflows, it is not uncommon that no two instances end up traversing their workflow template the same way.
To make matters worse, in healthcare it is common that durations for some tasks cannot be established until a task becomes a current task.
The question becomes how can you predict time overruns when you are no longer able to project completion dates on the basis of actual plus balance-to-go durations?
After much discussion over a period of months, Civerex developers came up with the notion of ‘countdown alarm’ nodes where a supervisor at an Executive Dashboard is able to view time remaining to alarm nodes across multiple cases.
A supervisor is likely to have ten or more direct reports, each of which can have 10-20 tasks per day to perform, so the task load can be 200 tasks at any hour in a work day.
In the absence of data mining where analysis of historical instances can yield ‘average’ durations for forward tasks along pathway instances, decision making at Executive Dashboards requires a good understanding of steps along a pathway template and how a case has been running.
Here is how resource leveling and balancing takes place at a CIVER-SUPPLIER Executive Dashboard.
The supervisor is able to oversee task loading at each staff member InTray (he/she sees about 200 current tasks)
- Current tasks on sub-pathways that have forward alarms are highlighted in green.
- Current tasks on sub-pathways that have forward alarms (indicating that a state of non-compliance has already been reached) are highlighted in red.
- If a particular InTray starts to look like a Christmas tree, the supervisor can offload work to other users or take back tasks and perform these himself/herself.
- Time compression decisions by the supervisor typically requires consulting the process map – it’s one thing to have four remaining hours on a sub-path that has eight tasks remaining compared to four hours to alarm time on a sub-path that has only one task remaining.
- Dramatic time shifts are the norm and take a bit of getting used to – remaining hours are always based on the longest sub-path to an alarm point as in Critical Path, however as a BPMx workflow instance reaches a decision point node and a robot or human makes a selection that causes branching, if a long sub-path is eliminated by committing the decision node, the outlook can suddenly improve dramatically.
Bottom line, it is possible in an automated resource allocation Orders Management System to ‘steer the ship’ from one computer screen, which is what Executive Dashboards are supposed to be able to accommodate.
Stay tuned for an upcoming post where I will explain how rule sets at auto-decision nodes along workflow instances are able to fire when these nodes become ‘current’.