The sound of one hand clapping.

John Davies
Senior Consultant
TFPL Ltd

07811 125769



-----Original Message-----
From: The UK Records Management mailing list on behalf of Donald Henderson
Sent: Thu 05/11/2009 09:19
To: [log in to unmask]
Subject: Re: What does good records management look like?

Keeping it as non-technical as possible, good RM satisfies the "temp
test". In other words, if you describe the filing system to a temp, can
they find a given piece of information in a reasonable time. If they
can, your systems are good.

Donald Henderson
Information Compliance Manager
Perth & Kinross Council


-----Original Message-----
From: The UK Records Management mailing list
[mailto:[log in to unmask]] On Behalf Of Lawrence
Serewicz
Sent: 04 November 2009 15:39
To: [log in to unmask]
Subject: What does good records management look like?

Dear All,
I have been away from the list for some time, (Jan 2008) but I thought I
would jump back in as my role has changed.

This may be a Friday question, but what does good or successful records
management look like?  I know we can describe bad records management,
from the total absence of RM structures and process to simply not being
able to locate and extract records.

What, though, is the opposite?  How do we know when we have good records
management? Is this a metaphysical state where the overall culture of an
organisation is able to deal with requests for information well and able
to support the performance management framework?  I know there are
arguments for "business cases" but to my mind that simply reduces RM to
an economic question.

I realize that compliance with ISO 15489 can be considered "good records
managment" but is it simply compliance or something more?  When we talk
about good RM or successful RM, what is it?

Perhaps the deeper question is what is the relationship between RM and
the day to day work of most staff?  In one sense, RM as a cultural
phenomenon, rather than a "business case", is one where all staff
recognise their role and responsibility towards information they create,
handle, and store as well as the records that may be created as a
result. 

Good RM would then be part of a good corporate culture whereby people
are operating with a wider awareness of their RM/DPA/FOI/EIR roles and
responsibilities as fits their post.   RM is seen as something they do
as part of
their own work rather than somethign that is done to them or by someone
else on their behalf.  However, if this is the case (very much open to
debate and
discussion) then RM needs to fit more into the corporate culture perhaps
through the performance management framework rather than for what many
may perceive as a specialism hidden away within or around FOI/DPA
(access to information) or archives.  I am not suggesting Performance
Indicators for RM as such, which creates its own problems, but
understanding how it fits within the wider corporate culture and the day
to day lives of most staff.

The above is a gross simplification designed to develop debate. My
concern is that the more RM is seen as a technical specialism done by
someone rather than seen as part of everyone's existence [not that
everyone is an RM but rather they have to be aware of RM] then the hard
it will to make the "business case" or the cultural case.

My apologies if this has been discussed in the archives. I scanned them
but could not find this type of discussion.

I would be grateful for your views on this topic.

Best,

Lawrence

For any technical queries re JISC please email [log in to unmask]
For any content based queries, please email
[log in to unmask]



Securing the future... - Improving services - Enhancing quality
of life - Making best use of public resources.

The information in this email is solely for the intended
recipients.

If you are not an intended recipient, you must not disclose,
copy, or distribute its contents or use them in any way: please
advise the sender immediately and delete this email.

Perth & Kinross Council does not warrant that this email or any
attachments are virus-free and does not accept any liability for
any loss or damage resulting from any virus infection. Perth &
Kinross Council may monitor or examine any emails received by
its
email system.

The information contained in this email may not be the views of
Perth & Kinross Council. It is possible for email to be falsified
and the sender cannot be held responsible for the integrity of
the information contained in it.

Requests to Perth & Kinross Council under the Freedom of
Information (Scotland) Act should be directed to the Freedom of
Information Team - email: [log in to unmask]

General enquiries should be made to [log in to unmask] or
01738
475000.

Securing the future... - Improving services - Enhancing quality
of life - Making best use of public resources.

For any technical queries re JISC please email [log in to unmask]
For any content based queries, please email [log in to unmask]

IDOX group email privacy & confidentiality notice:
The information contained in this email message is intended only for the person or persons to whom it is addressed. Such information is confidential and privileged and no mistake in transmission is intended to waive or compromise such privilege. If you have received it in error, please destroy it and notify us on 0870 333 7101. If you do not receive complete and legible copies, please telephone us immediately. Any opinions expressed herein including attachments are those of the author only. IDOX group does not accept responsibility for the accuracy or completeness of the information provided or for any changes to this email, however made, after it was sent. Please note that it is your responsibility to scan this message for viruses.

Registered Address:
IDOX plc, 2nd Floor, 160 Queen Victoria Street, London EC4V 4BF

Registered Numbers:
IDOX Software Ltd - 2933889 in England and Wales
IDOX Information Services Ltd - 4356896 in England and Wales
TFPL Ltd - 1946440 in England and Wales
j4b Software & Publishing Ltd - 06706798 in England and Wales

Vat Registration Number: GB 766 8008 04

Please consider the environment before printing this email.