The question of the week at BPM.com was

http://bpm.com/bpm-today/in-the-forum/what-is-the-best-way-to-build-an-executable-process-model

[Reading over the material at this discussion, I think we need a few more rounds before the traditional stampede over to a new question takes place.

Scott riled up a bunch of us by stating “Flowcharts (including IMHO BPMN) are simply not a great way to build an executable process model.”

At the 1st post, Emiel threw one spanner in the works, asking what “executing” means.

Here we are at response #19.

My experience is we can execute a model or we can execute a “best practice” template.

The former is a best practice under construction (albeit at a higher level of summary) whereas the latter is, (graphically, for those who relate to flowgraphs), the “best practice”.

We cannot “execute” graphs but we can compile them/interpret them/ scan them/ transform them by carving them up into discrete run-time steps that have various attributes such as the performance skill level needed, data collection forms needed to record data and some mechanism for attesting to the completion or commitment of individual steps.

Scott says the “really fun part” is “press the compile button”. I agree – a lot of behind the scenes things take place when you do this.

The objective is to be in a position, within some run-time environment, where software, machines and/or people can post steps to user InTrays for their attention/action.

Clearly, as one step is completed, we need the environment to provide orchestration by posting the next-in-line steps to the appropriate classes of users.

These users really need orchestration – in healthcare, a nurse can easily need to provide services to 20-50 patients per day, each of these patients will typically be at a different step along a private care pathway (read best practice template) and many patients will be on different pathways at different steps.

The nurses indeed are not robots, it’s totally unrealistic to think that all possible interventions for any patient could be “guided” by a best practice template.

What this means is the nurse needs to be able to insert an ad hoc step at any point.

They also need the ability to skip steps in the best practice, re-visit an already completed step, and record data at a not-yet-current step (i.e. the data has become available) – no point writing the data down on a piece of paper, then waiting for the step to become current and, only then, recording the data in the patient Electronic Health Record.

Lastly, the nurses need to be able to micro-schedule their work, supervisors need to be able to set priorities, supervisors need to level and balance workload across, in this example, nurses.

Can one do all of this on a cellphone? In principle, yes.

Can the run-time system work without orchestration, no. This would mean the organization would have no way to manage its best practices.

Is a flowgraph yes/no “a great way” to build an executable process model? You tell me.

How long does it take to build a flowgraph that captures the steps/directional arrows etc.?

How long does it take to build a best practice some other way? What does the result look like?

If you don’t like to build flowgraphs, even if another way takes five times longer, do it, providing a) you have the time b) the customer is prepared to pay for the end result.

The main lookup I made in participating at this discussion was the advice given by Dr Russell Ackoff. (The Art of Problem Solving, 1978)

The advice was along these lines “Decisions involve choices and if you can’t see the likely outcome of a choice then you cannot make decisions”

My comment . . . .no flowgraphs, no way to see likely outcomes, no way to make decisions.

Execept that maybe there IS (+1, Scott) an alternative to flowgraphs, but we need to see/hear what that is.

Linear task lists clearly are the way to go at run-time. Amit uses them, my group uses them.

A live/batch chat capability is a no-brainer (improves the customer experience or journey).

Once you admit that chats are “a good thing” you are admitting to ad hoc steps and your feet are firmly planted in “Adaptive Case Management” (a run-time environment with governance, with background BPM, with embedded CEM, with RALB or auto resource allocation, leveling and balancing, plus lots of other capabilities) that lets you “manage work”.

I have found a few folks who hold the view that “process management” means building, testing, updating paper process maps. OK, that works for a silo whose output is a paper process map.

For others, the end is a new beginning and the next thing to do is roll out the best practice in a run-time format so as to manage, not the process, but the Case that is hosting various (typically) process fragments and ad hoc insertions.

And the purpose of “managing” a Case is to support or contribute to corporate strategy/initiaties.

And the purpose of formulating strategies/initiatives is to build, maintain and enhance competive advantage.

All of this in support of Peter Drucker’s various statements along the lines of “the purpose of a business is to stay in business”.

A small problem is that for some, the purpose has changed to “let’s buy this company, fire management, put some lipstick on the pig, flip the company and make a lot of quick money”.