Cracking the Code on Acquisitions Transitions

From Voyager to Alma

William H. Midgley and Kavita Mundle

William H. Midgley (midgley@uic.edu) is Resource Acquisition Librarian and Clinical Assistant Professor at the University of Illinois at Chicago and Kavita Mundle (kavita@uic.edu) is Head of Resource Acquisition and Management and Associate Professor at the University of Illinois at Chicago. This paper is based on a presentation given at the DC Ex Libris Regional User Group 2021 Annual Meeting, October 1, 2021, online. The authors gratefully acknowledge the assistance of their colleagues Benjamin Aldred, Sandra DeGroote, Paula Dempsey, and Tracy Seneca for their assistance in preparing this manuscript for publication.

For decades the University of Illinois at Chicago Library relied on the Voyager integrated library system for acquisitions, cataloging, circulation, and other applications. By 2020, a wide range of stakeholders throughout the Library system had established their processes around its functionality. In the summer of 2020 the Library, along with ninety other members of the Consortium of Academic and Research Libraries in Illinois, went live in the final phase of a consortial migration to the Alma Library Services Platform. The absence of a “reporting funds” level in the ledger hierarchy in Alma threatened a fundamental premise of our long-established acquisitions processes through which Acquisitions staff translated transactions between a librarian-facing ledger and totally different University financial categories. A creative solution using Alma’s “Reporting Codes” feature was discovered after interviews with stakeholders, which prevented significant confusion throughout the Library and preserved all our processes. This case study describes the history of our acquisitions practices, the fundamental problem raised by the ledger structure in Alma as compared to Voyager, and the solution designed utilizing Alma’s “Reporting Codes” feature.

The University of Illinois at Chicago is a large, urban, public, Carnegie Research 1 university headquartered in the Near West Side of Chicago, with two additional campuses throughout the state and an annual budget of around $3.6 billion. It serves a student body of over thirty-three thousand, roughly two-thirds of whom are undergraduates and the rest graduates/professionals. It offers over three hundred undergraduate, master’s, doctoral, and certificate programs across its sixteen colleges, and employs more than 2,900 faculty and 6,000 civil service employees. It is the largest university in the Chicago area and a member of the University of Illinois system, which includes the flagship University of Illinois at Urbana-Champaign and the University of Illinois Springfield. UIC has five libraries: the Richard J. Daley Library, the Library of the Health Sciences, two regional health sciences libraries in Rockford and Peoria, and a law library. The Richard J. Daley Library is the operational center of the University’s library system.

The RAM (Resource Acquisition and Management) Department located in the Daley Library provides metadata, acquisitions, e-resources, and collection analysis and management services to all UIC libraries, except the law library. RAM consists of two units: an Acquisitions Unit and a Metadata Unit; the department also includes a collection and analysis librarian who reports to the head of RAM. The Acquisitions Unit acquires all print and electronic resources, streaming media, physical media, special collections items, and other resources, and manages shelf-ready processes and approval plans. E-resources staff within the Acquisitions Unit specialize in acquisition of electronic resources and troubleshooting, licensing, vendor correspondence related to e-resources, and organizing trials and renewals. The Metadata Unit handles MARC and non-MARC cataloging and is heavily involved in collaborations with the Special Collections and Digital Programs departments. RAM includes five faculty—the department head, e-resource librarian, metadata librarian, resource acquisition librarian, and collection analysis and maintenance librarian—as well as twelve staff members, and four to five student employees.

Migration: Voyager to Alma and Primo VE

The University of Illinois at Chicago Library is a member of the Consortium of Academic and Research Libraries in Illinois (CARLI). CARLI is the premier academic library consortium in Illinois, serving 127 libraries, providing a shared union catalog (I-Share) for resource sharing and delivery of materials, facilitating e-resource contract and pricing negotiations, and offering training and professional development opportunities, among other services. It centrally hosted the Voyager integrated library system (ILS) for most member libraries from 2002 to June 2020 and provided VuFind as the discovery interface for users. While VuFind replaced the traditional online catalog that enabled users to browse and search all the resources, it did not provide direct linking to e-content without using a link resolver product.

As Voyager was designed to manage print resources, member libraries had to use other methods or stand-alone products from multiple vendors to provide access to their e-resources. The combination of different products was inefficient and confusing; CARLI needed a more robust ILS that would integrate more library functions into one single system. Ex Libris’s Alma and Primo VE offered a complete solution to coalesce print and e-resources management, replacing link resolvers such as SFX. Primo VE provided not only a public-facing discovery interface with real-time discovery of both print and e-resources, but also support for reserve materials and other interlibrary loan services. A significant difference between Voyager and Alma is that the latter allows for automated, direct export of invoices into the campus finance system (Banner), which was not possible with Voyager. Over several years in the late 2010’s, CARLI leaders and members decided to switch to Alma and Primo VE collectively. The migration was slated to go live in summer 2020.

