When first starting a records management (RM) program it can seem daunting and insurmountable, but once the decision is made to not keep everything forever the real work begins. At its most basic, there are three activities in an RM program: retention, disposition, and holds. This post will present a solution approach that leverages minor customizations and out-of-the-box (OOTB) capabilities to satisfy most electronic and physical records management requirements.
How does this differ from Documentum RM/RPS/PRM?
In most RM implementations we’ve examined for our clients, the creation and maintenance of records, retention policies, disposition rules, and holds are each represented as discrete objects in the applications. While records and holds by their nature are best represented as singular objects associated with relationships, we’ve found that retention and disposition information can be combined and applied dynamically using a single custom Java program and scheduled jobs. In short, we reduce the complexity of the application by relying on existing Documentum objects, a small user interface addition for holds, a disposition program, and multiple jobs.
Records and Holds
By its nature a record should be a singular object within the system, either an electronic document or an electronic representation of a physical asset. Holds also typically need to be represented as singular objects since their presence prevents disposition and indicates a record is frozen. For implementation, we’ve created self-referencing relationship objects that prevent deletion of a record even if a user gains delete access via an ACL. This ensures a record cannot be accidentally deleted when it meets all disposition criteria.
The File Plan – Retention and Disposition
The purpose of a file plan is to make it easy to store, find, and delete records. Unfortunately, when a record is working its way through the creation process, it is rarely organized according to the file plan. Instead, it is organized in a way that makes sense to the people performing the process. For traditional RM systems this results in a disconnected process where the record creator must recognize that the final document is a record, declare it, and send it to the Records Manager for filing.
Taking advantage of the multi-dimensional nature of an ECM system and document attributing, there is no need to put a record in a structure that represents a file plan. Though for ease of use and consistency with tradition or an authority this may be done. The key is that the record must contain attributes that will place it within a file plan category. Using the attributes, the disposition program can find a set of records and dynamically apply retention rules while checking if the record is eligible for disposition.
This post summarized an alternative RM solution that leverages a custom program and out-of-the-box Documentum capabilities to perform records retention, disposition, and holds. There are additional activities that should also be included in any records management effort: periodic review, identification and record classification, disaster recovery and business continuity for vital records. Future posts will discuss those solutions.
For additional information:
- Implementing Records Management for An Existing Repository http://blog.tsgrp.com/2012/12/03/implementing-records-management-for-an-existing-repository/
- Records Management in Alfresco and Documentum http://blog.tsgrp.com/2011/07/28/records-management-in-alfresco-and-documentum/
- Organizing Documents for Easy Management http://blog.tsgrp.com/2012/10/31/organizing-documents-for-easy-management/
We’re interested in learning more about your challenges and successes with records management, please post comments or email us with any questions, mailto:firstname.lastname@example.org.