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:
Wed, 24 Oct 2007 12:27:13 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (76 lines)
>
>  I sat on a panel at the SNIA's Storage
> Networking World's conference in Grapeland, TX last week and this
> topic of discussion came up a number of times.   Many of the vendors
> are selling ILM as a fairly straightforward solution; the fewer the
> buckets (seven to 10) the better.  Yet the user community is finding
> implementation much more difficult, are seeking answers and not sure
> where to turn.
>
> This is another great opportunity for records managers.  If you don't
> know who your storage folks are, find them on the org chart, offer to
> take them out for a cup of coffee or lunch, and offer assistance.  The
> ones I spoke with understand that there are challenges with any
> solution.  They are for the most part just looking for help and
> guidance.


Bruce... the problem with this whole concept is the SNIA folks are convinced
it's a SOLUTION... but waht they're failing to do is understand the PROBLEM.

How can you propose a solution to something you've failed to analyze?

Here's the deal... SNIA is using data that shows the volume of "information"
being created and stored is growing exponentially and its creating havoc for
organizations to "manage".   But what they fail to remember is those that
are now the backbone of the SNIA are the same people that in the past told
organizations "storage is getting cheaper, the SOLUTION IS TO SIMPLY BUY
MORE STORAGE" =)

Anyone else remember this???

So, they didn't understand the problem then, and they offered a
"solution'... and THAT solution is what has caused the current problem
they're offering ANOTHER 'solution' for.

HELLO?!?!?!  What is wrong with this picture???

In the first place, all of this information doesn't rise to the definition
of a "record" for most organizations, and most of it doesn't need to be
stored.  How many times have we read articles in the past about "having to
keep everything forever"? Who ARE these people, the same ones who keep
shoving stuff in my garage??? =)

I think Bruce is right that we need to find people on the org chart to talk
to, but it ain't the "storage dudes".. and don't offer to break bread with
these folks unless they're buying... and even so, don't get your hands
anywhere near their mouths...  and he's right they DO need guidance... but
it needs to start with telling them to stop offering to store everything.

Someone needs to get the RM policy out, dust it off, and see if it still
fits the business model.  If not, update it and get it re-approved.  THEN
start marketing it and making people aware of it's existence and the
benefits of applying solid RIM principles and practices to everyday business
situations.  AND draw a "line in the sand" about what is being retained...
if ti ain't a record, and it serves no value to the business, then it
shouldn't be stored.  If it IS A RECORD, and it's identified in the
retention schedule, then you should know how long to store it.  If it's NOT
in the schedule, then get it in there and assign a retention period to it.

There's no question there is a TON of "landfill legacy information" that's
been kept and resides in storage, and a plan will have to be developed to
deal with it... but the first thing to do is stem the tide of the ever
increasing volume.

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