RECMGMT-L Archives

Records Management

RECMGMT-L@LISTSERV.IGGURU.US

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Content-Type:
text/plain; charset=ISO-8859-1
Sender:
Records Management Program <[log in to unmask]>
Subject:
From:
Maureen Cusack <[log in to unmask]>
Date:
Mon, 27 Aug 2012 19:09:25 -0700
In-Reply-To:
MIME-Version:
1.0
Reply-To:
Records Management Program <[log in to unmask]>
Parts/Attachments:
text/plain (63 lines)
I believe in taking the power - and the burden - of managing records away
from record owners. Wherever possible, at least for electronic
records, especially in repositories where records pile up. I've done this a
little bit with email already, to meet litigation needs, i.e. email
system-wide destruction programming, determined by attorney preference,
is automated. More robust automated classification, beginning with filters
for non-records, are still not implemented. Litigation needs aside, the
problem with not automating classification and destruction is that users
simply won't manage their records manually at the record level, or I should
say, they won't manage the records their business unit inherited. People
aren't motivated to classify or destroy their own records, let alone a file
they didn't personally create. Retention periods are much longer than the
tenure of many staff or the business units or teams that created the
records. The exponential growth of records - around 40% per year for email
and shared drives- then lands in IT's lap as a storage capacity problem.

GARP maturity model, level 5, mentions software tools explicitly in
'Transparency' ('software tools exist to aid transparency, regular
compliance audits') and use of ERMS software can be inferred in 'Integrity'
and 'Disposition' in the GARP model.
Implementation is key. Automated classification and destruction programming
needs to be built into ERMS software, and is very labor intensive,
no? Automation needs to be built the same way that RM policy is built, with
a little - or a lot - of input or oversight by high level stakeholder
record owners. The policy statements that record owners are responsible for
complying with the retention schedule, which means they are responsible for
records getting destroyed on time, means that they must collaborate in
building the automated rules, not that they must manually destroy records
at the folder or file level.

It seems to me that the vulnerabilities in ERMS implementation, i.e. the
ability to defend what gets destroyed, lie in the thoroughness of applying
the rules to the entirety of content, as well as in the quality of the
rules themselves. It's impossible to roll out automation to all content in
all locations immediately, or ever, since customized applications are not
suited to ERMS products (despite what vendors may say about their excellent
connectors or consultants). It can also get tricky to implement when IT,
who primarily identifies what content exists, tends to distinguish content
as much by server location - in geographically dispered offices - as by
application. So defining what a 'repository' is and targeting it for a
given implementation cycle seems to be important for the records manager -
not IT - to define.

Meanwhile, users should be trained on the definition of a record and how to
comply with the retention schedule, they should be free to decide what is a
record or not a record, and they should be free to destroy their records
manually (even if attorneys implement a system that overrides user
destruction) because users interact with many media and data sources every
day that have, unfortunately, varying levels of controls and automated RM
functions. We want users to perform recordkeeping to the extent it's
possible. Then we should expect that users won't do it most of the time.


-- 
Maureen Cusack
San Francisco, CA
[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