Where’s The Beef? – An under the hood look at “seamlessly integrated” BPMs

I keep reading about “seamlessly integrated” BPMs’ (Business Process Management Systems) but when I start to look under the hood, it quickly becomes obvious that many content authors have no clue regarding the needs of organizations in the area of process management.

Reality is they should be talking about “hay-wired” BPMs modules.

Most of the product pitches start with a description of a process mapping environment. Some of the descriptions go on and on about languages/notations. This tells us that the environment being promoted is not end-user oriented.

No end-user wants to learn a new language/notation nor do they want to hire or have to liaise with a team of process experts or software development intermediaries.

The real experts for any process are the folks who work with that process day in/day out. Chances are you need facilitators to drag them out of their silos but with minor prompting, end-users can build, own and manage their processes.

Next in the list of capabilities we learn that there are “interfaces” that convert the graphic process map into, it seems, a run-time template that is “not rigid”.

What “interface” exactly would one possibly want other than a “rollout” button? If there is more to it than this, this is a dead giveaway that the protocol is too complicated and unworthy of receiving a tag of “seamlessly integrated”.

Same for “not rigid” – given we know that managing any Case requires being able to deal with a random mix of structured versus ad hoc interventions.

Any detailed explanation about a BPM template not being “rigid” is a smokescreen for inadequacy in this area.

We all know that at any step along any process template you may be required to reach out to a customer (or some outside system/application) or accept input from a customer or outside system/application.   If “rigidity” has to be highlighted, other than in a historical account of the evolution of BPM, the setup is too complicated.

Strike three!

I could quit here but if any readers are still with me, I am not yet done with the rant.

Here goes – at any process template step it’s a given that users will need to collect data.

These software systems therefore need at least one form at each step/intervention and, from an end-user perspective, the form needs to be local to the step.

Same for all manner of .txt, .doc, .ppt, .pdf, .xls, even video/audio recordings that may relate to a step. All of these need to be attributes of steps, not off in some “shared” repository.

What end-users want/need is real “seamless integration” and a modest amount of “interfacing.”

Clearly, when they click on a .doc attribute at a step, they want interfacing with MS Word, not replication of word processor functionality within the Case environment.

Why multiple references to Case?

The thing is we want the primary focus to be on reaching objectives and if “work” has become a combination of ad hoc and structured interventions, we pretty much need to host all of this at a run-time environment that lets users decide what next to do, when, how (ad hoc intervention capability), with some “guidance” attributable to background BPM process templates. Clearly, it’s not only all about BPM.

We also need to look to the environment to “rein-in” extreme excursions away from policy/procedure (global case-level rule sets, if you like). Otherwise you have no “governance”.

Case provides all of the necessary functionality, including data exchange plus auto-buildup of a longitudinal history of interventions (how otherwise would a user be able to decide what the next intervention should be at a Case?).

The real icing on the cake in some of these nonsensical pitches is references to “process objectives”.

If you no longer have “processes” (what we have today are “process fragments” that get threaded together by users, robots and software at run time), how can/should we expect to find objectives at process template end points?

No processes, no convenient end points, no objectives.

The answer is objectives have gone from being plan-side attributes of process maps to run-time attributes of Cases.

Once you venture into areas where there is a need to accommodate a random mix of ad hoc and structured interventions (i.e. most business areas today except where we may find a few not-yet-automated end-to-end processes), it is the Case Manager who decides what the objectives are for a Case and they, not BI analysts, nor IT, park these objectives at each Case.

Case Managers also monitor progress toward meeting Case objectives and this typically requires fairly complex non-subjective decision making, not simple counting of the number of remaining steps along a process template pathway.

See posts I have made on FOMM (Figure of Merit Matrices).

Just last week I read some promotional material announcing a ‘transition’ to “Case”.

I pointed out to the authors that Case is not new, that it actually is a term borrowed from the legal profession and was alive and well in the UK in the area of medicine from as early on as 1603.

They have not thus far responded to my objections.

It’s easy to determine within healthcare whether there is a focus on Cases.

Just walk into a clinic/hospital and ask if you can talk to a Case Manager. You will probably have a roomful of choices and some of these folks have been doing Case Management for decades. They have job titles, job descriptions and really perform “Case Management” day-in/day-out.

Most of my readers, aside from members of the flat-earth society, are starting to get this. Except that the way things have been going lately, we may very well soon have a flat earth, so they may end up having the last laugh.

“Case” – not new, not close, no cigar.