In the previous blog entry we started to look at case artefacts, specifically case activities and how we should design these at the correct level of granularity.
In this entry we’ll look at case rules, the “glue” that connects case artefacts together at the level of the case.
As of PS6, the design-time for Case Management inside BPM Studio has no “holistic” view of the case and its artefacts, however this is planned for a future release. In the absence of this I’ve been trying to understand how it would be possible to visualize everything that makes up a case and how these things are interrelated.
My colleagues Prasen Palvankar & Ravi Rangaswamy came up with a neat use of mind-mapping to show the case & its relationships….
… I find this great for understanding the questions that need to be asked in the design of a case from within BPM Studio…”who are the stakeholders”, “what are the case activities”, “which documents can be attached to the case” etc. but from this I could still not immediately grasp what my case looked like and the relationship between the artefacts.
This brought me to a spreadsheet approach…. I’ve used this with customers intially to get them to think about what case activities make up the case, their granularity and their inter-dependencies. I then extended this to identify the relevant case rules and if necessary the permissions that attach to each artefact.
In order to demonstrate this approach I’ll use the standard EURent car rental scenario that is available with PS6.
First I wanted to understand what explicit case artefacts the case consisted of… case activities, case milestones, user-defined events etc.
Specifically for the case activities, I wanted to visualise what properties they had…. manual/automatic, required, repeatable, conditional, the importance of which will become apparent later. This resulted in the following spreadsheet….
… that’s it ! Seven types of condition which can result in actions on case artefacts.
Now that we have the activities, milestones etc… for EURent, let us add the dependencies between them where they exist….
Based on the understanding of case rules in step 2 and the defined dependencies in step 3, we can now add the case rules where appropriate….
…as you can see, EURent is only using 4 of the 7 types of case rule. In theory this classification could be used in within the case rule definitions themselves in BPM Studio to group rules into their appropriate categories, e.g. a decision table(s) for “Case Lifecycle Event Rules” etc.. this should help making subsequent management of the rules easier.
Step 5: Extend to Include Security etc.
Based on the knowledge we gained around stakeholders and permissions in a previous blog entry, we could also cross-reference the permission tags for the case artefacts (Note: EURent does not use any tags for case activities)….
In the absence of a “holistic” design-time view of the case and its artefacts in PS6 (planned for a future release) it is necessary to visualize in some way the inter-dependencies. The method outlined above may not be optimal but I find it works for me for several reasons….
Stay tuned for more case management blogs.