For the increasing number of managers who see Case as the environment of choice to put a focus on defining operational objectives and tracking progress toward reaching operational objectives, cross-Case visual analytics suddenly are a reality.
All that is required is a realization that the relational database management system (RDBMS) model typically used to host Case data needs to be supplemented by a multi-root hierarchical database model.
Never mind the terminology, see a screenshot below of a “multi-root hierarchical” database.
The new reality for individual Case management is that background BPM is capable of providing guidelines, global rule sets are capable of providing guardrails, and that Case is capable of accommodating a mix of structured and unstructured data. On top of this, of course, you need a Case environment.
Export key transaction data from Cases to a Knowledge Base (Kbase) that supports free-form searches and connect-the-dots initiatives and you have the ability to browse structured and unstructured data across multiple Cases.
The problem with unstructured data in an RDBMS environment is that whereas you can index all content and carry out searches within a Case, highlighting “hits”, the model does not easily lend itself to cross-Case searches.
A Kbase, on the other hand, not only allows you to view all “records” at one screen, it also accommodates multiple entity record types at the same screen.
In my warehousing application example featured in the screenshot, you can havesuppliers, product work breakdown hierarchies, distribution channels and customers all at the same screen and engage cross entity/cross case searches. i.e. “show me all transporters, within a 50 mile radius who have NOT moved products from a named supplier to a named customer”.
Your KBase does not have to be a read-only database.
So long as you take care to map Kbase nodes to intervention\steps at Cases, you can have the ability to consolidate multiple entity transactional data at your Kbase and post messages at a data exchanger to generate transactions back at Cases. Nothing wrong with a mix of top-down and bottom-up interventions so long as your entity record systems synch in real-time with your Kbase.
In the normal course of events, users would be busy launching transactions at separate supplier, warehouse, and customer entities.
The mode of use at a supplier/warehouse/customer Kbase on the other hand requires little more than dragging objects from one entity to another.
Since Kbase construction starts with a blank sheet, there is no “application”, it can be whatever you want to make it.
Courtesy to Walter Keirstead. This blog is also available on http://kwkeirstead.wordpress.com/
Follow
