In the area of computer programming, “small” is a good thing.

The major contribution of Object-Oriented Programming is to generate small pieces of code that are generic as opposed to being specific and that are capable of re-use and extension. This leads to more robust code that is easier to maintain.

We can use the same approach for process mapping by replacing ‘cast-in-concrete’ processes with process fragments and allowing software or people to thread these together at run time to manage workflow. Flexibility increases, maintenance effort decreases.

Here are several ways process fragments can be threaded together at run time in a Case environment.

1. Daisy Chaining: Set up process fragments so that at the “end” of one, there is a construct with a hard link to another process fragment, or several process fragments. This type of “daisy-chaining” can go on and on. The daisy chaining can be recursive subject to a global rule (i.e. repeat no more than three times).
2. Link To Pathway:  Any form attached to a process step can have one or more “fields” that look at recorded data and engage link processing on the basis of data element values. It’s easy to see the value of this in medicine i.e. if a checkbox called “suicidal” is checked, the system can engage emergency handling protocols.
3. Key Process Point Protocol Launch: At any Key Process Point (KPP) along any process fragment, the system can consult a hidden checklist and launch processing based on data at the checklist i.e. QA requires PASS or better at eight inspection points, if any one result does not meet the criteria, the system can engage appropriate re-processing.
4. Revolving Door: An end-of-fragment construct that calls a services inventory can help to ensure that Cases do not become orphans. The construct can be a manual decision box (“what would you like to do next?). Or, the construct can be a system-role decision box where each option is capable of auto-evaluation to TRUE/FALSE.

 The problem with #4 is all you need is one fragment with a missing end-of-fragment      “revolving door” facility and the Case becomes an orphan.  If a user terminates a fragment, the outcome is the same.

Looks like we can achieve pretty good governance with the above whilst a Record is ON a process fragment.

BUT, everything falls apart if the Record in not on a process fragment.

We know this can happen because users need to be allowed to skip steps as well as exit abruptly from any process fragment.

It gets worse.

In an environment where there is a mix of structured and unstructured work, users, left on their own are free to do what they like, which includes never engaging any process fragment, so how do we achieve governance from the time a Record is created until it is archived?

Here is where ACM comes in.

You probably noticed the qualifier re threading together process fragments i.e. “… in a Case environment”

CASE is the hosting environment of choice for all BPM (i.e. structured) work and all ad-hoc (i.e. ACM) work.

We can easily achieve governance within a CASE by presenting a single entry-point to Users that takes the User to a “services menu”.

The problem of orphan CASES is eliminated – a simple query tells you which CASES are not on any workflow.

Users at service menus find all possible actions that the organization accommodates, subject of course, to “need-to-know” (e.g. you cannot write checks unless you have a Role of Accounts Payable).

A services menu does not constrict users because one of the entries on the services menu is “None of the above”. But some processing such as “ship” can only be engaged from one services menu item that puts the Case instance on a pathway where the first step checks to see if QA has been performed on what is to be shipped.

If we augment Service Menus and Roles with Key Process Point (KPP) Rules, we have the wherewithal to achieve Governance along process fragments. Users are largely unaware whether they are calling up a process fragment comprising several steps or calling up a process of one step.

All of this effort (i.e. BPM, ACM, Case, Workflow Management) pays off in two ways.

It puts the “M” (management) back into BPM and turbo-charges process management (i.e. ACM plus BPM is greater than either of these on their own).

As in computer programming, re-use and extendibility via process fragments makes for consistency in areas of work where this is important.

The use of Process fragments greatly reduces maintenance and the need to re-deploy large processes.

Courtesy to Walter Keirstead. This blog is also available on http://kwkeirstead.wordpress.com/

Follow