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:
Andrew Ysasi <[log in to unmask]>
Reply To:
Records Management Program <[log in to unmask]>
Date:
Fri, 28 Mar 2014 12:31:06 +0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (72 lines)
All,

First happy Friday!  I don't know about anyone else, but I’m going to blame the RM/IG dispute on a very long winter!   

All kidding aside, while we professionals dispute the difference between Info Governance, Records Management, Information Management, Content Management, and Knowledge Management  (I'll refer to these professions as "us" and "we" throughout) consider we as a whole have been working through ARMA, AIIM, ICRM, and other organizations to get "noticed" by decision makers.  C-level's don't care what we call ourselves and our practice (if they care to address the issue), they want a plan and execution to manage information.

Coming from IT, it was a challenge to keep up and evolve, and we collectively need to quicken the pace to help IT and the organization simply due to data growth.  Hard to dispute with that....   With data transferring from system to system, and repositories becoming more and more available, the challenge to control "binary bits" (I'm going to break down information to its simplest form to avoid an argument...but know I may have started a new one :)) will continue and require multiple disciplines to address the challenge.  Hasn't this always been the case with successful programs regardless of discipline?  Let's not forget record or not there is plenty of information in physical form...ahem "non-binary bits"...going unmanaged as we speak.  What are we doing to connect with application developers to address the challenges we face?  As the article pointed out Nuix and others are working towards a solution, but the development alone is a monumental challenge to connect system after system regardless of application and database language.

I see a growing issue with failure to consider archival value of data during disposition...we cannot forget about our archive brothers and sisters!

A challenge to all...instead of debating on "us" we should profess whatever we believe to those who don't know who we are.  What are you doing to volunteer your time to discuss us with people who don't know who we are?

Pardon my grammar and punctuation...it is Friday...and no I don't type in 1's and 0's...sorry :).

Full disclosure:  I'm a member of the ICRM Exam Development Committee.  I write for Part 3.

Regards, 

Andrew Ysasi, MSA, CRM, PMP, CIPP/US, IGP
Executive Director
Kent Record Management, Inc. 

1950 Waldorf NW 
Grand Rapids, MI 49544 
616-459-6681 (Office) 
616-822-8887 (Mobile) 
616-459-6766 (Fax) 
http://www.kentrecords.com
STORE | SCAN | SHRED

Michigan Locations in Grand Rapids, Lansing, Kalamazoo, Muskegon, and Benton Harbor. 

Disclaimer: This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Kent Record Management Inc.  If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone.  Please contact the sender if you believe you have received this email in error. 
-----Original Message-----
From: Records Management Program [mailto:[log in to unmask]] On Behalf Of Nick Inglis
Sent: Friday, March 28, 2014 2:50 AM
To: [log in to unmask]
Subject: Re: [RAINbyte] Records management must evolve into retention management, expert says

<[log in to unmask]> wrote:
>
>If your process is designed properly to determine HOW and WHEN content 
>is ingested into an ERMS and controls are established as to WHO can 
>access it and WHAT they can do with it, then you should be relatively 
>confident that you are doing more than simply 'removing the 
>pointer/indexing' that provides access to the image/content stored and 
>that the content itself is actually deleted.
>
>Where you run into problems is if a wide range of users can access, 
>copy, re-store and re-purpose the content .But, IF IT IS A RECORD and 
>your policy clearly states a record must remain irrefutable and cannot 
>be copied, revised, re-named, or re-used... then you shouldn't have a problem.  NOW...
>if it's an ECMS and you store "Records" and "Content", then you're 
>talking about a whole different thing. And it's even a bigger issue is "content"
>can at some point in it's life be declared a record.

Larry, I understand where you are coming from here. Not all Records come into our organizations as Records, most start their life as organizational content, they are passed through email, cloud services (rogue or otherwise), ECM systems, mobile apps, etc. 

Every time that content changes hands, is modified, is utilized, it is duplicating across multiple systems. While the declared Record has remained irrefutable, what are we doing about the multiple copies that were never declared and aren't managed with the same care as the ERMS. 

The purpose of disposition is to reduce organizational risk and ensure compliance, does disposition achieve those goals (in most, or many,
organizations) anymore? No, I don't believe that it does and I think many would agree with me on that point. Disagree with how I propose we solve the problem, that's fine. However, this is a problem that needs to be addressed by the RM community, otherwise it will be addressed by CIOs/CTOs and lead to further marginalization of the RM profession.

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]

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