The digitization of the workplace is changing the traditional way of signing documents. OpenText and other ECM vendors now offer solutions that enable organizations to achieve the same level of authenticity inherent in traditional wet signatures, but to truly integrate this into your existing business process you often need a little additional support.
I’m sure you’re familiar with OpenText Electronic Signatures (eSign). It provides OpenText Content Suite users a means of signing-off electronic documents in a compliant fashion, while matching the authenticity of a physical signature. Many OpenText ECM clients have included OpenText’s eSign capabilities within their Content Suite-based workflows to enable their business to implement a robust enterprise solution for managing a wide range of change and approval control processes. If you’re not familiar with eSign, I’d suggest you take a look at OpenText’s datasheet.
For years eSign has been the standard for Content Suite users within regulated industries, as well as those requiring electronic signatures that meet standards such as the FDA’s 21 CFR Part 11. For many organizations the capabilities offered by the standard offering are perfect. However, I’ve worked with many organizations with complex signing needs that find its relatively inflexible approach causes substantial bottlenecks within their business processes.
For this reason, GCI PowerTools for OpenText Electronic Signatures (PTES) was developed. Since its introduction, many people have asked whether they still need OpenText’s eSign product and how both PTES and eSign operate together. The rest of this post attempts to highlight some of the common problems and answer these questions.
So let’s start at the beginning. PTES is built on, and enhances, the core Content Suite Electronic Signatures offering. It extends the capabilities of signing workflows; enhancing end-user experience and providing a more natural process flow. Beyond that it solves a few specific, yet common, problems with the core technology.
Out-of-the-box, eSign enforces a one-document signing process per workflow relationship. In practice, this means that if your existing workflow requires signatures be applied to multiple documents you need to setup and trigger a workflow for each document in turn. For many this is fine, but if you’re business requires that users are able to sign off packages of documents, this can be somewhat limiting.
With PowerTools for Electronic Signatures we removed these limitations. We give workflow designers the ability to allow multiple attachments to any individual signing process, enabling more than one document to be reviewed and signed simultaneously. For many of our clients, this has allowed business process to be automated without having to be completely redesigned.
Signing documents with OpenText Electronic Signatures is easy, and you can readily insert the minimum information required for compliant signing onto the signature page. However, many times I’ve been asked about including additional process related metadata on the page, something that the core eSign product does not do. Once again, PowerTools for Electronic Signatures comes to the rescue. It allows the creation of customized signing pages. These can use a stylesheet to allow custom designs and allow you to include business specific meta-tags within the content. Seems simple, and once you’ve tried it for yourself you’ll see how easy it can be.
When preparing to sign multiple electronic documents, another common step in many processes is collating a series of discrete files into a single document ready for final approval and signing. Typically, merging the approved documents involves an additional manual step or the use of automated tools outside of the control of the workflow process itself.
Using PTES, documents can be automatically assembled and merged into a final document which itself can then be approved and signed. Once signing is complete, the original documents can either be left in their initial location or moved off into an archive or other area.
In addition, PTES allows dynamic identification of which documents to convert, watermark and/or sign. Document item references within the workflow can be used to determine the required target of the signing operation, and individual per-step configuration ensures that the right documents are presented at the appropriate steps within the overall workflow process.
My final big difference comes in the area of the user experience. With many approvers being executives who do not use Content Suite on a regular basis, understanding its user interface can be somewhat challenging. Users need to be trained and without that they can find it confusing or difficult to locate the information they need in order to correctly approve or reject a document. So, how do we make this more simple for those folk?
The answer, of course, is to provide a significantly simplified signing view. Through the optional integration with GCI PowerTools for Workflow (PTW), the entire workflow interface can be fully tailored for each individual signing process, the signing UI can be designed around the needs of your users. We can even make it look just like your corporate intranet if you so desire. I’ve been told by our existing users that this has made their training a lot easier and that users are less resistant to using Content Suite – which is great. In addition to this PTW also allows workflow steps to be auto-completed if an approver rejects a document or if time deadlines are exceeded. Both were things that helped our clients to optimize the flow of their electronic processes..
I hope that I have managed to outline some of the main reasons that PTES exists, and if you feel that you have any of these issues in your own organization then I’d love to help you get them fixed. As PTES is on the OpenText price book we even makes the paperwork nice and easy if that’s the way you prefer to go 🙂 Please feel free to reach out to me directly, or fill out our online contact form and I will get straight back to you.