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:
Blake Richardson <[log in to unmask]>
Reply To:
Records Management Program <[log in to unmask]>
Date:
Wed, 3 Aug 2011 11:02:25 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (130 lines)
Julie I concur with your response (as I usually do).  At the risk of
stepping out on the proverbial limb and falling off - I believe a much
larger issue is that many organizations (regardless of size), do not
have the systems in place in which to appropriately manage email. 

I would be interested in learning what innovative approaches and tactics
companies have implemented to address this issue in lieu of additional
technologies.  

Blake E. Richardson, CRM

-----Original Message-----
From: Records Management Program [mailto:[log in to unmask]] On
Behalf Of Julie J. Colgan
Sent: Wednesday, August 03, 2011 9:49 AM
To: [log in to unmask]
Subject: Re: Preserving Email: The Nature of the Problem | Practical
E-Records

NOTE: I haven't read the lead story so hopefully I'm not being redundant
...

The biggest barrier, IMO, isn't in applying retention to email, it's
more
about getting email into a system in the first place.  That is where
more
automation is critical (and often the hardest to achieve because people
as
so darned emotional about email).

As it goes, you can provide a repository for filing of content,
including
email, but you generally have to rely on end users to move email to the
system.  People are always problematic.  And with most ERM/ECM
repositories,
there is a profiling step that typically sits as a large brick wall
between
intent of the system and actual use of the system as intended.  What
often
happens is 1) people just find some other place to stash important
email,
such as their gmail account, and/or 2) they apply the metadata that
shows up
first in the picklists in order to speed up the process (but which
dramatically affects overall adoption and success of the solution ...
more
on that in a minute).

If you are going to attempt to move email to a content repository by
manual
means, you need at least the following for any kind of consistency:

1. Integration into your mail client.  Don't make people leave their
email
environment to file email.
2. As flat a file structure as possible (read: big buckets on steriods)
3. The absolute least amount of manual profiling as possible.  Use every
default you possibly can and apply metadata through folder structure
inheritence.
4. Very clear guidance on which emails consitute a record and which
don't
(so you don't end up simply moving the storage of junk from one server
to
another)
5. A corresponding policy for email retention on email servers.  Regular
purge policies, if designed and implemented well, actually encourage
regular
filing of important email (note that I said encourage, not guarantee
...)
6. Regular monitoring, training, retraining and enforcement.

Another barrier to getting email filed into ERM/ECM repositories, from
my
experience, is poor search functionality/training.  If people are asked
to
put their precious email into a repository you had better be sure they
can
find it quickly; but honestly many implementations neglect to account
for
this need.  The majority of effort is spent configuring capture, then
second
is lifecycle management, then last is user interaction post-capture.  I
contend that approach is entirely backward.

All of that said, I'd recommend you look into the possibility of
removing
end users altogether.  Find a way to manage their email without
involving
them AT ALL.  Although people will claim that all of their email is
life-shattering important, keep in mind that in reality a vast majority
of
email is transitory in nature and need not be retained for any extended
period of time (depending, of course, on your industry, jurisdiction,
role
of the user, etc.).

And for as much as Steve W. hates paper, I hate email.

Julie



-- 
Julie J. Colgan, CRM

[log in to unmask]
http://twitter.com/juliecolgan
http://www.linkedin.com/in/juliejcolgan

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]


"Email Firewall" made the following annotations.
------------------------------------------------------------------------------

Warning: 
All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient.  This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s).  If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited.  If you have received this message in error, please notify the sender immediately.   
 
 =============================================================================

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