Whether or not SharePoint can be a viable DMS at a law firm has been a big point of contention in the legal community. A lot of this comes down to the mentality and size of the firm, and the specific requirements that the firm has for document management. With proper planning and one or two simple addins, SharePoint may be a viable DMS for certain firms that are flexible and willing to invest in a development effort.
The advantages of using SharePoint as a DMS are many:
- Being able to wrap an intranet or extranet around all of your content.
- Having basic matter management features available in every workspace, such as a shared calendar, task lists, and discussion threads.
- Having access to document workflows.
- Being able to search all of your repositories with Enterprise Search (available free with Microsoft Search Server Express.)
- Being able to integrate business intelligence dashboards.
- Providing access to web 2.0 features such as wikis, blogs, and personal sites.
- Leveraging native Word features, and not having to rely on vendors to update their software to support the latest version of Office.
The main way to ensure a successful SharePoint deployment as a DMS is with proper planning. SharePoint can all too easily be deployed out of the box, with no oversight in place. While this may work out ok for an intranet, it spells disaster for a DMS. Thought should go initially into defining what content types are needed for the firm. Content types are similar to document types in a DMS, and allow for the classification of documents by defining metadata, retention rules, associated workflows, and starter templates. After defining content types, you would need to create a taxonomy, or hierarchy for all of your clients and matters. One structure that works in WSS is to create a team site for each client, and then a document library for each matter. We’ve successfully written scripts to create client and matter workspaces based on this approach, and to import documents from the file system into SharePoint. When a user saves their own document into SharePoint, they would drill down the client site to the matter library, and then simply have to choose a content type associated with the document.
The thing that seems to scare people the most is something architectural rather than functional—the fact that SharePoint stores files in SQL blobs, rather than in the file system. This causes fears that corrupt files will not be able to be recovered, or that disk costs will get expensive or lead to unmanageable databases. However, we should remember that there are plenty of excellent third-party solutions for doing backups and restores of SharePoint at the individual file level, as well as native backups and restores in SharePoint. Microsoft Exchange stores all of its messages in a database format, and no one has ever raised an eyebrow. The backup and restore process in SharePoint ends up being quite similar to Exchange. In fact, Exchange stores its data in the JET database engine, which is even less robust that SQL. Microsoft has also certified their enterprise search engine to be able to index 50 million documents in a single SharePoint repository, and SharePoint can manipulate files in SQL faster than a traditional DMS can manipulate the files on a file system. All in all, it is our belief that this architectural design of SharePoint should not be a contributing factor in determining whether or not SharePoint is viable.
There are also some additional differences to keep in mind if you’re used to a traditional DMS:
- Re-filing is more difficult in SharePoint. Metadata will not automatically update if you move documents between different matter libraries, and you’ll need some additional user training or third-party software.
- Document permissions may be harder to keep track of. It’s important for the administrator to correctly assign permissions at the site or library level, and for users to individually secure their documents if need be.
- Some features are only available in MOSS, the licensed version of SharePoint, such as document trail auditing.
- The user interface is completely different. The firm will need to be open to working differently and retraining users.
- SharePoint does not natively number documents—it only creates a unique URL for each document. We recommend an inexpensive tool from MacroView Wisdom for doing unique document numbering. Also worth noting is that SharePoint 2010 is supposed to natively support unique document numbering.
- While SharePoint libraries can be viewed in Outlook, messages cannot be dragged into a SharePoint folder in Outlook. We recommend another tool from MacroView Wisdom for email management in Outlook. In addition, SharePoint Workspace 2010, which is a full desktop client for SharePoint, may alleviate some of this need in 2010.
As firms look for creative ways to cut costs, while maintaining functionality, it will be interesting to see if SharePoint gains momentum as a DMS in the legal community.