We know that Case Managers manage Cases but that is not the end of it.
Cases often need to draw on pooled resources and when the pool runs dry someone has to step in and make decisions regarding which Cases get the resources they need and which ones do not.
It’s hard to anticipate Case demands for resources unless we have structured sequences of steps with resource loading at each step.
Satisfying those demands is typically beyond the boundaries for most Cases, other than ones that own the resource pools they use.
It follows that we need to consolidate copies of Case instances somewhere so that given a start date for each Case instance we can position all instances along a common timeline and see resource demand peaks and valleys.
Leveling resource demand requires an understanding of the relative priority of each Case with stretchout of Case instance timelines in such a way that minimizes damage.
Clearly, leveling/stretchout algorithms are likely to be complex.
Do we throttle back resources evenly across all Case instances, leading to such eventualities as leveling one resource at the expense of others? Do we rank Cases in such a way that the ranking reflects the extent to which each Case contributes to corporate strategic objectives? Do we try to negotiate with the owners of key resources to get them to defer, for example, planned maintenance?
No easy answers here.
The mechanics are easy. Either you build a meta case infrastructure and put in place resource allocation, leveling and balancing (R.A.L.B.) at the top level of such infrastructure or you mirror Case instance data to, say, a Critical Path Method (CPM) or Enterprise Resource Planning (ERP) run time environment that allows you to model and adjust Case instance step durations then import durations back to individual Cases in the Case Management environment.
The latter seems to be the preferred option because most CPM environments support multi-project management, have built-in R.A.L.B. and accommodate import/export.