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.
- 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.
- 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.
Would Documentum High Fidelity Forms (based on OpenOffice Writer) fit in this discussion?
HFF submit the form meta-data as XML – which can then be easily routed through the workflow and printed, have barcodes etc.
One of the challenges we face – is that unlike PDF forms – DCTM HFF require end users to have OpenOffice Writer on their PCs or download a 40 meg ActiveX control – which encapsulates OpenOffice Writer 2.4
This is not practical in many circumstances
===
Would it be possible to link Adobe High Fidelity Forms with Documentum workflows – instead of a LiveCycle back-end?
I would suppose that:
An Adobe HFF will submit its data in the XDP schema – which should be easily interpreted by a HTTP Inbound activity and mapped to workflow SDTs and content (XDP schema encapsulates both form meta-data and binary PDF as separate elements)
What would be your thoughts on this?
regards
– Paras
Paras,
Some good thoughts. The tough part we have experienced with the High Fidelity Forms approach is the intelligence part of it – we had one client that wanted to turn fields on our off depending on how other fields were filled out. The LiveCycle interface is better for adding indelligence as it adds that Wizard approach to only showing what you need to fill out when you need to fill it out.
We havne’t really combined LiveCycle with the form as we are pretty biased toward our Active Wizard solution. We would love to do it but the price point of Adobe can push people to the Active Wizard as a free alternative. We are working with one engineering/energy company that is heavy into LiveCycle and Documentum so maybe we will get some more experience there to add to the post.
Dave
Thanks for sharing your thoughts and yes we have experienced similar issues as well. OpenOffice HFF – can show/hide fields dynamically – but that leaves empty spaces on the form 🙁
So, unless your form design is permissive of this – it looks very ordinary.
regards
– Paras