I just wrote on why we need Content Management for effective Case Management. It really is more of a background into defining the challenges. Now I am going to focus on how Content Management vendors can help solve this problem.
This is a little like closing the barn door after the horses have escaped. Most of the vendors out there have announced Case Management strategies. After my comments on EMC’s approach, many have felt that I thought that Content Management vendors should stay out of Case Management.
That is completely wrong. They need to be involved. So lets talk about the how…
What the Community Needs
So, what do we, the implementers, need from Content Management vendors. Two words. The first word is flexibility. The second word is where it gets tricky…simplicity.
You didn’t think this would be easy did you?
Why flexibility? Simple, I need to be able to leverage my existing investments and to configure the system to reflect the types of solutions I am building. As I’ve already discussed, for all their similarities, there is a lot of variety in the Case Management world. There is no one-size-fits-all.
Here are the problems I face regularly when I tackle Care Management:
- Matching data schemes with legacy data models
- Synchronizing relevant data
- Synchronizing security between systems
- Creating a record of a case, not just the content for that case
- Working directly with external constituents, both people and organizations (not just through email)
- ONE interface that is intuitive
- Not having to redo everything when one product needs to be upgraded
As you can see, there needs to be a lot of poser and flexibility in those Content Management products. The thing is, a lot of companies have been providing that flexibility for years, many with more than enough power. The issue has been, and continues to be, simplicity.
This is where it all falls apart. In my experience, the client rarely knows exactly what they want the first time out. The first prototypes are usually torn apart in the review session. That’s fine. After I learned that this was actually normal for a Case Management system, I stopped getting upset.
One rule is this: If it takes a lot of work to create the first version of a Case Management system, then it usually takes a lot of effort to change the system. If you change a component system, you usually need to ask for more budget.
Things need to be simpler. More configuration, less customization. More standards-based integrations, less vendor specific APIs or interfaces. Do you know one of the beautiful things about using CMIS in to solve a technical problem? You don’t have to worry about deprecated calls or changing your code when the CMS changes. That is a very nice benefit for those of us doing the work (or managing it).
So that leaves the question, what do we want?
When All You Have is a Name…
Let’s face it. There is no way that I can evaluate, personally, every Case Management offering out there in the CMS market. I have a day job that frequently spills into the evening. I have to look at approaches and strategies from each vendor, mix in the existing systems at a client, and createa short-list.
In general, configuration is better than customization. The ability to customize needs to always be there, but the more that can be done through configuration, the quicker the implementation and any subsequent changes. Configurations also tend to survive product upgrades which much less pain.
To classify approaches, here are some generic terms. It is important to note that some companies use a term for marketing purposes that may not reflect what they actually provide. This can be good or bad.
- Frameworks: These are nice. They offer pre-built starting points. They are very flexible and provide a nice starting point. They also tend to need more customization versus configuration (though mileage will vary). This is still much better than starting from scratch.
- Solutions: This tends to be a more complete offering. Many scenarios can be handled through configuration, though customization is still required for many options. Often, the difference between a “solution” and a “framework” is just a question of the maturity of the offering. Solutions take more time for a vendor to develop as they get feedback from clients.
- Product: This is taking it too far usually. This can become too rigid and not offer enough flexibility. That said, products aimed at specific types of cases, like correspondence management or insurance claims, can do quite well. These should be confined to 3rd party integrators and ideally should be based upon a vendor framework or solution.
For those offerings, the key is that they are built upon an Enterprise Content Management platform. The need to manage the content is the reason that these vendors are in such a good position to capture this market. It is important that the focus of the company remain Content Management in order to continue to be a viable platform for Case Management and all of the other solutions needed by the community.
After all, not everything is a case.
11 thoughts on “What ECM Vendors Can Do for Case Management Solutions”
Pie – Nice article, and your issue have been felt by others too.
I think a lot of the ones you mention in the bullet points of problems can be made to go away IF we can get to a point where one solution does both the data and the content. So rather than having to link an ECM system to A.N. Other system that is looking after the “structured” data (synch issues, security issues as you mention) an ideal would be able to do all the case management in one place. xCP2 MAY be that system… time will tell.
Right now, given the structure of the Documentum database, storing entities that may have content related to them, but not necessarily, is usually inefficient, and not simple. That said, if there was some XML Database that could be plugged-in to handle the data, that could greatly simplify things. 🙂
In general, many systems are not designed to handle both data and content well. That is a challenge and sometimes, it isn’t necessary. Standards will help, but more work needs to be done by both the standards developers and vendors.
I’m interested to see that you posted that without a single reference to CMIS. Do you think that CMIS can push the Content Management vendors into more of a position as commodity to support the Case process? After all unstructured content is one part of a Case, and as I’ve mentioned before decisions made on a case are typically made as a result of structure information on a Case, e.g. Date of Hearing in a Criminal Case.
You read it too fast, CMIS is referenced, it just isn’t the focus of this post. Thinking the next one will cover standards. To answer your question quickly, yes, I think it will allow for Composite Content Applications to be developed that will support multiple repositories.
Yes agreed. So, the efficient and meaningful storage of structured (case) data is one of the things xCP2 is looking at. We need to be able to model and store complex data structures in a non-Documentum-like way. If they can crack this nut, and for example make DCTM / xCP the single-system for case management then we do not need to glue systems together, synch them and have case data in a separate system to case content. Lots of issues gone, all happy in the world etc.
So basically my wish is to forget two systems and lets get a system that handles structured / unstructed all in one place. This removes Lee’s issue below too, as well as ensuring that the “record of the case” is all in one place, one set of security, one set of retention etc. Nirvana?
Pie said “In general, many systems are not designed to handle both data and content well.”
Is that where the NOSQL movement / non-relational databases come in ?
See Jeff Pots article “Alfresco, NOSQL and the future of ECM” at:
Personally I always liked that in Documentum you could have an “Empty” content item that was just there to enable relationships between ‘real’ content items, even if the mechanism is overly complicated.
The answer depends on the system. There is an inherent danger in trying to do everything well, you tend to do nothing well.
The problem with “Empty” content is that there is still the overhead of the dm_sysobject. There is power, but it comes at a price. For Documentum, the XHive acquisition, and the resultant XML Store product, is a resource that could be leveraged. Whether it will, or even can, is an entirely difference question.
One would think since Documentum already abstracts querying of the structure data via DQL, all they would need to do is to rewrite under DQL engine to read/write against XML store.
They also need to improve the integration of XML Store and the tools to support it. Ideally, you would do all your design work from Composer.
The pieces are there though.
Comments are closed.