Went to a Special Interest Group meeting in my company, around the Cordys BPM product.
A group of consultants had succesfully delivered a BPM solution for a large insurance company, around Claims handling.
While they were modelling and gathering requirements they found:
- It was impossible to model a coherent process front-to-back
- Many events could happen, at unpredictable times and sequences
- If trying to model this in production workflow style, the amount of exceptions was simply too much
- Not all tasks could be predicted based on context...
No need to go on - they found the case management situation.
They created quite a flexible solution, were:
- Certain parts of the process were modelled - "process fragments"
- When a "case" was started, users could decide which tasks (and process fragments) needed to be performed
- During execution of the case, new tasks/fragments (from a standard list + manually defined - single tasks) could be added or removed
- After execution of a task, users could decide (based on business rules) if the case was finished or not.
The interesting part: they build this with a tool that was more aimed at traditional BPM. By a clever combination of some custom code + BPM parts, they were able to create a good solution.
The session did make me think about what a process really is, and what approach to choose to model and automate. A warning there: if you start projects with the production workflow BPM mindset, you will try to fit in reality (if you have a hammer, all problems look like nails...).
What is a process?
I am still struggling with this. Maybe what I will present here is rubbish, but it's a first attempt.
A process is defined as:
- A set of possible events
- A data context (or state)
- A set of possible activities
- A set of rules that govern relations between these elements
The metamodel relations are:
- There are External Events (outside of "world") and Internal Events: change of state
- (Event + Certain context/state) link to a certain Rule, that triggers Activity.
- Activity results in Change in State. Change in State triggers Event.
Now, you could define certain heuristics to come up with your "BPM approach"...
1. If all Events are known, and Each (Event-State) triggers unique Activity, we have production workflow.
-> Deterministic
2. If Certain (Event, State) combinations have NO Rule or Multiple known at design time, but do require an action (from a person!).... Case management
-> Non deterministic
3. If not all States can be defined at design time... Case management
4. If not all events can be definid at design time... hm, exceptions in workflow, or case management.
Hm, maybe it's getting late. But I am trying to find some type of BPM metamodel, that allows us to analyse a business situation more fundamentally, instead of trying to start with a workflow.
Ideas welcome!
No comments:
Post a Comment