Tuesday, February 13, 2007

On serial thinking and case management

It's funny - how much people will start to think accoording to a tool metaphore, and forget reality. Dealing with business stakeholders, I typically walk through existing process documents (flows, diagrams, etc). During these sessions often we come to a certain proces, where a lot of steps are modelled, all done by the same user, modelled in a strict sequence, with a lot of business rules (e.g. research 1, if A, continue. research 2, if B, continue. etc.) Standard question: do you really do these in sequence?
Typically, the answer is... NO. A business person will do these in parallel, might skip a step, and will often have their own preference in which to handle first, and last. And usually, also the business rules are not done in sequence, but as a full-check.
E.g. the proces may look like:

Act1 -> CheckA -> Act2 -> CheckB -> Act3 -> Check C

And the business will do something like:
(In any order 1, 2, 3) -> (in any order A, B, C).

These leads to a number of observations:
1. Make sure that your model represents reality working
2. If something is not sequential, don't model it like that (even though it looks simpeler)
3. Wonder why sometimes users hate workflowmanagement solutions? Big chance they are forced to do things sequential, while reality or preference is different.
4. Try not to model all these rules in your process flow. Make it one decision case, and stick the rules in a rule engine....

Now, matters turn worse, if sequential oriented BPM modellers start trying to modelling processes, where the process is more a casemanagement business situation.
Casemanagement - difficult to define, but let's give it a try:
- Typical business process management solutions provide for production workflow - you can define a process template, and process instances will follow the process as defined in the template. There is always ONE point where the process instance is (except for maybe parallel tracks, but also there, there is always ONE point where the process-instance is, in that track).
- What if you have a situation, where the issue at hand (an order, a claim, etc), has a lot of different scenario's, which complicated timing dependencies and what-if's. For instance - a legal procedure, with many sidesteps, possible escalations and subprocedures. Trying to model that in a production workflow is seriously difficult - you end up with an almost unreadable diagram, with many many business rules, and not something elegant, agile and maintainable. Believe me, I've been there...
So.... what do we need? Technology that allows us to create unique process instances, where (in parallel) a user (or a system) can activate certain subprocess templates. A user interface that can help users with this (check out Flower, a dutch product).
And a modelling language that can support this. Ouch. We are talking state transititions, user selectable sub-templates, and still some way to know progress and termination. I would doubt BPMN is up to the task....

As observations:
- When you notice you are dealing with a complex business situation where production workflow modelling feels limited and create overly complex diagrams, you are probably on the wrong track...
- Don't try to squeeze a frog in a pan, don't try to squeeze a complex business situation in a too limited expression language such as BPMN.
- For now: create some kind of state diagram, an sub BPMN models + a lot of explaination :-)

1 comment:

Roeland Loggen said...

Good point about the way to deal with complex processes. Top-down, without loosing oneself in details. I agree.
However, the granularity depends a bit on the context.
You already pointed out one aspect: the process monitoring. In some cases, operational management stakeholders might be interested in certain KPI's that are tracked by measuring certain process activities (e.g. BAM). That will determine part of your process modeling detail level.
Another aspect is the process automation. If certain parts are straight through, more details might be required, up until the correct services to call.
And a third asxpect is knowledge management. If modeling was done for KM purposes, again the user requirements are key and will determine depth. Certain parts of the process might be straight forward and can be defined at a global level. Other area's might require specific step-by-step legal/compliance issues, and users might ask that those parts are modeled in more detail (but in that case a more clear textual description might sometimes be better).

But in generally: yes, BPM is in my opinion not about getting ALL details, but about managing processes to goals - "JEM" Just Enough Modeling should do.
Just Enough is driven by requirements: what goals are the stakeholders of the process modeling effort trying to reach?