After nearly twenty years on Voyager, a wide range of stakeholders throughout the UIC Library had long established their processes around its functionalities and the constraints it imposed. In June 2020, the Library with ninety other members of the CARLI consortium went live on Alma after a years-long migration preparation period. As part of this migration, we began to set up automated export of invoices from Alma to Banner. This article describes how, as we implemented the export process, a seemingly small technical difference between the ledger architectures of Alma and Voyager threatened a total breakdown of complex, critical, and long-established processes. We then describe how we discovered and implemented a creative solution under strict time constraints to prevent major confusion among Acquisitions staff, the collections coordinator, subject liaisons, and the library’s Business Office. This solution allowed us to preserve and even improve our processes.

Literature Review

The authors’ review of library literature uncovered a significant volume of studies related to the evolution of integrated library systems and the experiences of libraries migrating from one system to another, as well as a few on how migrations affected library acquisitions workflows. This review offers a snapshot of relevant literature grouped into three categories pertaining to the scope of this case study: evolution of integrated library systems, migration experiences of libraries to newer library systems, and acquisitions-related workflow changes that transpired due to ILS migrations. Notably, however, studies describing how libraries have used features and capabilities of next-generation library systems to streamline acquisitions functions are rare.

Evolution of the Integrated Library System

The origin of the ILS dates to the late 1960s/early 1970s. ILSs evolved considerably through the twentieth century from circulating materials, to creating catalog cards, to the traditional integrated library system (ILS), to their latest iteration of what is now called the “library services platform (LSP),” a term coined by Marshall Breeding to define systems which use cloud computing and web 2.0 technologies.1 Studies in the library literature have addressed reasons for libraries’ migrations from “traditional” ILSs to modern and next-generation cloud-based library systems. From the 1990s to early 2000s, ILSs were built as stand-alone systems with separate modules for cataloging, acquisitions, serials, and/or circulation. These systems were designed primarily around print materials and were not reconfigurable for accommodating rapidly growing collections of electronic resources and digital collections.2 As libraries started to invest heavily in the proliferating electronic and digital content, managing and discovering it using a traditional ILS became increasingly challenging. For example, they were unable to handle subscriptions and licensing information for electronic resources, especially at large scales.3 To compensate, libraries began using add-on products such as stand-alone electronic resources management systems (ERMs), OpenURL link resolvers, and federated search products to search and discover their electronic and digital resources.4 The lack of integration between these various products presented challenges to library staff in terms of duplicate data in multiple systems, and to users who had difficulty accessing electronic resources.5 To consolidate inefficient workflows, libraries needed a single comprehensive resource management system to accommodate and integrate all workflows that would encompass the work of acquisition, description, and access to both print and electronic resources.6

ILS to Library Services Platform (LSP) Migration

The year 2011 marked the beginning of a new era for library automation when Marshall Breeding proposed the concept of a next-generation ILS that embraced a more unified approach and supported the management of all forms of content through cloud computing, known as “Library Services Platform.”7 Advances in information technology compelled libraries to consider remotely hosted library systems that were supported by vendors and used by consortia.8 Migrating from an ILS that had been in use for decades to an LSP presents enormous challenges in terms of time, money and organizational readiness and it is crucial to understand how libraries have successfully taken this leap. A significant amount of literature documents case studies describing libraries’ experiences of the long and complex process of migration from an ILS to a modern LSP, but very few studies have reported migration experiences from an acquisitions point of view.

Many studies describe a step-by-step account of reasons for migration, benefits and challenges encountered during the migration for a library as a single university library or a member of a large consortium.9 Fu and Carmen offer a case study of Central Washington’s University’s migration to Alma and Primo which highlights their migration as a time-consuming process.10 The migration work needed cross-departmental teamwork to successfully complete all migration-related events; their study emphasizes the importance of systems and e-resources librarians in fixing and reporting outstanding issues.

Cote and Ostergaard also explored the skills and competencies of electronic resources librarians from the Treasure State Academic and Information Services (TRAILS) Consortium at the time when the consortium was migrating to a next generation of ILS.11 They suggested using NASIG’s “Core Competencies for Electronic Resources Librarians” as a basis to approach the implementation process. They emphasized electronic resources librarians as critical to this process due to their prior experience in troubleshooting e-resources, critical and analytical skills and their experience in managing communications between vendors. Dula and Ye’s case study on Pepperdine University Libraries’ migration to OCLC’s WorldShare reported that technical services had the most intense changes.12 The areas of acquisitions and cataloging blended, and the work became streamlined. The cloud-based system increased data sharing ability, offering a more strategic approach to acquisitions. Mary Beth Weber described her library’s experience of migration to a new LSP in 2018. She remarked that migrating three million plus records, verifying vendor and patron records, and checking outstanding records were some of the biggest challenges.13 Nicholson and Tokoro recently described their migration experiences from one LSP (WorldCat Management System) to another LSP (Alma).14 This is a one-of-a-kind study reported in the literature. The transition to yet another new LSP was complicated by data irregularities developed during the first migration to the second migration. It revealed significant problems with bibliographic and holdings data that needed significant data clean-up efforts post migration.

