DIE ÖSTERREICHISCHE BIBLIOTHEKENVERBUND UND SERVICE GMBH
„ZIEL ALMA“ : DER ÖSTERREICHISCHE
BIBLIOTHEKENVERBUND AUF WANDERSCHAFT
WOLFGANG HAMEDINGER
BIBLIOTHEKSKONGRESS
LEIPZIG, 15. MÄRZ 2016
Inhalt
• Überblicksangaben zum Österreichischen Bibliothekenverbund – Entwicklung
– Die Verbundzentrale – Verbundarchitektur
– Rahmenparameter / Aktueller Status
• Das Auswahlverfahren
– Vorbereitende Diskussionen
– Ermittlung des geeigneten Vergabeverfahrens – Bildung der Auftraggebergemeinschaft
– Verlauf und Ergebnis
• Implementierung (Alma für Auftraggeber) – Kohorten und Phasen
• Einzelprobleme
– Aufrechterhaltung der Verbundfunktion während der Umstellung („Parallelbetrieb“)
• Ausweitung auf Nicht-Auftraggeber
• Aktueller Stand
OBV IM
ÜBERBLICK
Der Österreichische Bibliothekenverbund (OBV): Entwicklung [1]
• Ursprüngliche Zielsetzungen:
– Elektronische Erfassung und Verwaltung der Bibliotheksmaterialien – Gemeinsame Nutzung von Ressourcen und bereits geleisteter Arbeiten
(Katalogisierung)
– Öffentliche Bereitstellung der Bestandsinformationen
• 1987 [1984]: Beginn der flächendeckenden Zusammenarbeit
– Ab 1984: Gemeinsames System zur Zeitschriftenkatalogisierung (ÖZDB) – Ab 1987: Gemeinsames System zur Monographienbearbeitung (BIBOS)
– Teilnehmer waren damals die meisten Universitätsbibliotheken und die Österreichische Nationalbibliothek
• 1996: Neuausschreibung des Bibliothekssystems
– Federführung und wesentliche finanzielle Beiträge des Ministeriums (BMWF) – Gemeinsame Auswahl durch die Teilnehmer
• 1998 bis 2001
– Einführung des heute noch im Einsatz befindlichen Systems Aleph 500 – Sukzessive Ablöse der vorhandenen zentralen und lokalen Altsysteme – Integration der unterschiedlichen Datenbestände
– Aufnahme erster neuer Verbundteilnehmer außerhalb der Zuständigkeit des damaligen BMWF
Der Österreichische Bibliothekenverbund (OBV): Entwicklung [2]
• 2002
– Institutionalisierung der Verbundzentrale durch Ausgliederung per Bundesgesetz als
„Die Österreichische Bibliothekenverbund und Service Ges.m.b.H.“
– Verselbständigung der Österreichischen Nationalbibliothek – Universitätsgesetz
• 2003 bis 2004
– Vorbereitung der internen (Selbst-)Organisation des Verbundes
• seit 2004
– Mehr als Verdopplung der Teilnehmerzahl durch Beitritt neuer Mitglieder
▪ Fachhochschulen, Landesbibliotheken, Ministerien, Forschungseinrichtungen, ...
– Selbstorganisation des Verbundes: „Verbundstatut“ mit Anker Verbundzentrale OBVSG – Verstärkung der internationalen Zusammenarbeit (besonders mit deutschsprachigen
Einrichtungen)
– Weiterentwicklung der Dienstleistungen durch Entwicklung zahlreicher und von vielen nutzbarer Tools zur Verbesserung der Bibliotheksarbeit
– Einrichtung des „ÖVK-NAH“: Österreichischer Verbundkatalog für Nachlässe, Autographen und Handschriften
– Intensivierung der Verwaltung elektronischer Medien
▪ Kataloganreicherungsdaten (Inhaltsverzeichnisse, Volltexte)
▪ E-Books
Die OBVSG als Verbundzentrale: Aufgaben und Ressourcen
• Ausgliederung der Verbundzentrale als „Die Österreichische Bibliothekenverbund und Service Ges.m.b.H.“ mit 1. Jänner 2002 (10,5 besetzte Planstellen)
• „Gewöhnliche“ privatrechtliche Form, somit keine Zwänge der Kameralistik mehr – Steht zu 100% im Eigentum des Bundes
• Institutionalisierte Verbundzentrale
– Bereitstellung der zentralen Dienstleistungen
– Operative Leitung des Österreichischen Bibliothekenverbundes, auch zuständig für Erweiterungen des Verbundes
• Abdeckung von Grundleistungen, insbesondere für die bis 31.12.2001 teilnehmenden, zum damaligen BMBWK gehörenden Bibliotheken durch Bundeszuschuss in Höhe von jährlich 1,72 Mio. €
• Strengere Kostenrechnung und gesetzliche Verpflichtung zur kostendeckenden Leistungserbringung
• Inzwischen 33 Mitarbeiter(innen) in den Abteilungen – Verbundbetreuung und Koordination
– Laufende Planung / Implementierung – Betrieb und technische Betreuung
Der Österreichische Bibliothekenverbund (OBV): Architektur
• Verteilung der Aufgabenstellungen auf ein zentrales und mehrere lokale Systeme nach der Maxime „Soviel zentral wie nötig, soviel lokal wie möglich“
– Flexibilität
– Hoher Grad von Synergieeffekten
• Zentrale Datenbank mit Anspruch auf weitgehende Dublettenfreiheit – Als Glücksfall entstanden auf Grund historischer Konstellationen – Spezialisiert auf Erfassung bibliographischer Datensätze
– Katalogisierung mit allen Finessen (Normdaten, Fremddaten, Z-Quellen) – Kataloganreicherung
– Basis für übergreifende sonstige Dienste
• Wechselseitige Datenreplikation zwischen zentralem System und den lokalen Systemen
• Auf Grund der Anforderungen weitgehend homogene Struktur – Beginn als reiner Aleph-Aleph-Verbund
– Derzeit nur Aleph 500 und Alephino-Systeme im Einsatz
Aktuelle Datenquellen und Datenfluss im Verbund
Fremd- daten
Online- Datenreplikation
HOL SE
BIB
DAITM
M
Aleph 500
Z e n t r a l s y s t e m
ITM BIB
Lo ka sl ys et me
HOL-1 HOL-2 SE-1
ITM-1 ITM-2 ITM-n BIB-1
BIB-2 BIB-n
A D M
Zeitschr.- Bestände ÖZZDB
Nichtaktive Teilnehmer
BIB
HOL ITM
Z39.50-Quellen (Verbünde)
Norm- daten
ACC09 Bestandsdaten
ZDB DNB (ftp)
ZDB
Rahmenparameter Verbund
• Möglichkeiten der Verbundteilnahme – Eigenes Lokalsystem Aleph
▪ Eigenbetrieb
▪ Betrieb und Systemadministration durch Dritten
▪ Vollversorgung durch OBVSG – Eigenes Lokalsystem Alephino
▪ Eigenbetrieb – Aleph-Sharing
▪ ASP-Versorgung durch OBVSG
• Teilnehmer
– 72 aktive Verbundteilnehmer (vertretende Institutionen)
▪ Österreichische Nationalbibliothek
▪ alle bundesstaatlichen Universitäten
▪ Fachhochschulen
▪ Landesbibliotheken
▪ Verbund für Bildung und Kultur (Bundesstaatliche Pädagogische Hochschulen)
▪ Verwaltungsbibliotheken
▪ Sonstige wissenschaftliche Bibliotheken – 93 selbständige Einrichtungen
Verbundstatus: Zentral bereitgestellte allgemeine Dienste
• OBVSG als ISIL-Agentur für Österreich (International Standard Identifier for Libraries and Related Organizations)
– Bibliotheksadressdatenbank und ISIL-Verzeichnis – ISIL-Vergabe
– kostenfrei
• Infrastruktur für Bibliotheksstatistik unter Nutzung der Umgebung für die DBS – Teilnahme aller wissenschaftlichen Bibliotheken in Österreich
– durch den Kostenbeitrag der OBVSG abgedeckt
• URN-Resolver
– Uniform Resource Name (URN)
• RDA-Toolkit
– Befristete Lizenzen für die deutschsprachigen Verbünde gemeinsam verhandelt – derzeit von der OBVSG finanziert und verwaltet
– temporär!
Verbundstatus: Zentral bereitgestellte Dienste für Verbundmitglieder
– Z39.50-Zugang von und zur Verbunddatenbank – Multinormdatei für Klassifikationen
▪ Mathematics Subject Classification
▪ Basisklassifikation – ZDB
▪ Bestandsdatenlieferung (seit Formatwechsel im November 2013 sistiert)
▪ Normdatei
– Kataloganreicherung
▪ u.a. Einspielen von IVSCAN und Publikationsdaten der TU Wien
– Tabellenbrowser zum Abgleich von und Einsichtnahme in Parameterdateien – Versorgung von Discovery-Diensten
– eDOC
▪ Basisdienst und Portale
▪ Konsistenztools für eDOC und Kategorie 655o im Verbunddatensatz – OPUS-Workflow zur Bearbeitung von Hochschulschriften
– Aleph-SAP-Schnittstelle – upgrade2ac
– Verbund der Literaturarchive (ÖVK-NAH) – EasyTool
– Einspielen von E-Books-Daten – Konsortiallösung MetaLib/SFX – Konsortialinstanz Primo
– Konsortiallösung Visual Library
Zusammenfassung der Ausgangssitution
• Sehr gut funktionierendes und effizientes Verbundumfeld – Stabiler Betrieb
• Langjährige Zusammenarbeit
– Entwicklung eines ausgeprägten „Mehrwerts“
– Immer wieder gemeinsame Zielsetzungen im Dialog
▪ Keine wechselseitigen Weisungsbefugnisse im Verbund
– Positive Erfahrungen mit der Einbindung von Fachexpertise bei der Ablöse des Aleph- Vorgängers BIBOS im Jahr 1997
• Der Verbund soll jedenfalls erhalten bleiben
• Unzulänglichkeiten von Aleph bei neueren Anforderungen sind nicht mehr zu übersehen
– an sich besteht kein Zeitdruck!?
AUFBRUCH
Projekt Aleph-Ablöse: „Ur- und Frühgeschichte“ / Beweggründe
• Überlegungen zur möglichen Aleph-Nachfolgesystemen seit 2009 – Aleph sehr gut an Verwaltung von Druckwerken angepasst – Nicht gut geeignet für Verwaltung von E-Ressourcen
– Berichtswesen (Statistik) unterentwickelt
▪ Lösung mit ARC nicht überzeugend
• Internationale Entwicklung
– Erkennbar: Richtung nach „Wolkenkuckucksheim“ = „die Cloud“
– Konzentration auf dem Bibliotheksmarkt – Alternativen
▪ Kommerzielle Software
▪ Open source Bibliothekssysteme
• Frage des strategisch richtigen Zeitpunkts
– Verbund soll erhalten bleiben → hochkomplexe Anforderungen – zu früh: frustrierender Kampf mit völlig unreifen „Bananen“
– zu spät: kein Einfluss mehr auf die Architektur des Systems → wesentliche Bedürfnisse möglicherweise nicht abbildbar
• Anmerkung in eigener Sache
– Projekt „Cloudbasierte Infrastruktur für Bibliotheksdaten“ (CIB) ohne Einfluss auf Vergabeverfahren und Auswahlentscheidung
Projekt Aleph-Ablöse: Vorbereitungen und Wegfindung
• Markterkundung
– Herstellergespräche – Unterlagensichtung
• Grundsätzliches
– Keine (ausreichenden) Zentralmittel an der OBVSG vorhanden
– Zufriedenstellende Auswahl und Akzeptanz von Lösungen nur bei breiter Einbindung von Verbundbibliotheken erreichbar
– Sehr gute Erfahrungen aus dem Ausschreibungsverfahren mit dem Resultat Aleph 500
• Überlegungen zu den Anforderungen an ein neues System
• Rechtliche Abklärung (1): Äußere Rahmenbedingungen
– Sehr viele Verbundteilnehmer unterliegen als öffentliche Auftraggeber dem Bundesvergabegesetz → formales Vergabeverfahren unvermeidbar
▪ Vergabeverfahren dient der Transparenz
▪ Und im Glücksfall auch der Kostenersparnis – Verfahrenswahl (Oberschwellenbereich)
▪ offenes Verfahren
▪ nicht offenes Verfahren
▪ Verhandlungsverfahren
▪ wettbewerblicher Dialog
Projekt Aleph-Ablöse: Auf dem Weg zum formalen Verfahren
• Rechtliche Abklärung (2): Interne Organisation - Wie bringt man mehrere Organisationen unter einen Hut?
– Anforderungen
▪ Keine Beliebigkeit ab Start des Verfahrens
▪ Klare Zuständigkeiten
▪ Reglement für Entscheidungen und Zusammenarbeit – Gewählte Lösung
▪ Unwiderrufliche Vollmacht jedes Auftraggebers
▪ OBVSG als vergebende Stelle zuständig für Einhaltung von Formalia und Abwicklung
▪ Teilnehmerkonsilium (eine Vertretung je Auftraggeber, insgesamt 14): zuständig für die grundsätzlichen Beschlüsse am Anfang wie Freigabe der
Ausschreibungsdokumente
▪ Verhandlungsteam (eine Vertretung je Bibliothekstyp, Universitäten bündeln,
insgesamt 8, später 9): Verhandlungsführung ab Eintritt in die Verhandlungsphase
▪ Stimmgewichte gemäß den festgesetzten Maximalauftragswerten
▪ Definiertes Quorum für normale Entscheidungen
▪ Einstimmigkeit bei erforderlicher Überschreitung der zugesagten Maximalkostenwerte
• Rechtliche Begleitung unabdingbar
– Spezialkenntnisse im Vergaberecht und bei Datenschutzfragen erforderlich
– Zusätzlich müssen Auftraggeber/vergebende Stelle wissen, was rechtlich vorgeht
Projekt Aleph-Ablöse: Die Auftraggeber
• Die Österreichische Bibliothekenverbund und Service Gesellschaft mbH
• Österreichische Nationalbibliothek
• Johannes Kepler Universität Linz
• Karl-Franzens-Universität Graz
• Technische Universität Wien
• Universität Innsbruck
• Universität Wien
• Veterinärmedizinische Universität Wien
• WU Wirtschaftsuniversität Wien
• Fachhochschule St. Pölten GmbH
• Kammer für Arbeiter und Angestellte für Wien
• Republik Österreich vertreten durch die Bundesministerin für Bildung und Frauen (Verbund für Bildung und Kultur)
• Medizinische Universität Wien
• Universität Salzburg
• Rechtliche Begleitung:
Freshfields Bruckhaus Deringer
Projekt Aleph-Ablöse: Verfahrenssplitter [1]
Organisatorisches
• Durchführung kooperativ und verbundbasiert – Vollversammlung
– AG Strategische Planung – AG Aleph-Ablöse
• Involvierung ausgewiesener Fachleute aus allen Gebieten – 6 Modul- und Konzeptgruppen
– Über 50 Expertinnen und Experten aus zahlreichen Verbundbibliotheken – externe Unterstützung für den Bereich Datenschutz
• Vertreter der Auftraggeber auf Leitungsebene (Teilnehmerkonsilium) – 14 Personen
• Verhandlungsteam – 8 Mitglieder
– 1 kooptiertes Mitglied aus dem Kreis der universitären IT-Verantwortlichen
• Projektkoordination – OBVSG
Projekt Aleph-Ablöse: Verfahrenssplitter [2]
Vorbereitung der Unterlagen
• Fachliche Grundannahme: Kein aktuelles Bibliothekssystem wird alle unser Bedürfnisse zum Zeitpunkt der Ausschreibung erfüllen
– Zwingende Funktionsanforderungen – Verpflichtungserklärungen
– Zwingende Konzeptanforderungen, u.a.
▪ Parallelbetrieb
▪ Datenschutz
• Ausarbeitung der Ausschreibungsunterlagen (Verfahrensvorschriften) inklusive Bewertungsschema
• Freigabe der Unterlagen durch die Auftraggeber Bekanntmachung
• EU-weite Bekanntmachung am 29. Oktober 2013
Projekt Aleph-Ablöse: Exkurs Verhandlungsverfahren - Visualisierung
Erstellung
Teilnahmeantrags- und
Ausschreibungsunterlagen Bekanntmachung Einbringung
Teilnahmeanträge (Frist: 37 Tage)
Auftraggeber Auftragnehmer
Angebotsöffnung Angebotserstellung und Angebotslegung (Frist: 40 bis 52 Tage)
Aufforderung zur Angebotslegung an ausgewählte Unternehmer
Auftraggeber Auftragnehmer
Angebotsprüfung Verhandlungen über
Auftragsdetails Last and Final Offer
Auftraggeber Auftragnehmer Auftragnehmer
Zuschlagserteilung Stillhaltefrist Zuschlagsentscheidung Auftraggeber
Auftraggeber
Auftraggeber
Auftraggeber Auftraggeber
Auftraggeber
Projekt Aleph-Ablöse: Verfahrenssplitter [3]
Bearbeitung der Ersteinreichungen (Juli 2014 - Jänner 2015)
• Ablauf
– Fachliche Prüfung – Teststellung
– Aufklärungen – Bewertung
Verhandlung mit den verbliebenen Bietern
• Zwei Verhandlungsrunden erforderlich – März 2015
– Juli 2015 Finale
• Letztangebot samt Prüfung und Letztpolitur
– Beschluss des Verhandlungsteams zur Erfüllung der fachlichen Anforderungen
• Zuschlag erteilt am 15. September 2015
– Auftragswert: 8.290.350,56 EUR ohne MWSt
Projekt Aleph-Ablöse: Verfahrenssplitter [4]
Ausgewählte Erkenntnisse
• Dieses Verfahren bestand aus Superlativen – Personalressourcen
– Zeitaufwand – Nervenbelastung
– Kosten (siebenstellig!)
• Gemeinsames Vorgehen bringt Stärke und schlussendlich effizientere Ergebnisse
• Ein gemeinsames Wollen ermöglicht vieles - auch Schwieriges
• Rechtlich stark bindende Selbstorganisation ist gelungen – Unwiderrufliche Verpflichtungserklärung
– Bevollmächtigung – Ablaufvorschriften
• Vertrauen ist gut, aber Kontrolle verhindert trotzdem Patzer
ALMA FÜR AG
Umsetzung in Gruppen („Kohorten“)
• Implementierung in 3 Gruppen – Kohorte 1 (6 Bibliotheken) – Kohorte 2 (7 Bibliotheken)
– OBVSG (Implementierung zentraler Services)
Ex Libris OBVSG Kohorte 1 Kohorte 2
Kohortenmanager 2 AK Wien
Medizinische Universität Wien Österreichische Nationalbibliothek Universität Graz
Universität Linz
Universität Salzburg
Verbund für Bildung und Kultur Kohortenmanager 1
FH St. Pölten TU Wien
Universität Innsbruck Universität Wien
Veterinärmedizinische Universität Wien WU Wien
01 2016
06
2016 12
2016
06 2017
12 2017
03 2018
Orientierung Zeitschiene
Überblick Projektphasen
• Konzeptionsphase (Conceptual Design): seit Ende Jänner 2016
• Implementierungsphase (Implementation Phase): ab August 2016 – Getting Ready Phase
– Implementierung Kohorte 1 – Implementierung Kohorte 2
– Implementierung zentraler Services (OBVSG)
• Betriebsphase (Post Go Live): August 2017 / Jahreswechsel 2018 / 2. Quartal 2018
Konzeptionsphase (Conceptual Design): Überblick
• Ende Jänner 2016 bis Ende Juli 2016 (optional weitere zwei Monate)
• Konkretisierung und Spezifikation der Zwingenden Konzeptanforderungen (KK1 bis KK6) – KK1 Verbundarchitektur
– KK2 Normdaten – KK3 ZDB
– KK4 Datenschutz („Bequemlichkeitsergänzungen“) – KK5 Migration und Parallelbetrieb
– KK6 Konsortiale Funktionalitäten (konsortiales ERM)
• Konzeption für Abnahmetests → Bildung einer eigenen „Konzeptgruppe“
Konzeptionsphase (Conceptual Design): Wesentliche Ziele
• Priorisierung der vereinbarten Entwicklungen von Zusatzfunktionalitäten nach zwei Klassen
– Klasse 1: Umsetzung vor Produktionsaufnahme der Kohorten – Klasse 2: Umsetzung vor Produktionsaufnahme der OBVSG
• Ex Libris erstellt in Zusammenarbeit mit den Auftraggebern High Level Design Dokumente
• Konkretisierung des Migrations- und Implementierungsplans
• Erstellung des Konzepts für Abnahmetests
• Entwurf eines Exit-Konzepts
Implementierungsphase (Implementation Phase): Übersicht
• Getting Ready Phase (Anfang August 2016 bis Ende Jänner 2017) – Phase richtet sich hauptsächlich an OBVSG
– Kleine Gruppe von Expertinnen und Experten kann hinzugezogen werden – Zugriff auf Testumgebung (konsortiale Standard-Sandbox):
Netzwerkzone + 3 Institutionen
– Parallel startet Ex Libris mit den vereinbarten Entwicklungen der Klasse 1
• Implementierung Kohorte 1
• Implementierung Kohorte 2
• Implementierung zentraler Services (OBVSG)
Implementierung Kohorte 1 und 2
• Zeitplan
– Kohorte 1 Februar 2017 bis Ende Juli 2017 (Go-Live Anfang August 2017) – Kohorte 2 Juli 2017 bis Dezember 2017 (Go-Live Anfang Jänner 2018)
• vor Go-Live der ersten Kohorte werden vereinbarte Entwicklungen in monatlichen Releases zur Verfügung gestellt
• Ausgewählte Aktivitäten – Analyse-Sessions
– E-Learning und Online-Training – Workshops vor Ort
– Integrationssupport
– Datenmigration (ein Testimport, ein Produktionsimport)
Implementierung zentraler Services (OBVSG)
• Zeitplan
– Februar 2017 bis April 2018 (parallel zu Implementierung Kohorte 1 und Kohorte 2) – Phase schließt ab mit dem Umstieg der Verbunddatenbank und Produktivnahme der
zentralen Services in Alma
• Technische Implementierung
– Konfiguration der Alma Network Zone
– Datenanalyse und -vorbereitung / Testmigration
– Entwicklung der konsortialen/zentralen Services und Integration externer Systeme – Vorbereitungen in Primo für den Umstieg auf Alma
– Tests des Sync-Prozesses (Aleph-Alma)
– Vorbereitung der Verbunddatenbank für Umstieg der Kohorten 1 und 2
• Parallel entwickelt Ex Libris die vereinbarten Erweiterungen der Klasse 2
Abnahme und Migration → Betriebsphase
• Kohorte 1, Kohorte 2 und OBVSG führen jeweils Funktionsprüfungen nach dem in der Konzeptionsphase vereinbarten Testkonzept durch
• währenddessen festgestellte Abweichungen vom vereinbarten Basissystem bzw. von den vereinbarten Entwicklungen sind zu protokollieren und in zwei Kategorien einzustufen:
– Kategorie A: wesentliche Abweichungen, die ein Go-Live verhindern
▪ Behebung durch von Ex Libris im Rahmen der Abnahmetestphase – Kategorie B: andere wesentliche Abweichungen
▪ Behebung binnen 12 Monaten nach der Produktionsaufnahme des letzten Auftraggebers der Kohorte 2
▪ bei OBVSG: Behebung binnen 12 Monaten nach Produktionsaufnahme
• Migrationsplan ist Teil des Implementierungsplans
EINZEL-
PROBLEME
Beispiel: Problemstellung Parallelbetrieb
• Ausgangspunkt ist ein voll funktionsfähiger Verbund – Automatische Replikationsmechanismen
– Klar definierte Datenquellen – Normdateinutzung
– Interndarstellung ASEQ-Format auf MAB2-Basis
• Übergang erfordert jedenfalls mehrere Jahre
• Parallelbetrieb von alten und neuen Systemen
– Verbundfunktionen müssen im größtmöglichen Ausmaß erhalten bleiben – Geringstmögliche Störungen für die Bearbeiterinnen und Bearbeiter – Erhalt der Datenkonsistenz
• Zusagen von Ex Libris:
– „There will be an automatic synchronization process between Alma (used by consortium members) and Aleph (central catalogue). By this an efficient cataloguing will still be
possible without a double burden of different cataloguing interfaces.“
– Diese Synchronisation zwischen den alten Systemen und Alma wird für mehrere Jahre ab dem Inkrafttreten des Vertrags gewartet
Aktuelle Datenquellen und Datenfluss im Verbund
Fremd- daten
Online- Datenreplikation
HOL SE
BIB
DAITM
M
Aleph 500
Z e n t r a l s y s t e m
ITM BIB
Lo ka sl ys et me
HOL-1 HOL-2 SE-1
ITM-1 ITM-2 ITM-n BIB-1
BIB-2 BIB-n
A D M
Zeitschr.- Bestände ÖZZDB
Nichtaktive Teilnehmer
BIB
HOL ITM
Z39.50-Quellen (Verbünde)
Norm- daten
ACC09 Bestandsdaten
ZDB DNB (ftp)
ZDB
Parallelbetrieb: Situation nach Umstieg von Kohorte 1 / 2
Parallelbetrieb: Katalogisierungsablauf nach Umstieg von Kohorte 1 / 2
• Alma-Teilnehmer
– Bearbeitung vollständig in Alma
▪ Katalogisierung im Alma-Web-Client
▪ MARC-basiert
– Synchronisation Institutionszone ↔ Aleph zentral
▪ „Push-Mechanismus“ für Neukatalogisate aus Alma nach Aleph zentral
▪ Zweiseitiger Replikationsmechanismus
• Aleph- und Alephino-Teilnehmer
– Bearbeitung unverändert vollständig in Aleph
Parallelbetrieb: Situation nach Umstieg aller Auftraggeber inklusive OBVSG
Parallelbetrieb: Katalogisierungsablauf nach Umstieg aller AG
• Alma-Teilnehmer
– Bearbeitung vollständig in Alma
▪ Katalogisierung im Alma-Web-Client
▪ MARC-basiert
– Integration Alma Institutionszone ↔ Alma Netzwerkzone
• Aleph- und Alephino-Teilnehmer – Bearbeitung vollständig in Aleph
– Synchronisation Aleph / Alephino ↔ Alma Netzwerkzone
▪ „Push-Mechanismus“ für Neukatalogisate aus Aleph / Alephino in die Alma Netzwerkzone
▪ Zweiseitiger Replikationsmechanismus
Parallelbetrieb: Situation vollständige Ablösung von Aleph/Alephino
Parallelbetrieb: Jedenfalls noch näher zu behandelnde Punkte
• Analyse der Replikationsvoraussetzungen – Aleph/Alephino: ASEQ-Intern MAB2-basiert – Alma: Internformat MARC21(-XML)
• Konsequenzen
– ASEQ/MAB2 ↔ MARC21 Konverter
▪ Achtung! Konvertierung in beide Richtungen erforderlich
▪ Hohe Qualität unabdingbar
– Anpassungen im Aleph-Internformat zu überprüfen
▪ betrifft dann auch jedes Lokalsystem
• Normdatenversorgung nach dem Übergang des zentralen Systems
– Andocken von Altsystemen an Alma zur Normdatenversorgung eher unwahrscheinlich
• Primo-Publishing
• Möglichst kurzer Parallelbetrieb
– Die Kopplung wird bei aller Mühe vermutlich nicht perfekt sein – Straffe Umstiegsplanungen nötig
• Anbindung von nicht Alma-Systemen
– Dauerhafte Anbindung von anderen Systemen mit Basisinformationen in der Netzwerkzone vorgesehen (zwecks einheitlicher Datenversorgung von Primo) – Katalogisierung und Erstellung von Bestandsangaben mit dem Browser in Alma – Synchronisation der bibliographischen Daten in das Fremdsystem vorgesehen
Zentrale Dienstleistungen OBVSG: Weiteres Procedere
• Inventarisierung und Analyse bestehender Dienste – „Eigenständig“ verwendbare Dienste
– „Integrierende“ Dienste mit Aleph
▪ hier sind jedenfalls Änderungen erforderlich
• Erwerb ausreichender Kenntnisse von Alma
• Einordnung
– Ersatzlos wegfallende Dienste
▪ in Alma nicht erforderlich oder mindestens gleichwertige Funktionalitäten vorhanden – Anzupassende / zu ersetzende Dienste
– Dienste, bei denen nur die Integration angepasst werden muss – Aufzugebende Dienste
▪ Schwierig nachzubilden
▪ Zu teuer
▪ Unpassend für die neue Architektur
– Inklusive Sammlung sich ergebender Ideen zu neuen Diensten
• Planung und Entwicklung entsprechend der Ergebnisse
– Jedenfalls bestehen bleiben die großen, weiterhin benötigten Dienste, wie z.B.
▪ Primo
▪ Visual Library
ALMA FÜR
NICHT-AG
Berücksichtigung von Verbundteilnehmern, die keine Auftraggeber sind
• Grundsätzliche Unterteilung der verbliebenen Verbundteilnehmer in – Teilnehmer mit eigenständigem Lokalsystem (→ Option 1)
– Teilnehmer ohne eigenständiges Lokalsystem „Aleph-Sharing“ (→ Option 2, unmittelbare Zuständigkeit der OBVSG)
• Umstieg auf Alma nach Migration der Auftraggeber (insbesondere OBVSG) möglich
• Interessentenumfrage unter den eigenständigen Lokalsystemen während der Bildung der Auftraggebergemeinschaft:
– Wesentlicher Inhalt der Vereinbarung:
„Der Verbundteilnehmer beabsichtigt, sich auch in Zukunft am
Bibliothekenverbundsystem der OBVSG beteiligen und erklärt, die von der OBVSG im Rahmen ihres gesetzlichen Auftrags zur Verfügung gestellten Verbundleistungen – vorbehaltlich der vergaberechtlichen Zulässigkeit – nutzen zu wollen und die OBVSG bei der Erfüllung ihrer gesetzlichen Aufgaben zu unterstützen.“
– Daher Vorrangposition im Anschluss an die Implementierung der Auftraggeber
• Ausschreibung hat die entsprechenden Informationen berücksichtigt
• Leistungsvertrag enthält einzelne Abrufmöglichkeiten für die Mitglieder der beiden Optionsgruppen
– Abruf erfolgt immer über die OBVSG
Eigenständige Lokalsysteme (Option 1): Nächste Schritte
• Eigenständige Lokalsysteme laufen mit – Aleph
– Alephino – Bond
• Ausreichende vertragliche Regelungen für eigenständige Lokalsysteme getroffen – Kosten
– Bedingungen – Serviceleistungen
• Nach Abklärung verbliebener kostenrelevanter Parametern daher Entscheidung über die Alma-Teilnahme einer Einrichtung möglich
• Implementierung vermutlich in Form der Bildung weiterer Kohorten ab Mitte 2018 – Berücksichtigung der Erfahrungen aus der Implementierungsphase
Aleph-Sharing Systeme (Option 2): Nächste Schritte
• Ausgangssituation:
Aleph-Sharing ist ein sehr kostengünstiger und auf die Möglichkeiten von Aleph
zugeschnittener Dienst → Modell zur Versorgung kleinerer Einrichtungen erforderlich – leistbar für die Einrichtungen
▪ idealerweise ohne Zusatzbelastung – erweiterungsfähig
– finanziell auch für die OBVSG darstellbar
• Ergebnisse des Verfahrens sind für ein Ablösemodell (noch) nicht ausreichend konkret
• Weitere Maßnahmen:
– Analyse der grundsätzlichen Koexistenz mehrerer Einrichtungen innerhalb einer Alma- Institution
▪ Rahmenbedingungen und Einschränkungen
▪ Überprüfung, welche Einrichtungen auf Grund von Größe / Komplexität /
umfassender Funktionalitätsnutzung besser eine eigene Alma-Instanz erhalten
▪ Synergien bzw. Mehraufwand bei der systembibliothekarischen Betreuung – Kostenrechnung
– Alternativensondierung
▪ Alma auch für „kleinere“ Einrichtungen
▪ Nicht-Ex-Libris-Produkte mit beschränktem, aber ausreichendem Funktionsumfang – Endentscheidung über das von der OBVSG angebotene zukünftige Modell
AKTUELLER
STAND
Das Projekt nimmt Fahrt auf ...
• Leistungsvertrag ist nach Einholung aller Unterschriften in Kraft
• Kickoff-Meeting hat Ende Jänner 2016 stattgefunden – Präsentation des aktuellen Entwicklungsstandes
– Analyse der in der Konzeptionsphase zu behandelnden Bereiche
▪ Konkrete Entwicklungserfordernisse
▪ Konzeptanforderungen
▪ Testkonzepte
▪ Exit Plan
▪ Finalisierung des vorläufigen Projektplans
– Einordnung aller Aktivitäten in 31 weitgehend parallel behandelte „Tracks“
• Projektmanagement ist aufgesetzt
• Die Bearbeitung der Tracks hat begonnen
• Viel Arbeit liegt noch vor uns – ein lohnendes Ziel wartet
Danksagung
Für verwendete Beiträge von
• Roland Lukesch
• Verena Schaffner
