RECMGMT-L Archives

Records Management

RECMGMT-L@LISTSERV.IGGURU.US

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Linda Buss <[log in to unmask]>
Reply To:
Records Management Program <[log in to unmask]>
Date:
Mon, 25 Aug 2008 22:13:51 +0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (77 lines)
Glenn,

How are you calculating the costs of scanning vs. storing hard copy?

Linda Buss

-------------- Original message -------------- 
From: Glenn Sanders <[log in to unmask]> 

> Earl 
> 
> Don't recall the document you are chasing, but here is an extract from a 
> guideline I developed last year: 
> 
> -------------------------------- 
> Deciding what to scan 
> 
> Scanning is very often part of a move to a largely electronic way of 
> working, but it is not the whole picture and often not the most cost 
> effective solution. The main reasons for scanning, in order of 
> importance, are: 
> 
> 1. To make documents quickly and simultaneously available to many users, 
> particularly if the users are spread across multiple sites 
> 2. To integrate hardcopy documents into new or existing electronic 
> procedures 
> 3. To protect important documents, eg as part of business continuity or 
> disaster recovery planning (although if the records are rarely used, offsite 
> hardcopy storage in a high standard facility will be cheaper) 
> 4. To save space (however offsite hardcopy storage is at least four times 
> cheaper than scanning, on a cost per page or cost per image basis) 
> 
> So as a generalisation, you would only scan records that are frequently or 
> simultaneously used, and where the required retrieval time is less than one 
> day. You would also scan material to integrate it into existing or new 
> electronic processes. You would only scan records to protect them, or to 
> save space, if electronic integration or simultaneous rapid access were also 
> involved. 
> -------------------------------- 
> You have to be careful with scanning. I've had people propose scanning 
> filing cabinets full of reports printed from MS Word (if they are on the 
> shared drives already why scan them?), and others proposing to scan material 
> scheduled for destruction in eighteen months. Others have wanted to scan 
> material used so infrequently as to be statistically immeasurable. Most 
> people don't even think about how to create or capture the metadata 
> necessary for retrieval, which can cost more than the scanning itself. 
> 
> It's too often a facile, glib solution, adopted with insufficient analysis. 
> And before Steve jumps on me, I hate paper too, and we are currently 
> involved in projects to scan two million A0 or larger plans ($5 mill 
> project) and parts of 50,000 technical manuals ($250,000 project), both 
> justified primarily by reasons 1 and 2 above, and slightly by reason 3. With 
> the approval of our local State Records office, most of the hardcopy will be 
> destroyed after scanning and QA. 
> 
> Glenn 
> 
> Glenn Sanders 
> [log in to unmask] 
> Australia 
> 
> These views are mine alone. They may or may not be those of any 
> previous or present employers or clients. I don't know. If I'd asked 
> and they'd agreed, I would have signed it "Harry Peck and Co and 
> Glenn". Or whatever. But I haven't, so I didn't. 
> 
> List archives at http://lists.ufl.edu/archives/recmgmt-l.html 
> Contact [log in to unmask] for assistance 
> To unsubscribe from this list, click the below link. If not already present, 
> place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message. 
> mailto:[log in to unmask] 

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]

ATOM RSS1 RSS2