Hello Records Managers,

Any thoughts on the 2 messages below that were posted to the ERECS list?

Thanks,
Bruce

On Fri, Aug 13, 2010 at 3:10 PM

> I will soon begin some research to determine if there are any existing best
> practices on the following question:
>
> "Is it best to scan *all* incoming paper documentation (including
> 'mundane' items like envelopes with Canada Post processing dates) according
> to Canadian Standards, and then apply the appropriate records disposition
> rules to the resulting electronic images; Or,
>
> Is it best to scan incoming paper selectively according to Canadian
> Standards, apply the appropriate records disposition rules to the electronic
> images, and also apply records disposition rules to those 'mundane' paper
> records that were not imaged."
>
> I can see the simplicity of the "just scan it all" approach, and destroy
> the paper after the quality control checks are done.  Of course the images
> of those 'mundane' items with a short life-cycle for administrative value
> would be disposed of by the electronic system.
>
> I can also see the appeal of the "only scan the important stuff" approach,
> as this would make the contents of an electronic system look 'cleaner', and
> reduce the number of disposition rules that the system needs to process.
>
> However, personally, the thought of having to separate the incoming
> documentation into 'scanned' and 'not scanned' boxes to manage the different
> retention periods is not very appealing to me.  It does seems simpler to get
> rid of all the paper with the scanning process and just deal with
> disposition in the electronic system.  Another of my personal biases is that
> I think the contents of electronic systems are (and will continue to become
> more) complex and that there is no sense hiding from that fact by not
> scanning certain documents.  Also, if a system has the logic to process one
> disposition rules, then it should be able to process many disposition rules.
>
> So, knowing the scenario and my biases. Has anyone come across any best
> practices in this area that would help me make a more objective decision?
>
> Many thanks for any ideas,
>
>
On 14 août 2010 15:53:
Some great dialogue thus far.  Many thanks.

I can provide a few more details.  The incoming paper documentation is for a
single client relationship function with ca. 3 record series.  There is some
variety in record types, but not too much - the existing scanning stations
(and the staff that currently administer them) can certainly handle the
variety in quality and format.  The planning and costing for the human
resources needed to scan the incoming documentation is already well
established, as are the necessary processes and procedures.

The task at hand is upgrading/rebuilding the application that is already
doing this work.  I find it interesting to note that it is the IT business
analysts and software engineers who are the ones doubting the wisdom of
'scan it all and let the machine sort it out'.  Our internal client (who
approached me for advice) does have previous experience in the creation of
correspondence tracking software in the Canadian Federal Government.  I too
suggested that best practices would be less relevant than the actual
business needs at hand (which are thankfully well documented), however there
was still a desire to demonstrate that we had taken best practices into
consideration.

If anyone else has any thoughts on the matter it would be great to hear
them!

Bruce


---------- Forwarded message ----------
From: Peter Kurilecz <[log in to unmask]>
Date: 2010/8/13
Subject: private reply was Re: Scanning of Active Records
To: [log in to unmask]


good question let me suggest that you cross post to the recmgmt-l listserv.
lots more people over there with the experience you seek

peterk

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]