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:
Thu, 15 Jan 2009 10:53:21 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (77 lines)
>I am not a records manager at Hamilton Beach, so I don't know if the
>statement in the second paragraph is true. I also know that Google does not
>presently provide records management in the traditional sense but does
>provide retention management and it could be that Hamilton's RRS is simple
>enough based on their internal risk assessment that what Google provides is
>sufficient.

It would have to be so simple that they only have ONE RECORD SERIES and ONE
RETENTION PERIOD =)  And they must see the risk as being LOW to determine
it's sufficient.  

A few of us had lengthy discussions with Google at the ARMA Conference
regarding Records Management practices and principles and I can guarantee
you what they provide only amounts to 'retention' in an IT sense... and it's
actually more what IT refers to as 'e-mail archiving'.  

They keep everything, for up to 10 years, if you're willing to pay for it,
and for a shorter time if you aren't.  The repository is mirrored and
regularly backed up, and in the event of an outage, all but the most
immediate exchanges can be restored.  And their overall up-time is
excellent, with limited long term outages recorded over the past three years
since they established a triple redundant backup server system.

The problem is their 'retention' doesn't satisfy the needs of many
organizations that want to be able to categorize e-mail by content and set
retention periods based on that content.  Sure, you can setup "Labels" but
you can't setup folders and set differing retention periods on messages
placed in those folders with trigger retention periods based on date
received/sent.  

And although Postini recently added a feature that allows you to search
across the repository and you place 'holds' on messages identified in a
search to ensure they are isolated and not destroyed... it does this (as I
understand) by making copies of the messages and then allowing you to set a
rule on retention of that copy.  Not sure how this would fly in an
e-discovery case, because the original remains in the repository and can
still be actioned.

And they are more than happy to talk to clients about retention beyond the
10 year ceiling they've set, but again, it isn't able to be specific enough
to do that based on categories of messages...yet, but if they keep
developing Postini, maybe in the future.

But bottom line is it's a searchable (IT defined) archive, not retention. 

I use GMAIL (multiple accounts) personally and have been satisfied with how
it functions most of the time, I have a lot of respect for the things GOOGLE
is doing as a company, but they openly admit RIM is **NOT** their space. 
When speaking to their developers and application support staff (three
different stops at the booth, speaking to different people there each time
to make sure it was 'cultural', not staff person specific) the most
frequently asked question when I asked about a certain capability of either
GMAIL or Google Docs for business users was 

"Why would you ever want to do that?" 

and the second most common question was 

"Do people REALLY do that?"

One of the guys two of us spoke to called a colleague over and asked us to
repeat a scenario we were wondering about how Google addressed data
management for and he said 

"I've heard those questions asked by a number of people here, but no one has
ever asked us those before... records management must have a REALLY
DIFFERENT set of requirements and practices than we're accustomed with"


Larry
[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