Documentum and SharePoint – Key differences for document control applications Part II

Our initial post back in March comparing Documentum and SharePoint for document control continues to be one of our most popular.  We are not sure if this coincides with the announcement that DCM will be fading away or just continued interest in all things SharePoint from the Documentum community.   This post will be slightly different as we will address common customizations in Documentum for controlled documents.  For this post, we will continue the discussion to include some of the things Documentum clients do that are not “out of the box” for either SharePoint or Documentum.

Change Request – the driver of Change Control versus Document Control

Most “out of the box” solutions for document control focus making a change to a document and getting it approved.  Change control focuses on managing of the change process with the idea that documents are part of that change.   The scenario below demonstrates the need for change control versus simple document control.

A life sciences company has discovered that a cap of one of their injectibles is leaking and is evaluating how best to replace the cap with a cap from another manufacturer.

1. Document Control – In a typical document control system, users might begin updating documents related to the cap change.  Approval of these documents would take place one at a time with someone being responsible for coordination of the approved changes being released at the same time.  Users could easily be distracted as the number of documents affected (ex:  Manufacturing Instructions, Bill of Materials, Package Inserts…) would all be routed as separate document changes.
2. Change Control – Advanced document control users embrace the idea of overall change control rather than just document control.  In this scenario, the initiator puts together a change request document that describes the change.  The change request has things like description, reason, justification as well as other specifics including affect on training and specific locations.  The change request is not just about documents but could also be about related activities that could include process validation, regulatory filings and even labeling requirements.  In some examples, the change request might not be related to documents (ex:  facility, equipment or IT system change).  If documents are impacted, they can eventually be attached to the change request form.  These documents could either be updated with the change or could be updated after the change request is approved. 

Change control is a much more complete solution than document control.  Some best practices include:

• Mass Change – Rather than a document at a time, all the affected documents can be routed together for a single reject/approval rather than bombarding the approver with an endless stream of “Approve this one Document” requests.  Multi-document approval is a common add-on for Documentum systems.
• Better use of knowledge workers – Too often expensive knowledge workers can be tied up in “wordsmithing” document changes rather than approval of high-level changes.  One client approach was to have knowledge workers only approve the change request with lower-level users approving that the change request was implemented correctly on each document.
• Dynamic Workflow – Typically, advanced change control includes dynamic routing to the correct people to approve based on fields within Change Request.  For example, if a box is checked that “Regulatory Approval” is required, the system will automatically either send it to the correct resource or give the user the option to select a person in regulatory for approval.
• Signature Reduction – tied to dynamic workflow, the system should insure that rules push for signature reduction.  We once worked with a client that, by applying proper rules, was able to reduce average signatures from 12 to 4.

Change Control for Documentum or SharePoint

Advanced Documentum users add in Change Request as a document type with either attributes or other means (XML) as a way of capturing fields related to the change itself.  For SharePoint users, the question should be “how can I set up this form in SharePoint”?  Keep in mind that the form:

• Should have some intelligence – as described above, if regulatory approval required is selected, user should be prompted with items related to regulatory approval.  If regulatory approval  is not required, the capture of regulatory approval information should be skipped automatically byt the system. 
• Should relate documents – Documentum users have used XML, Virtual Documents and Folders to relate documents to the change request document.   Users should be able to relate documents impacted by the change including worflow/approval documents that will may have versioned/lifecycle changes when approved as well as supporting documents that are attached for additional information.
• Should be tied to document lifecycle – If the related documents have been changed and are in DRAFT/Pending Approval versions, they should be updated when the change request is approved.  (APPROVED, EFFECTIVE are fairly common).    The documents on a CR might not all become effective at the same time depending on their implementation period.  The promotion of related documents is typically handled within the workflow component (once approved or rejected – promoted to approved or effective).
• Should be tied to routing – Our (TSG) best practice is to ask form and routing questions together to reduce training and complexity.   This is different from a typical workflow approach where a user selects either the workflow participants or a template.
• Should address completeness – Users need a way to track that everything on the CR was completed before it can be closed. Before the Change Request can be closed, the system needs to make sure that all of the activities outlined in the CR were done.
• Should be searchable – Users need a variety of searches including by change request and related documents.

In our (TSG) internal brainstorming discussions, we talked about a number of ways to accomplish an intelligent change request form within SharePoint.  Keep in mind that the “document” metaphor pushes away from doing a database application.  Like any document, the CR will be created, versioned and will exist as a document within the SharePoint Library just like the documents that are being changed.   Some of our thoughts:

• Word – SharePoint’s big advantage is the ability to have attributes in SharePoint updated from Word.  For the change request form, this could provide an interesting way to capture description, justification and other form components but we were slightly worried about Word having the intelligence to prompt for specific questions.  We haven’t been big fans in the past in regards to building complex functionality into Word.  Issues with versioning, document connectivity and having it as the driver to kick off workflow are all potential roadblocks that we would anticipate.
• InfoPath – Microsoft’s form solution is one option that would provide an intelligent form and connectivity to SharePoint.   We were not sure where InfoPath fits in the SharePoint universe but thought it would be worth some R&D.
• Adobe PDF and LiveCycle – Quick disclaimer, we are an Adobe partner.  We like Adobe’s capabilities in regards to intelligent form in a PDF or a LiveCycle Flex application.  Some concern would be the difficulties in regards to how to connect to SharePoint libraries and SharePoint routing (rather than Adobe LiveCycle).  Adobe does have SharePoint connectivity tools – the LiveCycle ES2 Connectors –  this looks like more of a Web Part approach similar to MyDocumentum for SharePoint rather than a solution that leaves the content in SharePoint and leverages SharePoint routing.
• XML – Most of our work in Documentum in regards to change request has been with our Active Wizard product that adds an intelligent forms as XML documents to Documentum.  Whether our tools or others, XML is a great vehicle for intelligent forms, workflow and document relationships.  We have one Documentum client that used a combination of XML and Virtual Documents to create the change request not using the Active Wizard.  We are reviewing our product plans to discuss SharePoint connectivity but are slightly concerned about mixing Java and .Net environments.

Please log your thoughts below on your thoughts and suggestions.  As we and readers continue  to build our SharePoint skills, any experience you can share would be welcome.