Zusammenfassung
Dieser Bericht über die Implementierung der cloudbasierten Bibliotheksmanagement- und Discovery-Lösung Alma & Primo VE von Ex Libris an der Bayerischen Staatsbibliothek beleuchtet die für dieses Großprojekt spezifischen bis einzigartigen Aspekte. Sie ergeben sich aus der Größe und zum Teil besonderen Art des Bestands, der arbeitsteiligen Organisation von Geschäftsgängen, den überregionalen Aufgaben der Bibliothek und ihrer gemeinsamen Nutzerschaft mit der Universitätsbibliothek der Ludwig-Maximilians-Universität München.
Abstract
This report on the implementation of the cloud-based library management and discovery solution Alma & Primo VE from Ex Libris at the Bayerische Staatsbibliothek highlights the specific and rather unique aspects of this major project. They result from the size and, in part, the special nature of the library’s collections, the organization of business processes based on the division of labor, the supra-regional tasks of the library and its joint patronship with the University Library of the Ludwig-Maximilians-Universität Munich.
1 Noch ein Bericht über eine Alma-Implementierung?
Am 30. April 2021 veröffentlichte die Bayerische Staatsbibliothek (BSB) auf dem deutschen E-Vergabe-Portal ihre Ausschreibung für die „Bereitstellung und Implementierung eines Next Generation Library Systems (NGLS) als Software-as-a-Service“. Nach Ablauf der sechswöchigen Angebotsfrist und der sich anschließenden Bewertungsphase wurde am 05. August 2021 der Zuschlag an Alma als Bibliotheksmanagementsystem und Primo VE als Discovery-System (zur Ablöse des OPACplus) von Ex Libris erteilt. Was für die aufwändige Erstellung der Ausschreibungsunterlagen, darunter auch ein Katalog von über 400 Leistungskriterien, der Zieldurchlauf war, läutete zugleich die Startvorbereitungen für das sich über insgesamt 19 Monate erstreckende Alma/Primo-VE-Implementierungsprojekt der BSB ein.
Über Alma-Implementierungsprojekte im deutschsprachigen Raum sind bereits etliche Berichte veröffentlicht worden. Die Autorinnen und Autoren des vorliegenden möchten deshalb den Fokus auf Aspekte richten, die das Alma/Primo-VE-Implementierungsprojekt der BSB in besonderer Weise charakterisieren. Daraus den Schluss zu ziehen, dass alles in diesem Bericht unerwähnt gebliebene ein Selbstläufer war oder gar unwichtig ist, wäre freilich vollkommen unzulässig.
2 Abweichung vom Standard-Migrationsplan
Ex Libris führt Migrationen auf das Zielsystem Alma üblicherweise nach einem fest vorgegebenen Ablaufschema durch. Es sieht für die aus dem Vorgängersystem zu migrierenden Daten einen sogenannten Test Load vor. Alle unbefriedigenden Resultate dieses Test Loads werden auf ihre Ursache hin analysiert, und geeignete Anpassungen von Datenextraktions- und/oder Datenmigrationsroutinen sollen dafür sorgen, dass diese Ursachen spätestens bis zum sogenannten Cutover Load unmittelbar vor dem Go-live mit Alma behoben sind.
Bereits in der oben erwähnten Ausschreibung waren jedoch drei komplette Testläufe des Migrationsprozesses als verpflichtendes Leistungskriterium gefordert, weil allen Beteiligten klar war, dass schon allein aufgrund der schieren Menge an zu migrierenden Daten (insgesamt knapp 15 Mio. Titeldatensätze) eine einzige Iteration niemals ausreichen würde, um sämtliche Fehlerquellen dingfest machen zu können. Die Tatsache, dass der erste Test Load relativ früh im Projekt angesetzt war, bedingte außerdem, dass für die zuvor noch von keinem anderen Alma-Kunden umgesetzten Teilvorhaben (z. B. die Migration der Vorhersagemuster für Zeitschriftenhefte) bis dahin auch kein fertiges Konzept stehen konnte.
Diese Einschätzungen mögen auf den ersten Blick übervorsichtig bis pessimistisch erscheinen, doch die praktische Umsetzung hat ihre Angemessenheit mehr als nur bestätigt. Da auch im dritten Test Load noch neuartige Fehlerphänomene auftauchten, willigte Ex Libris am Ende sogar ein, einzelne Teilportionen der Gesamtdatenmenge noch ein viertes Mal testweise zu migrieren, um ganz sicherzugehen, dass im Cutover Load – zumindest nach menschlichem Ermessen – alles glattgehen würde.
Im Rückblick hat sich der standardisierte Migrationsprozess von Ex Libris als zu starr erwiesen, um wirklich agil damit arbeiten zu können. Das ungute Gefühl, eventuell doch noch irgendein signifikant häufig auftretendes Fehlerphänomen in der Unmenge an zu sichtenden Daten übersehen zu haben, hätte sich umgekehrt aber vermutlich auch nach drei weiteren vollständigen Test Loads nicht ganz beseitigen lassen.
3 Abbildung der Organisationsstruktur auf die Systemtopologie
Die Aufgabe eines integrierten Bibliothekssystems ist die Unterstützung der unterschiedlichen Arbeitsabläufe und Aufgaben der Bibliothek. Dazu müssen die Organisationsstrukturen und Geschäftsgänge der Bibliothek auf Strukturen und Funktionen im Bibliothekssystem abgebildet werden. Das ist aber keine simple 1:1-Beziehung, sondern kann mit unterschiedlichen Daten- und Funktionsmodellen geschehen. Zum Beispiel kann die Ausleihe eines bestellten Buches an Nutzende einer bestimmten Nutzergruppe ganz unterschiedlich organisiert und auch in unterschiedlicher Weise in einem Softwaresystem modelliert werden. Wenn beim Wechsel des Bibliothekssystems die Frage gelöst werden muss, wie die Aufgaben der Bibliothek zusammen mit ihren Daten im neuen System abgebildet werden, dann stehen somit auch die Arbeitsabläufe der Bibliothek auf dem Prüfstand. Die ganz grundsätzliche Organisation des Bibliothekssystems in Alma wird dort unter dem Begriff „Topologie“ behandelt. Hierbei geht es um die grundlegenden Organisationseinheiten in Alma und ihre Beziehungen untereinander. Diese sind nicht nur entscheidend für die Umsetzung der Arbeitsabläufe, sondern auch für die Berechtigungen im System, z. B. die Frage, was von wem und wo entliehen werden kann. Herausfordernd ist dabei, dass dieselben Anforderungen über unterschiedliche Konfigurationen in unterschiedlichen Topologien abgebildet werden können, dass aber diese Varianten nicht gleich effektiv bzw. effizient sein müssen und auch die Limitierungen einer bestimmten Variante nicht unbedingt auf den ersten Blick offensichtlich sind. Nur die sehr gute Kenntnis von beidem, der betrieblichen Organisation einer Bibliothek, ihrer Notwendigkeiten und Abläufe auf der einen Seite, sowie der topologischen Möglichkeiten und Grenzen in Alma und Primo VE auf der anderen Seite, ermöglichen die Wahl einer guten Topologie. Damit wird die besondere Schwierigkeit der Aufgabe, die richtige Topologie zu definieren, deutlich, weil die Bibliotheksseite im Detail über das eine Wissen verfügt, das Projektteam von Ex Libris über das andere. Nur ein sehr intensiver Austausch und gegenseitiger Erwerb der entsprechenden Kenntnisse kann hier zum Erfolg führen.
Nach einem ersten Blick auf die Grundelemente der Alma-Topologie scheint Alma zunächst vor allem an Universitätsbibliotheken mit auf dem gesamten Campus physisch verteilten Teilbibliotheken orientiert zu sein. Die primäre und oberste Einheit, die es in jeder Alma-Instanz geben muss, aber auch nur einmal geben kann, ist die „Institution“. Auf dieser Ebene werden zahlreiche grundlegende Parameter festgelegt, die für alle Organisationseinheiten einer Bibliothek gelten, wie z. B. Öffnungszeiten, Berechtigungen der Mitarbeiter-Accounts, Sperren, Benachrichtigungen. Oftmals können diese aber wieder durch die Konfiguration auf unterer Ebene modifiziert oder überschrieben werden.
Unterhalb dieser Institution unterscheidet Alma die Ebenen der „Library“ und des „Campus“, unter dem mehrere Libraries zusammengefasst werden können. Zu jeder Institution gehört mindestens eine Library sowie eine Resource Sharing Library für die Fernleihe. Es kann aber auch mehrere Libraries geben, was bei Universitätsbibliotheken mit Teilbibliotheken als offensichtlich erscheint.
Die detaillierten Berechtigungen, beispielsweise für die Möglichkeiten der Ausleihe bestimmter Bestände, werden auf der Ebene der Library in den Ausleihbedingungen festgelegt, die unter anderem Standorte des Bestandes, Nutzergruppen und Ausgabeorte (Ausleihtheken) berücksichtigen. Zunächst erschien die naheliegende Topologie für die BSB aus nur einer Library für den ausleihbaren Bestand zu bestehen. Durch die Zuordnung von Bestandsgruppen (Medientypen), Standorten, Nutzergruppen, Lesesälen, Ausleihtheken und mehr schienen sich alle Arbeitsabläufe für Nutzende wie für die Bibliotheksseite abbilden zu lassen. Nach dem ersten Test Load der Bibliotheksdaten zeigte sich allerdings, dass dies für die hochdifferenzierten Bestände und die ebenso differenzierte Nutzerschaft doch nicht ausreichend war. Als eine der führenden Forschungsbibliotheken verfügt die BSB über zahlreiche Spezialbestände, vor allem auch sehr wertvollen Altbestand, die in einem differenzierten Rechtekonzept den jeweiligen Nutzergruppen in den unterschiedlichen Forschungslesesälen der Bibliothek zur Verfügung gestellt werden. Dabei geht es sowohl um einen angemessenen Bestandsschutz als auch um adäquate und differenzierte Services für Wissenschaft und Forschung. Speziell die verschiedenen Einschränkungen, welche Bestände in welche Lesesäle bestellt und entliehen werden können, ließen sich in der zunächst eher einfach gewählten Topologie nicht abbilden. Reine Ausleihbeschränkungen ohne Auswirkungen auf die Bestellbarkeit zur Vor-Ort-Nutzung in Lesesäle wären zwar möglich gewesen, sind hier aber nicht hilfreich. Sowohl für Nutzende als auch Personal entsteht ein enormer Aufwand, wenn Bestellungen zunächst an den falschen Ort gehen und dort dann nicht entliehen werden können. Erst als für jeden Lesesaal eine eigene Library konfiguriert wurde, konnte das benötigte Rechtekonzept umgesetzt werden.
Aber selbst damit war es noch nicht getan. Der vielfältige Bestand korrespondiert auch mit einer differenzierten Organisationsstruktur in der Erwerbung. Hier erwies es sich ebenfalls als die zielführende Lösung, mit eigenen Erwerbungs-Libraries zu arbeiten. Um die im Erwerbungskontext bewährte Teamstruktur der BSB – die Bibliothek verfügt über zwei erwerbende Hauptabteilungen mit insgesamt acht Erwerbungs-Teams sowie fünf Sonderabteilungen mit sechs erwerbenden Organisationseinheiten – auch in Alma abbilden zu können, wurden letztlich 14 Erwerbungs-Libraries eingerichtet, die je nach „Library Relations“ nur für sich selbst oder auch für andere Libraries der Institution zuständig sind. Bei der Einrichtung der Rollen und Berechtigungen musste darauf geachtet werden, dass Mitarbeiterinnen und Mitarbeiter, die mehreren Erwerbungsteams angehören, durch Auswahl ihres „physischen“ Standortes nach Bedarf ins jeweils andere Team wechseln können. Da jede dieser Erwerbungs-Libraries über eine eigene Bestelladresse verfügt, kann die gesamte Kommunikation mit den Bibliothekslieferanten (Bestellung, Bestellzetteldruck, Bestellverwaltung, Mahnlistenbearbeitung, Eingangs- sowie Rechnungsbearbeitung) weiterhin in den bewährten Organisationseinheiten erfolgen.
Leider ist eine grundlegende Umstellung der Topologie in Alma mit einem sehr großen Aufwand verbunden, da alle Konfigurationseinträge nur im Hinblick auf diese basale Struktur konzipiert und umgesetzt werden können. Schon allein in dieser Hinsicht wäre ein Vorgehen mit weniger als den drei Test Loads an der BSB nicht möglich gewesen.
4 Abbildung von Katalogstrukturen
Das Alma-Lokalsystem der BSB ist weiterhin mit dem Alephbasierten Verbundkatalog B3Kat verknüpft, in dem die Primärkatalogisierung von Monographien erfolgt. Für die Datenversorgung wird die Aleph-Alma-Versorgungsschnittstelle genutzt. Die Aktualisierung erfolgt maximal stündlich, aber einzelne Datensätze können von den Bearbeitenden jederzeit auch direkt nach Alma übernommen werden.
Lokaldaten werden in der Institution Zone von Alma verwaltet. Auch die bibliographischen Titeldatensätze (im Folgenden kurz: Titelsätze) können hier um lokal definierte bibliotheks- und exemplarspezifische Felder ergänzt werden. Mit den Titelsätzen sind die Bestandsdatensätze verknüpft, an denen wiederum die Exemplardatensätze hängen. Es ist jeweils nur eine 1:n-Beziehung möglich.
Für die Verwaltung von Bindeeinheiten bedeutet das, dass Bestands- und Exemplardaten stets an genau einen Titelsatz, den sogenannten „Ankersatz“, gehängt werden können. In den Titelsätzen der weiteren in einer Bindeeinheit enthaltenen Ressourcen stellt dann ein lokales Feld eine lediglich indirekte Verbindung zum Ankersatz und den daran hängenden Bestands- und Exemplardaten her: In diesem lokalen Feld ist neben der ID des Ankersatzes auch die Mediennummer des jeweiligen Exemplars anzugeben, damit bei Mehrfachexemplaren in unterschiedlichen Bindeeinheiten mit den richtigen Exemplaren verknüpft wird.
Aufgrund ihres historischen Bestandes mit sehr vielen Konvoluten und Mehrfachexemplaren gibt es an der BSB ca. je 1 Mio. Teile von Bindeeinheiten bei Monographien und Zeitschriften, also deutlich mehr als bei anderen großen Alma-Bibliotheken. Bei den Test Loads kam es zu erheblichen Problemen mit der Bildung der Bindeeinheiten; diese konnten im intensiven Austausch mit Ex Libris behoben werden, so dass beim Cutover Load schließlich alle Bindeeinheiten richtig gebildet wurden. Bei der Neubildung oder Korrektur von Bindeeinheiten müssen bei Monographien weiterhin manuell die ID des Ankersatzes, die Signatur des Bestandsdatensatzes und die Mediennummer des Exemplars angegeben werden; das erfordert große Sorgfalt und ist fehlerträchtig. Bei Zeitschriftenbänden reicht die ID des Ankersatzes aus, da es dort in der Regel keine Mehrfachexemplare gibt
5 Erwerbung
5.1 Lieferantendatenverwaltung
Bei der Migration der Lieferantendaten stand die BSB ebenfalls vor besonderen Herausforderungen. Im abzulösenden SISIS-System waren 28 unterschiedliche Kauf-Lieferantennummernkreise angelegt, denen insgesamt über 1 700 Lieferanten-Accounts zugeordnet sind; hinzu kamen 17 Lieferantennummernkreise aus dem unberechneten Zugang mit insgesamt über 10 000 Datensätzen. Insbesondere viele der großen Lieferanten, mit denen die BSB regelmäßige Kaufbeziehungen pflegt, verfügen jeweils über mehrere Accounts – und zwar differenziert nach zu erwerbender Medienart, Zugehörigkeit zu einem Erwerbungsteam bzw. nach Finanzmitteleinsatz.
Diese Struktur galt es auf die neue Topologie mit 14 Erwerbungs-Libraries abzubilden, wobei zu berücksichtigen war, dass in Alma die Bestellungen mit den Lieferantendaten verknüpft sind. Erschwert wurde die Umsetzung dadurch, dass die Lieferantendaten in Alma Teil der Konfiguration sind und somit bereits beim ersten Test Load migriert werden mussten, weil im späteren Migrationsprozess keine Änderungen mehr an den migrierten Lieferantendaten möglich waren. Im intensiven Austausch mit Ex Libris konnte schließlich eine BSB-spezifische Lösung gefunden werden, bei welcher für Lieferanten mit mehreren Account-IDs ein gesondertes Lieferformat spezifiziert wurde, über das die im ersten Test Load übermittelten Lieferantendaten im zweiten Test Load um weitere Accounts angereichert werden konnten.
5.2 Haushaltsstruktur und Rechnungsbearbeitung
Die Etatplanung, das Anlegen der Haushaltsstruktur sowie das Etatcontrolling erfolgt für alle 14 Erwerbungs-Libraries weiterhin zentral durch die Hauptabteilung Bestandsentwicklung und Erschließung 1. Dabei wurde die Haushaltsstruktur des bisherigen SISIS-Erwerbungsclients vollständig nachgebildet: alle 432 Konten und Etats wurden problemlos migriert, ihre Benennung sowie mehrstufige Hierarchie mussten vor dem Go-live jedoch manuell angepasst werden. Auch die Erwerbungsdaten des aktuellen sowie aller vorhergehenden Haushaltsjahre konnten erfolgreich übertragen werden. Allerdings kam es aufgrund von Migrationsfehlern zu einem sprunghaften Anstieg der Bestellbelastungen, der die Etatplanung aktuell noch vor Probleme stellt. Geringfügige Abweichungen gab es auch bei den Rechnungsbelastungen, da Posten mit null Euro – wie sie unter anderem bei Geschenken oder einzelnen Bänden mehrteiliger Monographien üblich sind – vor der Migration laut Ex Libris zwingend mindestens auf einen Betrag von zehn Cent erhöht werden mussten. Um in Bezug auf die Rechnungsdaten des laufenden Erwerbungsjahres einen Gleichstand der Systeme (SISIS/Alma) herzustellen, mussten diese Differenzen nach dem Go-live ausgeglichen werden.
Eine vor allem organisatorische Herausforderung stellte die Rechnungs- und Medienbearbeitung während der sogenannten Cutover-Phase dar, in der weder das alte noch das neue Bibliothekssystem genutzt werden konnte. Um den Bucheingang in dieser rund zweimonatigen Periode zu steuern, wurden mit ausgewählten Lieferanten Lieferstopps vereinbart. Rechnungen, die während dieser Zeit einliefen, wurden nach dem Go-live prioritär behandelt und rasch nachinventarisiert, wodurch das Etatcontrolling wieder auf eine sichere Grundlage gestellt werden konnte. Beim gedruckten Periodikaeingang war ein solcher Bestellstopp naturgemäß nicht möglich, weshalb einlaufende Hefte offline zwischenverbucht und nach dem Go-Live nochmals in Alma eingetragen werden mussten.
Als Mittelbehörde des Freistaats Bayern setzt die BSB das für die gesamte bayerische Staatsverwaltung vorgegebene Integrierte Haushalts- und Kassenverfahren (IHV) als Software für die Rechnungsbearbeitung, Buchführung sowie die Erteilung von Zahlungsanordnungen ein. Mit dem SISIS-Bibliothekssystem (SISIS SunRise, Multifunktionsclient) gestaltete sich der Workflow der Rechnungsbearbeitung folgendermaßen: Die Mitarbeitenden der erwerbenden Fachabteilungen bearbeiteten die eingehenden Rechnungen zunächst händisch, indem ein „Haushaltsstempel“ auf jeder Rechnung angebracht und dieser handschriftlich mit Zahlbetrag, Buchungsstelle und zwei Unterschriften befüllt wurde. Danach erfassten die gleichen Mitarbeitenden die Rechnungs- und Zahldaten im Multifunktionsclient, von dem aus diese Daten anschließend über eine Schnittstelle, die mit Unterstützung der Verbundzentrale des Bibliotheksverbunds Bayern (BVB) programmiert worden war, ins IHV übertragen wurden. Abschließend wurden die Buchungssätze durch Mitarbeitende der Hauptabteilung Bestandsentwicklung und Erschließung 1 haushaltsrechtlich zur Auszahlung angeordnet.
Federführend in diesem Prozess waren demnach die bibliothekarischen Fachabteilungen, weshalb der gesamte Workflow der Rechnungsbearbeitung in erster Linie an bibliothekarischen Anforderungen ausgerichtet war. In diesem Kontext stellte insbesondere die Einhaltung der Bearbeitungszeiten gemäß den haushaltsrechtlichen Vorgaben sowie der „Grundsätze ordnungsgemäßer Buchführung und Dokumentation“ (GoDB) eine Herausforderung dar. Die Rechnungsbearbeitung des restlichen Hauses, also außerhalb des Medienerwerbs, erfolgte dahingegen schon länger vollständig elektronisch direkt im IHV.
Vor diesem Hintergrund nahm die BSB die Einführung von Alma zum Anlass, die Rechnungsbearbeitung der erwerbenden Abteilungen denen des restlichen Hauses anzugleichen, vollständig zu digitalisieren und die Prozesse insgesamt den aktuellen rechtlichen Erfordernissen anzupassen.
Eingehende Rechnungen werden nunmehr, so sie nicht bereits als XRechnung oder im PDF-Format eingehen, umgehend verscannt, ins IHV importiert und dort den jeweiligen Organisationseinheiten zur haushaltsrechtlichen Feststellung der sachlichen und rechnerischen Richtigkeit zugeleitet. Zu diesem Zeitpunkt erfolgt anhand des zugeleiteten Rechnungsbelegs die bibliothekarische Inventarisierung in Alma, was zugleich die Grundlage für die Feststellung der sachlichen und rechnerischen Richtigkeit darstellt. Rechnungsbearbeitung und bibliothekarische Bearbeitung der Erwerbungen wurden auf diese Weise weitgehend getrennt. Im Ergebnis ist das IHV nun das führende System im Rechnungsbearbeitungsprozess, womit insbesondere den zeitlichen Bearbeitungsvorgaben der GoDB entsprochen wie auch eine Tax Compliance zentral gewährleistet wird.
Mehraufwände sind bei globaler Betrachtung des Prozesses nicht entstanden: Zwar hat die Finanzbuchhaltung nun je Rechnung einige wenige Angaben manuell zu erfassen und die Rechnungen zur Auszahlung anzuordnen; letzteres entfällt damit aber als Arbeitsschritt in der Fachabteilung. Medienbrüche entfallen ebenso: Wurde durch die Fachabteilung bisher der bereits erwähnte „Haushaltsstempel“ auf jeder Rechnung angebracht und händisch befüllt, werden die Daten nun im Rahmen der haushaltsrechtlichen Feststellung im IHV hinterlegt und von der Finanzbuchhaltung automatisch übernommen.
6 Periodikaverwaltung und -erschließung
Ein umfangreicher Komplex bei der Migration der Daten und der Implementierung des neuen Systems war die Verwaltung und Erschließung von Periodika. Dabei ist als Ausgangssituation zu beachten, dass die BSB als Forschungs- und Archivbibliothek in großer Tiefe ein geistes- und kulturwissenschaftliches Kernprofil pflegt. Vor dem Hintergrund der Struktur dieses Fächerspektrums verfügt die BSB wohl im Unterschied zum Großteil der nationalen und internationalen Alma-Anwender nach wie vor und auf absehbare Zeit über einen sehr umfangreichen Bestand an Printperiodika, die im folgenden Abschnitt im Mittelpunkt stehen. Herausgegriffen werden dabei exemplarisch zwei Themenkomplexe, die mit besonderen konzeptionellen Anforderungen verbunden waren.
6.1 Eingangsverbuchung der Zeitschriftenhefte und Bandnachweise
Eine wesentliche Komponente der Verwaltung eines umfangreichen gedruckten Periodikabestands ist die effiziente Organisation der Eingangsverbuchung von Zeitschriftenheften, von denen jährlich ca. 150 000 Exemplare eingehen. Während im SISIS-System der Hefteingang in einem dem Erwerbungsmodul zuzurechnenden elektronischen Kardex erfolgte, gelten die Hefteinträge (Items) in der Alma-Architektur strukturell als Katalogeinträge. Dies hat unter anderem zur Folge, dass sich aus aggregierten Hefteinträgen im Zuge des Bindegeschäftsgangs direkt Katalogeinträge für die gebundenen Einheiten generieren lassen. Alternativ können die gebundenen Periodikabände bzw. Einzelausgaben von Jahrbüchern im Unterschied zu den früheren Exemplarsätzen als eigenständige Titelaufnahmen katalogisiert und ausleihbar gemacht werden. Nach sorgfältigem Abwägen der Vor- und Nachteile der jeweiligen Lösung wurde letztlich die Entscheidung getroffen, jeweils eigenständige Katalogaufnahmen zu erstellen, unter anderem weil dieser Weg die Datenmigration auch mit Blick auf eine einheitliche Struktur bei Monographien und Zeitschriften vereinfacht hat und sich auf diese Weise mehr Zusatzinformationen zum Band wie Hinweise auf Lücken, Beilagen usw. vermerken lassen. Die aggregierten Hefte aus der Hefteverwaltung werden dabei auf die neue Titelaufnahme für den Band umgehängt. Alle Einzelbände sind mit der Titelaufnahme der Zeitschrift, der Zeitung oder des Jahrbuchs verknüpft, an der bei laufenden Titeln auch die Bestellung hängt. Bandtitelsätze können als Vorlage für die Erstellung weitere Bände derselben Zeitschrift herangezogen werden.
6.2 Vorhersagemuster
Um den Hefteintrag von Zeitschriften effizient zu gestalten und zu beschleunigen, bieten Bibliothekssysteme in der Regel die Möglichkeit an, mit Hilfe von sogenannten Vorhersagemustern Hefteinträge anhand von Informationen zur Erscheinungsweise der jeweiligen Zeitschrift vorzugenerieren. Die Vorhersagemuster bedienen sich einer speziellen Syntax, die in Alma ganz anderen (nämlich den MARC-21-)Konventionen folgt, als dies im SISIS-System der Fall war. Dies hat zunächst die Frage aufgeworfen, wie mit den Vorhersagemustern im Rahmen der Datenmigration umgegangen werden sollte, zumal es hierfür bei anderen Alma-Anwendern im deutschsprachigen Raum keine Vorbilder gab. Geprüft wurde zunächst, ob sich Regeln ableiten lassen, anhand derer sich zumindest häufig genutzte SISIS-Muster auf die Alma-Syntax vollautomatisiert konvertieren lassen. Dieser Weg wurde angesichts der maschinellen Unentscheidbarkeit der Aufgabe[1] verworfen und stattdessen anhand einer Ausspeicherung der vorliegenden Vorhersagemuster aus SISIS mittels Tabellenkalkulationsfunktionen zumindest teilautomatisiert das jeweilige MARC-21-Muster erstellt. Migriert wurden im nächsten Schritt sowohl die schon in der MARC-21-Syntax vorbereiteten Vorhersagemuster als Zeichenketten als auch bereits in SISIS vorgenerierte Hefteinträge, um in einer längeren Übergangsphase nach dem Go-Live auf diese Einträge zurückgreifen zu können. Die vorab angelegten und nach Alma migrierten Vorhersagemuster müssen dort auf Titelebene noch intellektuell aktiviert werden, um künftig in Alma neue Hefteinträge generieren zu können.
7 Online-Ressourcen-Management, -Erschließung und -Präsentation
Bibliothekssysteme der neuen Generation heben sich von älteren Systemen nicht zuletzt dadurch ab, dass dem Management von Online-Ressourcen große Bedeutung beigemessen wird. Dies eröffnet zahlreiche neue Möglichkeiten, erhöht aber auch die Komplexität in der Bearbeitung unter anderem im Zusammenspiel mit anderen Katalogsystemen.
Das Datenmodell von Alma sieht für elektronischen Bestand drei Ebenen vor. Dazu zählen die „Electronic Collection“, also insbesondere einzelne Datenbanken bzw. Pakete von E-Journals und E-Books, der „Service“, der alle einzeltitelübergreifenden Angaben über den Zugang zum Volltext umfasst, und das „Portfolio“, das als kleinste Einheit die titelspezifischen Zugangsinformationen enthält. Im einfachsten, aber zugleich für die Granularität des Link-Resolvings ungünstigsten Fall ist dies der URL einer E-Journal- bzw. E-Book-Homepage. Für Link-Resolving bis auf Aufsatz- bzw. Kapitelebene muss auf Serviceebene die anbieterspezifische Bauanleitung für Volltext-URLs dieser Linktiefe hinterlegt sein, und das Portfolio enthält statt eines kompletten URLs nur noch titelspezifische Bauteile.
Um bei der Datenmigration die Ausgangsdaten im Rahmen des sogenannten P2E-Verfahrens (Physical to Electronic) in diese Alma-Struktur zu überführen, musste aus SISIS eine Datei der relevanten Datensätze mit einer entsprechenden Kennzeichnung erstellt werden. Da Titeldaten häufig mehrere Links enthalten, die aber nicht unbedingt alle für den lokalen Zugriff einschlägig sind, wurde außerdem eine Link-Logik entwickelt, damit elektronischer Bestand möglichst nur für diejenigen Links erzeugt wird, die auch für die eigenen Nutzerinnen und Nutzer zum Volltext führen.
Eine neue Dimension der Arbeit mit Online-Ressourcen eröffnet sich mit der Verfügbarkeit einer umfangreichen Knowledge Base, die den Alma-Anwendern in Form der sogenannten „Community Zone“ zur Verfügung steht. Enthalten sind umfangreiche und zentral aktualisierte Metadatenkollektionen, die von Verlagen, Aggregatoren, aber auch der EZB geliefert und in die eigene Institution Zone übernommen werden können. Für die künftige Arbeit der BSB in Alma hat sich dabei die Grundfrage gestellt, in welchem Verhältnis Titeldaten, die in EZB/ZDB und B3Kat erstellt werden, zu den Kollektionen aus der Community Zone stehen. Mit Blick auf die Qualität der Titelaufnahmen werden weiterhin die Daten aus ZDB und B3Kat genutzt, sofern es sich nicht um sehr umfangreiche E-Book-Pakete, darunter auch Open-Access-Pakete handelt, die nicht in B3Kat erschlossen werden. Über diese Pakete hinaus liegt der Wert der Community-Zone-Collections für die BSB insbesondere in den auf Serviceebene hinterlegten Bauanleitungen für die direkte Verlinkung auf Zeitschriftenaufsätze und Buchkapitel, wie sie im „Central Discovery Index“ von Clarivate erschlossen sind.
Vor diesem Hintergrund wurde unmittelbar nach der Migration damit begonnen, aus den migrierten Titeldaten lokale elektronische Collections zu schnüren und diese mit möglichst guten „Matches“ in der Community Zone zu verknüpfen. Hierbei ergeben sich neben notwendigen Datenbereinigungen im Nachgang des P2E-Verfahrens einige Herausforderungen. Neben der riesigen Datenmenge liegen diese vor allem in den unterschiedlichen Datenständen zwischen den lokalen Titeldaten und den Community-Zone-Collections. Diese Diskrepanzen führen zu einem regelmäßigen Austausch mit Ex Libris, was wiederum zur Verbesserung der Datenqualität in der Community Zone beiträgt. In jedem Fall handelt es sich um eine Aufgabe, die nach dem Go-Live noch viele Monate in Anspruch nimmt.
Bemerkenswert ist dabei, dass die geschilderte Situation gerade kein Charakteristikum des Alma/Primo-VE-Implementierungsprojektes der BSB ist, sondern es trotz etlicher Vorreiterinstitutionen auch der BSB hier nicht anders erging als anderen Häusern. Speziell im Hinblick auf die Erstverknüpfung der migrierten elektronischen Ressourcen bleibt künftigen Alma-Einsteigern zu wünschen, dass die Alma-API es in Zukunft erlaubt, zumindest bereits vor dem Cutover Load erzeugte Verknüpfungen mit Community-Zone-Collections zu exportieren, um sie unmittelbar vor dem Go-live quasi auf Knopfdruck wiederherstellen zu können.
Die Entscheidung, weiterhin auf Erschließungsdaten aus den herkömmlichen Kataloginstrumenten zurückzugreifen und gleichzeitig das Verlinkungspotential der Community Zone zu nutzen, führt dazu, dass neu hinzukommende Daten durch entsprechende Suchroutinen laufend identifiziert und nachverknüpft werden müssen, was auch im Routinebetrieb mit zusätzlichem Aufwand verbunden bleiben wird. Ob angesichts des erhöhten Aufwands auch bei kostenfreien Ressourcen weiterhin eigene Erschließungsdaten verwendet werden, steht noch zur Diskussion. Möglicherweise muss darauf zumindest teilweise verzichtet werden.
Parallel zum Electronic Resource Management (ERM) von Alma, also der strukturierten Lizenzverwaltung und Workflowgestaltung, wird von der BSB im Kontext ihrer Funktion als Konsortialstelle des Bayern-Konsortiums das ERM-System LAS:eR für die Verwaltung von konsortialen Abschlüssen genutzt. Hier bleibt abzuwarten, ob von Seiten des Betreibers hbz im Zusammenspiel mit Ex Libris perspektivisch eine entsprechende Schnittstelle entwickelt wird.
8 OPACplus wird BSBDISCOVER!
Mit dem Umstieg auf Alma konnte auch die über lange Jahre entwickelte Endnutzerschnittstelle OPACplus auf der Basis von OCLCs TouchPoint nicht länger beibehalten werden. Zum Einsatz kommt jetzt das Cloudsystem Primo VE, das eng mit Alma verknüpft ist. In der Ausprägung für die Nutzenden der BSB wird dieses Recherche- und Serviceportal, das auch die Suche in einem Discovery-Index beinhaltet, als „BSBDISCOVER!“ angeboten. Für die vorherige Portallösung kam eine lokal betriebene Software zum Einsatz, für die über lange Jahre individuelle Anpassungen vorgenommen wurden. Als Standardsystem konnte man diesen OPAC schon lange nicht mehr bezeichnen. Obwohl auch für Primo VE gewisse Anpassungsmöglichkeiten vorhanden sind, war schnell klar, dass solche umfangreichen Spezialentwicklungen nicht für den Start von BSBDISCOVER! nachgearbeitet werden konnten, sollten sie denn überhaupt notwendig sein.
Komfortabel anpassbar ist für diese moderne Oberfläche jedoch das Design selbst, mit Logos, Farbgebung und mehr. Hier konnte eine gewisse Kontinuität mit dem Vorgängersystem, bei einer deutlichen Modernisierung in der Gesamtgestaltung der Oberfläche erreicht werden. Die für die Nutzenden wirklich essentiellen Funktionen für Bestellung und Ausleihe sowie Verwaltung des Nutzerkontos können zusammen mit einer zeitgemäßen Recherchefunktion mit dem System „von der Stange“ zufriedenstellend angeboten werden.
Übrig bleiben dann Detailprobleme, deren Umsetzung zum Teil aber mehr als nur wünschenswert ist, was sich durchaus als anspruchsvoll und langwierig erweisen kann. Für die BSB gehört zu diesen Problemen unter anderem das Angebot der retrodigitalisierten Bestände, die nicht zuletzt wegen des Google-Projekts ein wertvolles Angebot von ganz erheblichem Umfang repräsentieren. Da diese Digitalisate an der BSB innerhalb der Katalogaufnahme für den Printbestand nachgewiesen sind,[2] werden sie von Primo VE aktuell nicht als digitale Ressource dargestellt. Weder werden sie bei den Suchfiltern in der Anzeige der Trefferliste berücksichtigt, noch können die Links gezielt als Dokumentzugriff in der Vollanzeige angeboten werden. Als normaler Zugriffslink, mit JavaScript-Programmierung inzwischen zur Anzeige herausgehoben, kann der Weg zum Digitalisat ermöglicht werden. Als Dauerlösung reicht das allerdings nicht aus. Da hier ein eminentes Benutzerinteresse vorhanden ist, wird im Nachgang zum Go-live mit Nachdruck an einer Optimierung zusammen mit Ex Libris gearbeitet: Durch „OAI-Selbstharvesting“ erzeugt (und aktualisiert!) Alma künftig laufend automatisiert zu allen Printaufnahmen mit Digitalisatnachweis auf Bestandsebene zusätzliche Datensätze für digitale Repräsentationen.
9 Spezielle 3rd Party Integrations
9.1 Benutzerdatensynchronisation
Alma und Primo VE erlauben es, die Accounts der Endnutzenden primär in einem externen ID-Management-System wie etwa einem Hochschulinformationssystem vorzuhalten. Entsprechend unterscheidet Alma „interne“ Nutzende, deren Daten allein in Alma verwaltet werden, von „externen“ Nutzenden, deren Daten initial aus einem externen System geladen und laufend aus diesem synchronisiert werden.
Eine Anbindung an eine übergeordnete Institution zur Nutzerverwaltung gibt es an der BSB nicht. Es existiert jedoch eine sehr enge Kooperation mit der Universitätsbibliothek der Ludwigs-Maximilians-Universität (UB der LMU) in München mit einem gemeinsamen Bibliotheksausweis in beiden Institutionen. Schon in den Vorgängersystemen sorgte deshalb ein komplexes Verfahren für die Synchronisation der Benutzerdaten zwischen drei Partnern, da hierbei auch die Studierenden- und Mitarbeiterverwaltung der zentralen Universitätsverwaltung mit einbezogen ist. Mit dem Umstieg der BSB auf Alma war die vorhandene Synchronisationslösung nicht mehr ausreichend, da sie zumindest bibliotheksseitig ausschließlich für die Kopplung von SISIS-Systemen entwickelt worden war.
Um eine derartige Produkt- und Herstellerabhängigkeit für die Zukunft nachhaltig auszuschließen, wurde die neue Synchronisationslösung als Datendrehscheibe mit eigenem kanonischen Datenformat und REST-API-Schnittstellen konzipiert, die die Verarbeitungslogik eines multilateralen Message Brokers (sogenannter Enterprise Service Bus) implementiert.
Es stellte sich schnell heraus, dass mit der Erstellung dieser Synchronisationsplattform, die den Namen Argo erhielt, neben der Einführung von Alma ein relativ umfangreiches Projekt hinzugekommen war. Für die Programmierung der Komponente wurde deshalb ein externer Dienstleister verpflichtet. Zunächst wurden grundlegende Anforderungen in einem gemeinsamen Analyse-Workshop mit allen Beteiligten als Basis für eine erste Programmerstellung festgelegt. Ein wichtiges Thema war dabei auch das technologische Fundament und die Architektur des Projekts, mit dem zentralen Ergebnis, dass Argo, auf der Basis von Apache Kafka, als Open-Source-Komponente entwickelt wurde. In fortlaufenden Iterationen wurden mit den jeweils neuesten Programmerweiterungen Tests in den Quell- und Zielsystemen durchgeführt, dabei entdeckte Fehler oftmals ad hoc korrigiert oder notwendige Anpassungen der Spezifikationen vorgenommen. Nur so konnte innerhalb des begrenzten Zeitrahmens von nur einem knappen Jahr dieses vielschichtige Projekt zeitgerecht durchgeführt werden.
Mit Argo ist es nicht nur gelungen, den Status quo zu halten und damit zu vermeiden, dass sich riesige Schlangen von Menschen an der Zulassung der BSB bilden. Zugleich wird den vielen Nutzenden aus der LMU ein hervorragender Service geboten, der ihnen lange Anmeldeprozeduren an beiden Bibliotheken erspart. Das System ist damit auch anpassbar für Änderungen und Substitutionen der beteiligten Komponenten.
9.2 Externer Zugriff auf Online-Ressourcen
Die BSB verfügt nicht über einen Campus mit einem fest definierten Nutzerkreis, sondern hat von der Oberstufe der Gymnasien, über Studium, Wissenschaft und Forschung bis hin zur allgemeinen Öffentlichkeit eine überregional heterogene Klientel zu bedienen. Somit war nicht nur die Möglichkeit zum externen Zugriff auf Online-Ressourcen vorzusehen, sondern auch eine differenzierte Steuerung der Zugriffsberechtigungen für alle Fälle, in denen dieselben Ressourcen für unterschiedliche Nutzerkreise lizenziert sind. Die hierfür an der BSB bereits langjährig im Einsatz befindliche Software Hidden Automatic Navigator (HAN) der Firma H+H Software GmbH galt von daher als gesetzt. Es existierten auch bereits ein offenes Web-API seitens HAN sowie eine dieses API partiell unterstützende HAN-Integration seitens Alma, die jedoch noch keine Parameterübergabe zur Zugriffssteuerung bei unterschiedlichen Lizenztypen erlaubte: Lizenzen für Nutzende im Besitz eines Bibliotheksausweises, Nationallizenzen für den deutschlandweiten Zugang durch individuell registrierte Personen und Lizenzen im Rahmen der Fachinformationsdienste für die Wissenschaft müssen im Bibliothekskatalog BSBDISCOVER! teilweise parallel dargestellt werden. Zur Authentifizierung und Autorisierung für den Zugriff auf die lizenzierten Inhalte müssen die entsprechenden Nutzerkreise jedoch sorgfältig getrennt geführt werden. Angestrebtes Ziel war weiterhin, die Zugriffsoptionen zu bündeln, um auf die im Katalog ermittelten Online-Ressourcen auch mit jeder verfügbaren Kennung direkten Zugang zu erhalten.
Vor diesem Hintergrund war seitens Ex Libris eine technische Weiterentwicklung erforderlich, um in die bestehende Alma/HAN-Schnittstelle die Funktionalität eines HAN-Proxy-Multi-License-Moduls zu integrieren. Dieses bietet unter anderem die Option, auch in Alma auf der Service-Ebene der entsprechenden Electronic Collections die eindeutige HAN-Collection-ID und den Lizenztyp (im Bedarfsfall auch mehrere) hinterlegen zu können. Über die erweiterte Schnittstelle wird HAN eine eindeutige Zuordnung des interaktiv ausgewählten Lizenztyps ermöglicht, so dass automatisch der entsprechende Zugangslink generiert werden kann.
Authentifizierung und Autorisierung für den Zugriff auf die Ressourcen erfolgen durch HAN, das in diesem Kontext als Shibboleth Service Provider fungiert. So werden beispielsweise Zugriffsrechte für bestimmte Nutzergruppen oder Sperrgründe geprüft. Wenn Sperrgründe vorliegen oder ein Konto abgelaufen ist, wird die Anmeldung verweigert und ein entsprechender Fehlercode gesendet.
10 Schulungen und Vorbereitung der Einführung
Noch vor dem dritten Test Load startete die BSB mit den Schulungsvorbereitungen. Da angesichts der BSB-spezifischen Workflows weder Schulungsmaterialien von Ex Libris noch von anderen Alma-Anwenderbibliotheken nachgenutzt werden konnten, mussten sämtliche Unterlagen selbst entwickelt werden. In einem 63 Seiten umfassenden Dokument wurden alle 57 Schulungsveranstaltungen (darunter auch zahlreiche Wiederholungen) zu Alma und Primo VE aufgeführt und den rund 300 zu schulenden Mitarbeiterinnen und Mitarbeitern zur individuellen Planung zur Verfügung gestellt. Der Großteil der Schulungen wurde im Hybridformat angeboten.
Zu allen Schulungen wurden umfangreiche Unterlagen mit detaillierten Arbeitsanleitungen erstellt, die in einem BSB-eigenen Alma-Wiki hinterlegt wurden; diese Unterlagen werden auch nach dem Go-live ständig weiterentwickelt.
11 Fazit
Aus einem Projekt dieser Größenordnung lassen sich vielfältige Erfahrungswerte gewinnen. Im Rückblick kritisch zu sehen ist beispielsweise die sogenannte „Onboarding-Phase“, die im schematisierten Projektablauf von Ex Libris allein dem Kennenlernen des neuen Systems dient. Wäre in dieser Phase des Projekts auch schon damit begonnen worden, gemeinsam mit der Firma die bisher praktizierten Geschäftsgänge der Bibliothek zu analysieren, hätte dies dem Projektteam von Ex Libris die Chance eröffnet, das interne Räderwerk der BSB „by doing“ kennenzulernen. Auch das Festlegen der Alma-Topologie und später die Konfiguration der Workflows wären sicher um einiges leichter gefallen.
In jedem Fall aber hat die Einführung des neuen Bibliotheksmanagementsystems dazu beigetragen, den Grad an abteilungsübergreifender Abstimmung im Haus zu erhöhen: Das Alma/Primo-VE-Koordinierungsgremium der BSB, dem unter anderem vier der Autorinnen und Autoren des vorliegenden Beitrags angehören, wird diese neue Qualität der Zusammenarbeit weiter ausbauen und als ganz eigenen Wert hegen und pflegen.
Eines haben sicher alle Alma-Implementierungsprojekte gemeinsam: Nach dem Projekt ist vor dem Projekt, oder besser vor den Projekten! Sobald Alma und Primo VE produktiv sind, gilt es neben den Aufräum- und Nacharbeiten (Einstieg ins Lizenzmanagement mit Alma, optimierter Bindegeschäftsgang, Migration der BSB-Imagekataloge auf „Alma Digital“, Ausschöpfung des Potentials von „Alma Analytics“, dem Statistik- und Reporting-Modul von Alma usw.) selbstverständlich auch, sämtliche Workflows im Umfeld des alten Lokalsystems auf das neue umzustellen (z. B. Digitalisierungsroutinen, Bestellanbindung und automatisierter Rechnungsdatenaustausch per EDIFACT). Speziell im Falle der BSB schließt sich aber sogar noch ein weiteres Alma/Primo-VE-Implementierungsprojekt an, das fachlich und technisch begleitet sein will: die Migration der zehn regionalen Staatlichen Bibliotheken in Bayern.
Über die Autoren
Dr. Berthold Gillitzer
Foto: privat
Hauptabteilungsleiter Benutzungsdienste
Dr. Mathias Kratzer
Foto: privat
Leiter des Stabsreferats Informationstechnologie
Dr. Monika Moravetz-Kuhlmann
Foto: Bayerische Staatsbibliothek/H.-R. Schulz
Hauptabteilungsleiterin Bestandsentwicklung und Erschließung 1
Dr. Hildegard Schäffler
Foto: Bayerische Staatsbibliothek/H.-R. Schulz
Hauptabteilungsleiterin Bestandsentwicklung und Erschließung 2
Dr. MPA Stephan Schwarz
Foto: Bayerische Staatsbibliothek/H.-R. Schulz
Hauptabteilungsleiter Zentrale Administration
© 2024 bei den Autoren, publiziert von De Gruyter.
Dieses Werk ist lizensiert unter einer Creative Commons Namensnennung 4.0 International Lizenz.
