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:
Larry Medina <[log in to unmask]>
Reply To:
Records Management Program <[log in to unmask]>
Date:
Fri, 30 Mar 2007 09:13:15 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (114 lines)
> I agree with Steve here and would additionally note that given the current
> state of automatic classification tools vs. the overwhelming volume of
> email
> most organizations receive, many organizations are choosing to do what
> they
> can vs. trying to apply traditional records best practices that don't
> scale.


I was going to try and let this thread die on the vine, but I can't.   I
have to pitch my tent in Glenn and Steve's camp on this.  Archiving e-mail
in the sense it's defined by vendors serves little if any purpose, and
actually can result in exposing an organization to greater risk and cost
than doing nothing.  Taking small steps to set organizational policy and
begin the application of RM principles and practices to this extreme volume
of information serves as a much better solution.


> But someone still has to make the determination as to
> record or not and then do something with the record messages...and if
> that's
> only 5% of all of them that's still 30.4 million email records to be dealt
> with, declared as records, classified, indexed, etc.


 A lot of this volume can be reduced substantially by establishing policy
about the use of e-mail within an organization and setting up filters at the
incoming gateways that disallow a lot of useless e-mail from even making it
into the organization.  And this, too, requires some work. Announce the
policy, repeat the announcement multiple times before it goes into effect,
encourage employees to notify "friends and other non-business entities" to
NOT SEND e-mail to their business accounts, and then set up a JUNK mailbox
for each user where items that don't seem to meet the selection criteria
established go. Allow users to review these messages and classify them as
"not Junk", when appropriate and the system will learn from that, or allow
users to set senders as "trusted sources" so that e-mail doesn't get
classified as junk.

At the same time, most
> organizations' classification structures are all but opaque to users who
> don't have an MLIS or other appropriate info architecture background - and
> that's almost all of them. So a) the users cannot do it, at least not
> easily, and b) there aren't enough records managers on the planet to do
> even
> just the email.


Yeah, well, if that's the case, the RIMs who assisted in developing the
classification structures didn't do their job right.  One aspect of
developing a classification structure is working with end users and finding
out what they do and how they do it, and ensuring the records series
established map across to that set of processes.  If this is done, the
classification of e-mail, and all other electronic format records generated
in native form from desktop applications, can be done much more easily and
in some cases, even transparently to users.

A better approach might just be to combine email archiving with the
> full-text indexing capabilities of many of the email messaging
> applications/gateways/appliances available.


Full-text indexing relies too heavily on artificial intelligence to work
OOTB, and a lot of tuning and re-tuning needs to be done to get any level of
accuracy.  AND the storage of full-text indexed content requires
substantially more storage space than storing e-mail in it's native form.
In addition, anyone in the Federal Government or Contractors to a Federal
Agency, aren't allowed to use this as an option. (36CFR 1234.10)
Additionally, any e-mail that is declared a record must be moved out of an
e-mail application and into an approved ERMS. (36CFR 1234.24)

I'm not saying that this is the
> desired end state necessarily, but faced with the alternatives of doing
> nothing, doing a little tiny bit as exception, or archiving and full-text
> indexing, I know which one I'd recommend.


Well, not to wax too philosophical, but..."the shortest path to the one
you're already on…stand still, turn your head, change your point of view."
=)

A reasonable alternative, once you've stripped away much of the detritus by
applying policy changes is to consider a simple "three bucket practice" to
e-mail retention.

Non-Record, destroy as soon as practical
Short Term Record, retain for CY plus two years
Long Term Record, retain for 3 years or more

Those classified as long term records will have to be vetted by someone, or
put through a classification schema of some type to assign a record series
and retention period to each of them so they are properly managed, and this
can be developed over time.  Another "toolset" that can be used is a
combination of rules and role based retention, making a logical assumption
based on what someone does, based on their position and placement within an
organization, what the minimum and maximum retention period would be for
records related to their function and position.

Obviously none of these are perfect solutions, but they're better than the
illogical offering of most vendors suggesting that to be in compliance you
must save everything, and it's a better business practice to have it all and
not be able to find it than to be accused of spoliation.

Happy Friday ....discuss amongst yourselves....

Larry

-- 
Larry Medina
Danville, CA
RIM Professional since 1972

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance

ATOM RSS1 RSS2