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:
Wayne Hoff <[log in to unmask]>
Reply To:
Records Management Program <[log in to unmask]>
Date:
Tue, 13 Aug 2013 12:05:24 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (35 lines)
Thank you for the friendly invitation to disagreement!

I think our disagreement is not about the functionality of MFC's but around the 
context of their use.  You're describing MFC's as they are used commonly in 
offices today - installed by IT or office services and used as desired by 
employees with attention to nothing more than the green button that makes it 
all go.  I'm describing a specific situation where distributed scanning and 
centralized processing makes business sense.  This is scanning of a specific 
record type as part of a specific project, and within that project the 
parameters you mentioned would absolutely have to be controlled - DPI, 
record font size, B&W text, high-quality originals, etc. - otherwise, as you said 
earlier, garbage in garbage out.

I also was unclear about what I meant by imaging software tying to 
scanners.  What has come about in the last 3 years or so (or maybe sooner, 
I'm not sure) is a network connection to MFC's and software tie-ins so that 
they can communicate directly with the main server no matter how far around 
the world they are from each other.  That means paper is scanned on an MFC 
in a field office and seconds later it's part of a batch in head office, ready for 
QC, validation, and release.  I'm aware of one partnership between an MFC 
vendor and an imaging software vendor where this line of communication is 
direct, and with the copier interface providing directions to boot.

I agree that MFC's are bad for general scanning purposes, and not just bad, 
but terrible.  My argument though is that there may be a use for them in 
unique, well-controlled circumstances.

Wayne Hoff, CRM
Calgary, AB

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