Last month at our client briefing, electronic records management systems were a common point of interest, but interestingly, not a common practice. Even though everyone knew they needed to be smarter about using electronic records management only a few companies had taken the plunge. The others, like many of the companies we talk to every day, are managing records with spreadsheets, paper, and home-grown solutions and databases.
Over the past year, we’ve worked with clients interested in both the Documentum Records Management Family of products (RM, RPS, PRM) and Alfresco RM. (We’ll refer to the Documentum Family as Documentum RM for the rest of the article.)While both are DoD 5015.02 standard compliant, they approach creating the file plan, declaring a record, setting holds/freezes, applying disposition, and reporting differently.
Both Documentum RM and Alfresco RM are licensed products. As mentioned above, Documentum RM consists of three products: Records Manager which complies with 5015.2, Retention Policy Services which handles declaring records and applying retention policies and disposition, and Physical Records Manager for handling physical assets such as paper, CDs, and such. The Alfresco RM (Records Management) product includes all of the functions necessary for 5015.2 compliance in one install package. It’s important to note that while Alfresco RM is the only open source DoD compliant records management product it is not free in Alfresco Enterprise and is licensed separately.
In terms of ease of use and intuitiveness of user interface, Alfresco RM is hands down more user friendly than Documentum RM. The Alfresco RM product became available with version 3.2r and is relatively new compared to Documentum’s RM product. The Alfresco RM user interface, now at version 3.4.x, is implemented in Share and focuses on a RM dashlet and corresponding Records Management Share site.
Within the Share site, the records manager can easily set up a file plan, disposition schedule, and saved searches. A separate RM Management Console allows a user to populate lists used in the drop downs for the records and view and file a set of audit trail entries as a record.
Even though the user interface in Share is clean and the product conceptually easy to use the RM product has two significant drawbacks that are not in Documentum RM.
- Adding a document to a folder in a File Plan series does not automatically declare it a record. To declare a document a record, the user must have permission and edit the metadata supplying required values.
- An existing custom content model cannot have RM metadata and functionality added to it; instead the custom content model must inherit from the RM type. For companies that haven’t already invested in a production implementation there may be time to change, but for those that have a custom content model conversion is needed.
While the Alfresco RM product shows a lot of promise, the two-step declaration process and inflexibility concerning existing content models are hurdles to adoption in existing implementations. Many of our clients are looking to add electronic records management functionality to existing systems and do not have the green field system the product seems to anticipate. Nevertheless, with the simple user interface it may be worth a look to see if a conversion project would be beneficial.
In addition, there are a few Alfresco RM resources that bear mentioning.
- Getting Started with Alfresco Records Management document is an excellent primer and very concise in detailing the RM functionality
- The second is a book specifically focusing on the technical under the hood functions of RM, Alfresco 3 Records Management from Packt Publishing. TSG was given a copy of the book for review from the publisher. The book provides an extensive technical reference for Share and Alfresco RM generally but not the guidance on how to specify, design, and execute an overall records management project.
If you choose to evaluate or implement Documentum RM there is no shortage of documentation describing how to install and use the products, but you will need to be a customer.
- The training class covers a simple scenario and details the implementation steps
- Product documentation from EMC Documentum is exhaustive and describes all the configurations and permutations in depth.
The RM training from Documentum is several days of rote memorization and configuration of the retention plan, legal holds, disposition lifecycle, and implementation. In addition to endlessly specifying configurations, there are subtleties for security (privileged clients) and strict roles that govern what records management functionality is available to whom.
Specifying as much configuration as possible before sitting down to work with the RPSA/RMA (Retention Plan Services Administrator/Records Manager Administrator) user interfaces is highly recommended; the granularity of control is powerful but it also puts an enormous responsibility on the records manager. There are many functions such as reporting, retention policy specification and assignment, and disposition that can be time consuming to set up and test. It is easy to get lost in the weeds. In addition, the performance impact from RM can be significant depending how retention policies are applied in the repository, such as in a shadow index or to folders or documents directly. Performance should be tested before deploying to production.
The major drawback for RPS/RM is that it lacks a documented way to customize the user interface and back-end processing. This leaves sleuthing the only alternative approach to identifying customization points. Since it is a WDK-based application and uses typical Documentum constructs customization is possible but the product would be better served by having an easier way to expand or combine its functions.
With the intense interest in electronic records management amongst our clients today we are keenly aware of the effort and complexity required by a records management project. Even if a full-blown RM solution is not possible there are steps that can be taken today that can help prepare documents to be classified or culled as records in the future. We are happy to share our experiences and continue the conversation with you.
Thanks for an interesting post:
>Adding a document to a folder in a File Plan series does not automatically declare it a record. To declare a document a record, the user must have permission and edit the metadata supplying required values.
Could a rule or Java Behaviour be introduced to automate this?
>An existing custom content model cannot have RM metadata and functionality added to it; instead the custom content model must inherit from the RM type. For companies that haven’t already invested in a production implementation there may be time to change, but for those that have a custom content model conversion is needed.
I’m surprised that RM is based on concrete types & not aspects.
Good questions and you are fast with the comments, thanks!
For the records declaration process in Alfresco RM, I’m not sure a rule would be sufficient. Its possible it could be automated with some code but the program will need to be able to complete the necessary metadata elements. (pp 13-14 of the getting started guide if you have the pdf) All in all, it simply depends on if your application has ready access to the information and can populate it programatically.
The content model constraint surprised me too. I had to check with Alfresco to confirm it because it seemed an odd dependency but its there.