On October 7, NISO sponsored a workshop in Chicago called â€œE-Resource Management: From Start to Finish (and Back Again).â€ In the opening keynote, Norm Medeiros of the Tri-Colleges (Haverford, Bryn Mawr, and Swarthmore) asked what value electronic resource management (ERM) systems bring to libraries. His answer? Not much, yet.
If what your library needs most is a data warehouse for e-resources information, Medeiros said, you should not purchase an ERM. An Access database or other homegrown solution will work just as well, with less cost in both dollars and staff time and expertise for implementation. He said that libraries with large, distributed staffs, decentralized environments and the need to manage higher-level tasks or functions need these tools most â€“ but that they are mostly failing at those very functions for those very libraries.
Medeiros listed functions he wanted ERMs to perform, most of which involve being able to re-use data with flexibility and fluidity to eliminate the need for duplicative systems and â€œtechnical drudgeryâ€: he thinks ERMs should allow for global updating, incorporate a knowledgebase, be interoperable with other systems, and store data and generate reports. He stressed that managing workflow and communication are the biggest e-resource management challenges and no existing ERMs really meet them effectively.
For a while now Iâ€™ve thought that OCLCâ€™s interlibrary loan software ILLiad would make a great model for an ERM. It combines a knowledgebase (patron data and lending library information as well as WorldCat bibliographic data) and data tracking and reporting (statistics about requests, patrons and expenditures) with a web-based workflow management portal that allows staff to see at a glance the status of all the libraryâ€™s active borrowing and lending requests. Staff in different physical locations have access to all the data they need. Each task in the process â€“ from the submission of a request, to searching, copyright clearance, requesting, re-requesting, and fulfillment or cancellation, with all the capability to communicate with patrons, staff and other libraries in between â€“ is defined, and as one process is completed, the software automatically pushes the request on to the next step in the workflow. Libraries have ILL down to a science, and, even without ILLiad, libraries donâ€™t lose requests, can be reasonably sure of responding to them within a certain time frame, and can measure and predict their costs and workloads with accuracy.
Why does interlibrary loan work so efficiently while electronic resources management is still such a mess? Are e-resources really that much more complicated? Think of all the variables involved in an interlibrary loan request â€“ a patron, a source (database, bibliography), local ILSâ€™s, borrowing libraries, lending libraries, student workers, consortia, scanning software, legal issues (copyright, licensing), the postal service, language barriersâ€¦ And letâ€™s not forget â€“ much of the work now involves digital objects, not paper: interlibrary loan departments, while they still deal with physical objects, have successfully migrated to working in an electronic environment with electronic resources when possible. What have we figured out about ILL that we canâ€™t seem to about databases?
I keep coming back to that idea of a knowledgebase. We have them for e-journals, but, for databases, every library is still creating its own. Vendor contact information (especially support websites and e mail addresses), information on where and how to download usage statistics, information about MARC record availability, customization options, etc., should come with the system â€“ I shouldnâ€™t have to enter it into my ERM the first place or update it ever. Such a knowledgebase should also include information about databases â€“ titles, descriptions and urls. There should be no need for every library to separately maintain urls to all our EBSCO databases, for crying out loud. We donâ€™t do this for e-journals â€“ why are we doing it for databases?
The same thing goes for data sharing. This summer I looked at all the ARL librariesâ€™ websites to find out how they were managing public displays of their databases (A-Z lists, subject lists, and full resource records). Most libraries use homegrown systems to generate the webpages that contain this information, not vendor-supplied ERMs, though many of the same libraries have purchased ERMs. Exporting data in a shareable format from most vendor software requires complicated workarounds which even then donâ€™t guarantee it can be used where itâ€™s needed. Most libraries maintain double sets of data about their e-resources because they lack systems that allow data to be used and re-used as necessary.
Why are we stuck in this place with e-resources management while resource sharing is light years ahead? Maybe because creating a patron- and library-ready knowledgebase of databases would require competing vendors to work together (gasp) when what they really want to do is each create their own products to get a piece of the library automation pie. Resource sharing works because libraries believe in working together. As long as libraries keep feeding Audrey II, weâ€™re never going to get the collaboration from vendors we need. And even though OCLC has been accused of anticompetitive business practices, you still have to admit that the system libraries have created through OCLC for resource sharing is one of the best and most cooperative things we have.
Lately Iâ€™ve been engaging in a lot of the â€œtechnical drudgeryâ€ Medeiros decried, entering all the administrative information about our databases and their vendors into the data warehouse that is our ERM, mostly because Iâ€™ve discovered Iâ€™m spending way too much time trying to track this information down when I need it. I have admin info in there, stats info, vendor info, database info, tutorial info â€“ you name it. Iâ€™d be happy to send it to anyone who wants to re-code it into XML so we can re-deploy it and everyone can use it. But youâ€™d have to get it out of my ERM first.