Next-Generation Library Services Platforms and Acquisition Workflows

Switching library systems presents opportunities to reevaluate workflows so that new processes are more efficient. Branch provided an account of Virginia Commonwealth’s Alma migration from the Acquisitions Department’s viewpoint.15 The migration presented the department an opportunity to streamline workflows, clean up bibliographic and acquisitions data, integrate print and electronic resources, create efficiencies in work, and improve communication among colleagues. Every institution approaches the process of migration and challenges differently. Working with cataloging or acquisitions in a cloud-based system requires a new perspective. New LSPs offer the ability to automate ordering processes. The ordering processes are more inventory-driven, as opposed to being clustered around bibliographic records, as in the traditional ILS. Parent and Maclean described how working in Alma was different from working with Voyager and outlined some of the challenges they faced in automating acquisitions activities.16 Alma’s inventory-driven acquisition system “required a conceptual shift when rationalizing and predicting Alma behavior.”17 Ordering of physical items required more time than Voyager, and in the beginning of the implementation, ordering of electronic resources had to be halted due to the complexity of creating import profiles, setting match and merge parameters for loading Embedded Order Data, and using the community zone records for e-resources management and access.

When Old Dominion University Libraries migrated from Innovative Interfaces’ Sierra to Alma, the staff experienced challenges pre- and post-implementation.18 In the pre-implementation phase, the acquisitions coordinator noticed that test order records in Alma were complex, required more specific data than the Sierra records, and had a different terminology. Post-implementation problems noted were related to fiscal close creation and rolling over acquisitions data into a new fiscal year and more. Although training and educating staff to use Alma posed a challenge all through the migration, the authors noted that “Alma migration for Acquisitions has worked primarily because of the dedication, determination, and diligence of a very talented staff.”19

Spring, Drake, and Romaine reported on their experiences of being early adopters of Alma for the Orbis Cascade Alliance consortium of thirty-seven academic and public libraries.20 They noted the challenges in understanding the expanse of data clean-up activities, migrating acquisitions order data, and missing data elements in order records, but also commented that these changes presented collaboration opportunities including sharing import profiles, normalization rules, approval plans, vendor information, and record loading processes with other consortia members. Stewart and Morrison also reported on the Orbis Cascade Alliance consortium’s migration and what it was like to migrate as a member of a consortium and how it impacted acquisition workflows.21 Some of the challenges reported by the authors arose from terminological differences between Millennium and Alma. In Millennium, an order is always referenced as a Purchase Order, while in Alma, an order is referenced as a Purchase Order Line which represents a single distinct item. One or many Purchase Order Lines make up an Alma Purchase Order. The authors also noted difficulties in loading and paying EDI invoices; learning to work with records in the Institution Zone, Network Zone, and the Community Zone and understanding how they were linked to each other; and assigning permission or “roles” to staff so that they can perform the work with both cataloging and acquisitions.

Matthews and Davidian described how Rowen University Libraries managed an Alma migration in the absence of their former Acquisitions team.22 The library used Voyager to track workflows for only print monographs and serials, while it tracked electronic resources in Intota. The collection strategy librarian teamed up with the electronic resources and serials librarian to compare workflows in Voyager and Alma, to build new ledgers for the fiscal year 2020, and to integrate e-book purchasing and invoicing by synchronizing with the university financial system, Banner. Thus, by collaborating with workers from technical services, the Alma implementation team was able to employ new workflow and processes.

Lastly, the authors found one study in the library literature that noted an approach very similar to that taken by our institution while building a new functional ledger for carrying out acquisitions functions. When the University of Kentucky migrated from Voyager to Alma in 2016, it became apparent that much of the hierarchical fund structure in Voyager had to be altered to work in Alma.23 The library had a complex Voyager fund structure with thirteen ledgers and 855 funds, including summary, allocated funds, and reporting funds. At migration, Voyager reporting funds migrated as allocated lines and not as reporting codes, as structurally, Alma does not have a reporting funds level. Consequently, the library implemented a new fund structure by reducing the number of funds and using reporting codes to accurately export invoice information to the university’s financial system. The current case study expands on these concepts by describing how the UIC Library successfully implemented a much-needed change using reporting codes as a feature of a new LSP to improve acquisitions practices and workflows.

