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:
WALLIS Dwight D <[log in to unmask]>
Reply To:
Records Management Program <[log in to unmask]>
Date:
Wed, 1 Jul 2009 14:56:30 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (73 lines)
Pat, I attended a similar session a year or so ago in Seattle. Right now
the focus is on ingest of electronic formats. We'll figure out what to
do with the stuff later - a gross oversimplification, nevertheless the
bottom line.

All valid points, Amy - and a reasonable description of the RM/IT
relationship for many years. I actually think things have improved
significantly - its been a while since IT last proposed eliminating my
program, something that was a bi-annual event for at least a decade. I
really don't see IT as the enemy anymore. Here's a dirty little secret -
they are as perplexed as we are, and would love to have us as partners
in solving these dilemmas.

Regarding practicality and social media, here are the RIM solutions:

(1) Consistently apply retention to records content based on retention
policy: I'm not sure that one can practically do this at this stage of
the game.

(2) Train on appropriate use and monitor: Currently this strikes me as
the most practical solution, but it really does not address long term
costs, nor, in my opinion, does "don't do anything stupid" address long
term risks, as "stupid" changes over time.

(3) Prohibit and/or restrict usage for business purposes. Seems as if
the CEO's of the world have chosen this practical solution. 

But here we run up against that innovation thing. Perhaps we need to
focus more on risk analysis models. Over time, what aspects of a given
information system presents risks, and how can we offset those risks
against the benefits accrued? To give an analog example: Recently
military discharges have been declared exempt from disclosure in Oregon.
As these have been mixed on microfilm with recorded deeds in many Oregon
counties, this makes that microfilm directly inaccessible to the public.
What was "smart" for 40 years to save costs is now "stupid". Does mixing
functional record series in a given system increase risks? By how much?
Can we assume now that any record with personally identifying
information presents risks? In what technology? With newer electronic
recordings, the vendors have provided patches to electronically restrict
the military discharges. Problem solved! In this case, the electronic
system is the lower risk system. Yet these are permanent records -
presenting the "media obsolescence" risk. It would seem to me that
developing such risk assessment matrices would demand the same attention
as RIM competencies or standards. In my own work in this area, risks
gets uncomfortable stares - you're not going to get your own
organization to acknowledge it for obvious reasons. All the more reason
for an external approach to develop practical models.

One reason risk assessment seems increasingly critical is because (3) is
the safest, most practical choice, but is it really the choice we want
to propose? I remember when "permanent" was the "safest" choice -
perhaps Ms. Noveck agrees.

One thing I have full confidence in: IT and RM will ultimately work
together and are working together to solve these issues. Basically we
have no choice. I think this is a positive that starts with 2 simple
propositions: Know thyself. Listen respectfully.

Dwight Wallis, CRM
Records Administrator
Multnomah County Fleet, Records, Electronics, Distribution and Stores
(FREDS)
1620 S.E. 190th Avenue
Portland, OR 97233
Phone: (503)988-3741
Fax: (503)988-3754
[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]

ATOM RSS1 RSS2