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, 27 Apr 2007 12:55:04 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (162 lines)
On 4/27/07, Jesse Wilkins <[log in to unmask]> wrote:
>
> Email is NOT as simple as Steve and Larry describe -


Really? .... ho wonders deeply what this claim is based on.... and walks
away with a furrowed brow.... BUT WAIT...

otherwise more
> organizations would already have applied 60+ years of RM best practices to
> the problem and have solved it, thereby rendering those vendors'
> unnecessary
> solutions, well, unnecessary.


Ahh... it's based on the assumption that because it hasn't been SOLVED!
Well, hecksakes, that makes it simple, now doesn't it?  And since when has a
vendor offered a 'solution'?  All I've seen is tools, that when deployed,
and combined with the necessary rules, practices, policies and constant
tweaking, help provide a method for accomplishing something

It hasn't been 'solved' by many organizations because they don't have an
enforced POLICY in place, and haven't provided sufficient training about how
to use e-mail and what it is intended for.  They don't have a policy in
place about HOW TO DECLARE A RECORD, and what one ISN'T.

Here's an example- An organization send a blast e-mail out to it's 10k
employees, how many of these are a record?  ONE... MAYBE... the one that was
sent.  All the others are copies, intended for use and reference, and they
have no record value.

Here's another- An employee receives 50 e-mail messages a day from the
RECMGMT-L Listserv (maybe less while the AIIM Conference is in session =) )
and how many of these are a RECORD?  None.

If an organization establishes a clear policy that when you provide
direction to others, document a transaction or decision, or give guidance on
policy in an e-mail that it is a RECORD, then you can easily limit what
people are retaining.  This is just an example of what an organization's
declaration of a "record" might be... but I think if most of us looked
across how many messages of this type there are on an daily basis, there
wouldn't be the purported 177 messages a day we're seeing in some articles.
I receive around 100 BUSINESS RELATED e-mails a day, generally, about 10-15
of these are a record.  Many have a 3 or 5 year retention, a few have a
longer retention.  But over 80% of them get jettisoned.

I do not claim that "the sky is falling". I do claim that because of the
> intrinsic qualities of email including but not limited to ease of
> forwarding, Ccing, BCCing, multiple attachments of any type which
> themselves
> might be records, the tendency to have multiple messages as part of a
> single
> message (as Steve just demonstrated) which are editable prior to
> replying/forwarding, the tendency to keep the same subject line for that
> thread ten messages after the thrust of the thread has changed completely,
> the fact that emails are sent to and received from inside and outside the
> organization, often as part of the same thread and at different times in
> the
> conversation to different individuals and groups, the different electronic
> formats available for email messages and the applications used to create
> and
> store them (3 different things here), and most importantly the sheer
> volumes
> involved, that email cannot be addressed in the exact same fashion as
> paper
> records or even many other types of electronic records, which otherwise
> might be addressable in the fashion Steve describes (although I reserve
> judgment on that as well in many instances).


Again, POLICY is what is lacking here.  Just because e-mail has these
"intrinsic qualities" (and I think qualities may be an incorrect assessment)
doesn't mean that they SHOULD be used in a best business practices setting.


Step back a few years, and ask yourself, how many times did you make copies
of a letter you received and send it to multiple parties in your office, or
how many times did you write your response on the bottom of the letter and
send it back, along with whatever attachments you received, to the sender
and others?  And how many times did the other party write their response on
it and send it back again, and again , and again to you and multiple
parties?

Why do we have this 'situation"?  Because we don't control it.  Simple.
See.. here, I'm responding to Jesse's letter, but in "my personal
organization" the content (of either the original letter OR the reply) isn't
of sufficient value for it to be considered a RECORD, so I'm going to
discard it.

I think this is akin to arguing that microfilm is just another record media
> and should not be treated any differently. This is also not true - from
> the
> physical storage to the indexing mechanisms used to retrieve a requested
> frame to how that information can be shared with others, we do treat
> microfilm slightly differently. And multipart forms. And physical records
> like core samples. And notarized documents. And the list goes on and on
> and
> on. Or that CAD files are just another file format and can be treated as
> their paper counterparts, while ignoring the unique things having the
> original electronic file provides (views and layers as a starting point).


Some of these are records; some of these are not... in some organizations.
This is an apples and oranges argument to the proposal that e-mail, as "an
entity", isn't a record that gets scheduled.  Core samples aren't always
records, depends on what they represent or support, or the purpose they
serve. Each "part" of a multi-part form may be a record, and each may serve
a different purpose, and similarly, each may have a different retention
period, but they aren't assigned a retention period based on them being a
"multi-part form".  All core samples CERTAINLY don''t have the same
retention period, it's based on the "CONTENT" of the core sample. and what
it supports.  CAD files can be a record, but the "layers and views" can be
turned on and off, you don't assign a retention period to the layers and
views, you assign it to the CAD file, based on what the content of the file
is.

If your organization has already solved the email challenge, and you're
> declaring as high a percentage of those email messages that rise to the
> level of records and as accurately as you do paper, congratulations.


If your organization has realized WHY you have so many e-mail messages to
categorize and schedule and is on the way to limiting the volume they need
to deal with, an even greater set of congratulations is in order.

Of
> course, you probably don't need an ERMS either - because since electronic
> records are the same as paper, just a different media, it's unnecessary;
> only vendors who assert that "the sky is falling" would design solutions
> to
> address electronic records; and only users who have been hornswoggled
> would
> ever buy those solutions.


Funny, but this "logic" (argument?) doesn't seem to make a bit of sense to
me.

A record is a record, irrespective of media form or format to a  Records
Management Practitioner or Professional, that's the way I learned it and
have practiced it all the years I've been in RIM. Anyone else??   What needs
to be done with electronically generated records IS THE SAME, you just use
different methods to achieve the same thing.

And sure, an EDMS, ERMS, ECMS or whatever alphabet soup you want to throw
after the name of the "tool" being used to accomplish the physical
management of the information asset is, the RULES and POLICIES still need to
be set and designed for the tool to accomplish it.

They aren't "electronic records", they're RECORDS in electronic formats.


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