Image from: Catalog Management in the Cloud: Two Years In Catalog Management IG Meeting, ALA Annual June 25, 2016 Stacie Traill and Betsy Friesen University of Minnesota

Topics Systems environment in 2011 Environment prior and at go live in 2013 Differences between Aleph and Alma Highlights and challenges with Alma

Minnesota Environment in 2011 Aleph servers near end-of-life Encouragement to move to the cloud Solicitation to be early adopter Environment scan: Alma vs ??? Aleph functionality as Alma baseline

Minnesota Environment in 2013 Topology just for Minnesota Migration processes were works-in-progress Functionality in development -- lots of it Issues with user interface

Aleph vs. Alma Local-hosted servers and maintenance Support required from central IT Server access allowing views of logs and running of complex queries Local Aleph client and maintenance Local devoted system support team = 5 FTE Service packs and upgrades requiring major testing effort Mature system Software as a service (Cloud = no local servers) No support -- AT ALL -- required from central IT No server access allowing views of logs and running of complex queries No support required by library computer support Local devoted system support team = 1 FTE Monthly releases where testing has diminished over time Infant system

Alma Alma functionality is still a moving target... But it is less so, 2 1/2 years in.

Searching and set creation Fairly robust set of indexes available, with ability to search MARC elements not indexed via a special process. Complex queries are easy to save and use as the basis for batch processes Sets of records can be created by uploading lists of identifiers. Browse indexes not originally included; browse recently developed, but not really usable yet. Little local control over indexing (except 9XX fields). Image by Chris, CC-BY-SA 3.0https://commons.wikimedia.org/wiki/File:SMirC-smile.svg

Batch changing bibliographic records Good flexibility in normalization rules/processes. Rule design and single-record testing available to all catalogers. Straightforward logic and syntax means learning curve is not too steep. Many things still easier in MarcEdit. Processing speed can be an issue for large batches. Image by Chris, CC-BY-SA 3.0https://commons.wikimedia.org/wiki/File:SMirC-smile.svg

Batch loading/importing bibliographic records Import profiles easy to set up Custom bib record editing easy to incorporate and fairly flexible Merge routines easy to customize Job reports useful and detailed, allowing download of failed and skipped records Import profiles can be shared with the Alma community Item mapping not as complete as it should be (especially for material types) Image by Chris, CC-BY-SA 3.0https://commons.wikimedia.org/wiki/File:SMirC-smile.svg

Demand/Patron-Driven Acquisition (DDA/PDA) Good built-in tools for importing DDA records and acquisitions data. Ability to pause, terminate, clean up, or cancel DDA profiles with a single command. Image by Chris, CC-BY-SA 3.0https://commons.wikimedia.org/wiki/File:SMirC-smile.svg

Publishing and Exporting Metadata For Primo: Alma shows last published version of the record, making troubleshooting discovery layer problems much easier. General publishing is flexible and powerful. Basic bib record batch export is simple and usually very fast. Image by Chris, CC-BY-SA 3.0https://commons.wikimedia.org/wiki/File:SMirC-smile.svg

E-resource management Link resolver/knowledge base combined with traditional ILS confusing at first, but ultimately much more efficient. Explicit hierarchical structure helpful for managing bib data as well as KB/linking. No separate steps beyond activation to get basic discovery metadata for titles in KB collections. Lack of flexibility in linking acquisitions records has been a challenge. Currently no ability to batch update Community Zone bib records. Image by Chris, CC-BY-SA 3.0https://commons.wikimedia.org/wiki/File:SMirC-smile.svg

APIs Alma offers an extensive and growing set of APIs that can address most of its data and processes. With some programming skill, many things are possible. Limits on number of daily API calls. Programming skill required to take full advantage. Image by Chris, CC-BY-SA 3.0https://commons.wikimedia.org/wiki/File:SMirC-dunno.svg

Authority Control No need to maintain authority files ourselves, but authority file maintenance not always accurate. Basic heading matching and flipping jobs run daily but need careful monitoring. Initial implementation was poor. Inability to browse headings means we do that elsewhere. Name heading flips too “greedy” (flipping occurs based on $a match only). An area of ongoing concern and communication. “Works well 98% of the time.” Image by Chris, CC-BY-SA 3.0https://commons.wikimedia.org/wiki/File:SMirC-dunno.svg

Analytics (reporting) Much MARC data not available in Alma Analytics, making many reporting tasks much harder than they should be. A completely different, often counterintuitive, system to learn. All staff can have access to Alma Analytics, making it much easier for individuals to create their own simple, small, ad-hoc reports. Image by Chris, CC-BY-SA 3.0https://commons.wikimedia.org/wiki/File:SMirC-sad.svg

Cataloging UI (Alma Metadata Editor) Very frustrating for staff since Day 1, and not greatly improved since. Lots of mousing and clicking, and some inconsistent behavior. Client-based macro approach doesn’t work well. Not as full-featured as Aleph cataloging module or OCLC Connexion Client. Version history for bib and holdings records readily available. MARC standard documentation loads contextually per field. Image by Chris, CC-BY-SA 3.0https://commons.wikimedia.org/wiki/File:SMirC-sad.svg

Image from: photobucket.com