Why do we need Records Management?

Someone pointed me at Lee Smith’s blog about Records management. He discusses that it is strange that there are separate products for Records Management. I totally agree with that perspective.

Lee writes: /QUOTE

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.

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.

UNQUOTE/

My perspective is the following: 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 reasons 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. All that is very understandable from a technical and business viewpoint and not to be booed at.

But the problem comes later when REcords Management is suddenly no longer a standalone application but has to interact and interface with everything else. Suddenly you will be in deep programming mud.

With the ISIS Papyrus Platform things are quite different. Point 1, 2, and 3 are standard functions of the ISIS Papyrus Platform and used for ECM, BPM and CRM processes. 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.

That kind of consolidation is the future.

I am the founder and Chief Technology Officer of ISIS Papyrus Software, a medium size software company specializing in communications and process management. I wrote several books and hold a number of patents. My quest is to bring common sense to IT, mostly by focusing in human quality issues rather than cost saving, outsourcing and automation. I am also Chief Architect at VIPorbit software which provides mobile relationship management.

Tagged with: ,
Posted in Business Architecture, Content, Records
2 comments on “Why do we need Records Management?
  1. Fred says:

    Dear Max,
    It sounds to easy to be true :-) so i have some questions
    Some questions:
    – Can retention policies be declarative described and dynamically assigned (rules)?
    – Can records be devided in so called sub-files to apply different retention policies?- Is there support for classification schemes aka taxonomy (industry specific) and if so how is classification being done (manual, automatic, pre-defined)?
    – Is there support for audit trailing
    – Is there support for Retention and Disposition Schedules
    – How is backup and Recovery of the records and meta-data addressed?
    – Is there support for schredding (destroying)
    – Is there support for “disposal holds” (to prevent destroying of specific documents)?
    – What about the workflow (e.g. review, approval) of certain actions like disposition?
    – Can records being transfered to other locations, systems? If so, is the orignal then destructed afterwards?
    – Could you tell a bit more about Inbound (capture) does it include also email management?
    – Do i understand correctly that ISIS supports RM for Outbound (how)?

    – Is DoD 5015.2-STD supported (how) and if so is Papyrus certified?
    – Is MoReq2 (european) supported (how) and if so is papyrus certified?

    Like

  2. Max Pucher says:

    Hi Freddy, yes it is true that we support all the items you ask for. I admit the following: Not all processes and object types that one would need to do records Management are already predefined. We define them in the WebRepository in customers request or the IT there can do it themselves. We can provide a default framework but it is not complete as each business has different needs for records management. For example the DOD and MoReq2 standards are not widely needed and while we can support them we do not have a default definition set nor are we certified. We would do that for a project that requires it. As your questions are very product specific I will answer them on my ISIS Papyrus Architecture blog -> http://isispapyrus.wordpress.com/2008/08/30/papyrus-for-records-management/

    Like

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

Max J. Pucher
© 2007-16
by Max J. Pucher. All rights reserved.
Real World Statistics
  • 200,855 readers

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 8,157 other followers

%d bloggers like this: