Nr. 4 (2025)
DOI: 10.5282/o-bib/6203
Die Universitäts- und Landesbibliothek (ULB) Münster war Teil der sogenannten "Welle 2" des NRW-weiten Umstiegs auf das cloudbasierte Bibliotheksmanagementsystem (CBMS) Alma der Firma Ex Libris. Es galt, den Kurs gut zu planen, das Ziel genau anzupeilen sowie den Gefahren und Herausforderungen des zu erwartenden Seegangs zu trotzen.
Zur Organisation, zum zeitlichen Ablauf und auch zu den technischen Aspekten und den generellen Themenkomplexen bei Implementierungen wurde bereits in diversen Beiträgen berichtet.1
In der ULB Münster sind die Workflows rund um Alma mittlerweile etabliert (wenn auch fluide), und wir wollen hier einige Aspekte aus den Bereichen Planung, Kommunikation und Schulung vorstellen, die im Rückblick für unseren Umstieg besonders wichtig waren: “Key Learnings” zu Arbeitsmethoden, Fehlerkultur und Teambuilding. Sie können auch für andere Einrichtungen und in anderen Change-Prozessen jenseits des Wechsels von Bibliotheksmanagementsystemen hilfreich sein.2
Die vom Hochschulbibliothekszentrum Nordrhein-Westfalen (hbz) eingerichteten „Functional Experts”-AGs für den Alma-Umstieg nahmen im September 2019 ihre Arbeit auf; die ULB Münster (im Folgenden: ULB) war an jenen zu E-Ressourcen, zur SISIS-Migration und zum Aspekt Zweischichtigkeit beteiligt. Im August 2021 wurde die “Zweite Alma-Welle” mit einer Kick-Off-Veranstaltung gestartet.
Ein bei uns bereits zwei Jahre zuvor begonnenes Vorprojekt zur Bereinigung von Titel- und Bestandsdaten war wie erwartet sehr aufwendig; es lief bis zum „Freeze“ genannten Redaktionsschluss für die Daten im Juni 2022 durch. Dies war allerdings eminent wichtig für den Erfolg des Umstiegs, da die Datenmigration ohne die Bereinigung von rund 150.000 Datensätzen zu deutlich mehr Fehlermeldungen und Inkonsistenzen geführt hätte.
Aufwendig war ebenfalls die Erhebung und Evaluierung sämtlicher Prozesse in allen – damals noch rund 75 – Bibliotheksstandorten rund um das Bibliotheksmanagementsystem. Diese Workflow- und Topologie-Überlegungen waren zeitintensiv. Sie wurden präziser, je weiter wir uns in die Alma-Struktur eindenken und mit unseren Prozessen mappen konnten.
Für die ULB hat sich aus dem Prozess z. B. der Beschluss ergeben, die Ressourcenerfassung nur noch mit bibliothekarischem Fachpersonal durchzuführen und nicht mehr, wie bislang, auch mit studentischen Hilfskräften, die für die Erfassung im sogenannten Minimalformat geschult worden waren.
Das GoLive für die Münsteraner Alma-Instanz erfolgte am 1.8.2022 mit knapp 4,5 Mio. bibliographischen Datensätzen, rund 150.000 ZDB-Sätzen, 48.000 Nutzerdatensätzen (im Alma-Jargon: Patrons), 70 Bibliotheken (Libraries) mit 485 Standort-Einheiten innerhalb der Bibliotheken (Locations), knapp 55.200 Ausleihen (Loans) und rund 2.000.000 elektronischen Medien (Portfolios).
Das Projektteam umfasste rund 45 Personen verteilt auf das sogenannte Kernteam, die AG Alma-Admin, die AG Schulung sowie das Projektbüro und die Projektleitung. Die inhaltliche Arbeit des Kernteams war in fünf Teilprojekte mit insgesamt 20 Arbeitspaketen aufgeteilt.
Der Arbeitseinsatz für das Alma-Projekt wurde bis September 2022 über ein selbst entwickeltes Online-Tool erfasst: Er akkumulierte sich auf über 43.500 Arbeitsstunden, was rund 1.100 Vollzeit-Arbeitstagen oder 4,85 Arbeitsjahren entspricht.
Lessons learned
Die Vorbereitung von Änderungen in so zentralen Bausteinen wie einem Bibliotheksmanagementsystem sollten mit ausreichend Vorlauf beginnen und die Teams gemischt aus allen betroffenen Abteilungen zusammengestellt werden. In zweischichtigen Systemen sollte dabei v.a. an Kolleg*innen aus den dezentralen Standorten gedacht werden, um sie von Anfang an aktiv in die Überlegungen einzubeziehen.
Die zu migrierenden Daten können dann mit der notwendigen Gründlichkeit geprüft und bereinigt, Geschäftsgänge analysiert, entstaubt, detailliert dokumentiert und für die Umstellung vorbereitet werden. Es wird dann auch möglich, Bedürfnisse und Wünsche an das neue bzw. geänderte System zu formulieren.
Für die Erfassung der zeitlichen Aufwände für ein Projekt ist der Einsatz eines einfachen Tools sinnvoll, das täglich an die Eintragung der Daten erinnert.
Beim klar definierten Organisationsgerüst von hbz und Exlibris schienen einige Lösungen und Ideen eher für Jollen als für den großen Münsteraner Dampfer gedacht.
Um dem Projekt Struktur zu geben und eine kluge Zielplanung zu betreiben, richteten wir eine AG Alma mit mehreren Arbeitspaketen ein. Eine dezidierte und z. T. rigorose Urlaubsplanung wurde eingefordert, im Gegenzug gab es flexiblere Arbeitszeitregelungen, damit Aufgaben termingerecht erledigt werden konnten.
Die Projektarbeitsgruppe setzte sich zusammen aus der Projektleitung mit zwei Kolleginnen, dem Projektbüro, den allgemeinen AGs zu Schulung und Administration sowie dem Kernteam mit den thematischen Arbeitsgruppen. Neben der Aufgabe, den Gesamtüberblick zu behalten, oblag den Projektleiterinnen als unseren nautischen Offizierinnen auch die Kommunikation mit der Direktion.
Nach dem GoLive wurde das Projektteam in eine AG Alma mit ebenfalls rund 45 beteiligten Kolleg*innen überführt, strukturell angelehnt an die Arbeitspakete des Einführungsprojektes und ergänzt um einen Lenkungskreis (vgl. Abb. 3).
Aus dem „Servicepunkt Dezentrale Bibliotheken“ wurde die Abteilung “Alma Services” im Dezernat Wissenschaftliche Bibliotheksdienste. Die Kolleg*innen in den Arbeitspaketen (AP) werden jetzt mit unterschiedlichen Stundenanteilen in den AP eingesetzt, sind aber weiterhin organisatorisch in ihrer "eigentlichen" Abteilung verortet.
Kommunikativ hielt das Projekt direkt zu Beginn eine große Herausforderung bereit: Nicht ALLE Bereiche waren anfänglich gleichermaßen betroffen. Es herrschte allerdings schon Unruhe. Der Wind of Change trug dies und das über die Flure. Es gab jedoch noch wenig Konkretes, was man vorstellen konnte. Klare Kommunikations- und Dokumentationsstrukturen waren daher gefragt.
Lessons learned
Flexibel bleiben! Was auf dem Papier zunächst gut klang, erwies sich in der Praxis zum Teil als sinnlos. Theoretische Überlegungen aus dem Vorfeld mussten von den Expertinnen in den Abteilungen und Arbeitspaketen mit Inhalten gefüllt und agil angepasst werden.
Übergreifende Teams (abteilungs-/dezernats-/bibliotheksübergreifend) waren extrem wichtig, nicht nur für die Fachkenntnisse, sondern auch für das gegenseitige Verständnis und das Gefühl, nicht nur "wahrgenommen", sondern "mitgenommen" zu werden. Das förderte die Sicht auf die vielfältige universitäre Bibliothekslandschaft als Gesamtsystem und ermöglichte den Vergleich der Bedürfnisse und Möglichkeiten sowohl dezentral als auch zentral.
Gutes Projektmanagement steht und fällt mit der Kommunikation. Daher gab es bereits früh in der Vorprojektphase, Ende 2019, einen Workshop zum Fragenkomplex “Wie kommunizieren wir wann wo mit wem worüber?”. Neben Inhalten für die diversen internen Zielgruppen galt es auch, Informationen an extern Betroffene transparent zu veröffentlichen.
Für die Kommunikation stand ein ganzes Arsenal an Kanälen zur Verfügung. Das war gut, um unterschiedliche Informationsgewohnheiten bedienen zu können, wurde aber auch als unübersichtlich und unpraktisch wahrgenommen:
ExLibris und das hbz stellten die Projektmanagementplattform Basecamp, das System Salesforce, zwei hbz-Wikis, ein Ticketsystem und für Online-Besprechungen Webex, GotoMeeting, Circuit und Zoom bereit;
dazu gab es innerhalb der ULB ein allgemeines Alma-Wiki, Mattermost als Chat-Programm, "Alma-Telegramme" und längere Berichte im ULB-internen Blog sowie sogenannte “Galerievorträge”3 vor Ort und online;
das Projektteam nutzte zudem ein internes Wiki und Netzlaufwerke, teameigene Mattermost-Kanäle und ein Ticketsystem (OTRS) für die zentrale Projekt-Mailadresse;
Informationen für die ULB-Nutzerschaft wurden – zum Teil auch auf Englisch – über die Website, Nachrichtenmeldungen und den ULB-Newsletter ausgespielt.4
Während Zoom seit Corona-Zeiten an der Universität Münster breit bekannt war, erfuhren die zu Projektstart bereits schon länger verfügbaren Wikis (via Confluence) und Mattermost durch die Nutzung im Projektkontext eine deutlich verstärkte Anwendung. Dabei wurde von den Kolleg*innen z. T. eine steile Lernkurve verlangt.
Mit der Zeit ergaben sich Redaktionsrichtlinien z. B. für das Messengersystem: Es ist gut geeignet, um schnell etwas zu fragen oder zu diskutieren, aber sich daraus ergebende Informationen, die dauerhaft verfügbar sein müssen, sind im Nachgang im Wiki zu dokumentieren. Es gab auch im Nachhinein banal erscheinende Erkenntnisse wie: Es wäre gut gewesen, die Confluence-Schulungen eher am Anfang als am Ende der Projektlaufzeit durchzuführen.
Im Workshop zur Projektkommunikation waren vorab eine Liste aller Interessengruppen sowie folgende Aspekte erarbeitet worden, die auch für unsere weiteren Projekte relevant blieben:
Transparente, sachliche und kontinuierliche Kommunikation in alle Richtungen,
Möglichkeit für Feedback und Austausch innerhalb der Teilprojektteams sichern,
aufpassen, dass niemand durchs Raster fällt,
kurzfristige Erfolge explizit benennen,
verschiedene Kanäle parallel bedienen.
Sehr hilfreich um den Überblick zu behalten und Texte passend vorbereiten zu können, war eine Tabelle im Wiki, die meilensteinartig auflistete, was wann von wem an wen kommuniziert sein musste.
Eine ebenfalls viel genutzte Wiki-Seite war eine, die sich erst nach und nach entwickelt hat: Eine zentrale Auflistung aller Alma-relevanten Termine mit Datum, Veranstaltungstitel, Meeting-Link und Zielgruppe (vgl. Abb. 6).
Lessons learned
Die internen und externen Zielgruppen für Informationen rund um ein Projekt sollten möglichst frühzeitig überlegt und definiert werden. Analog zu Projekt-Meilensteinen sollten Kommunikations-Meilensteine festgelegt werden, die sich gut vorbereiten lassen.
Bereits vorhandene Kommunikationskanäle sollten daraufhin geprüft werden, ob sie alle benötigten Aspekte und Interessengruppen abdecken oder noch ergänzt werden sollten. Dafür und ggf. für von außen hinzukommende Tools muss Zeit für Einarbeitung und Schulung vorgesehen werden für die Kolleg*innen, die damit bislang noch nicht oder nur wenig gearbeitet haben.
Kleine Einfälle können sich als sehr hilfreich herausstellen, wie z. B. eine zentrale Übersicht über Termine mit Zugangsdaten und Zielpublikum. Unabdingbar: eine regelmäßige Überprüfung, welche Informationsbedürfnisse sich ggf. mit fortschreitendem Projektverlauf noch ergeben und wie sie zügig adressiert werden können.
Gute Wiki-Systeme bieten Möglichkeiten, sich auf dem Laufenden zu halten, z. B. durch ein abgestuftes System von Benachrichtigungsmöglichkeiten zu inhaltlichen Änderungen. Sie erlauben das Reagieren auf Entwicklungen und Erkenntnisse während der Projektlaufzeit, beispielsweise durch leichtes Umstellen von Wiki-Bereichen oder Verschieben von Seiten, ohne dass Verlinkungen auf der Strecke bleiben.
Für das Münsteraner Alma-Projekt hat sich der Luxus eines eigenen Projektbüros mit zwei (anteiligen) Kolleg*innen bezahlt gemacht: Es gab damit eine zentrale Stelle für den Überblick über alle Projektbereiche sowie für die Kommunikation ins Haus und an die Nutzer*innen. Das Büro etablierte eine niedrigschwellige Austausch-Instanz und lenkte alle Anfragen auf eine zentrale E-Mail-Adresse.
Seit dem GoLive gehen alle Anfragen an ein Ticket-System, in dem sie thematisch gezielt den jeweils zuständigen Projektteam-Kolleg*innen zugeordnet werden. Aus den Fragen resultierende allgemeingültige Erkenntnisse werden dokumentiert und ggf. zeitnah veröffentlicht.
Wenig in Anspruch genommen wurde hingegen die eigens eingerichtete Telefon-Hotline zur akuten Beantwortung auftretender Fragen während der ersten Schritte mit Alma.
Lessons learned
Bei großen Projekten kann ein Projektbüro, das die Projektleitung für Koordinierungs- und Kommunikationsaufgaben unterstützt, sehr hilfreich sein.
Die Nutzung einer zentralen (Projekt-)Mailadresse für Fragen aller Art in Verbindung mit einem thematisch strukturierten Ticket-System hilft bei der gemeinsamen und damit schnellen Beantwortung von Anfragen und dem Aufbau einer gemeinschaftlichen Wissensbasis.
Wenn Kommunikationskanäle nicht genutzt werden, darf man sie schließen.
Mit der Inbetriebnahme eines neuen Systems ist die Arbeit keineswegs getan, sondern sie geht dann oft erst richtig los.
Daher war es uns wichtig, das Ende des Einführungsprojektes als solches zu markieren, um es auch mental abschließen zu können, bevor es dann in die nächste Alma-Phase ging. Mehr zu dieser Abschlussbesprechung weiter unten. Eine Kommunikationserkenntnis daraus war: Ein „Zielfoto“ ist unbedingt notwendig, das die gewünschte Situation nach Abschluss des Projektes formuliert. Wir hatten zwar die Erwartung “Alma läuft”, aber es wäre gut gewesen, wenn wir im Vorfeld eine genauere Zielformulierung auch mit Blick auf unser Leitbild5 erarbeitet hätten.
Aber auch eine im Projektverlauf immer weiter verbesserte Kommunikationsstrategie kann nicht verhindern, dass sich dann und wann ein Gefühl von "Das wird mir zu viel! Was soll ich denn sonst noch alles lesen? Betrifft mich das überhaupt?!” einstellt. Neben einer klaren Definition von Zielgruppen und Kanälen ist hier auch ein gewisses Maß an Frustrationstoleranz und Gelassenheit aller Beteiligten notwendig: Man muss unterscheiden zwischen “wichtige Dinge auch mehrfach kommunizieren” und “diese Mailbenachrichtigung ist für mich nicht relevant, aber ich lösche sie einfach, statt mich darüber aufzuregen”.
Lessons learned
Man kann kaum zu viel kommunizieren. Eine umfassende Kommunikation, die Ängste nimmt, Sicherheit und Verlässlichkeit mit sich bringt und Transparenz schafft, hilft, unabdingbare Veränderungen und Herausforderungen gut, gesund und sogar weiter motiviert zu überstehen.
Dennoch bedarf es einer gewissen Gelassenheit, sich gerade in komplexen Projekten nicht überfordert zu fühlen.
Ein „Zielfoto“ kann dabei helfen, an das Ziel zu erinnern: Wie soll die Gesamtlage nach Erreichen des Projektendes aussehen?
Unser Kurs für die Schulungen zur Einführung von Alma war festgelegt: Alma, Regelwerke, Datenformate, vorhandene personelle Fähigkeiten und Ressourcen. Das Ausrollen der Inhalte verlangte von uns aber einiges an Kreativität und Improvisation.
Das erste Konzept, das wir für die Entwicklung und Durchführung hatten, war ein eklatantes Beispiel für “in der Theorie geplant und an der Praxis gescheitert”. Zu viel Zeit wurde am Anfang mit sehr allgemeinen Überlegungen – wie z. B. Nutzen wir geschlechtergerechte Sprache? Benötigen wir barrierefreie Dokumente? – vertan, woraus sich am Ende immenser Zeitdruck ergab. Auch hier haben sich diverse Teams bestehend aus erfahrenen Schulenden und neuen Kolleg*innen und ihren frischen Sichtweisen bewährt. Ganz praktisch wurden die einzelnen Schulungsmaterialien in kleineren Teams entwickelt. Es erfolgte eine Aufteilung in Module (z. B. Ressourcenerfassung, Erwerbung, Benutzung). Erstellt wurden vertonte Präsentationen mit Handouts, Übungsaufgaben und Selbstlernmaterialien.
Generell mussten sich alle zukünftigen Alma-Nutzenden nicht nur an eine komplett neue Oberfläche gewöhnen, gleichzeitig galt es, sich auch mit den MARC-Feldern vertraut zu machen, weil in SISIS/Aleph bislang mit MAB gearbeitet worden war.6 Schnell kristallisierte sich heraus, dass die neue Komplexität zu einer größeren organisatorischen Änderung führen würde: Ab der Alma-Einführung wird, wie bereits erwähnt, nur noch durch bibliothekarisches Fachpersonal katalogisiert und nicht mehr auch durch geschulte studentische Hilfskräfte.
Die von ExLibris im “Knowledge Center” zur Verfügung gestellten Materialien waren nur als Orientierung nutzbar, nicht aber als adaptierbare Unterlagen, denen nur einige lokale Besonderheiten hinzugefügt werden müssten. Es gab im Vorfeld einen Zeitplan, bis wann die Kolleg*innen sich welche Materialien ansehen sollten. Das führte allerdings zu Verwirrung, da die Informationen oft sehr allgemein gehalten waren und somit nicht zu unseren lokalen Workflows passten. Sie konnten auch nicht ausprobiert werden, da die für uns konfigurierte Sandbox erst spät verfügbar war. Dies verzögerte auch die Möglichkeit, spezifische Schulungsunterlagen für unsere Alma-Installation zu erstellen.
Videokonferenzen und Webinare sind seit Corona tägliche Praxis. Trotzdem steckte der Teufel im Detail: Unter Zeitdruck war die Verzweiflung über störrische Mikrofone und die Tücken von Videoaufzeichnungen zum Teil groß.
Ungeachtet dessen konnten viele eigene, gut nutzbare Schulungsvideos erstellt werden. Sie wurden zu festen Terminen "abgespielt", um Abhängigkeiten von der Verbindung zur Sandbox zu vermeiden, mit der Möglichkeit im Anschluss Fragen zu stellen. Ergänzend wurden "Nachsorgetermine" angeboten, die sich mit den Anliegen beschäftigten, die sich aus dem Probieren und Üben ergaben.
Zusätzlich zu den Informationen im Wiki gab es einen großen Wunsch nach abgeschlossenen Dokumenten in Form von Handouts mit Screenshots und Beispielen, die dem Stand der Präsentationen entsprachen und in denen man sich Notizen machen konnte. Die Videos konnten auch den Kolleg*innen zur Nachbereitung dienen, die an den Präsentationsterminen nicht teilnehmen konnten oder sich bestimmte Aspekte noch einmal anschauen wollten.
Die Videos und Anleitungen sind weiterhin im internen Bibliothekswiki abrufbar, und sie werden durch die Teams der jeweiligen thematischen Arbeitspakete aktuell gehalten. Dort werden auch die Schulungsunterlagen fortgeschrieben und z. B. für die Einarbeitung neuer Kolleg*innen genutzt.
Lessons learned
Das Thema Schulung von Anfang an mitdenken und nicht einfach nur "ans Ende hängen"! Das Erarbeiten von Materialien dauert IMMER länger als man denkt und ist oft auch komplexer als geplant.
Bereits im Vorfeld sollte man sich gutes technisches Equipment und Menschen suchen, die souverän damit umgehen können.
Die Akzeptanz eines neuen Systems steht und fällt mit dem Gefühl, "gut geschult und vorbereitet" zu sein.
Mit der Einführung ist es noch nicht vorbei. Schulungsbedarfe müssen auch "für nach der Einführungsphase" bedacht werden: Neu ins Team kommende Kolleg*innen, Änderungen im System oder neu zu entwickelnde Workflows in der Einrichtung verlangen nach passenden Materialien.
Schulungsunterlagen aus Verbünden oder anderen Häusern sind kaum 1:1 nachnutzbar: Lokale Rahmenbedingungen und Festlegungen müssen berücksichtigt werden, Strukturen von Anleitungen sollten einheitlich sein usw. Normierte Vorlagen erleichtern die Orientierung und den Überblick.
Während unserer gemeinsamen Reise haben wir in Gesprächen mit den Kolleg*innen nicht nur über Bestellkatalogisate, Überordnungen oder Ausleihkonditionen nachgedacht, sondern immer wieder auch über “das Große Ganze”: Wo stehen wir, was läuft gut, wo stottert es, und wie geht es uns dabei?
Um solche Rückmeldungen und auch die vielen einzelnen Ideen zu “was man beim nächsten Mal besser machen könnte” sammeln und auswerten zu können, aber auch, um uns zu vergegenwärtigen, dass das Projekt zur Einführung beendet ist, gab es zum Ende der Laufzeit eine Abschlussbesprechung. Nach einem Rückblick auf das Geschaffte hatten alle Mitglieder des Projektteams im Sinne eines Debriefings die Gelegenheit, sich zu einigen vorgegebenen Fragen, aber auch ganz allgemein zu äußern.
Viele Kolleg*innen berichteten von sehr hoher und z.T. ungleichmäßig verteilter Arbeitsbelastung sowie Zeitdruck und Informationsflut für alle Beteiligten. Dem stand positiv gegenüber, dass sich die Zusammenarbeit im Projektteam gut entwickelt und dass die Zusammenarbeit von Kolleg*innen aus dezentralen Bibliotheken und Zentralbibliothek das “Zusammenwachsen” zu einem Bibliothekssystem7 befördert hat. Dadurch ergibt sich ein angenehmeres Arbeitsklima auch für Aspekte und Projekte jenseits von Alma. Allerdings hat die Zeit seit dem GoLive auch gezeigt, dass diese Beziehungen nicht einfach “jetzt so da” sind, sondern weiter gepflegt werden müssen, um nicht wieder in das alte Muster “die ULB vs. die Institutsbibliotheken” zurückzufallen – daher nun die Bezeichnungen “Zentralbibliothek” und “dezentrale Bibliotheken”.
Eine weitere Erkenntnis sollte ebenfalls immer im Hinterkopf bleiben: “Schnelle Lösungen sind nicht immer die schlechtesten”. Während in der Alma-Projektlaufzeit der Zeitdruck dafür gesorgt hat, dass bibliothekarischer Perfektionismus nicht ausgelebt werden konnte, müssen wir uns daran jetzt manchmal erinnern, uns mutig zu trauen, “einfach mal zu machen”.
Und manchmal müssen wir es uns gestatten, Feierabend zu machen, auch wenn ein für den Tag geplantes Aufgabenpaket noch nicht abgearbeitet ist: Würde etwas Dramatisches passieren, wenn etwas erst am nächsten Arbeitstag erledigt wird?
Um in Workshops und Besprechungen unkompliziert, umfassend und trotzdem schnell und kreativ Aspekte zu sammeln, haben sich agile Methoden z.B. aus dem Design Thinking bewährt.
Um wertschätzend zu verdeutlichen, dass das Alma-Einführungsprojekt geschafft und etwas “Erinnerungswürdiges” war, erhielten die Mitglieder des Projektteams bei der Abschlussbesprechung einen Becher mit der “Maskottchen-Kuh” Alma mit Lorbeerkranz. Zum “Einjährigen” des GoLive, an dem auf die ersten 12 Monate praktischer Arbeit mit Alma zurückgeschaut wurde, gab es eine Glasdose mit Holzdeckel, den eine “Geburtstags-Alma[-Kuh]” ziert. Die Überraschung mit diesen (z. T. privat aus der Projektleitung finanzierten) “Memorabilia” ist gelungen, und sie fungieren im Büro oder auch zu Hause als positive Erinnerung an das gemeinsam Geschaffte.
Ach, und Alma läuft auch gut. Manches erfordert "mehr Schritte" als früher, aber Alma ermöglicht eine dem jeweiligen Bibliothekssystem angepasste Konfiguration, außerdem sind z. B. Auswertungen sowie Listen für den Arbeitsalltag einfacher zu erstellen, und die Verfügbarkeit von Medien (auch dezentral) ist transparenter darzustellen.
Allerdings mussten wir uns daran gewöhnen, dass es nicht, wie früher, erst einmal eine "stabile Phase" gab mit der eingeführten Software-Version, sondern dass ständig Bewegung im System ist durch die regelmäßigen Alma- und PrimoVE-Releases und die damit verbundenen Tests, Implementierungen und Anleitungsüberarbeitungen. Diese Unruhe muss man aushalten können.
Lessons learned
Ein Debriefing am Ende eines Projektes ist wichtig, um gemeinsam positive und negative Erfahrungen zusammenzutragen und mental abschließen zu können, bevor es ins Tagesgeschäft oder in ein nächstes Projekt geht.
Nicht nur in zeitkritischen Kontexten kann es sich lohnen, “einfach mal zu machen”, statt langwierig aufwendige Lösungen zu entwickeln: Mut haben, auch mit zunächst nicht perfekten Konzepten an den Start zu gehen und sie dann weiterzuentwickeln. Im Werkzeugkoffer des Agilen Arbeitens finden sich für jedes Team hilfreiche einzelne Methoden, ohne gleich die gesamte Arbeit auf New Work umstellen zu müssen.
Kleine Aufmerksamkeiten zwischendurch – und sei es nur “Süßkram” – können dazu beitragen, dass sich die Kolleg*innen “gesehen” und wertgeschätzt fühlen, auch wenn der Workload dadurch nicht reduziert werden kann.
Bei großen Projekten kann ein “Erinnerungsstück” an die gemeinsam durchgemachte Zeit zum Wir-Gefühl beitragen.
Das regelmäßige Erstellen von Screenshots und Fotos während einer Projektlaufzeit – bei Meilensteinen und auch einfach mal zwischendurch – erleichtert Dokumentationen und Rückblicke.
Transparenz zu Arbeitsbelastungen auch nach dem Ende eines Projektes kann helfen, Unverständnis und Unmut anderer Kolleg*innen z.B. über längere Rückmeldezeiten zu vermeiden.
Auch wenn unser Projekt ein gutes Ende gefunden hat, muss festgehalten werden, dass die Arbeitslast unterschiedlich verteilt war, dass alle Beteiligten beunruhigt waren und dass einige Kolleg*innen an ihrer Belastungsgrenze gekommen sind und manchmal auch darüber hinaus.
In den rund drei Jahren seitdem haben wir einen stabilen Routinebetrieb mit Alma erreicht. Das Fahrwasser ist also ruhiger, aber natürlich herrscht schon allein aufgrund der regelmäßigen Alma-Updates nie Flaute.
Was haben wir aus der “Projekt-Welle” in diesen Routinebetrieb mitgenommen?
Einen übersichtlichen und vertrauten Werkzeugkoffer,
das gewachsene Verständnis und Vertrauen innerhalb des Teams,
die praktische Vernetzung über das gesamte Bibliothekssystem,
aber auch das Bewusstsein dafür, wie schnell man in alte Gewohnheiten zurückfallen kann
sowie drei Erkenntnisse:
dass Oberflächen und Abläufe in Alma nie vollständig für längere Zeit stabil sein werden und man also flexibel bleiben muss,
dass auch im Alltagsbetrieb ab und an ein Innehalten zum Rückblick auf das Erreichte und zur Anerkennung von Zwischenerfolgen wichtig ist, statt immer nur auf das noch nicht Erreichte zu schauen,
und dass alles leichter wird mit einer guten Prise Humor!
Lessons learned
Lernen Sie aus Ihren Fehlern, und machen Sie dann neue. :)
o-bib Das offene Bibliotheksjournal
ISSN: 2363-9814
