Documentum and SharePoint – Key differences for document control applications

We have recently begun working with a couple of clients on potential migration efforts from Documentum to SharePoint for their document control applications.  In preparing for these efforts, we are in the process of upgrading OpenContent, OpenMigrate and even parts of HPI to run on either SharePoint or Documentum.  For this post, we thought it might benefit those familiar with Documentum to understand the differences for a typical control application.

Search

Documentum users tend to be pretty proficient at using the Documentum search for finding the right information.  In a document control application, a typical search might be “show me all SOPs for any plant that include this equipment number”.  In Documentum, this would be a search on both attributes (SOP doctype, plant) and full text (equipment number) and could either be accomplished with Webtop Search, HPI or another search interface.  For SharePoint, the search is somewhat more difficult for a couple of reasons:

• SharePoint is divided around “sites” with each site having a library.  In an instance where there are multiple plants, the administrator would have to decide whether to set up an “SOP” site with one library to enable this search (would leave the folder navigation very crowded) or a site per plant with libraries that contain more than just SOPs.  (would force separate searches on each site).
• SharePoint doesn’t easily provide for cross-library searches with attributes.  Basic search is limited to full text but, like Doucmentum simple search, is just a Google-like full text search with search results.
• SharePoint advanced search is available and is similar to Webtop search.  Users have to build a query; however, users don’t get pre-populated pick lists like in Webtop.   Also, SharePoint doesn’t natively support the idea of a “contains” search and defaults to an equals or does not equal search, forcing the user to have to type and spell the whole value correctly.  For advanced cross-library searches, all attributes (called properties in SharePoint) from any library are in one giant property pick list and not shared across libraries (doc type for one library would have to be named something different for another library or it would show up twice).
• SharePoint search results only provide a “Google-like” result list – not the tabular, sortable format that Documentum and HPI users expect.   For example, being able to sort on an attribute column or download search results to Excel is not available in SharePoint.
• SharePoint does not provide for saved searches like Documentum or HPI.

We are enhancing HPI Search with access to SharePoint via the SOAP APIs.  Like Documentum users, the ability to have a robust, configured search is a common enhancement for document control applications.

Document Retrieval – Support for PDF

As we pointed out in a previous post, Documentum users are used to storing a variety of document formats and doing retrievals, overlays, annotations and other functions on a rendered PDF.  SharePoint “out of the box” doesn’t really support the automatic generation/storage of a PDF rendition or the ability to add overlays for document header/footer/signature page like Documentum users are used to seeing with PDF Aqua or OpenOverlay.  While there is a strong add-on market for SharePoint (we are adding to it as well for this), those evaluating should understand that any rendition would be stored as a separate object in SharePoint and would require some type of training/customization to make sure the PDF rendition was viewed/manipulated for retrieval.

Document Storage and Navigation

Most Documentum users are used to a cabinet/folder metaphor .  For SharePoint, the concept of Site/Library might be somewhat similar.  As already highlighted above, deciding to create and SOP site or a Plant site will be a major decision with impacts through the design of the application.  The difficult part of SharePoint is that within a library, the applications forces “common” property views.  To take advantage of the interface, users need to set up views per document type.  Some other key SharePoint differences:

• Security – Security can be managed on a document level but, out of the box, the security is  not tied to document status as is typically setup with a Documentum lifecycle and ACL.  For example, with a Documentum lifecycle, you can set up that users cannot update when pending approval, can not edit when approved/effective, but can edit in Draft.  In SharePoint, out of the box users can edit no matter what the document status value.
• Renditions – as mentioned above, documents appear in their native format without the concept of a PDF rendition.
• Office Integration – SharePoint has superior Microsoft Office integration to Documentum alternatives.

Workflow Review

Because SharePoint does not support document renditions, SharePoint workflow is more of a check-in/check-out process with track changes on whereas Documentum approvers typically review a PDF rendition and annotate/provide comments.  One concern about using native word tools is that reviewers can be too likely to be word-smithing  throughout  rather than reviewing content.  Also, the check-out lock limits parallel review.   Lastly, the lack of PDF support requires similar functions to insert header/footer into the word document giving the appearance that it might be editable.  We couldn’t get document name, version and status per our testing into the header.

Workflow Approval

The out of the box approval workflow still has check-out enabled.  Users should configure/customize SharePoint to remove that ability.  If users update approved document content after other approvers have finished, the integrity of the approval is lessened.  Editing during the workflow works for document review, but not a true approval process.

Electronic signatures are not supported out of the box.  If you want to capture a user’s signature, you have to insert a signature object into the Word document.  SharePoint does audit and provide adequate reporting status tools.

Final Thoughts

Overall, most Documentum users will see SharePoint as a “light” ECM tool and, from what we have experienced, will be frustrated with certain functionality and how best to incorporate their process for managing controlled documents.  Please add a comment or contact us with any thoughts or questions you may have.

Update 2013 – with SharePoint continuing to fade, we are seeing more and more clients consider Alfresco as a Documentum Alternative – please view solution and related screencams from a recent Alfresco Webinar.