Magazine article Computers in Libraries

You Have How Many Spreadsheets? Rethinking Electronic Resource Management

Magazine article Computers in Libraries

You Have How Many Spreadsheets? Rethinking Electronic Resource Management

Article excerpt

Meet Theresa Borchert, the electronic resources librarian at our library. Theresa's email inbox is a disaster. Or rather, it was. Concordia College, a small liberal arts college in the Midwest where author Erika Rux also is employed as computer and web services librarian, had a library like every other in the country. Our internet-based resources and collections were growing exponentially, and we were poorly equipped to handle the explosion. Theresa had become a "hub." She and she alone knew where to find passwords, terms for license agreements, email support addresses, and anything else we needed to process and update access for our online resources. She was maintaining multiple spreadsheets, many of which contained duplicate information; her paper file cabinet was overflowing; and her email inbox was an unwieldy mess of messages containing passwords, updated passwords, contact information, new contact information, etc. Additionally, while Theresa's workload was steadily increasing, members of the staff who were managing print resources found their workloads decreasing. We needed a better solution. We needed to organize all of this information in a more efficient way, and we needed to store it in a place where multiple members of our staff could access it.

Investigating ERMs

We knew that there were commercially available electronic resource managers (ERMs) that might suit our needs, and we decided to start with an investigation of those options. After reading articles written by Marshall Breeding, Maria Collins, and Donna Ekart about the major commercial systems available, we developed an information-gathering plan. Staff members wanted to know what other libraries were doing, and we needed to prioritize our requirements.

Our first step was to poll librarian colleagues through an email list. We asked about experiences with the different vendors, and we began collecting data about the pros and cons of each. Simultaneously, we began analyzing our current practices. We considered the data we were already trying to manage, brainstormed about new information that needed to be tracked, and looked at our current workflow to begin thinking about ways to increase our effectiveness and efficiency.

The results of our investigation were somewhat surprising to us. One of the tools we learned of was very appealing, but it was still in development. Others provided attractive features (e.g., robust knowledgebases containing metadata for the major databases, server space to store and preserve data, and support and ongoing development). But the challenges these systems posed for our library quickly began to outweigh these benefits. None of the commercial tools did everything that we wanted it to do. None of them provided an out-of-the-box solution to all of our challenges. And all of the products came with significant costs--they presented budgetary challenges in the form of initial setup and training costs, as well as ongoing contractual obligations. With any system we decided to implement, we realized that our commitment of staff time was going to be immense. These realizations weighed heavily on us, and we decided that the commercial tools could not provide the solution that we had hoped to find.

Still, we knew that if we continued on the path we were following, our problems would only become more unmanageable. In the past, we had discussed creating our own relational database using Microsoft Access, and we returned to those conversations. We read about William Doering and Galadriel Chilton's self-created ERM that could be stored on an institution's local server. This system seemed to come closer to filling our needs in terms of customization, and the price was much more accessible. However, after downloading the program, we determined that it really didn't provide us with what we needed. We needed a product or system that could be accessed by multiple simultaneous users. We needed a system that was user-friendly and would not require a lot of technical knowledge and training for our technical services staff. …

Search by... Author
Show... All Results Primary Sources Peer-reviewed


An unknown error has occurred. Please click the button below to reload the page. If the problem persists, please try again in a little while.