Ah, the debate goes on. Can SharePoint really be used for Document Imaging? Is it really capable of storing tens of thousands of image files?
There are a number of vendors out there building some really cool tools for high-volume import of image files into the SharePoint system. But before utilizing this application for a true imaging tool, I think you need to ask some really pointed questions during the planning phase:
- How many pages per day are you going to be scanning? Microsoft recommends that a Document Library should have 2,000 or less objects. Why? Mostly for performance reasons, as the system will display all the items within a library on a single page. You can get around this with some planning. Take for example an accounting department that is scanning invoices. Maybe you create a new library each month or week to maintain optimal performance.
- Is your server hardware up to the challenge? SharePoint requires some decent horsepower if you are going to be serving up large image files. Remember, these files are stored within a SQL DB, so you may need to tier off your web server and DB server.
- What type of capture application are you using? How you capture scanned images can really have an impact on the overall performance of the system. If you are scanning with a high volume app like PSIGEN’s PSI:Capture, then you may want to schedule upload of images during off hours so there will be a minimal impact on the end-users. If you are utilizing eCopy, and just scanning individual documents throughout the day, there will be a minimal impact on the server.
- How often will users be retrieveing the images? If SharePoint is just going to be an archive for images that are rarely accessed, then network bandwidth may not be an issue. If the images are constantly accessed by multiple users at 6 branch offices and internet users, then you will need to place high importance on network infrastructure.
For more info on SharePoint, and additional articles on planning for a Document Imaging System, go to ScanGuru.