![[Zettelkatalog]](../../images/jetta.jpg)
1. Ein Blick auf die Geschichte
Am 1. Oktober wird die Library of Congress (LC) einen weiteren Meilenstein in ihrer 200-jährigen Geschichte erreichen. Nach über zwei Jahren Vorbereitung sind zur Zeit hunderte von Mitarbeitern dabei, ein kommerzielles integriertes Bibliothekssystem zu implementieren. Das von der Bibliothek erworbene System Voyager von Endeavor Information Systems Inc, intern kurz ILS (Integrated Library System) genannt, bringt die Bibliothek gerade noch rechtzeitig vor dem Ende des 20.Jahrhunderts auf einen modern technologischen Stand. Durch den Einsatz eines modernen Client Server Systems erhofft sich die LC Produktivitätssteigerungen und Arbeitsflussverbesserungen, um weiterhin ihrer Doppelrolle als Bibliothek des amerikanischen Kongresses und Nationalbibliothek gerecht zu werden.
1. Ein Blick auf die Geschichte
Die Library of Congress wagte als eine der ersten Bibliotheken Anfang der 70er Jahre den Sprung in die Automatisierung. Eigenentwicklungen waren damals die Norm und wie andere grosse amerikanische Bibliotheken (Harvard University, Hollis System; University of California, Melvyl) benutzt die LC ihr mit IBM Grossrechnern arbeitendes MUMS System noch heute.
Nach jahrelangem Argumentieren, dass aufgrund ihrer Grösse, Komplexität und speziellen nationalbibliothekarischen Bedürfnissen kein kommerzielles System den Anforderungen gerecht werden würde, wird nun endlich ein integriertes System installiert.
Wie bei vielen anderen Bibliotheken, die zur Zeit in neue Soft- und Hardware investieren, gibt es politische und vor allem technische Gründe für den Sinneswandel.
In der Library of Congress bereitete eine Reorganisation das politische Umfeld, aber wenn nicht das Jahr 2000 Problem (Y2K) am Horizont erschienen wäre, würde es wohl noch einige Jahre dauern, bis das Projekt intern die nötige Unterstützung vom schwerfälligen Beamtenapparat bekäme. Die Bibliothek präsentierte das Projekt dem Kongress und erhielt 1998 die finanziellen Mittel, um das Unternehmen in Gang zu setzen.
Seit Beginn der Computerisierung der LC arbeitet die Bibliothek mit IBM Hardware. Neben mehreren Grossrechnern betreibt sie RS6000 und einige Sun Server. Ende der 80er Jahre wurde zum Erstaunen vieler das Betriebssystem OS/2 gewählt, welches bis heute parallel zu Windows benutzt wird. In der Katalogisierung und Erwerbung werden beispielsweise "bibliographic workstations" unter OS/2 benutzt, aber viele Mitarbeiter benutzen Windows für Textverarbeitung, etc.
Auf der IBM Plattform wurden im Laufe der Jahre mehrere Applikationen entwickelt, um den speziellen Bedürfnissen der verschiedenen Abteilungen gerecht zu werden. Einige Produkte, z.B. in der Katalogisierung, waren für die damalige Zeit hervorragend, nur eines gelang der Library of Congress nicht: die einzelnen Softwareprogramme zu integrieren. Bis heute funktionieren mindestens drei Systeme isoliert voneinander; die Automatisierung der Zeitschriftenabteilung scheiterte nach einigen Versuchen vollständig.
Eine Folge dieser dezentralen Automatisierung ist u.a., dass der Katalog der LC keine Bestandsdaten verzeichnet, da die Datenbank weder USMARC-Holdingsrecords noch Itemrecords besitzt. Der Bibliotheksnutzer kann bei einer Suche im Katalog nicht ersehen, ob ein Titel ausgeliehen ist, oder welche Nummern einer Zeitschrift wirklich eingegangen sind.
Alles begann 1971 mit MUMS (Multiple-Use MARC System), welches die Katalogisierungsabteilung benutzt, um in einem LC internen MARC Format zu katalogisieren. MUMS arbeitet mit einer komplexen Befehlsstruktur und ist zum internen Gebrauch gedacht. 1975 wurde für das Publikum Scorpio entwickelt, eine Applikation, welche dem Benutzer erlaubt, nicht nur Autoren oder Schlagworte zu finden, sondern im Katalog über "browse" Befehle zu blättern.
Während in der Katalogisierung mit sog. "bibliographic workstations" versucht wurde, zumindest die Dateneingabe zu modernisieren, wurden für die Benutzer einige interessante, moderne Applikationen und bessere Oberflächen für die Grossrechnerprogramme geschaffen. Der Katalog ist über das Internet suchbar (www.loc.gov) und mit Hilfe einer Volltextsuchmaschine von Inquery wurde ein hochkarätiger Internet Experimental Search Catalog produziert, der mit Keyword Search und Relevance Ranking Faktoren arbeitet (http://lcweb2.loc.gov/resdev/ess/). Inquery Softeware wird ebenfalls für Recherchen in den Datenbanken der National Digital Library benutzt (http://memory.loc.gov/). Wie und ob diese Anwendungen in das ILS integriert werden, steht noch offen.
Ebenfalls in den 70er Jahren wurde die Erwerbungsabteilung automatisiert. Ein Lochkartensystem diente der Dateneingabe und eine terminalbasierte Textverarbeitung wurde hinzugefügt.
Mitte der 80er Jahre begannen Vorbereitung für eine Ablösung der Lochkarten, aber es dauerte bis im November 1993, als endlich das neue (und leider technisch schon wieder veraltete) Acquiresystem eingeführt wurde. Wie so oft, wenn innerhalb eines schwerfälligen Verwaltungsapparates Technologie entwickelt wird, wurde Acquire für den IBM Grossrechner entwickelt, während gleichzeitig in der Softwareindustrie der Umbruch von Grossrechnern zu Client Server Computern stattfand.
Für die Ausleihe wurde 1988 ein wiederum in sich geschlossenes eigenständiges System entwickelt. Rund 200'000 Einheiten zirkulieren pro Jahr, ein Grossteil davon wird innerhalb der Bibliothek ausgeliehen. Die Library of Congress ist keine Leihbibliothek, die Sammlungen werden nur an den Kongress verliehen. Die Ausleihe verzeichnet deswegen eine relativ kleine Zahl von etwa 16'000 Nutzern.
Die Zeitschriftenverwaltung ist ein Thema, über welches man in der LC nicht gerne spricht, denn bis heute arbeitet die Abteilung manuell mit einem Kardex. Im Zuge einer der vielen dezentralen Automatisierungsvorstösse wurde zwar ein Teil der Information aus dem Kardex in jahrelanger Arbeit in eine Computerdatei konvertiert und das sogenannte SERLOC File im MUMS System entstand. SERLOC ist eine Standortdatenbank. Die Aufnahmen enthalten Zeitschriftentitel, welche in der Bibliothek vorhanden sind, ebensowie ausgesonderte Titel und Titel, die von der LC nicht für die Sammlung ausgewählt werden. Des weiteren existiert ein MUMS Serials File, bestehend aus Daten die vom Cooperative Online Serials (CONSER) Program in OCLC jede Woche in die LC Datenbank geladen werden. Diese Datenbank enthält Datensätze der LC ebensowie anderer Bibliotheken.
2. Die Suche nach einem integrierten System
Vor diesem Hintergrund stürzte sich die Library of Congress vor ca. zwei Jahren ernsthaft in das Unternehmen ein kommerzielles integriertes Bibliothekssystem zu erwerben. Wie kam es dazu, dass schlussendlich der Versuch, die dezentralen Teile miteinander zu verbinden oder selbst ein neues System zu entwicklen, aufgegeben wurde?
Teile der Bibliothek hatten schon seit Jahren versucht, nicht mehr selbst zu entwickeln, sondern Expertenwissen in der Form eines Systems zu kaufen. Verschiedene Vorstösse scheiterten jedoch an politischen und teilweise systemtechnischen Problemen. Bis vor kurzem war wahrscheinlich keiner der amerikanischen Systemanbieter wirklich in der Lage, ein für die Grösse der LC adäquates System anzubieten.
Der wichtigste Grund für die Richtungsänderung war jedoch schlussendlich ein externer Faktor: das Jahr-2000-Problem (Y2K). Die Programme der Bibliothek sind alle nicht Y2K kompatibel. Einige Programme, v.a. Datenbanken des Congressional Research Service, wurden Y2K-fähig gemacht; die reorganisierte Bibliothek beschloss jedoch, die veralteten und proprietären IBM-Programme durch ein neues System zu ersetzen. Innenpolitisch setzte sich ein neues Herangehen an kommerzielle Systeme durch. Barbara Tillett, die Leiterin des ILS Projekts, beschrieb es mit den Worten: "Wir sind nicht so sehr anders als andere wissenschaftliche Bibliotheken, wir sind nur sehr viel grösser."
In den 80er Jahren scheiterten verschiedene Vorstösse ein integriertes System zu erwerben an innenpolitischen Schachzügen. Einer der Pläne, die Notis Software (entwickelt an der Northwestern University in Chicago) in der Zeitschriftenabteilung einzusetzen, wurde nach umfänglichen Tests aufgrund technischer Probleme nicht weiterverfolgt. Der Versuch eine eigene Zeitschriftenverwaltung zu entwickeln wurde schlussendlich ebenfalls aufgegeben.
Vor ca. zwei Jahren begann eine Gruppe unter der Leitung von Barbara Tillett ein Request for Proposal (ein Pflichtenheft) mit Anforderungen an ein Bibliothekssystem zu entwickeln. Dieses RFP definierte klar, dass die Bibliothek ein Client Server System suche. Aus der Ausschreibung wurde ebenfalls sehr deutlich, dass die Bibliothek erwarte, ein fertigentwickeltes und bei Kunden bereits installiertes System zu kaufen. Da die Library of Congress durch das Y2K Problem unter enormen Zeitdruck gekommen war, beschrieb das RFP ausdrücklich, dass man nicht gedenke, ein System, welches sich in der Entwicklung befindet, zu erwerben.
Das Dilemma, in das die Bibliothek dadurch geriet, wurde schnell offensichtlich:
Als die Library of Congress im Juli 1997 ihre Ausschreibung öffentlich machte, gab es auf dem amerikanischen Markt tatsächlich nur ein einziges System, Voyager von Endeavor Information Systems, welches gross genug war und in einer Client Server Version alle Module fertigentwickelt und in Produktion hatte. Alle anderen grossen Anbieter sind nach wie vor dabei, entweder das Erwerbungsmodul zu entwickeln oder arbeiten an der Fertigstellung der Zeitschriftenkontrolle.
Teile der Library of Congress waren besorgt, man könnte sich mit einem RFP leicht aus dem Markt herausdefinieren. Die Grösse der Bibliothek reduzierte das Feld der Bewerber und man hoffte, dass am Ende trotzdem eine gute Auswahl möglich würde.
Der Systemanbietermarkt in den USA ist relativ klein, man kennt die Anbieter, und wie erwartet, bewarben sich alle mittelgrossen und grossen Firmen. Es ist nicht bekannt, welche Firmen in der Endauswahl landeten, aber es ist mittlerweile durch die Anbieter selbst bekannt geworden, dass unter den im Wettbewerb vertretenen Firmen, Namen wie DRA, CGI, VTLS und Endeavor waren.
Ohne Kenntnis der Auswahldetails, genügt ein Blick auf die Situation der o.g. Firmen, um festzustellen, dass diese Systeme nicht ebenbürtig sind. DRA z.B., ist nach wie vor dabei am neuen System Taos zu arbeiten, Zeitschriftenkontrolle und Erwerbung sind noch nicht in Produktion. Dies konnte Bibliotheken wie die Unversity of California und Harvard allerdings nicht davon abhalten, das System zu kaufen. Die Library of Congress jedoch setzte strengere Kriterien für ihre Auswahl fest.
CGI ist in einer ähnlichen Situation und das neue System ist noch nicht in der British Library in Betrieb. VTLS ist in einer noch schlechteren Position und versucht seit vier Jahren erfolglos das Client Server Virtua fertigzustellen.
Endeavor Information Systems ist nach wie vor die einzige amerikanische Firma, welche ein Client Server System vertreibt, das in grossen wissenschaftlichen Bibliothek in Produktion ist. Aber Endeavor hatte es einfacher als alteingesessene Firmen, die Kunden mit alten Systemen unterstützen müssen. Die Firma wurde 1995 neugegründet und hat Voyager dadurch von Grund auf ohne Altlasten entwickeln können.
Aufgrund ihres rigorosen Zeitplans und dem Ziel, mit einem neuen System das Y2K Problem zu lösen, konnte es sich die Library of Congress nicht leisten, ein System ohne Erwerbung oder Zeitschriftenmodul zu kaufen. Die Bibliothek hat dem Kongress (dem Geldgeber für das Grossunternehmen) versprochen, am 1.Oktober mit dem neuen System in Produktion zu gehen.
In einer strengen Auswahlprüfung wurden so die Anbieter einem Systemtest unterworfen, der es verdient, als einer der kompetentesten und besten Tests in die Geschichte der Bibliotheksautomatisierung einzugehen.
Normalerweise ist es relativ einfach für Firmen bei Systemdemonstrationen Teile, die noch nicht richtig funktionieren, zu "verbergen", so dass der Eindruck entsteht, das ganze System arbeite perfekt. Nicht so beim Test der Library of Congress. Jeder Anbieter musste die gleichen Arbeitsschritte vorführen und es war nicht erlaubt, geplante oder in Entwicklung stehende Teile zu zeigen. Damit wollte die Bibliothek erreichen, dass nur ein System mit voll funktionsfähigen Modulen ausgewählt wird.
Am 15. Mai 1998 wurde schliesslich der Automatisierungsauftrag an Endeavor Information Systems, Inc. vergeben. Endeavors Bibliothekssystem Voyager ist eine Client Server Anwendung. Die Client Software arbeitet mit Windows, die Serversoftware läuft auf einer Sun Plattform unter Unix. Oracle wird für die Datenbank benutzt.
Die Bibliothek hat das Voyager System intern in ILS (integrated library system) umbenannt und im August 1998 wurde ein temporäres ILS Program Office mit der Planung und Installation des Systems beauftragt. Barbara Tillett leitet das Projekt, welches die Computerumgebung für rund dreitausend Mitarbeiter von einer Grossrechner betriebenen OS/2 Welt auf Windows und ILS Software umstellt.
16 Vollzeitmitarbeiter arbeiten im ILS Program Office. Sie leiten und koordinieren Mitarbeiter in einem komplexen Projektmanagement. Die Struktur des ILS Programms ist in Abbildung 1 (97kb) dargestellt. 76 Implementationsteams arbeiten in einer Matrix bestehend aus rund 560 Mitarbeitern.
Das Projektmanagement läuft unter dem Zeichen "facilitative management", wo - im Gegensatz zu einem "top-down approach" - eine grosse Zahl von Mitarbeitern jeglicher Hierarchiestufe in die Planung und Entscheidung direkt einbezogen werden. Nach Abschluss der Installation Anfang Oktober werden die Projektgruppen aufgelöst. D.h. so einfach gestaltet sich das Ganze nur nach dem Management-Lehrbuch. Viele der notwendigen Arbeitsflussänderungen können aufgrund von Zeitmangel erst nach der Systeminstallation angegangen werden. Aufgrund dessen werden eine Reihe von Gruppen entweder weiterbestehen oder werden umformiert und müssen sich dann an die sogenannten BPI, die "business improvement processes" machen.
Hier zeigt sich ein weiteres Dilemma des Unterfangens: Der gegenwärtige Arbeitsfluss (basierend auf einem Grossrechnersystem) wird mehr oder weniger direkt in ein windowsbasiertes, modernes System übertragen. Viele überkommene und unnötig komplizierte Arbeitsschritte werden so mit viel Schwierigkeiten in ein neues System gepresst. Gleichzeitig fehlt die Erfahrung mit dem neuen System, so dass man selbst wenn man die Zeit hätte, viele Arbeitsgänge nicht verbessern kann. Dadurch wird das erste Jahr der Produktionsphase zentral wichtig, denn nur durch die Implementierung eines verbesserten Geschäftsganges wird das neue System vollumfänglich ausgenutzt werden können.
Charakteristisch für Projektmanagement ist die Bildung von Arbeitsgruppen. Das ILS Programm Office, Abteilungsleiter, und Gewerkschaftsvertreter schlugen Mitarbeiter vor; gleichzeitig wurde aus einer grossen Gruppe von Freiwilligen ausgewählt. Das ILS Program Office hat sehr detailliert jeder Arbeitsgruppe vorgegeben, welche Teilbereiche analysiert und entschieden werden müssen. Die ganze ILS Installation wurde in hunderte von sog. "deliverables" (Terminvorgaben wann welche Entscheide, Berichte, Handbücher, usw. dem Programm Office geliefert werden) aufgeteilt.
Für viele Mitarbeiter bieten diese Arbeitsgruppen die Möglichkeit, vor Produktionsbeginn mit dem System vertraut zu werden und sich so zu qualifizieren. Aber wie zu erwarten macht sich jetzt, am Ende des Projekts, Stress bemerkbar. Die meisten Gruppenmitglieder haben ihr volles Arbeitspensum neben der Projektarbeit zu erledigen. Des weiteren hat die grosse Zahl von Gruppen zur Folge, dass Entscheidungsprozesse lange dauern, da es z.B. bei Uneinigkeit immer die Möglichkeit gibt, das Problem eine Stufe weiter zu schieben und in einer anderen Projektgruppe zu diskutieren. Die Methode des "facilitiative Management" impliziert, dass Entscheidungen mittels Konsens in der Gruppe getroffen werden sollen. Viele Mitarbeiter sind es aber nicht gewohnt zu entscheiden. Noch schwieriger gestaltet sich der Umgang mit dem vom ILS Program Office rigoros eingehaltenen Zeitplan. Beispielsweise werden oft bis in die letzte Minute Entscheidungen über Katalogisierungsdetails, etc., modifiziert und revidiert.
In Anbetracht der Grösse der Projekts ist es allerdings bemerkenswert, dass bis anhin keine Verzögerung auftrat und es sicher ist, dass mit Hilfe der hunderten von Mitarbeitern das System nach Plan am 1.Oktober vollständig in Betrieb genommen wird.
4. Ein Blick hinter die Kulissen
Zeitschriften und Erwerbung sind die kompliziertesten Teile jeder Bibliotheksinstallation und ein Blick auf die Details in der Library of Congress machen es deutlich:
Wie oben erwähnt, arbeitet die Zeitschriftenkontrolle manuell mit einem riesigen Kardex. Neben dem Kardex existiert zusätzlich ein alter Zettelkatalog, der zwar selten benutzt wird, aber nach wie vor für Konsultationen zur Verfügung steht (Abbildung 2). Die komplizierten Arbeitsvorgänge und die Masse von Zeitschriften, die hier verarbeitet werden, machen diese Abteilung (Serial Record Division) zu einem faszinierenden Studienobjekt (für die Autorin) und einer beruflichen Herausforderung und/oder einem Albtraum (für die LC Mitarbeiter, welche diesen Teil automatisieren müssen).
Die Zeitschriftenkontrolle wird am 1.Oktober wie alle anderen Teile der Bibliothek mit dem ILS arbeiten. Neuzugänge werden über das Serials Checkin Modul des ILS verarbeitet. Für die Zusammenführung der verschiedenen o.g. Datenbanken und v.a. für die Konversion der Kardex ist allerdings mehr Zeit eingeplant. Es wird erwartet, dass eine vollständige Automatisierung der Zeitschriften erst in einigen Jahren erreicht werden wird. Ein Blick auf die Fakten macht deutlich warum:
![[Kardex]](../../images/kardex.jpg)
Das grösste Problem bereitet die Zusammenführung der verschiedenen Datenbanken mit dem Kardex, da dadurch unzählige Dubletten entstehen werden. Weitere Diskussionspunkte bieten die vielen Standorte und wie die Bestandsnachweise mit der Hilfe des Holdingsrecord am besten verzeichnet werden können.
Eine Konversion des Kardex ist geplant und zur Zeit läuft eine Ausschreibung für den Auftrag. Es wird erwartet, dass eine Firma die Konversion in der Bibliothek selbst unternimmt, da der Kardex für Anfragen offen bleiben muss.
Insbesondere in der Erwerbung prallen zwei Welten aufeinander: komplexe Bibliothekssoftware und die über Jahre tradierten, komplizierten und verzweigten Arbeitsabläufe der Library of Congress.
Bibliothekare in den ILS Projektgruppen müssen entscheiden, wie der Arbeitsfluss mit dem neuen ILS laufen soll und die Arbeitsgänge werden bis ins kleinste Detail dokumentiert. Da diese Entscheidungen ohne lange praktische Systemerfahrung getroffen werden, entstehen oft paradoxe Situationen. ILS Handbücher werden geschrieben bevor die Projektgruppen endgültig über alle Details entschieden haben, und Entscheide, die vor Monaten getroffen wurden, sind kurz vor Produktionsbeginn plötzlich hinfällig.
Ein Grossteil der Neuerscheinungen aus publikationsreichen Ländern wird von den Lieferanten - in Deutschland Harrassowitz - unter einer Approval Plan Vereinbarung geliefert. Spezielle Publiaktionen werden über ein umfangreiches Tauschprogram gefunden und Überseebüros kaufen in einigen Teilen der Welt direkt ein. Wie bei den Zeitschriften stellt der Umfang und die Komplexität der Abteilung hohe Anforderungen an das ILS:
Im Januar wurden die ersten Tests für die Datenmigration von MUMS ins neue System begonnen und im Juli wurden 12 Millionen bibliographische Daten in den neuen Sun 10000 Server geladen.
Etwa 4 Millionen Autoritätsaufnahmen wurden vom MUMS Authority File in die relationale Datenbank des ILS migriert. Da das ILS nur mit lateinischer Schrift arbeitet, muss die Katalogisierung in Sprachen wie z.B. Chinesisch oder Japanisch bis auf weiteres mit RLIN und OCLC erfolgen. Die LC erwartet, dass in einer zukünftigen Version des ILS Unicode eingesetzt wird.
Wenn man als Library of Congress ein kommerzielles System kaufen will, stellt sich sofort die Frage der Skalierbarkeit. Es gibt nur wenige vergleichbar grosse Bibliotheken, und die meisten Bibliothekssysteme automatisieren Bibliotheken mittlerer Grösse und Katalogen von einigen Hunderttausend bis zu mehreren Millionen Titelaufnahmen. Der Sprung von einer Bibliothek mit vielleicht 4 Millionen Aufnahmen zu LC mit 12 Millionen und Tausenden von Mitarbeitern ist jedoch nicht zu unterschätzen.
Es ist vor allem die grosse Zahl von Personal in der Katalogisierung und Erwerbung und die Zahl der simultanen Benutzer (man rechnet mit 3000), welche die LC Installation so einzigartig machen. Hunderte von Bibliothekaren arbeiten an Titelaufnahmen und modifizieren Datensätze.
Nach langem Hin- und Her wurde die für die LC schwere Entscheidung gefällt, von der IBM Plattform abzuweichen und Sun Server zu installieren. Die LC benutzt zwar seit langem einige Sun Server, die Mehrzahl der Hardware sind jedoch IBM-Rechner.
![[Ultra Enterprise 10000 Server]](../../images/10001.jpg)
Die neue Hardware, ist ein Sun Ultra Enterprise 10000 Server (Abbildung 4) und zwei E3500 Sun Server. Die Ultra Enterprise Maschinen sind Server, welche Sun beim Kauf von Cray Research, dem Hersteller von Supercomputern, übernahm. Dieser Server ist ein sog. SMP, ein Symmetrisches Multiprocessing System, welches für grosse Anwendungen leistungsfähig skaliert.
Der Ultra Enterprise 10000 (Starfire) Server läuft unter der Betriebssystemumgebung Solaris mit Oracle als Datenbanksystemsoftware und der Voyager Bibliotheksapplikationssoftware.
Der Server besitzt 56 Prozessoren und 30 Gigabyte Memory; einer drei E3500 Server wird mit 8 Prozessoren als Webserver genutzt. Zusätzlich werden Sun StorEdge D1000 RAID Speichersysteme eingesetzt. Mit diesem Server erreicht die Library of Congress 11 mal die Prozessorenkapazität des alten Grossrechners.
Im Vergleich zu Computeranwendungen in der Industrie oder im Bankwesen, ist die Datenbank einer Bibliothek, selbst der grossen Library of Congress, vergleichsweise klein. Selbst innerhalb der LC ist der Speicherplatz für die bibliographischen Daten vergleichsweise klein, weniger als 500 Gigabytes. Das sind nur ca. 5% des Speicherbedarfs, den die National Digital Library beansprucht, wo Fotos, Manuskripte und andere Materialien als gescannte Images gespeichert werden. Die Installation wird etwa 2.000 Pentium PCs umfassen, alle haben eine Windowsumgebung, die meisten sind 300 MHz Computer.
Die Herausforderung für das Voyagersystem ist wahrscheinlicher weniger die Grösse der Datenbank. Dies ist die grösste Installation, die Endeavor je unternommen hat, aber ein Benchmarktest vom April diesen Jahres bei Sun in Kalifornien verlief positiv. Für den Test wurde die Voyager Software und eine Kopie der LC Datenbank in einen Sun Enterprise 10000 geladen und dann ein Leistungstest mit 3.000 simultanen Benutzer durchgeführt.
Es ist zu erwarten, dass der wirkliche Test des Systems jedoch im funktionalen Bereich der Zeitschriften und der Erwerbung in der Produktion erfolgen wird.
In praktisch jedem Bibliothekssystem sind dies die Schwachstellen. Voyager arbeitet z.B. mit einer für Windows entwickelten Oberfläche und benutzt viele sog. Pulldown Menus, um Listen von Adressen, etc. zu präsentieren. Diese Menus sind in einer kleineren Bibliothek sehr einfach zu benutzen, aber was geschieht, wenn man ein Fenster öffnet und in eine Liste von 15000 Tauschadressen gerät, oder hunderte von Standorten durchsuchen muss? Jedermann ist gespannt, wie sich das System dann mit allen geladenen Daten verhalten wird.
Voyager wird von über 200 Bibliotheken benutzt und verzeichnet unter den Kunden grosse Anwender wie die National Library of New Zealand oder die Northwestern University in Chicago. Es war eines der ersten Bibliothekssysteme, welche EDI (electronic document interchange) im Erwerbungsmodul anboten. Z39.50 ist im System eingebaut und ein ISO 10160/10161 Fernleihmodul ist in Vorbereitung.
Präzise nach Plan sind Katalogisierung und Ausleihe am 16. August in Produktion gegangen, und der OPAC steht ab dem 24. August dem Publikum zur Verfügung (Abbildung 5). Stichtag für Erwerbung und Zeitschriftenkontrolle ist der 1. Oktober.
![[Timeline]](../../images/time.gif)
Die Library of Congress hat den Schritt weg von Eigenentwicklungen gemacht und arbeitet mit einem kommerziellen Bibliothekssystem.
Dass das ILS in der Bibliothek eingesetzt werden kann, ist sicher; wie einfach es zu handhaben ist, wird sich zeigen. Am deutlichsten sichtbar wird die Umstellung in der Zeitschriftenabteilung und der Erwerbung. Diese beiden Abteilung werden ihren Arbeitsfluss überdenken müssen, denn nur so können mit dem neuen System wirklich Einsparungen erzielt werden.
![[Dr. Wüst]](../../images/wuest.gif)
Dr. Ruth Wüst ist Informationswissenschaftlerin und arbeitet als Consultant für Automatisierung in der Erwerbungsabteilung der Library of Congress.
2828, Connecticut Ave, #807
Washington,D.C., USA
E-Mail: ruthwuest@hotmail.com