Wednesday, 12 May 2010

BPM not appropriate here?

Keith Swenson used the example of a major amalgamation to indicate an area where BPM would not be applied in his post Where did I put that major airline merger process definition?
Of course that may be true in that particular case, but it is poor argument for decision-making about how you are to manage a process, or processes in general.
I accept that there are things you just do (let's have lunch today...) and that some things come about despite having no obvious plan or process (UK government, eventually) but dispute the premise that BPM should not be playing a part.
One problem with BPM, is the assumption that the process cannot be changed in flight. It seems entirely reasonable that
  1. a process instance should be followed ;
  2. have a “I’m sorry, Dave. I’m afraid I can’t do that.” moment;
  3. and be changed at that point.
Visualising the state in a BPMN diagram allows a view of what has been followed up to a state and what is expected to follow. The executable BPMN engines of today will struggle with a change to in-flight process instances but there is still plenty of development mileage to run there.

Incidentally, scheduling lunch or any other meeting often does need to follow a process while personal assistants juggle diaries. An advantage of formalising those processes is that all the players understand what is going on and play their part in a choreographed fashion. There are a number of function-specific tools that hide the complexity of process involved in some common activities but that does not mean the disciplines of BPM should be ignored.

1 comment:

Keith D Swenson said...

David, see my response to your comment. The problem is one of usability. BPM (the entire category, not necessarily any given product) is designed for mass production of routine processes. The attempt to support routine processes ever more perfectly drives BPM (products) toward requiring highly skilled process designers. Yes, I am generalizing here, but there is solid evidence for this.

I do see a category of product that allows processes to be adapted every time to every situation. We don't need to argue what to call this category. I call it Adaptive Case Management, but you can call it BPM-X if you like. The point is, to support this kind of flexibility, there are certain requirements, and one is that the process model is so easy that 100% of the managers in an organization can do it. We use "ACM" as a handle to talk about these requirements.

The Fujitsu Interstage BPM product has this capability, and it is called Dynamic BPM. It does NOT use a BPMN modeler when creating dynamic tasks. Instead it uses an interface very much like email. This is an interface easy enough for 100% of the managers to use....

There you have it ... you can do this with a BPM product. But I would claim that in this way, this product goes beyond what is considered part of the "BPM functionality". Maybe someday all BPM products will have ACM functionality. IF so, that will be great. Most don't now, though.

See: Adaptive Case Management

Also highly recommend for a thorough treatment of this subject:
Mastering the Unpredictable