Workflow scheduling in the office/services domain is complicated by the fact that not all of the work can be described plan-side using flowgraphs.
Compare CPM (Critical Path Scheduling), a deterministic flowgraph scheduling methodology (where there is one convenient starting start and one converging end step) to ad hoc Adaptive Case Management scheduling in office/services where, at first glance, the only attribute linking any two steps at any Case is time.
In the domain of office/services, we lose the ability to assign durations at some steps (i.e. how long will it take you to complete the invention you are working on?), so traditional ES-EF-LS-LF calculations can no longer be used.
The presence of pathway-embedded decision boxes that carry out branching on the basis of run-time data values takes us further away from plan-side scheduling.
We do have, thanks to BPM, “best practices” process fragment templates for some office/services work, but about the only thing we can say about office/services scheduling at the end of the day is we need an environment that can accommodate any mix of unstructured and structured work.
The mix can vary from 95/5% to 5/95%. Beyond these two ranges you no longer need one of BPM or ACM.
No wonder managers agonize over scheduling, but it can all come together without a lot of fanfare if we facilitate three types of scheduling at Cases and across Cases.
- Scheduling as a result of background BPM (i.e. steps post according to BPM process logic to the attention of workers who are available and have the appropriate skill sets to perform steps).
The posting method used results in each next-in-line step being broadcast to all
workers who have a Role that matches a Role at the step.
The first to “take” the step owns it and is expected to perform the step and commit it.
The owner-worker micro-schedules the step based on his/her specific workload for
Supervisors level and balance workload across workers.
- Insertion of ad hoc steps at worker InTrays by supervisors and workers.
- Insertion of steps or sequences of steps by intercept engines that parse incoming external event messages and post steps to gatekeepers or worker InTrays.
What is extraordinary is the simplicity of the User Interface required to accommodate the above activity.
All you need to manage workflow is a split screen with a traditional calendar on one side and a to-list on the other, plus a refresher course on how to use Agenda books that all of us have, at some stage, used.
Proof that the setup works comes from a realization that everyone, every day, comes to their place of work and first takes note of their fixed time commitments for the day. In between these, we focus on one or more to-do tasks.
Aside from ‘sticky’ to-do tasks (i.e. breakfast meds in a hospital), workers are best left alone to micro-schedule their to-do tasks. Some people like to advance a large to-do item in their InTray, others prefer to “clean up” several small to-do items.
So there you have it, a simple setup for what initially appears to be complex scheduling. It turns out most scheduling is not that complex at all.
But, but, but, you say, “the devil is in the details”. Correct, and here are examples of not-so-easy scheduling tasks that we all face now and then.
Healthcare: When a worker “takes” a task, fails to complete/commit it and goes off shift, “the show must go on” so you need a mechanism called “break glass” that allows virtually anyone, subject to inputting a reason, go in and complete the task or assign it to someone else. An intervention of this kind should only be done following verbal contact/e-mail response because of the danger to patients. e.g. no dose can be fatal, double dose can equally be fatal.
Manufacturing: If you are a government inspector visiting defense manufacturing plants, you need to use a “traveling salesman” algorithm for advance scheduling.
The lesson here is any run-time environment/UI you put together needs to route data collection to a Data Exchanger. In respect of the latter, rule sets can direct data to specialized engines for data enrichment and import back of enriched data for use within the Case environment.
Nobody said it was that easy, overall.