-----Original Message-----
>>I'm being pushed to limit the start of my future process state flowcharts
at the point in time that something is declared a record.  I've started
both the physical/electronic process flows at the creation/capture step
and  am having trouble getting the point across that in todays world
Records & INFORMATION Management needs to include that portion of the
equation formally know as DM.   I've used the chain of custody,litigation
discovery, knowledge mgt,4 good record tenets, transparency when declared
as record,new civil procedure rules,etc explanations without much success.

  The response keeps coming back that it's like the free world vs the
communist state and that  I shouldn't care until it's a record what's done
with it and how it's managed.  In some instances such as nonbusiness
related information this is true BUT the instant something is considered a
business document or business related it's to our advantage to bring it
into our process.<<
------
Steve - just so we can be clear about your problem, could you clarify what
you mean by "that portion of the equation formally known as DM"?  Document
management? Database management? Doesn't matter?

I think you're saying that you need to look at the flow of information
through the entire work process in designing your new systems, and I
couldn't agree more.  Systems have to be designed to deal with all kinds of
information, some of which is "records" and much of which is not.  Early
system design planning should be able to identify some information which is
nearly always "record" material, such as invoices in Finance, final design
drawings in Development, and electronic customer orders placed on the
company website, and then manage that material as records.  Other
information can be determined to be consistently "non-record" data, and
promptly discarded by the system at the appropriate time, such as
intermediate computer transaction files, prior draft versions of a document,
etc.  The system should be designed to deal with both of these two
categories from the beginning of their lifecycle, when they are generated or
received.

It's the troublesome third category that I think your compatriots are
talking about: information that requires some intelligence - human or
machine - to make a determination that it does or does not qualify as a
company "record."  This is information that is generated from a variety of
sources, but must at some time hit one of those diamond-shaped decision
boxes on your flowchart that asks: "Is this a record or not?"  It then
branches into two or three different processes, "yes", "no", or "maybe". (Or
"It depends" in listserv parlance.)  The things that are "records" then need
to have consistent approved retention and disposition rules applied to them
by the system.

Greg Schildmeyer, CRM

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance