Document Management System - SharePoint

gollem_1975

A (small) company wants me to create a Document Management System ( and I have agreed to do it )

I posted earlier in this forum with regards to the version of SharePoint I should use ( I'm going with 2010 ) - thanks to Thoie, ginger, Stevenmu and anyone else who contributed.

At the moment I am trying to understand the planning/design of a document management system.

should I be concerning myself with reading up on Information Architecture, taxonomies, Document/Knowledge/Information Management...

and if so can anyone suggest some books /URLs that they found to be useful

cheers,

Gollem

stevenmu

There's a couple of blogs/whitepapers worth reading.

The Microsoft ECM Team blog. Some posts go into very detailed specific situations, but others cover more general capabilities such as this. Lots of their older posts were for 2007 naturally, but the concepts will apply every bit as much to 2010.

Microsoft provides lot's of whitepapers, such as this (and a large but not complete list of them available here), and case studies (some here) and lots more linked from the ECM blog or by searching).

I wouldn't get too concerned about the theoretical side of document management. Focus instead on the functionality offered by SharePoint, on the clients requirements, and most importantly making sure that the two align in such a way that you can implement it in a reasonable and predictable time-frame.

I would suggest that you first have a conversation with them about their expectations of their DMS, then create and present a demo using SharePoint to show how it can meet those expectations. Then either as part of that demo, or as a separate workshop define the more detailed requirements. Then begin the implementation from those. If the requirements are reasonably long, it's often a good idea to break them down into more manageable chunks for delivery (and the process and delivery of the first chunk can help shape both yours and the customers processes for the next chunks).

Ginger

Like Stevenmnu I start with the client and look at what they want. Is it just sharing, trying to understand how much they need and looking at a good pilot department/function/section/group to start with.

I dont look at the meta data (taxonomy) straight away but start looking at their existing folder structure if they are using a file system based system. This usually gives me an idea of what they use for their content structure.

Additionally I will look at where they want to go (for licencing purposes), so that they dont spend too much on it. Some customers just need the foundations (free) version to get started and they upgrade to the portal once they are set.

gollem_1975

the company has a shed load of legacy documents on a file server.

I want to be able to harness SharePoint to search through these documents.

I know one option is to manually go through all these documents and upload them to SharePoint ( 2010 ) .

Is there a way to avoid this and just point SharePoint directly at the file server ?

Ginger

You can do it programatically through the webServices and/or Object model. Since you will be doing this from the file server to SharePoint its the Web Service interaction you will need.

A LARGE word of caution. Importing all your documents into Sharepoint without a proper structure/meta is just moving the mess to a different place. this is a good time to clean break and look to the future for their document management strategy.

A proper QA and import process is needed.

If I may suggest the following

Start moving function/department/group one at a time, moving their key documents to Sharepoint with a correct metadata structure. Once they are in place monitor their progress and any document not in the library is imported as required. Freeze their access to the file server and make the move specifically to Sharepoint. Do not delete anything from the file server.

After a while you willl see that the requests for specific documents will become very few and thats usually where you QA is finishing.

Once they have been migrated, make sure the meta data is correct and move onto the next function.

You will find that certain meta data is key across the company and there will some specific to each department. try to keep all meta data requirments tight rather than using every little thing. Normally its 4 to 4 common pieces and up to 5 more per function. Now when I say 5 pieces of meta data, i referring to types such as say Author, Document type, Department and Date. For specific ones you might have Confidential (Yes/No), Authorized By, Manager etc etc.. Try to limit it, otherwise it becomes really hard for people to categorise stuff. Looking at their existing folder structure will give you an idea.

gollem_1975

I was hoping that it could be done through

Central Administration -> Create External Resource Mapping

without the need for writing code.

the documents on the file server are being described to me as "legacy" documents and most are rarely if ever used.

"Going forward" the company will plan, design and implement a document management strategy but for the moment I want to try to get SharePoint to index their legacy content.

in doing so I hope to get users familiar with using the SharePoint interface in their day to day jobs and also help them to locate information quicker than they are doing at the moment through windows explorer.

Ginger

Alternate Access Mappings allow for different URLS to go to the same resource. or shorten a resource name so that its easier to remember. This doesnt do anything for the file system.

You have a couple of options though like the Bulk importer on CodePlex (http://spbulkdocumentimport.codeplex.com/wikipage?title=Command-line%20options) or the Bamboo File System library (http://store.bamboosolutions.com/sharepoint-file-share-library.aspx)

Lets be realistic here, if you are going to attempt to index "legacy" documents, you are going to get a moutain of junk in your searches and you are going to need to tune your search as well. Additionally there will be some stuff taht is not required so why index it. A better plan is to bring key documents in, keep them as legacy and if it cant be found, use it via windows explorer and then bring that document into SharePoint.

Ginger

Alternatively, you could use Rsync list to do some of this http://sprsync.codeplex.com/

gollem_1975

Ginger wrote: »

the Bamboo File System library (http://store.bamboosolutions.com/sharepoint-file-share-library.aspx)
.

sounds good .

I must download a trial and check it out.

am a bit concerned that this functionality would not be available though

stevenmu

Do you want the documents to actually reside within SharePoint, or is it just enough that they are available via SharePoint Search? The search service can crawl and index documents which reside on a file share as well as it can documents in SharePoint. Of course you loose out on the richer metadata provided by SharePoint, but it will still index the document contents etc. It also supports security trimming, so users won't be shown files that they do not have permission to on the file system anyway. Files will be shown in the results as normal, and when the users clicks on them they will open directly from the file share.

You can configure this by add a new "Content Source" to the search service. Go to Central Administration->Manage services on server->SharePoint Server Search->Search Service Application->Content Sources->Add new content source. You can then easily specify that the content source is a file share and configure the needed paths, crawl schedules etc.

gollem_1975

stevenmu wrote: »

Do you want the documents to actually reside within SharePoint, or is it just enough that they are available via SharePoint Search? The search service can crawl and index documents which reside on a file share as well as it can documents in SharePoint. Of course you loose out on the richer metadata provided by SharePoint, but it will still index the document contents etc. It also supports security trimming, so users won't be shown files that they do not have permission to on the file system anyway. Files will be shown in the results as normal, and when the users clicks on them they will open directly from the file share.

You can configure this by add a new "Content Source" to the search service. Go to Central Administration->Manage services on server->SharePoint Server Search->Search Service Application->Content Sources->Add new content source. You can then easily specify that the content source is a file share and configure the needed paths, crawl schedules etc.

steven and ginger I hope ye have a great weekend , you've both been super helpful. thanks again.

I'm told that only about 1% of the Documents on the file system are useful ( though what 1% is anyones guess)

as a result i think they want to be able to search through the Fileshare from SharePoint so Stevenmu's tip above could be very useful for me.

I have kicked off a crawl of the Fileshare and can test the search functionality when it completes.

Perhaps any documents residing on the Fileshare that they need to modify going forward can be added to SharePoint.

Any new content/documents the users produced goes straight into SharePoint.

cheers peeps.