There are two perspectives:
This blog is about the second perspective.
A case management application (or case system) often has a process as its central theme. In the previous update, it was mentioned that this process can be implemented with or without a specific sequence.
In a process without a predefined sequence, we link all possible activities to the case, possibly grouped into consecutive phases. Most case systems of Blueriq's customers roughly follow the phases Request-Assessment-Completion, but of course, this can be freely chosen and adjusted. After all, we are modeling, so these phases are not "hardcoded" into Blueriq.
Each of those possible activities – such as uploading a copy of your passport, filling in income details, downloading a pro forma calculation, etc. – has a rule that dictates when it makes sense or is even necessary to perform the activity.
So, what happens when the process rules – and thus the models – change? For example, when an activity X needs to be added?
In a flowchart (orange), this becomes a big puzzle because how do the arrows continue from there? What happens to the decisions that have already been derived? Do they need to be adjusted? And how do you ensure that old cases still follow the old process while new cases follow the new one? Or perhaps even more complicated: when you want old cases to follow the new process as well?
In a model with separate activities and rules (purple), adding such an activity is easier. You determine which phase the activity belongs to, add it, and formulate the rule that specifies under what conditions this activity becomes relevant. Old cases will show this activity if you’ve defined it in your rule. Much more control and, above all, much clearer.
I could give an even more passionate argument for removing an activity. If done correctly, you’ll immediately see the difference in impact when Y is removed from the orange versus the purple process. The orange process immediately breaks down because a decision was made just before Y, and another one follows right after. There’s a good chance that the second decision relies on what was filled out, retrieved, or derived from Y.
Even in the purple model, something needs to happen because rules for other activities might rely on what activity Y added to the case. But reshuffling lines, rerouting, splitting, and merging isn’t necessary.
Therefore, the term "Dynamic" in Dynamic Case Management also applies to how easily a process can be adjusted. Perhaps this dimension of Dynamic Case Management is less tangible for the consumer or citizen who has an ongoing case, compared to the previous one, but a lot of money is spent on (and wasted in) process changes.
Want to read more? Check out parts 1, 3, 4, or 5.