The Past: Acquisitions Infrastructure in Voyager

Budgeting Process

Every fiscal year’s acquisitions operations began with a collections budget. The Business Office began the process by determining with the dean what percentage of our total budget would be allocated for collection development acquisitions. This total collection development dollar amount was then reconstituted out of university funds accessible to the Library. Specifically, the bulk of the collection development budget for both the Daley and health sciences libraries came from the student IT monies (“CDIT”) and state funds (“ICR”); then, one dollar amount was assigned for collection development to the Daley Library and one to the health sciences libraries as a group (“LHS”) from each of those funds. This funding was supplemented with various smaller gift fund allocations. These gross allocations were given to the collections coordinator, who collaborated with the resource acquisition librarian to more finely subdivide them into ledgers for the Daley Library and Library of the Health Sciences within Voyager. These two ledgers together included more than one hundred allocation funds and were designed with the subject liaisons and collection coordinator in mind, with the Daley ledger finally allocated into funds for subject+format and the LHS ledger by library site+format.

Voyager Ledger Structure

Each ledger comprised hierarchically organized funds of three types: summary funds, allocated funds, and reporting funds (see figure 1). As the name implies, summary funds encompass and summarize a set of allocated funds; for example, for Daley there was one for each subject area encompassing allocated funds for each format within that subject, and for the health sciences libraries there was one for each library site, encompassing funds used for that site’s collection. Allocated funds are funds into which a discrete monetary allocation is placed, and as such they are the building blocks of a ledger. Reporting funds, a feature unique to Voyager, were hierarchically subordinate to allocated funds and did not contain dollar amounts. RAM staff applied reporting funds and not allocated funds directly to each invoice line. Reporting funds were used at our library for three purposes: to deduct an item’s cost from the allocated fund under which the reporting fund was positioned; to provide granular categorization regarding the expenditure’s format and thereby facilitate generation of detailed reports around expenditures; and to apply a numerical code called a “FOAP number” to the invoice line, which categorized the expenditure into campus finance categories (table 1). FOAP numbers are four-part numbers which describe a transaction by encoding “Fund,” “Organization,” “Account Number” and “Program” to standardize expense reporting across university entities. FOAPs are the language of Banner, Ellucian’s enterprise resource planning product used by UIC to organize and automate campus finances.

The reporting fund fulfilled a critical role by translating line-item expenditures from Voyager’s ledger to two other financial categories used by the Business Office and university. Although the ledger was organized by subject+format (for the Daley Library) and library site+format (for LHS) those categories, internal to library acquisitions, had no resemblance to Banner categories or the university’s fund structure. There are two types of campus finance categories relevant to library acquisitions. The first are the university’s funds, out of which the library’s collection development allocation is ultimately constructed—for example, “CDIT” and “ICR.” The second is Banner’s FOAP number scheme. The university’s funds relate to budgeting and allocating at the university level, whereas FOAP numbers relate to reporting and description of individual expenses. It was the FOAP numbers into which line items in Voyager had to be translated to be processed by our Business Office and fed into Banner.

Voyager and Banner

Banner payment categories used for library acquisitions revolve around a few distinct, basic categories of expenditure for library resources: capped (library-owned) and non-capped (leased/rented) firm orders, continuations, and audiovisual acquisitions, whereas the Voyager ledger included five to ten unique reporting funds under each allocation fund, resulting in hundreds of distinct reporting funds. A FOAP number was stored in Voyager in an “institution ID” field of each reporting fund. Each reporting fund’s stored FOAP thus described the format of the expenditure but did not itself encode any information about the subject. This is why there were so many reporting funds; all possible FOAPs had to be replicated under each allocation fund via a subordinate reporting fund. The Library used a feeder program that imported invoice data, including the FOAP, from Voyager and translated it into a Banner-usable data format, finally sending that into Banner to keep our campus finance system in sync with Voyager. This feeder program was a basic script coded for us by Library Systems staff. Invoice lines were created in Voyager by RAM staff and assigned to reporting funds as they completed transactions. RAM staff were familiar with both the names and alphanumeric codes of the reporting funds, but they did not need to see or know the FOAP numbers stored within them. For example, table 2 depicts all the reporting funds under the Engineering Monographs and Engineering Serials allocation funds.

