But what about someone sitting at your desk in 2 months or 2 years?  Today a
records creator creates a document for boss, sends email with attached .doc
electronic record, boss reads email, downloads and opens attachment, boss
approves attachment, converts it to PDF and emails to President to read on
iPhone which doesn't read Word docs.

With the lifecycle (creation, use, disposition) RM model, each "evidence of
transaction" would be a record, but do we risk managing too many redundant
records if we're not careful?  In other words, when in the "lifecycle" do we
account for conversion to PDF (or some compressed) format for short-term
access by different departments for different purposes, and does policy
recognize and stipulate this difference?


David Kay, MLS

On Wed, May 26, 2010 at 1:42 PM, Larry Medina <[log in to unmask]>wrote:

> >How confident am I that the people who sit at my desk in 10, 20, 30 years
> will have the interest, expertise, resources, governance, staff time, and
> budget to accomplish renewal of electronic records?
> >In general, I am not willing to oblige successive generations to records
> maintenance if a minimum-maintenance storage option is currently available.
>
> >>
> >>There are two separate issues:
> >>Managing/Policy - How long to keep specific content - this is an RM issue
> >>Procedural/Practical - How to keep the content accessible. (Here is were
> it is easy to conflate the two because at some point this is also
> "managing"
> the media.) Be it paper or on cd, or fax, or ZIP drive, 5.25, SD, thumb
> drive, whatever....this is an RM and IT issue
> >>
> >>We'll need to roll the content forward onto new media or new
> technologies...
> >>
> >>The firm decides on the policy, it is my responsibility to see that the
> records are viable for as long as that policy states.
> >>
>
>
> Actually it's correct to state the firm/organization/owner of the
> information makes the decision based on the value or necessity of ensuring
> the information remains persistently accessible for as long as it is
> required to be retained to meet obligations, whether these are legally
> mandated, of a business need, or for some intrinsic enduring value of their
> content.
>
> The organization assigns responsibility for implementing the practices to
> meet the policy to someone in a position on their staff- that might be the
> Records Manager (if there is one) or some cadre of Administrative Staff,
> the
> IT Department, who knows? Some organizations assign these responsibilities
> to a contractor or consultant- but it's still policies and practices that
> establish the course of actions that need to be taken.
>
> Conversion and migration is inevitable for information that has to be
> retained for extensive periods of time, and plans need to be made to ensure
> this happens proactively (including quality control and validating content
> following conversion/migration) in advance of any degradation or
> obsolescence occurring.  And as much as some people hate to hear it... in
> some cases this may include a hard copy option for a minimal group of
> records.
>
> I guess what I'm getting at is it doesn't matter what the individual in the
> role wants or thinks is appropriate, it's what the organization needs to
> meet their requirements and objectives for managing their information
> assets.  The decision isn't up to an individual to 'oblige others' to do
> certain things, or to select the easiest option available now- it's to make
> plans for the future to remain in compliance with the policy and
> obligations.
>
> Larry
> [log in to unmask]
> [Yes, it's really me =) ]
>
> 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]