ABSTRACT
Library electronic resource management involves administering several complex workflows. The authors share their experiences as librarians at Malmo University, Sweden, in participating in a system development project for the Electronic Resource Management System ROAM, from initial discussions to implementation. An awareness of internal and external processes grounded in Techniques for Electronic Resource Management.
Systems (TERMS) proved to be essential in guiding the various implementation stages. Future challenges for ROAM are considered, mainly concerning integrations with other systems and usage statistics.
Introduction
Effectively managing the various stages of the e-resources life cycle is a challenge that involves development and successful implementation of several internal as well as external workflow processes. Librarians’ desire for a flexible, efficient, and transparent system to “handle it all” might be too much to ask for but wishes are free. When the opportunity presented itself to partner with the company Subscription People in the development project for a new Electronic Resource Management System (ERMS), the E-Resource Group at Malmo University Library took the opportunity to participate. Subscription People had previously developed an ERMS for library consortia, called ConsortiaManager, and was ready to create a similar service platform for individual libraries. Library management and staff saw this as a rare occasion to influence the development of an essential system for e-resource management. This article describes the very first steps and discussions with the system developer, the development and implementation phases, and our experiences and conclusions in using what came to be called ROAM (Research Output & Acquisition Management).
Malmo University
Malmo University, located in the south of Sweden, is a relatively new institution, founded in 1998, with a full-time equivalent enrollment of approximately 12,000 students. The University is currently experiencing growth in research activity, which began following an upgrade from University College to University in 2018.
Malmo University Library employs approximately 40 librarians as well as six additional staff such as library assistants, a bibliometrician and other personnel working mainly in researcher support. Three physical libraries are spread out on different campuses in the city, but acquisition, cataloging and e-resource management are centralized as is the budget for collections, staffing and library premises. Four librarians working with e-resource acquisition and management were involved in the ERMS development process, alongside their regular work assignments. The need for a new ERMS
Reviewing the library’s ERM processes
At Malmo University Library we have a diversified system landscape with products from different vendors. We use Sierra from Innovative as our integrated library system, and both link resolver and discovery systems are from EBSCO. Such a diversified system landscape is both good and bad, but all things considered it allowed us to be very flexible when we decided to investigate a new ERMS.
The library had previously used the ERMS Verde from Ex Libris for several years. When Verde no longer continued to be developed in 2013, it was time to move on and start to look for a replacement. Various systems and solutions were considered by the E-Resource Group, and as a complement to Verde, a homegrown OneNote solution as well as a master Excel file became an acceptable alternative to keep track of the library’s e-resources. But a need was soon articulated for a more comprehensive and efficient system that would support the workflows of the entire life cycle of our e-resources.
In this context, we realized we needed to take a closer look at how we managed our e-resources. This began in 2015 with a purchase of some e-book packages from one of the larger publishers on the market. We did not verify that the packages were available in our link resolver knowledgebase but instead took this for granted. It was not until after the purchase was finalized that we realized the titles were not included in the knowledgebase. This was a real setback and we determined that we needed to better document our processes and create checklists to avoid the same mistakes in the future. We also started to review the literature to see how other libraries were managing e-resources and we found some very interesting articles about Techniques for Electronic Resource Management Systems (TERMS) (Emery & Stone, 2013; Hosburgh, 2014) in the process.
Developing ERMS requirements: techniques for electronic resource management systems (TERMS)
TERMS (TERMS, n.d.) is a process which guides ERM practitioners through the e-resources life cycle. We familiarized ourselves with the process and ran several workshops where we documented our workflows and created checklists for the evaluation and implementation of e-resources. Our work with TERMS was finalized in the beginning of 2016 and is still the framework we rely upon for conducting our daily work. TERMS also provided us with a foundation for what we desired from a future ERMS, which included the following requirements listed in no particular order:
- Save information about licenses, including number of users, dates, terms, etc.
- Display license information in the link resolver menu
- Receive reminder notifications of upcoming renewals
- Save copies of licenses (upload and store PDF files)
- Save administrative information (links to URLs, user IDs and passwords)
- Show which titles are included in packages
- Display financial information and trends for multiple years
- Save information about product trials and new e-resource suggestions (period, results and decisions)
- Collect and save usage statistics
Building a better ERMS
In May 2016, we attended the annual conference coordinated by the Swedish national consortium Bibsam (Kungliga Biblioteket (KB –National Library of Sweden), 2021a) where representatives from Subscription People, a Danish company and developer of the consortium’s newly implemented ERMS, ConsortiaManager (ConsortiaManager, n.d.), gave a presentation. Among other features of the system, they showed a prototype of a prediction tool where different pricing scenarios could be entered to find out how they would affect the consortium’s or library’s budget.
This looked very interesting but the feedback we provided was, as long as we did not have a system where we could even see all our library’s e-resource agreements (local as well as consortial), the prediction tool was not useful since we only allocate part of our budget for national agreements. We then offhandedly asked if and when they would consider developing a system for single libraries as well as for consortia.
The ROAM development process
After arriving home, we sent an e-mail message to Subscription People with some additional input, and they replied that they were interested in learning more about our needs. We had a first meeting with the project manager from the company in January 2017 and afterwards finalized an agreement of cooperation for the development of a software system with the working name Library Manager. That year, we also had several meetings with the project manager to work our way through TERMS and what this meant for day-to-day work with our e-resources, which included considering several workflow questions: What were our usual steps for investigating new e-resources, making first contacts with a new publisher, or handling renewals? What happened from the time we agreed upon a license until it had been executed and the invoice paid? And finally, how did we implement a new resource and subsequently evaluate it once it had been in use for a while? In the beginning, the new system would nominally be developed as a module to ConsortiaManager and automatically populated with the information from our consortial licenses.
This turned out to be more technically difficult than expected to implement, so the developers decided to opt for creating a brand-new standalone system instead. During the course of 2017, Subscription People also set up a similar collaboration with the library at the Stanford Graduate School of Business. The three parties involved in the development did not participate together in the same meetings, and all communication from our side of the project was held directly with the project manager from Subscription People. In the autumn, Subscription People shared the first mockups of what was eventually to be called ROAM, detailing how they translated our discussions and thoughts about processes based on TERMS into a system design. The mockups would evolve into a beta version of ROAM a year later. Development continued during 2017 and 2018 with regular meetings held during this time to provide feedback on the work that had been completed. We were able to test the beta version in the winter of 2018–2019, a big step for us as it meant our mental picture of an ERMS was blended with reality.
Evaluating other systems
We also took a close look at other systems available on the market in parallel with the ROAM development process. We found that ProQuest had withdrawn their ERMS and that EBSCO had done the same, both opting to put their efforts into broader library management systems.
Another university library in Sweden using the open source ERMS CORAL (CORAL, 2020) gave us a presentation on how they utilized this system, after which we created a test account and applied our ERMS requirements stated above to evaluate it. Our conclusion was that CORAL did not meet all our requirements, but even more important was the fact that we did not possess the expertise or resources necessary to manage an open source system in-house. Implementing CORAL would have meant contracting with a third party to host, develop, and customize the system. As a result, we waited to see if ROAM would develop into a satisfactory system that met our requirements before potentially committing to CORAL.
Selecting ROAM
After testing the beta version during the winter of 2018-2019, we felt that ROAM fulfilled most, if not all, of the ERM requirements we had specified before entering the project. We therefore decided to commit to the product, finalized an agreement with Subscription People, signed the license, and began to prepare for the implementation.
Before the project with Subscription People began, we had discussed the potential risk of entering into a collaboration with a system developer. Would our engagement in the project and fear of disappointment make us blind to deficiencies in the final product? In light of this concern, the list of requirements we developed was essential in keeping us on track and guiding us in finalizing our decision to select ROAM.
As one of the first institutions to commit to ROAM, we experienced much trial and error in implementing and becoming familiar with the system. There was no formal training or support documentation in the beginning as exists today, but the developers helped us understand the system and were available for discussions and questions whenever needed. It was a special circumstance to start using a system still very much in an early phase of development. Design elements were changing, and features were regularly being added, with the overall experience being fun but also a lot of hard work.
Implementing ROAM
In autumn 2019, we started to populate the system with all information pertaining to our current e-resources. At first, we hoped to be able to export the data from our existing ERMS Verde. This turned out to be impossible since the format of the data was incompatible with ROAM and thus could not be imported into the system. Instead, we manually populated large Excel files with data that Subscription People could then import into ROAM. Taking the initial steps to implement a new system is challenging in many ways. It takes time and extensive planning, including having many discussions on how, what, and maybe even why a particular set of information should or should not be included in the ERMS. For instance, we had ideas about how to enter information for one-time e-book package purchases that seemed fine at the time, but which resulted in unforeseen and unwanted consequences for the financial overviews provided by the system. We learned it was necessary to make adjustments along the way and appreciated that the system allowed us to make them.
ROAM functional modules
The basic structure of ROAM is divided into the following main functional modules:
Publisher –Where information about publishers, including URLs, contact information, etc. is stored.
Vendor –Used to track purchases or subscriptions procured through an entity other than the publisher (e.g., a consortium, subscription agent, or other intermediary).
Products –All the basic information about a product, including special characteristics like title lists, is located here. The ability to create product types (e.g., e-books, serials) also exists.
Subscriptions –Where all information about a specific purchase or a subscription is collected and managed, including pricing information, administrative details, subscription period, etc.
All of the functions above are connected within the system workflow, called the Dashboard (Figure 1). The workflow guides users through steps starting with Consideration (requesting price information), followed by Negotiation (reviewing a license, adding final pricing), moving to Decision (engaging stakeholders, conducting product evaluation, making a final procurement decision, and placing orders), and finally to Invoicing and Implementation.
Meeting our ERMS requirements: a ROAM scorecard
After we had been using the system for a while, we took some time to fully evaluate how ROAM was meeting our ERM needs. Below, we score ROAM’s capability for meeting our TERMS-defined requirements, assigning a rating of Yes, No, Yes and No, or To Be Determined to each.
Requirement 1: Save information about licenses, including number of users, dates, terms, etc.
Yes. All pertinent information about a license may be entered into the system. The ability to define terms is available and we have created as many as possible using the same vocabulary employed by Bibsam in ConsortiaManager but have also added a few of our own (Figure 2).
Requirement 2: Display license information in the link resolver menu To Be Determined. We have not explored this yet, but the information should be possible to fetch through an API. This requirement has not turned out to be as important for us as we initially thought it would be.
It is mostly our interlibrary loan colleagues who need this information on a daily basis and, as they are also using ROAM, they can find and access this information within the system itself.
Requirement 3: Receive reminder notifications of upcoming renewals
Yes and No. Reminders are not sent to an e-mail address but utilizing the system workflow a task notification appears on the Dashboard page. We try to have all subscription periods running with the calendar year and it is easy enough to create a report with all pending periods every autumn.
Requirement 4: Save copies of licenses (upload and store PDF files)
Yes. We can upload and store any document related to a license.
Requirement 5: Save administrative information (links to URLs, user IDs and passwords)
Yes. We are saving all e-resource administrative information in the system. All URLs, user IDs and passwords are stored and updated in ROAM.
Requirement 6: Show which titles are included in packages
Yes. We can upload title lists and do so primarily for purchased e- book packages. Since most of our journals are licensed through Bibsam consortial deals, we have settled with the title lists found in ConsortiaManager for them.
Requirement 7: Display financial information and trends for multiple years
Yes. This information may be retrieved in several ways; for example, it may be displayed at the specific product level (Figure 3). A customized report for one or a selection of products, or a complete report including every single subscription or one-time purchase stored in the system, may be created.
Requirement 8: Save information about product trials and new e-resource suggestions (period, results and decisions)
Yes. It is possible to create and edit product types; we created two product types called TRIAL and SUGGESTION. Whenever we evaluate a new e-resource, we use one of these product types. If we decide to procure a resource after a trial, we continue the process by changing the product type –to, for instance, BIBLIOGRAPHIC DATABASE –and start a subscription. In this way it is easy to go back and review the reasons leading to a subscription decision.
Requirement 9: Collect and save usage statistics Yes and No. It is currently possible to manually enter very simple usage data for subscriptions. The system displays graphs illustrating usage development (trends) and cost per use (Figure 4). It is not yet possible to manually upload COUNTER reports or automatically harvest usage statistics through the Standardized Usage Statistics Harvesting Initiative (SUSHI) protocol, for example.
Conclusion
ROAM has been in use at Malmo University Library since the autumn of 2019. Our e-resource librarians use it daily to complete ERM tasks such as obtaining subscription details, accessing logins and other administrative information, creating financial and holdings reports, or reviewing one-time purchases. Accomplishing these tasks in a single system is a real timesaver. We no longer use OneNote as an ERMS, and our previously used “master file” in Excel containing pricing and other essential information about database subscriptions has outlived its usefulness.
The road to this point has been lined with many discussions and decision points. How we use ROAM today reflects what we think is essential and important, but this is almost certain to change over time.
A lesson learned is that some of the items that seemed important when we began planning to populate an ERMS with our data, such as keeping track of all subset components of a large e-resource, may not fit system requirements or result in unintended consequences. We learned that splitting data into too many separate records may result in the system providing an unwanted fragmented resource picture, for instance inaccurately detailing cost trends for an e-resource over time. Another example is how we manage one-time purchases. The problem of splitting data between records is especially troublesome for annually purchased ebook packages (e.g., Sage encyclopedias 2016, 2017, and so on). If we create a separate one-time purchase record for each of these, we will never get a full overview –including pricing trends –of what was bought unless we create a specific report in the system. This also creates problems when collecting usage statistics. If we purchased a package in 2017, hopefully it will continue to be used in the years to come, but in this setup, we only have one period (2017) in which to attach usage data. This does not allow us to view trends in system-generated visualizations for all subsequently procured packages with the same title.
Addressing transformative agreements in ROAM also requires workarounds.
Malmo University Library is included in several such deals for journal packages negotiated through Bibsam (Malmo University, n.d.), agreements that combine costs for reading and for article processing charges (APCs) for open access publishing in hybrid journals (Kungliga Biblioteket (KB –National Library of Sweden), 2021b). Some of the agreements have defined publishing and reading costs. We have created two separate subscriptions for each deal to keep track of cost allocation, one for publishing costs and one for regular reading costs. In this way it is possible to identify publishing costs, but on the other hand it is more complicated to get a complete picture of overall costs, unless a specific report is generated, exported, and manipulated. Managing two cost units for one subscription also has negative implications for compiling usage statistics as two separate subscriptions in the system represent one journal package. Our implementation choice in this case, logical from a budget point of view, prevents us from linking usage to the total cost of a deal. It is obvious that transformative deals no longer place all value into subscriptions but share it with the cost of publication. How this transformation will be addressed in any ERMS on the market remains to be seen.
Subscription management is generally a strength of ROAM, but the system would benefit from further development to better support nontraditional resources (e.g., transformative journal agreements and purchased packages). This has been pointed out to the developer who is working on a solution.
We made the decision to include all single journal subscriptions in ROAM, both print and e-journals, even if we use a subscription agent to handle them. The reason for this was our underlying desire to keep track of all data related to each subscription in one system as much as possible. The downside of this approach is that we now use two systems to manage single journal subscriptions, the subscription agent platform and ROAM. On the positive side, information related to journal administration, pricing and contacts are kept together in ROAM. In fact, ROAM could be used as a platform to manage all single subscriptions without a subscription agent, should this seem like an attractive and plausible solution in the future. The same effect with double administration is seen in connection with consortial deals. All communication with Bibsam on these subscriptions is channeled through ConsortiaManager, and as long as there is no integration between ConsortiaManager and ROAM, double work is required to keep a holistic perspective of our e-collections.
Another potential timesaver would be for ROAM to develop processes that better support when a resource is paid in foreign currency. Today, we need to follow up on each of these payments and continuously update final costs when payment in local currency is fulfilled. To make this possible, both system development and integration between accounting systems used by the University and ROAM would be necessary.
After using ROAM for a while, we decided to deactivate all parts of the workflow except adding price information and decision-making. From our point of view, the available system workflow features are not currently flexible enough for our needs. For instance, it is only possible to contact stakeholders when that particular task comes up in the workflow, thus preventing us from contacting them any other time utilizing system functionality.
The most important lesson learned during our first years of using ROAM is that one should be prepared to reevaluate and adjust processes and procedures along the way. We have found that a system that supports a flexible and iterative approach to our working processes is essential, and not the other way around –a system that forces you to work in a particular way for an undefined future period.
The future
So, what can we expect from ROAM in the future?
We hope to see a solution for the challenges we face in managing one-time purchases and transformative deals in the system, which would provide us with a better overview of resources belonging together in one way or another.
ROAM would greatly benefit from adding the ability to harvest and upload usage statistics; this feature would help to make it a really strong ERMS. In addition, if ROAM could fetch and import data from other systems such as ConsortiaManager or those used by subscription agents, it would mean decreasing the amount of double work currently necessary for librarians and staff to support multiple systems. Similarly, integrations with any accounting system in use by the University would also simplify workflows.
So far (as of June 2021) we are one of three university libraries in Sweden using ROAM. To better support each other, we created an email list to communicate issues and questions. Perhaps we will establish a more formal user group in the future. Any ERMS, we believe, benefits from an engaged user group and a system developer that listens and takes into account the needs of its customers. We have found that ROAM supports our library’s most essential e-resource management needs, enabling us to effectively conduct and document our work and be more proactive than was possible before.
JOURNAL OF ELECTRONIC RESOURCES LIBRARIANSHIP
2021, VOL. 33, NO. 4, 288–297
https://doi.org/10.1080/1941126X.2021.1988467
References
ConsortiaManager. (n.d). About ConsortiaManager. https://consortiamanager.com/pages/about_us
CORAL. (2020). CORAL: An open source electronic resource management system. http://coral-erm.org/
Emery J., & Stone, G. (2013). Techniques for electronic resource management: Introduction and literature review.
Library Technology Reports, 49(2), 5–9. https://journals.ala.org/index.php/ltr/article/view/4732
Hosburgh, N. (2014). Managing the electronic resources lifecycle: Creating a comprehensive checklist using Techniques for Electronic Resource Management (TERMS).
The Serials Librarian, 66(1–4), 212–219. https://doi.org/10.1080/0361526X.2014.880028
Kungliga Biblioteket (KB –National Library of Sweden). (2021a). Bibsam consortium. https://www.kb.se/samver-kan-och-utveckling/oppen-tillgang-och-bibsamkonsortiet/open-access-and-bibsam-consortium/bibsam-consortium.html
Kungliga Biblioteket (KB –National Library of Sweden). (2021b). Open access in Bibsam agreements. https://www.kb.se/samverkan-och-utveckling/oppen-tillgang-och-bibsamkonsortiet/open-access-and-bibsam-consortium/bib-sam-consortium/open-access-in-bibsam-agreements.html
Malmo University. (n.d). Publishers with prepaid or discounted publishing fees. https://staff.mau.se/tools-and-serv-ices/research-support/publish-and-communicate-research-findings/#accordion-27633
TERMS. (n.d). TERMS: Techniques for Electronic Resource Management. https://library.hud.ac.uk/archive/projects/terms/