I have a client who has been with us for years. They have been using one of our healthcare products for Case management but somehow never got around to using the workflow management module.
Recently, they started up a new division and asked us to help with streamlining of their operations.
This included mapping out processes, assigning roles to process steps, attaching data collection forms to steps, compiling the maps and rolling out processes to a run-time environment where BPM was able to provide background orchestration and ACM was able to provide governance via global rule sets.
We rolled out each process, invited a group of stakeholders to take on featured Roles and piano-play a few process template instances. As anticipated, we got feedback on the process logic and forms (steps with bad Role encoding, steps in the wrong sequence, wrong forms at certain steps). The versioning turnaround time in most cases was immediate i.e. change the Roles, change process logic, change process step forms then re-compile and roll out a new version.
Since the mapping was done in real-time with the active participation of stakeholders and since the environment lent itself to close to “instant gratification”, it did not take a long time to “improve” the processes.
Unfortunately, for most organizations, the BPM story ends here with delivery of a mapped, modeled, improved process on paper.
The real purpose of BPM, in our view, becomes evident when you put processes in a run time Case environment where you are able to achieve orchestration from BPM and achieve governance from the Case environment.
You need automated resource allocation, leveling and balancing capabilities (R.A.L.B) at the Case environment so that process steps from multiple Cases\process templates\instances post automatically at User InTrays as and when steps become current along what typically works out to be a Case load of 20-50 patients in healthcare and possibly 100 interventions per day of Day Orders for a worker in a job shop manufacturing setting.
Without RALB, workers do not have an easy time prioritizing (micro-scheduling) process steps that post to their individual InTrays nor do supervisors have an easy time leveling and balancing workload across workers.
The other thing often missing is Interoperability – if your Case environment is not able to export data to local and remote systems and applications and import data from these, your Case environment becomes a “ivory tower” where decisions are made in the absence of current data that could have an important bearing on such decisions.
Being able to manage workflow at Cases is all important because Case automatically gives you a history of all interventions at any Case with date/time stamps and user “signatures”. You get to see Case data, as it was, in reverse chronological order, on the form versions that were in service at the time the data was collected. Case plus interoperability allows workers to make decisions based on past and current data and if we add in predictive analytics, workers have the wherewithal to carry out “Case Management”.
It’s hard to imagine how e-Case Management would be incapable of providing at least a 30% improvement in productivity.
If we add onto this increased throughput as a result of having next-in-line steps post immediately as current steps along Cases\process templates\instances are committed, decreased errors as a result of in-line step-specific rule sets, and improved compliance as a result of Case level governance it is hard to understand why so many BPM initiatives quit at the paper process map stage.
A possible explanation is that BPM imposes rigidity in respect of the performance of work. This makes it difficult to get workers on board and even more difficult to sustain your BPM initiative.
Facts are if you inventory all of your BPM processes at a Services Menu and then include in this inventory a reasonable sub-set of individual process steps as “processes of one step each”, your software users will never feel constrained by BPM – they can, at any time, simply by selecting a menu item at a Case, revisit already committed workflow steps, insert steps not in the process template and record data at steps not yet current along a BPM workflow.
The final discovery once you get staff on board with e-Cases is that with Case-level governance you are likely to discover one worker performing interventions using a process template, with another worker, for whatever reason, performing the same scope work via a number of seemingly, except to that worker, unrelated ad hoc interventions.
Since both know what they are doing (i.e. we hire knowledge workers with the presumption that they know what to do, how to do it), it’s not surprising both are able to reach the same goals/objectives.
The lesson here is clear – make sure you go “the extra mile” with BPM. You can do this by combining BPM, ACM, RALB in an e-Case environment that accommodates interoperability.
The elevator pitch to CEOs/CIOs is easy – workflow management environments provide orchestration (the center line guidelines along a highway) plus governance (guardrails on the sides of the highway).
The benefits are increased staff efficiency, increased throughput, decreased errors, improved compliance with internal and external rules and regulations, all of which lead to improved outcomes and increased competitive advantage. With a potential 30% productivity improvement, ROIs should turn positive in 12-18 months, with clear sailing beyond this.
The punch line is – “when you have ways and means of doing the right things, the right way, at the right place , at the right time, using the right resources, there is not much that is likely to fall between the cracks”.