Just wondered if anyone can advise please? I work in a local authority which provides 600+ services to the public. We hope to use Documentum to manage all case & non-case content relating to these services.
With regard to the case-related content the metadata requirements are all based around common elements – people, properties, projects & events. So one case file type (e.g. a human resources case file) might require a person’s metadata whilst another (e.g. an asset management case file) might require property metadata, etc.
To minimise the development overhead of creating 600+ different case file object types (and that’s before we deal with the non-case content!) we’ve developed a generic object model. At its core this is based on only 2 main classifcations of content – a case related object and a non-case related object. To complement this we’ve also created a generic list of metadata attributes to describe these objects (again in terms of people, properties, projects and events) at the ‘case file’ object level. To define particular instances of each case type (e.g. an asset management case file, or a human resources case file) we’ve used config objects to identify which of the generic attributes are required / mandatory for each case and to put user friendly labels against them (e.g. we replace the standard ‘case ID’ attribute label with an “employee number” label for our HR case files).
Our objectives in doing this were simple – reduce the development time; roll out Documentum fast & wide as quickly as possible; make it easy for users to understand and use (e.g. prohibit them from wading through long lists of objects types every time they want to create a new document). All good so far!
Unfortunately design doubts started to creep in when started to add retention & disposal services. Out-of-the-box R&D seems to assume that we have a broad range of object types to which policies can be associated. We did consider R&D in the early part of the design but we assumed that we’d be able to apply all retention at the folder level. Unfortunately what we’re finding now is that RPS prefers to use object types – particular for things like re-qualification and report writing. We know that we can code alternative processes to deal with this, but it seems a shame to have to do so if the functionality is already there (assuming your model has this broad range of object types).
My main worry isn’t necessarily with R&D (I think this is just an indicator) it’s with all the other Documentum modules that we haven’t installed yet (e.g. workflow, xCP, Centre Stage, etc). By adopting a generic model are we in effect bucking the trend and working against Documentum’s built-in design philosophy? Should we consider extending our generic model and deliberately building a broader range of document object types?
Your thoughts and comments will be appreciated.