Maintaining this setup, in which the Business Office on the one hand and the Acquisitions staff, collections coordinator, and liaisons on the other had completely different understandings of collections expenditure categories involved significant challenges. Since a small set of ten to twenty possible FOAP numbers was repetitively duplicated under each of the allocation funds in the form of reporting funds, the total number of Voyager reporting funds was around five hundred. The reporting funds’ institution ID fields needed to be adjusted manually for each new year’s ledger, as their FOAP numbers changed slightly each fiscal year. Conversations about expenditures and the budget between the Business Office staff and all other stakeholders required “translation” by a knowledgeable party, which led to at least occasional misunderstandings and inefficiency in communication. Despite these issues, however, the system functioned smoothly in the vast majority of cases, and staff throughout the library were comfortable with it. For their part, Acquisitions staff were fluent with the hundreds of reporting fund names, probably due to an understanding of the recurring patterns among them across different allocation funds, and they understood how to determine the category of a particular expenditure and apply the appropriate reporting fund to it. GOBI Library Solutions, our primary agent for monographs, had all of our reporting funds on file in their system, and our orders placed on their platform would be passed to us with the proper code already applied. Since each reporting fund would deduct the dollar amount on an expenditure from its parent allocation fund, liaisons for subjects or the health sciences library sites could easily monitor their allocations as the fiscal year went on. Despite requiring maintenance of hundreds of very redundant codes, the system negatively affected only the resource acquisition librarian, who had to manually and carefully input hundreds of these repetitive codes into Voyager at the beginning of each fiscal year. Since these processes worked smoothly, we wished to replicate them in Alma for at least our first year in that system.

Problem

In June 2020, ninety-one CARLI member institutions simultaneously went live on Alma and Primo VE. We hoped to minimize differences between our Voyager and Alma configurations during migration due to timing- and staffing-related pressures. Our “go-live” coincided with the very beginning of a work-from-home-period occasioned by the COVID-19 pandemic; this left us with very little time and energy to coordinate any fundamental reimagining of our ledger. However, it quickly became clear that a significant change would be required to get a functioning ledger running in Alma. We realized Alma allows for ledgers, summary funds and allocations funds only; this presented a problem due to the absence of any feature resembling the critical reporting funds. There was no problem with re-creating the general structure of the ledgers because summary and allocation funds were included. Alma’s ledger architecture seems best suited to creating allocation funds that correspond directly to budget allocations existing somewhere in the university or library budget, out of which expenditures would be paid directly. Conversely, our Voyager ledgers basically overlaid an internal collection development-oriented fund structure onto unrelated categorization schemes of university funds and FOAPs. However, without reporting funds or something analogous to it, Acquisitions staff who were accustomed to assigning transactions directly to those categories would be unable to indirectly apply FOAPs. If we couldn’t figure out a way for staff to apply FOAPs to line items in a way that would automatically feed Banner with FOAPs, our payments couldn’t be processed, and the acquisitions process would break down immediately.

Solutions

Several potential solutions were contemplated. The first was to restructure the ledger such that it would be based on campus finance categories or university funds, and not on subject+format and campus+format. However, the new fiscal year was about to start and we needed to get a ledger up and running within a couple of weeks. There was insufficient time to completely re-imagine a ledger from the ground up. Furthermore, the university fund and campus finance categories are meaningless from the standpoint of subject and format distinctions and the FOAP categories do not have budgets or allocations assigned to them anywhere. The idea of constructing collections allocations proceeding from these categories was not reconcilable with the way we needed to use our ledger.

Another approach would have been for Acquisitions staff to directly add FOAP numbers to line items in the invoice creation screen in Alma. There was a field we were not using, “invoice reference number,” on invoices in Alma. However, that field does not allow a set of values to be pre-loaded into it and cannot provide drop-down options for staff; it is simply a free text field. We needed a centrally managed set of values for Acquisitions staff to select from quickly and easily. We became aware that there was an “external ID” field on each of the allocation funds in Alma, but since we determined that the allocation funds in our ledger didn’t ultimately correspond to campus finance categories, these fields could only hold one element of the multi-part FOAP numbers. This would mean some kind of script would still have to find or construct the rest of each FOAP number for a line item. It was not worth it to continue to pursue the idea of using scripts to assemble FOAP strings for each line item, as such a process would be extremely complicated and time-consuming to design—not to mention potentially fragile if it were technically possible. We continued to look for a place where we could work with an uploaded set of complete FOAP numbers.

Alma Reporting Codes

In our search for somewhere to input a set of FOAP numbers and, ideally, text labels for each number that would be intelligible to Acquisitions staff, we became aware of a feature in Alma called “reporting codes.” According to Ex Libris documentation, these are user-defined “primary, secondary, and/or tertiary codes that can be used for analyzing acquisitions in subsequent reporting.”24 These categories are applied to invoice lines but managed outside of Acquisitions in the Configuration area of Alma. Users upload a set of values that consists of a “reporting code” and a “reporting code description.” In our case, the former could be a FOAP number and the latter a reporting fund name staff recognized from Voyager. This flexible feature seemed like a potential solution to our problem, but there were two major hurdles. The first was that we often needed to split line items across multiple FOAPs; this had been possible with Voyager reporting funds. Second, if we simply copied our repetitive reporting funds and their corresponding FOAPS as-is from Voyager, there would be numerous instances of the same FOAP number having different names in the reporting code table. The first problem was overcome when we realized Alma allowed for up to three sets of reporting codes to be uploaded (at the time of migration—now it allows for five) and we determined that we could simply upload an identical set of codes and FOAPs three times in Alma, into each reporting code table, allowing us to employ up to three different FOAP numbers/reporting codes at a time to any line item. The second issue was not so easily solved. An attempt to upload all our reporting fund names and their FOAPs from Voyager into a reporting code table failed. The reporting code field in the reporting code table cannot contain duplicate values; from a database design perspective to repeatedly upload the very same primary key into a table (reporting code/FOAP number) and then label it with different names (reporting code description/the former reporting fund names) is illogical.

