Welcome to Kraft Kennedy

With eDOCS DM 5.3 gaining traction among our clients, I wanted to take this opportunity to share my overall experience with the latest version and the upgrade process.  I recently upgraded a client from DM 5.2.1 CU5 to DM 5.3 Patch 1.  The back-end upgrade went remarkably well, as have all my recent experiences with Open Text eDOCS for the past year or two.   In testing the updated client, I couldn’t be happier that Open Text embraced MSI technology for the installation and deployment of the DM client.  With a simple single command line, I was able to customize a complete client install, without having to run through the DM Extensions Server Setup on the DM  server itself as with previous versions.  The MSI properly upgraded the previous version without any apparent issues or error messages.   Adding the MSP patch to my installation script was also tested without any errors.

In testing our pilot deployment, one issue was apparent.  The ODMA integration between Adobe Acrobat and DM was broken!  I checked the Open Text Knowledge Center on the proper steps to integrate Adobe with DM, and verified that yes, the API file is in place, and yes the PassiveODMA registry value is in place.   Upon opening a support ticket, I was informed that ODMA integration is gone with DM 5.3.  In fact, starting with DM 5.2.1 CU4, Open Text was not including the ODMA integration with Adobe.   That seemed strange, since it was working with our 5.2.1 CU5 client just fine.  Turns out that if the API file and PassiveODMA registry key are in place from a previous installation, it will still work with CU5 and CU6.   However, with 5.3, ODMA integration is no longer in the code, so if you have the API file in place, that DM menu option in Adobe is there but that does absolutely nothing.

In double-checking the release notes for DM 5.3, I found that this integration change was mentioned, but as the 4th footnote on a page — definitely not prominent.  And no mention of this change with 5.2.1 CU4  in the Knowledge Base or in the Application Note titled  “eDOCS DM 5.2.x – How to Successfully Integrate Adobe Acrobat and Adobe Reader”.

This leads to two valuable lessons for any product integrator:

1. Be sure to read all Release Notes, including footnotes!
2. Before deploying a software upgrade, deploy to a small pilot and test all integrated applications.

Regarding the Adobe integration with DM 5.3, the DM Interceptor is needed.  This is actually documented as an option in the Application Note referenced above, but is a requirement starting with DM 5.3.

With Office 2010 being unleashed on the world, many customers are asking when their DMS products will support it.   No need to ask around, because we’ve gathered the official stances for some of the major vendors.

• WorkSite iManage 8.5: “We will look to certify/support Office 2010 within 90 days with the current 8.5 Worksite clients and later”
• Open Text eDOCS DM 5.3:  “We will release v5.3 beta this summer and the final release is scheduled to be launched in late September”
• Worldox GX2:  “Office 2010 integration files should ship within 30 – 45 days of the official general release of Microsoft Office 2010″
• Microsoft SharePoint 2010:  “Come on, we’re Microsoft.  It’ll work day one!” (Disclaimer: NOT a real quote)

So as of right now, it looks like Worldox may win the horserace to support Office 2010.  As soon as official release announcements are made, we will be sure to test functionality in our research lab.  Of course, simply supporting integration with the application doesn’t mean that the DMS product will be able to leverage any of the extra features of Office 2010, such as the Backstage view or simultaneous editing (which requires the document live on SharePoint 2010).

Autonomy iManage and OpenText eDocs both have protocol handlers for SharePoint, which enable the SharePoint Enterprise Search engine to index documents stored in the DMS, while keeping the documents in the DMS.  Many people haven’t been aware of this and thought you had to migrate all of the documents into SharePoint to search them, or to use an enterprise search engine provided by the DMS vendor.  However, these protocol handlers can provide the best of both worlds by allowing you to continue managing documents in the current DMS, while taking advantage of Microsoft’s FAST enterprise search indexer to index the DMS content, SharePoint content, file shares, web sites, Exchange public folders, and other enterprise systems.  Security trimming is preserved by the protocol handler, so users will never see documents in the DMS that they don’t have access to.  The protocol handlers both support Microsoft Office SharePoint Server 2007.

More information on the OpenText eDocs SharePoint integration and protocol handler can be found here:

http://www.opentext.com/download/livelinkdownload.html?path=product/microsoft/ot-clmsp-edocs-po.pdf

More information on the iManage SharePoint protocol handler can be found in their partner portal, by filtering the list of products to “SharePointProtocol Handler.”  Note that you need a partner login account to download the documentation and release notes.

http://worksitesupport.interwoven.com/WorkSite/scripts/portal.aspx

Both vendors also offer a comprehensive set of web parts to drop into a SharePoint environment to view and manage their documents from within a SharePoint site.

So you’ve decided to implement Matter Centricity at your firm.  Whether you are using Autonomy iManage (formerly Interwoven), Open Text eDOCS (formerly Hummingbird), or another Document Management System (DMS), the basic idea behind Matter Centricity is the same — to present virtual Redwelds for each matter, with folders to categorize and classify documents within.  Couldn’t be simplier!

But in order to design these virtual Redweld structures (iManage calls these “WorkSpaces”), input is needed from each Practice Area or department of the firm.  Since many of the users have no idea what Matter Centricity is, and some may not have any idea what a DMS is to begin with, it can be difficult to obtain the information needed to design a structure.

Here are a few tips to get the message across:

• Give a high-level 20-minute presentation prior to your WorkSpace design discussions with a user group.  Provide some screen captures to display a sample structure.  Briefly discuss how they would interact with the structure on their desktop environment. Even with this presentation, it is hard for some people to grasp the concepts and visualize the structure
• Take notes during the presentation and the following design discussion.  Try to identify those users who are having a more difficult time.  Notes are also very helpful when following up with certain attorneys or administrative assistants.  The user will appreciate that you remembered their comment from the discussion.
• Create some sample structures in a lab environment, based on the initial input of the user groups.  Invite some of the people who had a hard time understanding the concept and demonstrate how to save and access documents from the structure.  Hopefully this will help them along and their ideas can be included as well.

Using these tips, the hope is not only that the users better understand the concept in general, but also have a better idea of how their input for the design will be translated into technology and their daily work process.

In future posts, I’ll discuss how to interpret all this input and combine it with iManage and Kraft Kennedy’s best practices.