>
> I'm also contemplating a switch from 100% microfilm imaging to either some
> combination of imaging and microfilming or 100% imaging.
Hybrid systems serve a lot of purposes. Strong consideration should be
given to the location of your user base to the repository of information and
the access pattern of users. If they're centrally located, or they contact a
portion of the organization (RIM or whomever) to provide service in
accessing images, and the usage pattern is so low that it wouldn't support
the cost of converting the images form film to anything else, these would be
excellent candidates for leaving on film.
If the user base is spread over a wide geographic area (or areas) and the
access is random and frequent, then there would be a reason to consider
imaging the film and making it available on-line.
If you're considering 100% imaging, you have a lot of other issues to
consider, like investigating the source of the materials and if there's a
way to make the source electronic to begin with and skip the middle man. You
may also want to consider the ability of your organization's communication
system to handle the increased load of passing images back and forth and if
this change will impact it's performance. And don't forget the need for
massive amounts of storage and backup capabilities, and how this plays in a
disaster recovery/business continuity scenario.
In past jobs,
> we've had an ERM into which 300 dpi compressed and OCR'd PDF images were
> migrated along with their index data (usually from barcode fields and the
> least amount of manual keying) from the scanning software. Once indexed in
> the ERM, the images were then available with full text searching and
> searching on metadata fields to authorized users with the appropriate
> access
> rights.
A 300dpi OCR'd PDF is not exactly a small file... and what do you do in the
case of images, embedded hyperlinks, color text, etc?? Even compressed,
these files can become storage hogs. And don't forget... compressed files
don't always backup and uncompress well.
I'd be curious how others' deliver their common size images (Legal/Letter).
>
> 1. ERM, EDMS, Windows Explorer or another delivery system?
> 2. PDF (No OCR), PDF (w/OCR), TIFF or another format
We've pretty much eliminated all use of Legal size.
As for delivery, we use a mix. Some items are in an ERMS and in those
cases, we actually deliver in a variety of methods. We have viewable PDFs,
downloadable PDFs and native file formats (which are controlled by a
'rules-based system' ). We use TIFF for most images (image only type files)
and also manage some things like CAD files in their native forms, which can
be accessed through a file viewer. Lots of PDF, very little with OCR, mainly
because of the file sizes.
I'm looking for a somewhat simple, effective and also searchable system to
> use to introduce effective imaging delivery to the company to whet the
> appetite. I have a few small projects which I'll be able to use as
> demonstrations (while probably still microfilming them per current
> standards).
There are generally "islands" within organizations that are prime
candidates for these type of systems, but you need to look for the right
fit, in terms of business needs balanced against cost. The software licenses
and ongoing support cost can be high, and you may need to look at replacing
monitors to get higher resolution and larger screen sizes for "pan and scan"
features to be fully usable. There will also be the need for training, and
as mentioned a possible need to purchase additional storage and more
efficient backup systems.
Keep in mind, pilots can work well... but scope creep can kill you. Find
out what people do now and what their expectations for improved the
technology are and get the specs for the system in writing. If the users ask
for something more as you go along, explain the cost in terms of direct
charges from the vendor/implementer and the impact on the schedule, and make
sure they're willing to pay for it before you move forward.
Larry
List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
|