This article explores the contribution of a methodology called BPM (Business Process Management) to the “management of work” and lists essential features for background BPM services at Cases.
BPM is core to workflow. It also contributes, to an extent, to workload management. It contributes directly to efficiency and contributes indirectly to effectiveness.
In the overall scheme of things, BPM deals with what, how, who, and where.
It’s one thing to embrace a methodology and another to make good use of that methodology so let’s go over essentials or “must haves” for BPM.
Your takeaway will hopefully be that you will see BPM as core to the planning and management of work, but relatively easy to implement.
BPM has a plan-side dimension (process mapping capability) and a run-time-side dimension (background orchestration capability at Cases)
One BPM “must have” is the ability to document “as-is’ processes.
This is best accomplished within a graphic space where users are able to put down tasks or process steps and interconnect these with directional arrows.
Extending an “as-is” process map to a “to-be” process map requires the ability to re-arrange and extend process steps (e.g. easy insertion of steps between existing steps, disconnecting and easy re-connecting directional arcs between steps).
The transition from a “to-be” process map to a run-time “best practice” process is typically automatic following several process improvement iterations.
I will detail here below four (4) “must-have” features of run-time BPM out of a total list of 13.
See . . . .
“Success Factors with BPM ”
1 BPM Compilers
Auto-generation of a run-time process template is the first BPM “must-have” feature for the simple reason that different steps must be performed by different people with different skill sets.
A BPM compiler solves the problem by carving up process maps into discrete steps for posting to the InTrays of the right people at the right time.
2 Run-time BPM (branching decision box construct)
A second “must-have” feature is the ability along a process pathway (process map template instance) to engage processing along sub-pathways. The required construct for this is a ‘branching decision box” roughly equivalent to a fork on a road except that in an electronic environment, two or more sub-pathways, or all sub-pathways can be contemporaneously engaged.
Two types of branching decision boxes are needed. One, manual, where the user selects from available options, the other, automated, where the software system makes selections from available options based on data present at each decision box.
3 Run-time BPM (loopback construct)
A third “must-have” feature is a “loopback”. This allows a portion of a workflow to be processed two or more times (e.g. call a telephone number and connect or try later up to, say, three times and then take some alternative action if communication has not been established).
4 Run-time BPM (link to pathway construct)
The fourth “must have” feature is “link to pathway”.
In the absence of “link to pathway” BPM practitioners have no way for allowing managers and staff or robots to thread together “process fragments”. A process fragment is any non-end-to-end sequence of steps that does not have a definable objective at the “last” step in that sequence.
To summarize, organizations need BPM to help plan and manage workflow, manage workload and achieve operational efficiency.,
This leaves operational effectiveness as a topic for a subsequent article.
How Low Can You Go? – Part I
How Low Can You Go? – Part II – BPM essentials
How Low Can You Go? – Part III – Case Management essentials
How Low Can You Go? – Part IV – Essentials for Building, sustaining & improving corporate competitive advantage.