This is in response to “How good is SharePoint as Document Management System?” by Toni Frankola. In the post, Toni scored SharePoint’s Document Management (DM) capabilities on a 5-star scale using the following criteria:
- Metadata – 5 stars
- Integration - 3stars
- Capture – 1 star
- Indexing – 5 stars
- Storage – 3 stars
- Retrieval – 3.5 stars
- Security – 3 stars
- Workflow – 4 stars
- Collaboration – 4 stars
- Versioning – 4.5 stars
SharePoint Document Management Needs Multi-file Documents
I liked the post overall and agreed with most of the ratings. However, I would lower SharePoint's marks for versioning, workflow, and security. The reason is that SharePoint supports only single-file documents. I.e. a logical document is stored as a single file in SharePoint. In order for SharePoint to truly excel as a DM system, SharePoint needs to support multi-file documents. When I say "multi-file" document, I mean something like a compound document or virtual document. Yes, SharePoint Server 2010 has document sets, but they are more like the SharePoint version of Office Briefcase rather than true multi-file documents.
SharePoint’s Single-file Document Limitation
SharePoint’s single-file document limitation manifests itself in these ways:
Versioning: The version information is not very granular. You can only tell when the entire document has changed, but you can not tell which part of the document has changed. For example, your 3-person team is creating a proposal with introduction, technical approach, and pricing sections. The entire proposal has 100 versions over its lifespan. How can you tell when the pricing section was changed without going through each version? The difficulty clearly stems from the fact that SharePoint stores the entire proposal document as a single file. If the proposal were stored as a compound or virtual document with the pricing section as a separate file, it would be very easy to see exactly when the section were changed and by whom independently of the entire proposal's version history. Let me reiterate that the proposal document is logically a single document not a set of documents grouped together, so it is not quite right to represent the proposal document as a document set.
Workflow: To extend the example of the proposal document, the 3-person team has grown to a 6-person team, with different members focusing on different aspects of the proposal. The proposal is about 400 pages now, and the team has just published a major version. The approval workflow takes a long time, because the approval workflow can only be run at the granularity of the entire proposal document. That means that there are lots of reviewers for each workflow, even when the section in which a particular reviewer is interested has not changed since the last time the approval workflow was run (see above comment on versioning). This means that the reviewer is wasting his/her time needlessly looking over a 400-page document. Additionally since the workflow is running at the scope of the entire 400-page proposal, it is difficult to focus the reviewers' comments on particular sections or even to make it clear to the reviewers which sections have actually changed since the last review. If each section were a separate file, you could easily run smaller, focused workflows on just the sections that have significant changes, before running one final workflow on the completed proposal.
Security: Extending the example of the proposal even further, let's say you now have two sub contractors helping to create the proposal. You want the subs to help create portions of the technical approach. However, you do not want either of the subs to see the other’s work as it contains competitive information. Further, you don't want either of the subs to see the pricing section, since that contains your markup over their rates. There is no way to give each sub contractor access to their proper proposal sections without also granting them access to the entire proposal, as all of the sections are stored in the same file. A content manager could easily secure each section of the proposal individually if the proposal were stored in a multi-file format.
What else can Multi-file Documents Do?
These are just some quick notes. We have a white paper that talks about many usage scenarios made possible with multi-file documents here:
http://www.blackbladeinc.com/en-us/products/docBlock/Pages/UsageScenarios.aspx
