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]