Documentum Records Manager

I’ve recently found some time to look at the Records Manager product. Having only dabbled with it in the past it was good to really get to grips with it, and I was quite surprised with some of the things I found.

Firstly I always wondered why Documentum needed a product specifically for Records Management, surely most, if not all, requirements of a Records Management installation could be achieved through out-of-the-box functionality, with some minor customisations/configurations. Having looked at the product now its a lot clearer. Records Manager is based on some basic principles:

Policies: there are a number of policies which can be applied to objects in the repository, these are Naming Policies, Security Policies, Retention Policies and Containment Policies;

Formal Records: the product also lets you declare items as formal records, a folder, cabinet or a document. Actually you create formal cabinets or folders and you can then declare documents as formal records.

Upon closer inspection the Formal Records are actually pretty much useless, unless you are interested in DOD compliance. In fact worse than being useless they create an overhead as they create another object in the repository as the formal record and another one as the assembly for the formal record. Unless you need to comply with DOD I cannot see a reason to do this; but can think of many reasons not to!

So if we use the 4 policy objects we can pretty much deliver a solution which is compliant to the main standards for Records Management and it does not have to look much different to a standard Documentum app. A quick description of each of these:

– Naming Policies. These allow you to put rules around what the users can call their objects in the repository. Looks quite neat but some of the user interface used to create the policies is pretty poor, e.g. you have to type in the attribute name if you wish to create a construct value (why is there no dropdown??). In fact there is no reason why this should not be a standard part of Documentum, I know it would help a number of customers;

– Containment Policies. These allow you to set rules on how the repository is structured including number of levels and what can be put it in what container. Again, looks nice. Could be improved for the end user interface, e.g. if I have said folders should only go down 7 levels why let a user initiate the creation of a folder and then give them an error message, stop it at source! Again though, why not part of the core product?

– Retention Policies. Now of the 4 this is the one which is available on its own and is probably the most important and richest of the lot. I’ll post about this on its own as it really merits this.

– Security Policies. At first glance these look quite neat, enabling you to apply policies to folders based on object types. However they are not designed to work if you take control of the acl of your volition, for obvious reasons. So imagine a scenario where a document is in a lifecycle, yet also has a Security Policy applied. When the document reaches a state in the lifecycle which requires that it is available to a wider audience you lose the benefits of Security Policies. It would be great if policies could be applied based on more than just Object Type and Folder, at the end of the day these are just attributes anyway….increasing the number of attributes which have influence will make things much richer and yet keep some of the nice administration available in Security Policies.

So all in all, a real mixed bag. The policies are, for me, the value of the product and I would love to see Documentum being more imaginative in how they sell this product. We don’t need the Formal Records etc…., they add fat to a product which simply does not need it. I’d like to pick and choose the Policies which are important to the client I am working for and pay for them. Have Formal Records as a DOD add on for Documentum, just don’t call it Records Manager.

Records Manager also includes Physical Records Manager, again this is worthy of a post of its own and I will do that in a few weeks time. First impressions though are that it looks neat but a lot of thought and care will be needed to implement.

Advertisements

4 thoughts on “Documentum Records Manager

  1. Nice Post, me too was already wondering what Records Management added to the product nad how to justify the additional costs.

    Looking forward to your post on Retention policies and Physical Record management

  2. Hi Lee, I totally agree with you. If a content management system was designed correctly from the ground up then it has three core features:
    1. Freely definable object types and relationships (provides naming and containment definitions)
    2. Storage class definitions (provides the retentions policy and also where something is kept and if it has to be digitally signed or encrypted for example)
    3. Role/policy security (defines who is allowed to do what with any object type)

    There you go: That is your Records Management System.

    The main reason that Documentum are selling those functions additionally are sales reasons and second that all their functions and processes are hardcoded and can thus only be expanded by programming which makes even more revenue for Documentum.

    Having enlightened the readers to the above I may say that point 1, 2, and 3 are standard functions of the ISIS Papyrus Platform. Therefore Papyrus can be used as a fully functional Records Management System without the need for buying additional software or expensive customization. Furthermore, Records Management is suddenly deeply imbedded into ALL Inbound and Outbound document processes without additional effort.

  3. Max,

    Remember Documentum is a Content Platform, its not the end result when you buy it. It does need work to fit into the business scenarios required. Having said that its power is in its flexibility. The Naming and Containment Policies shoud be part of the core product, Retention is something which not everyone would like so I see value in not having that as core and as an additional product. The Security Policies are not the finished product in my view, but when they are they should be core.

    I’ll certainly have a look at Papyrus.

    Thanks,

    Lee

  4. Pingback: Documentum Physical Records Manager « Observing Content Management

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s