In the previous three blog posts around the Technical Case for Case Management,I've been posting my thoughts on what technical features are truly required to have a complete case management solution.
For today, I'll be raising the requirement for native Enterprise Content Management (ECM) when building a Case Management solution.
Arguably, the relationship between Enterprise Content Management (ECM) and Case Management has been much like the relationship between Workflow and Business Process Management. Workflow is a foundational element to BPM, but workflow alone does not make a BPM system. Workflow is the simplistic routing of tasks from one person to another. Any BPM platform can provide this basic level of functionality, but without a workflow component, the system could not be considered a BPM platform at all.
Similarly, ECM is the ability of a Case Management system to store, manage and distribute a variety of types of content. AIIM (Association for Information and Image Management) defines ECM as:
ECM vendors have historically excelled at providing 1st generation Case Management solutions as they specialized in the ability to capture content in an ad-hoc and unstructured manner, and distribute that content on-demand to knowledge workers. This empowered the knowledge workerwith faster and easier access to data and content, but did not usually help a manager manage the rules, policies and efficiency inhow cases are handled.
Similarly, workflowsoftware helpedusers route work items to appropriate people, but did not help process managers manage the efficiency and distribution of the process underlying the workflow.
Many BPM software vendors are now claiming they support Case Management, but there is typically an underlying problem in how they handle content. BPM products often do not look at content in the same light as ECM systems. Content (the documents and data) is often treated as a BPMN Data Object, or process artifact, and not as a first class object. For those of you not familiar with BPMN Data Objects, you canreferenceBPMN 2.0 spec on Data Objects.
The key conflict around BPMN Data Objects and Case Management is the Data lifecycle and visibility. On page 186 of the BPMN 2.0 spec, the Data Object Lifecycle is described. A data object's lifecycle isintrinsicallytied to the life of its parent process and sub-processes. When the process is disposed of, the data object is also deleted.
Below is a snippet from the BPMN 2.0 spec that shows the relationship between Data Objects and BPMN processes.
This treatment of content in BPM systems is best shown by the ever popular "Attachment". I've seen some BPM platforms attempt to pass-off the ability to attach a document to a process or task as having Enterprise Content Management capabilities. The attachment though is tied to the process and once the process ends, the content also isdeleted. Additionally, the content is only viewable by specified points inside the process.
This treatment of content is just dead wrong in the realm of Case Management. In Case Management, there can exist two entirely different processes that share common Content and Data. Multiple, asynchronous processes may refer to common shared data and content, and the lifecycle of the content is not tied to the lifecycle of the process. Additionally, processes and content each have their own state. Processes have clear states that can be defined as activities in a BPMN diagram and content can have different metadata or properties that define it's state and can be independent of process.
Content and process though are linked. Process, for example, can update the state of dataor content.Similarly, dataor content changes can alter the state of a process.
For example, let me refer back to the medical patient analogy frommy previous posts. A classic example ofthe poor BPM disconnect between process and content is "Doctor Shopping".
"Doctor Shopping" is the practice of patients seeking prescriptions from several doctors simultaneously as to typically obtain alarger quantity of controlledsubstances to support an addiction. In this instance,each doctor is treating the patient as a "Case" using a BPM methodology.This means that the data gathered by each doctor is only available to subsequent steps and actionsinside that doctor'sprocesses, and is not shared with other doctors' processes. The patient is now able to game the system by starting several simultaneous processes to obtain a larger amount of drugs.
One could argue that BPMN does allow for complex messaging and intra-process communications that could prevent "Doctor Shopping", but these models are difficult to construct and understand using the current BPMN 2.0 specification. This is largely acknowledge by OMG and the larger BPM community and a new effort to extend Case Management paradigms into BPMN has begun.
A proper Case Management solutionmust seamlessly combine BPM process capabilities with a native Enterprise Content Management to ensure content and data can be shared across processes and both are treated as first class objects. Instead of locking data and content intoa process as "Data Objects", a Case Management solution has pointers to shared content that can be accessed simultaneously by multiple disconnected processes. Additionally, changes to the state of content must be able to trigger process actions, such as a BPMN conditional or message event.
In summary, ECM has always and remains a critical component of a complete Case Management solution. Common ECM capabilities like:dynamicallysharing content,managing content lifecycle, adding metadata to content, and monitoring content state remain critical components to managing the data and content gathered inside a Case. Additionally, ECMfunctionality provides a great mechanism to bring together common case content into a "Case File" concept to make content access easier for knowledge workers.
Where Enterprise Content Management and Case Management diverge is primarily on their commonuse of the word "Management". What it means to "Manage" content is different from managing a case. Case Management employs content management, but managing the case refers to ensuring the goals and objectives of the case are met in the most efficient manner and in conformance to specified rules and policies.
I appreciate your attention if you've managed to make it to the end of my post. I am noticing that each of my posts are getting progressively longer (purely unintentional :P). I'll try to tighten up the phrasing on the next few posts, but there is certainly stillmuch to be discovered and defined in the realm of case management.
In my next post I'll be exploringhow Collaboration and Enterprise 2.0 features play inside Case Management solutions.
As always, I'm open to comments and feedback.
Thanks,
Malcolm Ross
Director Product Management
The Technical Case for Case Management Series
Part 3: Real-Time Events and Business Intelligence
Part 4: Enterprise Content Management
Part 5: Collaboration / Enterprise 2.0
