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 :-)