Anatoly uses an example of a cross-functional process to show how one can dramatically oversimplify how an actual business works - and as a result, write a really "broken" process.
The key insight he offers is this:? a BPM isn't a workflow.? It is multiple processes and inter-process communications.? As a result, modeling a business process is an exercise in modeling multi-threaded systems (parallel programming).? The problem:
- Some people doesn?t see this barrier. They hit it but doesn?t realize what?s the problem really.
- Others instinctively bypass the barrier by implementing BPM pilot projects aiming at processes like ?Vacation Request?. A pilot like this is going to be successful but does it have any value for business?
I believe this is the sources of most of the disappointment in BPM: those who narrow it down to the workflow end up with predictable failure.
Technically, multithreading is what distinguishes BPM from workflow. Remove the interaction between asynchronously executable processes via data, messages and signals and what you?ll get would be ?workflow on steroids?, not BPM.
Unfortunately, this is the case with many software products marketed aggressively as BPMS. For me, the main BPMS criterion is the support of BPMN-style messages. There are other criteria indeed but this is the most useful at the moment. Everything else - graphical modeling, workflow engine, web portal, monitoring - is implemented ususally, better or worse, but many products totally miss inter-process communication. Most likely not because it?s that difficult but rather because no one has explained how important it is.
Agreed-? in fact, in some cases it is useful to model the entity lifecycle (process, you might say) of a critical element - like an Order - as well as the various processes that interact with orders (e.g. production process).? We've taken this approach before with product returns and dispute resolutions, for example - and I often refer to the processes as "orthogonal" - they intersect, but they have different purposes and objectives.? Of course, as Anatoly points out - much of the complexity is the business, not BPMN.? BPMN isn't making the business more complex, after all - it already was that complex.? Anatoly explains:
The name of complexity is business, not BPMN!
Whoever promises a simple solution to business issues, whether it?s BPM or something else - do not believe it. Business is a human competition by nature: smart people are competing for living better than others. Therefore business has been and will remain a complex matter.
The complexity of BPMN isn?t excessive, it?s adequate to the complexity of the business. Students of my BPMN training have no question about why there are so many events: no one is excessive. And by the way, note that BPMN 2.0 is practically no different from 1.x at workflow part - the standard evolves in supporting more sophisticated multithreaded programming: choreography, conversation.
But what really grabbed my attention is seeing a different perspective on the "routine work" argument that we hear so much about from the ACM camp (and I'd be interested to read more from Anatoly on this subject):
They say the percentage of knowledge work vs. routine work is constantly growing. But exactly where is it growing? Mostly at US companies that offshore routine activities to Asia. A predictable observation for analysts located in US. But as soon as the amount of knowledge work grows at one place, the amount of routine work grows in another. And managing routine procedures running on the other side of the globe is the best task for BPM that one can imagine.
He's pointed out a US-bias I hadn't noticed myself (one of the benefits of reading blogs from other countries - increased perspective!).? What he says makes sense - the routine work in the US hasn't gone away - its just been (largely) reassigned to people in other timezones or countries.? With all the benefits and costs associated.