To solve that problem, we identified the set of unique FOAP numbers used in acquisitions, and then designed a new reporting code naming scheme that would still be intelligible to Acquisitions staff. To accomplish this, we first isolated the set of all Voyager reporting funds and their FOAPs that had been used over the past couple of years. CARLI ran a report for us against our Voyager data to give us all the reporting funds found in our previous year’s ledger along with the FOAP for each one. The set of unique FOAPs used in acquisitions transactions in Voyager turned out to be only about fifty distinct numbers despite our hundreds of reporting funds. We analyzed those FOAP numbers component by component to determine what exactly each piece of each code represented, and then came up with a new descriptive name for each distinct FOAP number. The end result was a set of reporting code names and FOAPs that de-duplicated the hundreds of Voyager reporting funds down to about fifty distinct campus finance categories, and we worked to develop a set of consistent names for them that Acquisitions staff would understand (table 3). We realized that there would be a training and adjustment period for staff, but overall, this represented a highly workable solution for our overarching problem. Conversations with Library Systems staff confirmed that the Banner feeder could be made to pass this information from these fields in Alma similarly to how it had worked with Voyager, so they gave us a green light to proceed with this new scheme.

Implementation

Previously, Acquisitions staff applied one of several hundred reporting funds to each line item. This served a dual function: due to the ledger structure of Voyager, it simultaneously applied the reporting fund’s parent allocation fund to deduct the cost as well as a FOAP number. This conveyed the category of the transaction to the Business Office automatically via the Banner feeder. Now, Acquisitions staff would have to apply these two separate pieces of information separately by first situating the transaction under an allocated fund (e.g., “ENG-MO,” “Engineering Monographs”) and then applying one of the new reporting codes from a drop-down field on the invoice. Staff were given a “crosswalk” document that translated the old reporting fund into the new reporting code name (“reporting code description”) (table 4).

With the crosswalk document and list of new reporting codes in hand, we explained the changes repeatedly in departmental meetings and paid close attention to this new feature when training staff in Alma acquisitions processes. We made sure documentation was updated and strongly emphasized the importance of using the correct reporting code for transactions, as correct coding had such a significant effect on downstream stakeholders in the Business Office and for potential use of the reporting codes for reporting purposes in the future. We tasked staff who were serving as invoice reviewers for others to pay close attention to double-checking this element of invoices. Further training was given immediately whenever errors were detected. Whenever a change was made to the set of reporting codes, the updated set was immediately distributed to staff and they were instructed to delete any copies of the old set to minimize risk of using an outdated code they may have gotten into the habit of using. The fiscal year proceeded and the system worked smoothly.

Two Years Later: Discussion, Retrospective, and New Developments

The new acquisitions infrastructure has shown itself to be stable and durable enough to be used for subsequent fiscal years with minimal changes, and Acquisitions staff’s aptitude with it increased rapidly and significantly. As mentioned earlier, yearly maintenance of the old reporting funds was a major inconvenience for the resource acquisition librarian, and the new reporting code-based system saves them a significant amount of time. Since Alma supports exporting and uploading spreadsheets, now the set of all reporting codes/FOAPs can be downloaded, the fiscal year number can be replaced in every instance at once with a “find and replace” command, and the new updated spreadsheet can be immediately re-uploaded. Whenever we need to add or subtract a code from the list, this process can be completed in seconds. One minor disadvantage of the new system is that since the reporting code structure is separate from the ledger structure and is maintained elsewhere in Alma, adding a new collection development allocation fund can sometimes be a two-part process. For example, a new gift fund corresponding to a distinct gift FOAP number must be added both in the ledger as a fund and then separately as a reporting code. However, for most new collection development allocations, new FOAPs do not need to be added. Another manageable challenge created by the new system is keeping Acquisitions staff apprised of any changes to the reporting codes. In our first year in the new system, a few transactions were miscoded, but these were usually caught and corrected by having staff approve one another’s invoices in the invoice submission process.

