A retention schedule is not a policy about how to use it or who it applies
to, it's just a schedule. There needs to be explanation published along
with the schedule - but not part of the schedule itself - that explains what
a retention schedule is, its purpose, use i.e. how to use it in the event
of legal holds, who it applies to and what that means, i.e. what record
ownership means, and where to find definitions of records, non-records,
official records, copies. The RM policy should also explain all of that.
Explanations published alongside retention schedules should include links
to the RM policy. Links could also go to other business unit policies,
procedures or prominent systems that rely on the retention schedule.

The RM policy statement that the record owner is the record creator
clarifies who owns, for example, BOD records. Is anyone puzzled about
whether they, or their business unit, were the creator of the BOD meeting
minutes?

Question: If you choose to identify specific owners of a record then how
are you mapping to record class in a functional retention schedule?
Functions consist of many activities involving many business units, often
duplicative, for example,when activities are split by product type. To
identify an owner of an official record do you first identify specific
record names associated with some business activity that is part of the
larger business function? Do you identify every activity and every record
name or record type?

I provide record type examples and/or record names in the retention
schedule itself for almost every record class. People find examples useful. I
don't take it one step further to list who the current owner/keeper of the
official copy happens to be. Staff are free to sort that out for
themselves, and I referee from time to time. In the retention schedule I
ensure record examples represent more than one business unit creator so no
one thinks they own the record class or that it applies only to their
records and not anyone else's.

I also map software applications to record classes, keeping it outside of
the retention schedule.

A relational database might be helpful to capture all these extra facets of
records retention schedules that fall outside of functional classification,
facets like record names, record type, owner, software application. But if
you only have 69 function-based record classes, and a well organized
software application index then it's just as easy to track those facets
manually.


-- 
Maureen Cusack
San Francisco, CA
[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]