Adaptive Case Management – the widening picture


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 have suppliers, 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”.

Warehouse

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.

About kwkeirstead@civerex.com

Management consultant and process control engineer (MSc EE) with a focus on bridging the gap between operations and strategy in the areas of critical infrastructure protection, connect-the-dots law enforcement investigations, healthcare services delivery, job shop manufacturing and b2b/b2c/b2d transactions. (C) 2010-2017 Karl Walter Keirstead, P. Eng. All rights reserved. The opinions expressed here are those of the author, and are not connected with Jay-Kell Technologies Inc, Civerex Systems Inc. (Canada), Civerex Systems Inc. (USA) or CvX Productions.
This entry was posted in Adaptive Case Management, Case Management, Decision Making, Operational Planning, Strategic Planning and tagged , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s