Two fiscal years after this project, in the summer of 2022, a significant additional functionality of our new arrangement was developed to meet an unexpected need. A Banner submission tool used by the Business Office was phased out, and they needed a tool for exporting their own invoices (i.e., those not originating from RAM or related to collection development expenditures) into Banner. We realized we could create a separate ledger in Alma for the Business Office containing a placeholder fund for their use, and they could add their own reporting codes to our table. This would allow them to generate their own invoices in Alma and push them through to Banner with the FOAPs they use, without it interfering or intersecting with Acquisitions data and processes. Acquisitions staff trained Business Office staff in vendor addition, invoice creation, and reporting code creation processes. Business Office reporting code descriptions are preceded by “BO-” in the reporting codes table, to visually offset them from our Acquisitions codes. That our reporting code system in Alma was chosen for the Business Office’s use in this situation is a testament to its simplicity and reliability, as various other options were considered by the Business Office, Library Systems, and RAM librarians and staff as potential solutions to that problem. It also points to the flexibility of the reporting codes feature, as it can encompass different sets of numerical codes and labels for different functions within one (or more) tables.

Although our scheme for utilizing reporting codes was borne out of time constraints and a desire not to re-work our old ledger system, it has proven highly resilient and has allowed additional functionality beyond what we initially intended or imagined. Now library departments outside of RAM can also use Alma to feed invoices into the campus finance systems efficiently. Updates to reporting codes can be done quickly and easily, which enhances our ledger’s flexibility within the fiscal year. The number of values that need to be maintained and updated was reduced from hundreds (of reporting funds) to tens (of reporting codes), which makes our acquisitions processes more intelligible for training purposes.

In retrospect, several generalizable lessons are apparent from our experiences with this system migration. We were caught off guard by a minor but very consequential difference between the acquisitions infrastructure of the two systems that just happened to conflict with our previous ledger construction principles and Voyager setup. This situation could have been avoided or mitigated in a number of ways; for example, by having or proactively designing a ledger structure that was somehow more in line with university finance categories. We also could have allowed ourselves time for a ledger redesign, or at least a smoother rollout of the new system, if we had run trial acquisitions transactions in more detail in the pre-migration sandbox version of our Alma instance that Ex Libris allowed us to use before our migration. We could have tested every step of acquisitions processes in as realistic a manner as possible instead of trusting that Alma could and would do everything the old system could do in the same way. Our experiences also suggest that regular review of the ledger’s structure and contents by major stakeholders with an eye toward simplification and consolidation is beneficial in keeping it as lean, consistent, and uncomplicated as possible. Over time, unedited ledgers can proliferate in complexity and unused funds or codes can clutter the system. With this in mind, the resource acquisition librarian has begun to proactively initiate regular conversations about ledger design with the collections coordinator before each year’s rollover and new ledger creation.

Since presenting at a conference on this project, the resource acquisition librarian has answered listserv inquiries from librarians at other institutions interested in solving similar problems with similar applications of the flexible reporting code feature in Alma. Alma could facilitate many potential approaches to ledger construction and use of reporting codes, so this case study should be of interest to anyone working with ledgers, reporting codes, or invoice automation processes from collection development, library business, or acquisitions perspectives. Facing a migration situation in which we were forced to make significant changes to acquisitions processes and configurations while constrained by unexpected incompatibilities and complex sets of stakeholder needs, this detailed case study provides solutions and examples of how we applied creative thinking and generated long-term solutions for acquisitions and procurement processes.

References and Notes

