Data-First™ and Dynamic Case Management
Why modeling DCM systems is the inverse of BPM modeling
I recently held a webinar titled “How Dynamic Case Management turns BPM on its Head.” In fact I did it more than once because the response was so overwhelming and not just from DCM or BPM practitioners, but from individuals across the enterprise looking to implement enhanced systems of engagement. The two areas that people are most interested in exploring further are:
- What does Data-First™ mean?
- How can a focus on data improve constituent engagement?
A Bit of Context
As business people we require three basic elements to efficiently oversee operations:
And if we are going to build a system, it’s pretty obvious that it must be able to accommodate and manage these elements for us.
- Information may be any combination of structured data (information in a database, forms) and unstructured data (documents, audio files, images).
- Policies may be standards-based (HIPAA, NIST, etc.) or may be domain based (industry or business specific).
- Procedures may be structured (rigid processes) or unstructured (state to state).
If we are building a case management system it is best to do it in the above order beginning with information (data) followed by policies and finished off with procedures (if necessary).
Data-First is a simple concept. It simply describes the fact that in modeling a case management system that you start with the information (data) model. Policy modeling comes second. Process modeling comes last (and in some cases there is no process modeling at all).
At its core a case is information. A case is an aggregation of structured and unstructured data that knowledge workers will guide, collaborate, and rule on with a goal of delivering an effective and appropriate outcome. If the information isn’t correct or comprehensive no matter how good the process is we can’t effectively manage the case. So in the world of case management, information is king. We therefore begin with data modeling, building the system around the information we are going to manage. We will also design the “states” that the case will reside in. There will most likely be an initiation state and a completed state, and any number of states in between the two (such as information gathering, review, ruling, etc.).
Once we have our case’s data model completed we might want to employ some policies to govern how the case will be managed. Policies can be standards-based, domain-based, or may be unique to a particular organization. For example, an organization may have a policy that everyone must be at work by 9:00am. By capturing this policy in the system we can set up listeners for violations of the policy. These listeners can in turn can trigger other actions. In this scenario the case would be the employee’s file, if that employee arrives late the system might fire off an email to the supervisor alerting them to the fact that the employee is late.
This is also a point where case management systems diverge hugely from BPM systems. We can actually stop with our system modeling once we have added policies – we don’t necessarily need process.
In our above example the employee’s case resides in the “currently employed” state, the supervisor has been alerted to the “status” of the case (the employee’s tardiness), but the subsequent actions by the supervisor can be left entirely to that knowledge worker, there may be no official process for how to handle tardiness – the system can be flexible and absent of associated process.
Most case management systems however employ processes. They may or may not be end-to-end processes but there will probably be some. Here we employ the concepts of “state modeling” and link the states together to form processes. We can make the process very rigid (like BPM) and only allow our cases to flow from state to state in a fixed order, or we can be very free-flow and give the knowledge worker the ability to choose which state a case should reside in at any given time, or (as is most common) some combination of the two.
Why BPM is Challenged when Modeling Case Management Systems
BPM platforms begin with process modeling and move up the stack, adding policies and finally data – a fine approach if you are building a rigid, process-driven system. If there is going to be a lot of unstructured, knowledge worker guided workflow in the case management system, starting with process modeling is going to be challenging.
At their core case management systems are data intense. They manage the investigations, appeals, claims, correspondence and other matters that affect our daily lives. If the data isn’t correct or comprehensive and the relationships aren’t complete, it doesn’t matter how good the process is, the system won’t help generate appropriate outcomes for the constituents it serves.
Questions? Feel free to contact me to learn more about our Data-First approach and how entellitrak can address your organization’s case management needs.
- Answering Your Questions about Partner Sales Enablement February 5, 2020
- Introducing Chris Flores, Vice President of Global Alliances January 15, 2020
- 6 Tips for Stress-Free Software Adoption December 11, 2019