Your BPMs shopping list

Blog: KWKeirstead's Blog

If you are in the market for a BPMs, you may be better off looking for a BPFMs (Business Process Fragment Management System).

Please don’t make this into a new acronym – we don’t need more acronyms with “Intelligent Business Process Management”, “Agile Business Process Management”, “Dynamic Business Process Management”. I am here to simplify things, not complicate them.

The thing is in today’s business world there are very few remaining end-to-end Business Processes to map.

Corporations long ago automated their continuous and end-to-end processes with the result that most of all we have left are “Process Fragments”.

What’s the difference between a Business Process and a Business Process Fragment?

Basically, It’s the presence or absence of objectives at flow graph end nodes.

Business Process flow graphs conveniently dovetail into a terminal node which can accommodate an objective. Get to the end node and you have reached the objective.

Business Process Fragment flow graphs, on the other hand, have no plan-side objectives.

You get to the end node of one process fragment and a robot, human or software threads the end node to another Process Fragment.

Of course, you could thread process fragments together plan side but this would require that you anticipate all possible eventualities and that you have in place rule sets to guide the branching down specific pathways.

Do the math. The higher the number of decision branching points toward the start of a flow graph, the higher the number of permutations and combinations. Easy in a relatively simple flow graph to get to 500,000.

It’s OK to let your knowledge workers do some of the decision branching. The usual reason for hiring knowledge workers is that they know what to do, when, how, and why and if you deploy them properly, where. .

If you are worried about allowing knowledge workers to pick the branching at run time, you probably should not have hired them.

Under the new era of Business Process Fragments, how do we know, plan side, when we are done?

Answer, you don’t.

Objectives move to run-time Case environments where a Case Manager decides when objectives have been met and it is OK to close the Case. (i.e. “It ain’t over until the fat lady sings”)

Now, it’s obvious from the above that our running list of “must haves” includes a) a graphic process mapping facility, b) a compiler so you can roll out templates of your graphic process maps, and c) a run-time environment capable of providing workload management across orders and users in the context of scarce resources.

You need d) global Case level rules so that as and when users deviate from “best practice” protocols, (i.e. skip over steps, perform steps out of sequence, perform ad hoc steps not in any process fragment and thread together process fragments in ways that are less than ideal), these users will be tripped up by such rules.

You also need e) a repository so you can look back over time and see who did what, how, when and where.

And, you need f) the capability to import data and export data from/to 3^rd party local and remote systems, including customer systems and applications.

So, there you have it, your complete shopping list for a BPMs.