1. Marshall Breeding, “Library Tech Strategies: Efficiency or Innovation? The Systems Librarian,” Computers in Libraries 31, no. 8 (2011): 28–30; Marshall Breeding, “Library Technology: The Next Generation,” Computers in Libraries 33, no. 8 (2013): 16–18.
2. Geraldine Rinna and Marianne Swierenga, “Migration as a Catalyst for Organizational Change in Technical Services,” Technical Services Quarterly 37, no. 4 (2020): 355–75, https://doi.org/10.1080/07317131.2020.1810439.
3. Xiaohua Li, “What Would Be the Future of the Integrated Library Systems?,” in 2014 IATUL Proceedings, Helsinki, Finland, 2014, https://docs.lib.purdue.edu/iatul/2014/libservsys/3/.
4. Guoying Liu and Ping Fu, “Shared Next Generation ILSs and Academic Library Consortia: Trends, Opportunities and Challenges,” International Journal of Librarianship 3, no. 2 (2018): 53–71, https://doi.org/10.23974/ijol.2018.vol3.2.94; Breeding, “Library Technology”; Li, “What Would Be the Future.”
5. Marshall Breeding, “Looking Toward the Future of Library Technology,” Computers in Libraries 25, no. 5 (2005): 39–41.
6. Yongming Wang and Trevor A. Dawes, “The Next Generation Integrated Library System: A Promise Fulfilled?” Information Technology & Libraries 31, no. 3 (2012): 76–84, https://doi.org/10.6017/ital.v31i3.1914.
7. Breeding, “Library Tech Strategies.”
8. George Machovec, “Consortia and Next Generation Integrated Library Systems,” Journal of Library Administration 54, no. 5 (2014): 435–43, https://doi.org/10.1080/01930826.2014.946789.
9. Sever Bordeianu and Laura Kohl, “The Voyage Home: New Mexico Libraries Migrate to WMS, OCLC’s Cloud-Based ILS,” Technical Services Quarterly 32, no. 3 (2015): 274–93, https://doi.org/10.1080/07317131.2015.1030267; Steve Shadle and Susan Davis, “Wrangling Cats: A Case Study of a Library Consortium Migration,” Serials Librarian 70, no. 1–4 (2016): 116–20, https://doi.org/10.1080/0361526X.2016.1148421; Erin M. Grant, “One Cataloger’s Action-Packed Adventures with Alma Migration,” Georgia Library Quarterly 54, no. 1 (2017): 7; Kristin D’Amato and Rachel A. Erb, “The Road from Millennium to Alma: Two Tracks, One Destination,” Serials Librarian 74, no. 1–4 (2018): 217–23, https://doi.org/10.1080/0361526X.2018.1428475.
10. Ping Fu and Julie Carmen, “Migration to Alma/Primo: A Case Study of Central Washington University,” Chinese Librarianship: An International Electronic Journal 40 (2015), https://www.white-clouds.com/iclc/cliej/cl40.htm.
11. Conor Cote and Kirsten Ostergaard, “Master of ‘Complex and Ambiguous Phenomena’: The ERL’s Role in a Library Service Platform Migration,” Serials Librarian 72, no. 1–4 (2017): 223–29, https://doi.org/10.1080/0361526X.2017.1285128.
12. Michael W. Dula and Gan Ye, “Case Study: Pepperdine University Libraries’ Migration to OCLC’s WorldShare,” Journal of Web Librarianship 6, no. 2 (2012): 125–32, https://doi.org/10.1080/19322909.2012.677296.
13. Mary Beth Weber, “Editorial: The Bedrock of Library Services,” Library Resources & Technical Services 62, no. 2 (2018): 52–54.
14. Joseph Nicholson and Shoko Tokoro, “Cloud Hopping: One Library’s Experience Migrating from One LSP to Another,” Technical Services Quarterly 38, no. 4 (2021): 377–94, https://doi.org/10.1080/07317131.2021.1973796.
15. Denise Branch, “Alma in the Cloud: Implementation Through the Eyes of Acquisitions,” in Proceedings of the Charleston Library Conference, 2014, https://docs.lib.purdue.edu/charleston/2013/Tech/3.
16. Melissa Parent and Lesa Maclean, “Go with the Flow: Discovering New Workflows in Alma,” in Proceedings of the VALA Conference (VALA—Libraries, Technology and the Future, Melbourne, Australia, 2014), 3–6, https://www.vala.org.au/download-category/vala2014-downloads/#.
17. Parent and Maclean, “Go with the Flow,” 5.
18. Stacey Marien, Alayne Mundt, and Rob Tench, “Let’s Get Technical-Migrating to Alma Acquisitions: One Library’s Experience,” Against the Grain 29, no. 4 (2017): 69, https://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=7918&context=atg.
19. Marien, Mundt, and Tench, “Let’s Get Technical,” 67.
20. Kathleen Spring, Megan Drake, and Siôn Romaine, “How Is That Going to Work? Rethinking Acquisitions in a Next-Generation ILS,” in Proceedings of the Charleston Library Conference, 2014, https://docs.lib.purdue.edu/charleston/2013/Management/12.
21. Morag Stewart and Cheryl Aine Morrison, “Breaking Ground: Consortial Migration to a Next-Generation ILS and Its Impact on Acquisitions Workflows. Notes on Operations,” Library Resources & Technical Services 60, no. 4 (2016): 259–69, https://doi.org/10.5860/lrts.60n4.259.
22. Jennifer Matthews and Christine Davidian, “Migrating to Alma Without an Acquisitions Staff: Evolving Acquisitions and Electronic Workflows from Their Legacy Silos,” in Proceedings of the Charleston Library Conference (2019), https://doi.org/10.5703/1288284317187.
23. Kate Seago, “Flattening Funds: Using Alma Fund Structure & Reporting Codes,” https://uknowledge.uky.edu/libraries_present/169.
24. “Configuring Reporting Codes,” Ex Libris Knowledge Center, 2015, https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/020Acquisitions/110Configuring_Acquisitions/020Configuring_Reporting_Codes.