Anyone who knows how to read a software feature matrix can
compare line by line the details of functionality between two ECM systems. What
I’d like to do is hone in on aspects of these comparisons which are fantastic
or frustrating, and in some cases, mindboggling.
First, we’ll look at configuration, then we’ll look at using
the tools.
Config: Document Types
In both OnBase and DCTM software packages, doc types run the
UI show, that is, they function as the core of metadata, permissions, interoperability,
functionality, forms, etc. When you do anything with content, you start with doc
types. The underlying database and application designs for each app shows
itself in the doc type configuration differences. Besides scaling and
performance considerations, I’m guessing some copyright patents mess with the
best ways to design certain functionality as well. I will show you some of these
later.
In OnBase, there is a doc type group and a doc type, that’s it. You cannot create a hierarchy of types like in DCTM. This has many ramifications good and bad. This limits the potential for complexity, which plagues some DCTM object type designs. However, you can’t use doc types as an organizing factor for more than two levels of categorization in OnBase, which is annoying in medical records when you have hundreds of doc types and one doc type group called, “medical records”. Picture constantly having to scroll through hundreds of doc types for each search, retrieval, scan queue, etc. It’s not productive.
Change Management: A huge plus of OnBase is that you can version a doctype. This allows you to add/delete/change metadata and move on with the modified doc type definition, leaving the previous version with the old content. This is huge when you consider records and auditing. In DCTM, you would have to modify the existing doc type which would change all the previous content, or create a new doc type and migrate the old content. A real hassle if you've ever done it.
Config: Metadata
OnBase’s label for metadata is “keyword” which is confusing
to most ECM folks as it can be associated to the Dublin Core metadata standard name
of “keywords” which means any related term to the content being described. So,
OnBase’s “keyword” really means metadata (attributes, or properties) of the
document. In both, we have system level metadata like file path, size, format,
name, etc.
Change management: Onbase has cool feature which allows you
to set multidoc keyword changes on a keyword. This allows for changing values
of a metadata across all docs. Of course, you can do this in DQL. DQL still
remains a powerful tool for the right person, and a dangerous one for others.
Part 2 looks at relations in Document and Onbase and compares some of them.
Part 2 looks at relations in Document and Onbase and compares some of them.
