Martin,
You can usually create (or get a developer or vendor to create) a
'lookup' table from an existing data source to pull unique references
from when adding or searching for metadata. You can also pull other
data from the lookup at the same time (name/DOB/address) and fill
metadata fields with it. This would eliminate duplication of folder
names because you could validate the entry against the lookup and you'd
have access to the data source from within the edrms. It is also very
popular with users.
Regards
Suzy
Suzy Taylor
Records Manager
New College Durham
Framwellgate Moor
Durham
DH1 5ES
Tel: 0191 375 4422
E-mail: [log in to unmask]
"SAVE THE PLANET - PLEASE DO NOT PRINT THIS EMAIL UNLESS STRICTLY
NECESSARY"
>>> Martin Anderson <[log in to unmask]> 01/12/2009 01:28 >>>
Thanks to Paula, Matt, Suzy, Marc and Oliver for your comments and
attachments which have given me quite a bit to think about.
I take the main points that an EDRMS is not quite as simple as it seems
and
that the majority of the effort required in implementation and use
comes with
the preparatory work, the training and the maintenance. I cannot agree
with
Paula that because there are less players in the market that the market
is
shrinking … (IBM - Microsoft?) I think the market will grow hugely and
that
costs must tumble.
As you may have surmised, I work in local government and what drives my
current thoughts is watching and trying to usefully participate in the
implementation of an EDRM solution in our Local Authority. Good
practice
seems to have dictated that we try to use a single large
“corporate” EDRMS
and adopt a fileplan based on the Local Government Classification
Scheme.
This approach involves each service area trying to reconcile our
multifarious
needs in respect of file structure and metadata and try to load our
documents
with some sort of common good practice. The “front end” for the
retrieval of
documents would presumably then be a direct interface with the EDRMS
bringing up results which will be only as well differentiated as the
metadata
which we have time to apply. This is all very labour intensive and I am
not
convinced that it is time well spent.
I see other problems with the approach apart from the sheer amount of
work
involved in the creation of the file structure and in applying
sufficient
metadata to make the content properly searchable. We could file address
based case records on a file structure based on folders for each
address but
this could possibly suffer from duplication as in:
102 Willowbrook Rd
102 Willowbrook Road
102 Willow Brook Road
….. etc etc with every persons idea of how that address is spelled/
formatted
or every mistake potentially creating a separate folder (NB I have
often seen
such variation within documents) This possible duplication of folders
for a
single address is a problem and therefore the wish to base a file
structure on
UNRN instead (because of the U = Unique)
This then raises further problems of how to search or browse for
documents in
a non-intuitive structure. Would you now have to go into the case
management software to search for the UPRN to then look for a folder in
the
EDRMS or do you have to take the time to manually add the relevant
metadata to locate the case which again could contain the same mistakes
you
were trying to avoid in the folder naming?
If, as I surmise, EDRMS's will become significantly cheaper (if only to
compete
with Sharepoint), surely it is best for each Case Management suite to
have a
possibly basic but fully integrated documant management system at the
back
of it. The case management software already contains all of the
metadata and
the search facilities you should need including facilities to find
documents
associated with a case, the linking of cases to an address and the
linking of
the address to further cases etc. It would require a considerable
amount of
applied metadata to allow the “corporate” EDRM system to do all of
this.
If all these various small EDRMS’s were allocated folder structures
representing
an appropriate portion of the LGCS for their relevant service area and
they all
had a common architecture and could output content together with xml
metadata, you could later merge or split data as you wished to
accommodate
changes in organisational structure. Many CRM and Workflow applications
already have bolt on EDRMS solutions supplied by their vendors which we
could encourage vendors to develop towards common interoperability
standards. Most of these software packages also have pretty good access
control and retention could be as simple as delete all cases and
associated
rerords before XX/XX/XXXX Date.
I see this as a more likely start on the long road to success than
trying to get
your IT dept or a single company to sort out adapters to a wide range
of
disparate systems while huge backlogs of uncaptured information build
up. Our
potentially wonderful (allegedly) corporate EDRMS is virtually useless
until we
can work out how to apply large amounts of metadata and/or integrate it
with
existing systems.
Again … comment welcome.
Regards,
Martin
For any technical queries re JISC please email [log in to unmask]
For any content based queries, please email
[log in to unmask]
For any technical queries re JISC please email [log in to unmask]
For any content based queries, please email [log in to unmask]
|