Friday, June 08, 2012

The BPM pattern challenge?

Dear Readers
   I have been doing some deep thinking about the value proposition of BPM. The modeling environment, the execution engine, the admin console, the user tasks engine, the reporting and the list goes on...
In this laundry list of features, users may often overlook the very reason why they needed a BPM tool in the first place. The reason people decide to do BPM is to run their business - with accuracy, promptness and absolute fidelity; and they want the ability to change their business based on new market conditions "VERY" rapidly.
    If this is the reason why you are doing BPM - to run your business process with absolute fidelity - then dont be fooled by the laundry list of features - go for the kill. Can the BPM tool in Question run your business process with "ABSOLUTE FIDELITY" - can it "CHANGE RAPIDLY"?
   I argue that most tools cannot. And I am doing so with the experience and conviction that I have.
   And the reason we started building Roubroo was exactly the above - to be able to execute what your business process is with absolute fidelity, sometihng that we call "WYDIWYE" for the past couple of years. Sometimes, it is difficult to articulate the value of process fidelity and WYDIWYE - but probably it is easier to articulate the value of not having it. Ask the following Questions:
1. Does your tool let you model the process you want to draw? Or does it draw extra gateways etc as you model, trying to "help" the modeler?
2. Does your tool execute the process as is?
3. Do you have to call in your IT folks to code wait conditions or other checks to work around the limitations or as they say "features" of the said tool?
4. How rapidly are you able to add or remove steps?
5. How easily can you change the order and dependency of the steps - change the flow logic of your process?

I think if the answer to any one of these questions is No or the estimate of change is more than a matter of day (I wanted to estimate minutes but to be more benevolent, or couple of days) - chances are you are dealing with the wrong tool.

And the reason is not that someone made a mistake, its simply that these tools were built without the correct execution semantics. This basic and fundamental power is buried under layers of tooling and feature lists which is hard to argue around - every vendor claims they have all of these items in their feature list. What they dont tell you is what is at the core of the engine. What are the mathematical fundamentals around which they built the process engine?

I will leave today with a few examples and I will ask you friends to enlighten me if your BPM tool can build these patterns in a matter of minutes or not?

Take a look at these patterns - I have built only 4 for now, to see if the tool you have chosen can support your business process with "ABSOLUTE FIDELITY". And mind it these are the simplest of examples with no more than 4-5 steps required to demonstrate the BPMN 2.0 pattern. When we start modeling the real business processes there will be combinations of these patterns at play.


Bruce said...

Very interesting, but the semantics of your first example are ambiguous. As drawn you have multi-merge at Fan Design, meaning you do this task twice and also do Mechanical Design twice. That does not make sense (to me); also the join semantics are ambiguous - wait for 3 tokens or 2? I suspect maybe you meant join at Fan Design, which would require a gateway. Is it multi-merge or join?
--Bruce Silver

Vishal Saxena said...

Thanks Bruce for pointing out. AS you know I have been a big proponent of implicit OR semantics in case of multiple inbound sequence flows. Anyway, I have added the missing IOR gateway before Fan Design to illustrate my point.