This is a policy question. The drafts of record documents may or may
not have value. In the simplest example a document goes through x
versions, a final Record copy is created and declared as a record.

We know that end users will not clean up prior versions consistently.
Therefore you need to have a process to do it for them. The process
needs to be clearly defined and communicated as any other part of your
RIM program.

I'd suggest something like "record copies must be declared. Non record
copies will be deleted n months after last accessed/modified date"

The concept applies to ALL information. Documents on file shares,
documents in a Document Management system, E-mails in your e-mail
system.  Etc

Work in progress obviously needs to be left around long enough for the
business use, but eventually things must be cleared out.

Establshing clear, reasonable time frames can be done and will be an
effective part of your entire RIM program.

On 6/15/11, Janet L Nelson <[log in to unmask]> wrote:
> I have a question for those who are using enterprise content management
> software in conjunction with records management software.
>
> Here is the situation:  Users can enter records into the software without
> declaring them to be official records.  Over time, for some of the records
> they create multiple versions before officially declaring the final
> version.  Once they declare the final version, they forget about all the
> undeclared versions.   They should go back and delete these non-official
> versions, but they often don’t.
>
> At some point the declared version comes up for disposition and gets
> purged, but because the RM software doesn’t know the undeclared versions
> exist, they don’t get purged.  Here is the question:  If this happens in
> your company, how are you handling it?
>
> We have been discussion this and have come up with these options.  They
> have their pluses and minuses.
> 1.      We create and run a utility or script which automatically declares
> all of the versions so they will come up for disposition.   This is the
> plus.  The minus is the user will get a disposition review batch with all
> of the versions listed.  The batch does not show version numbers, just the
> title.  They won’t understand why the same record is listed multiple
> times.
>
> 2.      Have a utility or script run and delete the undeclared versions
> when the official record gets purged.  The plus is the user won’t see all
> of the versions on the batch.  The minus is purging records without the
> user knowing it is being done.
>
> In both cases, we would be deleting records without approval from the
> users.  It is our practice to get approval before official records are
> purged.  At this time, I don’t have any policy or procedure about purging
> unofficial records.  Whatever we decide to do, it will become part of our
> documented procedures.
>
> It isn’t practical to do searches for undeclared versions and then ask the
> owners to review and delete them.  Besides being pretty sure it would
> never get done, there are too many records in the repository to do this.
>
> I said I would come to this group and see what others are doing or what
> your thoughts are.
>
> ***********************************
> Janet Nelson CRM
> Manager Records
> Dairyland Power Cooperative
> 3200 East Avenue South
> PO Box 817
> La Crosse WI 54602-0817
>
> [log in to unmask]
> 608/787-1218
>

-- 
Sent from my mobile device

Dana Yanaway, JD, CRM
[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]