Now I’ve been heavily involved in different aspects of Case Management for some time now, from a number of different perspectives, and one of the things which is being pushed heavily at the moment is putting ECM at the heart of the Case Management solution. CMSWire have posted two articles on this subject, Enterprise CMS Usage Scenario and ECMs that implement Case Management Frameworks.
I would recommend organisations looking at Case Management to be vary wary of jumping into an ECM solution without careful consideration. Why? Well one of the key reasons is embodied in the first article from CMSWire but has not been brought to the surface, early in the article they talk about what a Case is including:
“Case Have a Single Location Storage: In a case management system, the information regarding a given client will generally be stored in a single location and in single folder where everyone concerned can access and work on that information. BPMS do not necessarily need all users to have a 360 view, whereas in case management they do.”
Great, and I fully agree it should be possible when looking at the Case to have a complete view of the information related to that Case. However later on there is the following definition of ECM, itself taken from AIIM:
“the strategies, methods and tools used to capture, manage, store, preserve, and deliver content and documents related to organizational processes. ECM tools and strategies allow the management of an organization’s unstructured information, wherever that information exists.”
I’ve highlighted the key term in the quote, ECM is about managing unstructured information, such as documents, audio files, pictures and video files. They are not intended to be used as a Database, although each one can be used in such a way it is a far from ideal way in which to use them. So that leaves the question of where to store the structured information?
In many Case Management implementations one will find that a common construct of a Case is a person, e.g. an applicant in a registration process, a claimant in a Claims process or a suspect in a Criminal Case Management process. Even more important is the relationships that this person may have with the information in the Case, e.g. in a Criminal Case Management system a suspect may have a relationship with a victim, or was the subject of a digital interview. A person is something which is best modelled as a structured piece of information (N.B. I am not distinguishing between Relational or Object Oriented in this use of the word Structured). There are other aspects which are best modelled as Structured including Locations and Objects (such as Vehicles).
Therefore we have a situation where we need to model and manage structured and unstructured information.
Another typical requirement of a Case Management solution is the need to be able to manage the information associated with the Case for the relevant time periods, and to dispose of it properly when needed. This, Retention Management, is a common feature in EDRM systems, its even making its way into SharePoint in 2010! At first glance this is great, but a closer inspection we find that the Retention Policies tend to be driven by the Persons involved in the Case, e.g. in Claims Management it could be a defined period after the Case has been completed or may be driven by Data Protection Requirements, again focussed on the person. So if we have a situation where the structured data is not ideally suited to the ECM system but the Retention Policies are applied based on information held within that repository we have a problem to resolve.
Now I don’t suppose to have an answer to this problem but when looking at the Case Management needs it is important for people to really understand the mix of data they hold about a Case as well as the other requirements which need to be met. If the content is primarily unstructured then an ECM could well be the answer, if there is more of a mix then the solution will need to encompass products which can serve both needs….there will still be a need for ECM if there is unstructured content within that case which needs managing, its just a question of how much of a role does it play. This really backs up some of the points which Pie made in his recent post and which I responded to where the ECM product may just supply some of the platform services but the UI and other services are provided from other products.
Observing Content Management 
I agree with a lot of the points addressed.
Like you I disagree with “Case Have a Single Location Storage” but for me it is even broader than just the distinction between structured and unstructured content.
I would say that information in a case – regardless of structured or unstructured – is located in one or more storage locations. Not just one.
It is not rare for cases to deal with unstructured content that for legitimate reasons does not reside under your control and is located in several repositories.
Think of a virtual patient file (the case) that contains documents from a GP, a surgeon at the hospital and a practitioner at a treatment centre. For valid reasons these documents reside at their ‘ own’ repositories.
Still, the case worker should be able to have a complete view on the information related to the case. This however, does not imply that the content must be stored in a single location. Technology today allows us to create the view without merging all data in one location.
Even for records management this works better because some documents will have a life outside the case with e.g. different retention policies.
And taking it one step further: Image a second case that would need the same GP information but deals with another surgeon at another hospital. Bringing all information for the first case into a single location and doing that again for the second case, does create a lot of data duplication that we don’t want.
Regards,
Ed
Ed, completely agree…your views further reinforce the need to be careful when considering the solution and reinforces the need to consider ECM as a platform service which can be leveraged by different vertical applications.
love this topic – I suggest that case management is ALL about structured information. there may be huge volumes of bits and bytes in unstructured files but the case data (incident, evidence, investigator, hearing…) are all better managed as structured with references to static unstructured – actual storage location may or may not be within the confines of the case.
All case management framewords address the “content” problem – in many respects its the easiest part of the equation. What you really need to look for is a system that effectively manages relationships (containment and reference) through the lifecycle of the case. Some ECM platforms fo this very well – the trick is to get past the presupposition that just because its an ECM platform that it doesn’t manage structured data.
Case management is a lot more than merging together structured and unstructured information. A typical ECM is not able to offer case management except with a lot of custom programming. Case management that supports structured and unstructured processes without needing upfront analysis and coding was named by a workgroup of the WfMC ‘Adaptive Case Management’ while I prefer ‘Adaptive Process’.
Obviously, structured data entities and unstructured content may reside in different places but you do need a central point of control, which would be a system the supports such functionality. Additionally most seem to forget that there is such a thing as STRUCTURED CONTENT, meaning documents that are created in such a process from templates and business data. You don’t want to create those with customer code and MS-Word.
So the question is how do most such systems handle STRUCTURED information without a lot of coding or being built for a particular application, i.e. law or medical records. Most ECM systems don’t and that is one of the problems that is hardly discussed.
Max, thats my point re the original article, ECM systems do not handle the Structured information and thus should not be considered the master applicatin in a Case Management architecture. Thanks for replying.
Case management was one of my first “loves” in the ECM space. It is actually quite simple to discuss and define, it just always falls apart in the implementation.
Lee, your approach is dead-on. An ECM system is a place to store content. It does need some metadata from the case, but only enough to relate it back to the case and/or the entity(s) that are connected to the content.
The case data should be stored in a system that is designed for it. You can build it on top of an ECM platform, but once you get beyond simple case structures, you start to put undue stress on an ECM system that wasn’t designed for this solution.
I see the challenge being the uniqueness of defined processes that start and end a case sandwiching an undefined process, potentially collaborative in nature, to work a case. Having that seamlessly tie together is the key.
The content is the easy part.
-Pie
This is a very topical debate for my organisation at the moment, we still have loads of paper and are very document centric. We’ve just invested in our embryo strategic Case Management system a mix of BPM engine & ECM repository.
As far as I can see where we don’t have structured data stores today (databases) then rather than inventing them we’re better off using XML schemas to define the structure and storing the resultant XML documents in our ECM repository.
This has an added advantage in that we can version control and audit change to structured data (i.e. for evidence purposes) which is harder with traditional databases. This also helps with our retention question.
Finally adopting an XRX approach for applications will allow us to develop new solutions that reuse that data if the ECM repository supports robust interfaces.
John, the problem is the resultant change management to the metadata definitions. Which version of which XML schema are you using where? ow does it map to which external data store and which XSLTs and XSD are used in what part of your case or content management application. Version control for the actual data is not enough.
XML is therefore not a solution. It simply creates additional problems. I am however with you that the transactional mindset of relational databases does not provide enough functionality for managing and data and versions for process and case management.
That is the same reason why we use a object-relational data model that provides full version control of the metadata definitons.
XRX is another X-hype that supposedly empowers non-programmers. Get real please … there is no such thing. Just because in theoretically read by a human that does not mean it makes technological sense or simplifies application development and change management.
Max,
Agree version control around the data is not enough but don’t see that management of the meta data is insurmountable; surely the data package holds a link to relevant XSLT/XSD version(s) (in the CMS) and good schema design should support backwards compatibility? I was doing similar stuff (or at least with similar intent!) with data dictionaries 20+ years ago and to a degree I think we’ve moved backwards.
Maybe XRX is hype, the lack of real development certainly suggests that but I do find it frustrating that we still seem to hand code so much stuff, for the sort of simple data capture solutions we often deploy we shouldn’t have to write a line of code!
John, I do agree. We have gone backwards with XML and Java. That’s why we use a central metadata repository in Papyrus to version and change manage and deploy all elements of the application. One does need logic (in rules or scripts) in some places but also that has to be managed well.
Lee,
Good post. ECM is just not up to the job, it must be part of a holistic solution that provides access to all of the information that case workers and managers require from cradle to grave on a case. Lee Dallas touched on an interesting area about the intelligence that sits in the relationships between “case” entities. I have seen network visualisation tools layered on top of case management systems in order to mine this relationship information for investigative purposes. The output of this can then lead to further cases.
So everyone’s rushing to market with Case Management solutions, yet we’ve been building case management solutions for customers at systems integrators for years.
There is no “Magic Pixie Dust” that can be spread across complex business processes tagged by vendors as case management problems. Caveat emptor.
Niall, absolutely – neither ECM nor BPM is capable of doing the job of case management! Agreed. On the other hand it is a mistake to believe that just because ‘case management solutions’ have been hardcoded for years, that there aren’t better ways to enable that functionality.
Yes, there are people ‘rushing’ to claim that they can do case management like functionality and some are from the BPM and some from the ECM domain. But even that shouldn’t be generalized.
The Papyrus Platform has been available for ten years, has been used for applications that include content management capabilities and lately also BPM like capabilities. It is a perfect case management platform with powerful data modeling and integration interfaces, Web 2.0 collaboration, as well as an embedded rule engine with natural language capability for the users. It even has data network visualization tools you speak about.
But even more powerful is the patented ‘User-Trained Agent’ that learns from user activity to propose actions to participants based on situations in previous cases.
So don’t throw the baby out with the bath.
Pingback: Documentum Renewal: Identity Management « Word of Pie
Good information, Its really great, this blog has got really good information. Keep it up! Good luck for the future success of this blog. Thank you.