Agiles Service Engineering für digitale forschungsunterstützende Dienste in Hochschulbibliotheken

2.1 Bibliothek und Universität

Schauen wir für die Nutzergruppe der Forschenden auf das Beispiel der Universität Münster, so sehen wir im Verlauf der letzten Dekaden eine Reihe von Meilensteinen auf dem Weg hin zu einer immer stärker ausgeprägten Digitalisierung der Wissenschaft. Bei der Entwicklung des forschungsunterstützenden Dienstleistungsangebots nimmt die ULB Münster eine wichtige Rolle als Dienstleisterin und Projektpartnerin unterschiedlicher universitärer Einrichtungen ein, nicht zuletzt aufgrund der jahrelangen Zusammenarbeit mit dem IT-Center der Universität Münster (CIT). Ein Fokus liegt auf der Entwicklung von neuen und experimentellen digitalen Serviceangeboten wie der Exploration eines Unterstützungsangebots zur reproduzierbaren Forschung. Besonders deutlich wird dies mit Blick auf die geförderten und gemeinsam durchgeführten Projekte,^[7] die die Entwicklung von innovativen digitalen Produkten zum Ziel hatten. Durch den direkten Austausch zwischen fachübergreifenden Anlaufstellen ist es möglich, Anforderungen und Ideen aus der Wissenschaft aufzugreifen und generische Basisdienstleistungen für eine breite Nutzerschaft zu entwickeln. So wurden etwa mit dem Aufbau des an der ULB angesiedelten Service Center for Digital Humanities (SCDH)^[8], dem Service Center for Data Management (SCDM)^[9] sowie der Schaffung von hoch spezialisierten Ressorts aus dem E-Science-Umfeld (etwa Research Software Engineering oder Data Science) wichtige Anlaufstellen für die digitale Forschungsunterstützung und -vernetzung aufgebaut.

Flankierend existieren entsprechende Kooperationen der Forschenden in den NFDI-Konsortien.^[10] Eine ihrer Aufgaben ist es, die heterogenen Anforderungsprofile der Fachdisziplinen zu harmonisieren und herauszuarbeiten. Im Ergebnis erfordern die durch eine hohe Dynamik charakterisierten Veränderungen des Wissenschaftsstandorts in den Phasen der digitalen Transformation stetige Anpassungen des historisch gewachsenen gesamtuniversitären Serviceportfolios. Im Mittelpunkt der von der ULB Münster angebotenen digitalen Dienstleistungen stehen vor allem die Themen des Forschungsdatenmanagements^[11] sowie die Beratung bei der Anwendung digitaler Methoden. Ersteres umfasst neben der Weiterentwicklung eines Repositoriendienstes mit InvenioRDM^[12] ein Angebot für Elektronische Laborbücher (ELN), das wir im Folgenden (s. Abschnitt 4.1 Transfer in die Praxis) ausführlicher erläutern. Die Methodenberatung spielt bei den Unterstützungsangeboten aus dem Umfeld der Digital Humanities eine wesentliche Rolle.^[13]

2.2 Vernetzte Infrastrukturen

Ein Serviceportfolio digitaler Produkte führt insbesondere hinsichtlich des Betriebs zu einer Auseinandersetzung mit den infrastrukturellen Gegebenheiten am Standort. Bundesweit stehen die Hochschulen und Hochschulbibliotheken vor vergleichbaren Herausforderungen. Die Lösung kann realistischerweise jedoch nicht sein, an jedem Standort das gleiche vollumfängliche Spektrum an Services redundant aufzubauen und dauerhaft zu betreiben. Wie die Beispiele der nordrhein-westfälischen Kooperationsgemeinschaft Digitale Hochschule NRW oder dem aus der Landesinitiative NFDI der Digitalen Hochschule NRW hervorgegangenen fdm.NRW zeigen, sind Verbundstrukturen ein gangbarer Weg.^[14] Damit Forschende gleichzeitig von einem maximal ausgestalteten Spektrum an Services profitieren können, die Standorte aber angesichts begrenzter Ressourcen und inhaltlicher Spezialisierungen nicht überfordert werden, braucht es Vernetzung und das Ausnutzen von Synergien. Hierfür wiederum werden Governance und Strukturbildung benötigt.

Für die einzelnen Standorte bedeutet dies, dass neue Serviceentwürfe in einem formal beschriebenen Ablaufschema entwickelt werden können. Entsprechend profitiert ein formalisiertes Service Engineering von Standardisierungseffekten. In der Praxis werden Serviceideen immer wieder neu an die involvierten Institutionen herangetragen oder leiten sich aus hochschulpolitischen oder anderen strategischen Entscheidungen der servicegebenden Institutionen oder Hochschulen ab. Diese Art eines formalen Ablaufschemas sowie das dazugehörige Rahmenwerk meinen wir mit dem Konzept des Service Engineering. Es ist eng an das später für den Betrieb digitaler Produkte und die Pflege des Serviceportfolios relevante Service Management gebunden.

Auch in der zugrundeliegenden Betriebsinfrastruktur sind große Entwicklungssprünge zu verzeichnen. Richtet eine Institution ihre Softwareentwicklung auf den Betrieb der entstehenden digitalen Produkte im Cloudumfeld aus, so kann sie von vielen Vorteilen Gebrauch machen.^[15] Die wesentlichen Aspekte, um digitale Produkte für die Forschenden bereitzustellen, sind Sicherheit, digitale Souveränität (Selbstbetrieb von Software on-premises), Skalierbarkeit sowie die Modularisierbarkeit der Angebote.^[16] Diese Aspekte sind von großem Nutzen und können entsprechend an allen Hochschulstandorten als dauerhaft erstrebenswerte Ziele identifiziert werden. Da sie schwer zu erreichen sind, liegt hier ein hohes Ressourcenrisiko vor, falls an Hochschulstandorten redundante Lösungen entstehen. Redundanz liegt vor, wenn mehrere Hochschulen denselben Service unabhängig voneinander erarbeiten und als digitales Produkt bereitstellen.

Als ein Beispiel für cloudbasierte Dienste ist das Jupyterhub zu nennen, eine Plattform für interaktive Datenanalyse, die als Webservice in der Cloud der Universität Münster hardwareseitig in der Research Data Infrastructure vom CIT Münster betrieben wird. Als on-premises cloud^[17] bietet die Betriebsinfrastruktur ein Höchstmaß an digitaler Souveränität für die Forschenden. Auch eine synergetische Teilhabe an digitalen Produkten innerhalb von Hochschul-Serviceverbünden mit gemeinsamer Basisinfrastruktur ist außerhalb des Cloudumfelds schwer vorstellbar. Somit tragen Hochschulclouds dazu bei, forschungsunterstützende Dienstleistungen mit ihren skalierbaren digitalen Produkten schneller und qualitätssicherer in Wert zu setzen oder überhaupt erstmals bereitzustellen.^[18] In ihnen angesiedelte modular angelegte Servicebausteine wachsen zu einem digitalen Ökosystem zusammen, in dessen Umfeld leichter automatisierbare und interoperable Prozessketten aufgebaut, ausgetauscht und referenziert werden können, das heißt, der Output eines Prozesses ist ein valider Input des nächsten Prozesses.^[19]

Im Folgenden werden wir nun zunächst die theoretischen Grundlagen des Service Engineering näher vorstellen.

3.1 Ein neuer Ansatz? Die Wurzeln des Service Engineering

Die Wurzeln des Service Engineering reichen bis in die 1970er- und 1980er-Jahre zurück. Im angloamerikanischen Raum setzte sich in den 1990er-Jahren das Konzept des New Service Development durch, während sich in Deutschland und Israel der Begriff des Service Engineering etablierte.^[21] Im Gegensatz zu dem amerikanischen Ansatz und dessen strikter Marktorientierung zielt das Service Engineering darauf ab, die Mechanismen der Produktentwicklung auf die Entwicklung und Bereitstellung von Dienstleistungen zu übertragen. Vergleichbar mit dem Entwicklungsprozess, den ein Produkt von der ersten Idee bis zur Produktionsreife durchläuft, können auch Dienstleistungen durch eine Systematisierung der Prozesse an Effizienz und Qualität gewinnen.

Parallelen zwischen der Entwicklung von Produkten und Dienstleistungen zeigen sich beispielsweise bei der Identifikation versteckter Potenziale durch neue und innovative Methoden.^[22] Zudem erlaubt das Konzept des Service Engineering, bereits früh in der Konzeptionsphase zu klären, ob die Voraussetzungen bzw. notwendigen Ressourcen für die Umsetzung des Service vorhanden sind.^[23]

Mit dem Service Engineering wurde also ein Rahmenkonzept geschaffen, das offen ist für den systematischen Einsatz unterschiedlicher Modelle, Methoden und Werkzeuge. Damit ist es möglich, flexibel auf Veränderungen und Innovationen zu reagieren und durch die stetige Weiterentwicklung von Dienstleistungen selbst eine „Innovations- und Wettbewerbsfähigkeit […] zu (er)schaffen“.^[24] Zentrale Ansatzpunkte sind die Modularisierung von Dienstleistungen, deren systematische Entwicklung sowie die zunehmende Nutzer- bzw. Kundenorientierung.^[25]

Praktische Relevanz gewann das Konzept des Service Engineering ab den frühen 2000er-Jahren, als es als eine Alternative zu der „eher spontan und intuitiv“^[26] arbeitenden Dienstleistungsentwicklung wiederentdeckt wurde.^[27] Slogans wie „Standing out from the competition through innovative services“ waren und sind dabei Schlagworte, die in einem stetig wachsenden Dienstleistungssektor eine dynamische und zukunftsweisende Transformation der eigenen Serviceangebote und eine Zukunftssicherheit bei der Digitalisierung von Dienstleistungen versprechen.^[28] In den folgenden Jahren zeigte sich, dass das Konzept des Service Engineering auch vor dem Hintergrund sich verändernder Rahmenbedingungen wie beispielsweise den Herausforderungen der Digitalisierung angepasst und selbst zur Grundlage für die Gestaltung von kooperativen Service-Systemen wird.^[29]

3.2 Service Engineering – Kundenorientierung als übertragbares Konzept

Im deutschen Wissenschaftssystem bilden Hochschulbibliotheken eine Schnittstelle zwischen Infrastruktur und Forschenden, indem sie zentrale, forschungsunterstützende Dienstleistungen entwickeln und anbieten. Daher ist bei dem Konzept des Service Engineering insbesondere die Kundenorientierung für Hochschulbibliotheken wichtig. Hierin liegt, so Leimeister, der wesentliche Unterschied zu der Perspektive gängiger marktorientierter Unternehmen:

Während sich die Marketingperspektive mit den Bedingungen, Erfolgsfaktoren und Hindernissen bei der Entwicklung von Dienstleistungen beschäftigt, fokussiert Service Engineering einen kundenzentrierten Ansatz und berücksichtigt die qualitativen Eigenschaften zwischen Mensch-Mensch und Mensch-Computer Beziehungen.^[30]

Für einen solchen produktiven Einsatz des Service Engineering in Hochschulbibliotheken ist es jedoch notwendig, die einzelnen Entwicklungsschritte innerhalb und außerhalb der Einrichtung überprüfen und kommunizieren zu können. Dies wird einerseits ermöglicht durch ein systematisiertes und modularisiertes Vorgehen zwischen den an der Entwicklung beteiligten Personen, den späteren Nutzer*innen und weiteren Stakeholdern, wodurch beispielsweise die Kommunikation und der Abgleich von Zwischenständen erleichtert werden kann. Andererseits wird die Dienstleistungsentwicklung anhand von Kenn- und Nutzungszahlen überprüfbar gemacht.^[31] Indem auf diese Weise Entwicklungskosten reduziert und die „Entwicklungszeit bis zur Markteinführung“^[32] verkürzt werden, ergeben sich Vorteile sowohl für die Servicenehmenden als auch für die Servicegebenden.

Damit wird auch der aktuelle Trend der Entwicklung aufgegriffen, dass bei der Bereitstellung, aber auch der Automatisierung von (Teil-)Services zunehmend große Datenmengen erzeugt und erhoben werden. Diese Daten stellen, so Roth et al., wiederum selbst die „Basis für neue Dienstleistungen und Geschäftsmodelle“^[33] dar. Dementsprechend wird Service Engineering in der Literatur häufig auch als ein Ansatz eingeordnet, mit dem sich Potenziale zur Optimierung der Dienstleistungsentwicklung erkennen und umsetzen lassen.^[34] Nicht berücksichtigt wird hierbei, dass für die Ausbildung und Überprüfung von Dienstleistungen auf Grundlage des Service Engineering auch Ressourcen benötigt werden. Dies umfasst unter anderem „individual people’s time, attention, and capital as well as environmental resources, societal and business resources, etc.“.^[35] Erst mit einer ganzheitlichen Analyse des Service-Umfelds wird das Service Engineering ein methodisch klar umrissener Ansatz, der über eine reine Identifikation von Optimierungsmöglichkeiten auf Produktebene hinaus „Potentiale für systemische, interaktive und kollaborative Dienstleistungsentwicklung“ erarbeitet.^[36]

Ein geeignetes Umfeld für eine solche moderne Dienstleistungsentwicklung auszuprägen, ist Aufgabe von Hochschulbibliotheken. Sie sind in der Pflicht, die Voraussetzungen für innovative Serviceangebote selbst zu schaffen sowie die geeigneten Konzepte der Dienstleistungsentwicklung zu übertragen. Für den infrastrukturellen Teil dieses Umfelds kann vielerorts auf die Leistungen der Rechenzentren, etwa bei der Nutzung von Hochschulclouds, gesetzt werden. Da die Ressourcen hierfür in der Regel beschränkt sind, ist es wichtig, frühzeitig erste Ideen zu sammeln und zu priorisieren. Service Engineering bietet hierbei eine Methodik, den Entwicklungsprozess mit Blick auf die institutionellen Gegebenheiten zu steuern, Fehl- und Mehrfachentwicklungen zu vermeiden und auf diese Weise passende und ressourcenschonende Dienstleistungen zu etablieren.^[37]

3.3 Umfeld der Dienstleistungsentwicklung – erste Schritte in die Praxis

Im Folgenden erläutern wir, wie ein passendes Umfeld für die Dienstleistungsentwicklung im Sinne des Service Engineering geschaffen werden kann.

Zunächst braucht es ein geeignetes Vorgehensmodell, das entweder aus verschiedenen Vorlagen ausgewählt oder selbst entwickelt werden kann.^[38] Ein solches Vorgehensmodell bildet den „Rahmen für den Einsatz von Methoden und Werkzeugen“, der sich über die verschiedenen Phasen der Dienstleistungsentwicklung spannt.^[39] Die konkrete Ausgestaltung hängt stark vom jeweiligen Einsatzgebiet bzw. der Art des Produkts oder Dienstleistung ab. Entsprechend finden sich in der Literatur unterschiedliche Vorgehensmodelle für das Service Engineering mit dem Ziel, die Markteinführung neuer Produkte und Dienstleistungen abzubilden. Ist ein passendes Vorgehensmodell ausgewählt, kann es an die Spezifika der Einrichtung, z. B. einer Hochschulbibliothek, angepasst werden.

Das Vorgehensmodell der ULB Münster umfasst fünf Phasen, die ein Service von der ersten Idee bis zur Reife durchläuft:

Schritt 1: Ideen finden und bewerten

Schritt 2: Serviceidee konkretisieren

Schritt 3: Service konzipieren

Schritt 4: Service implementieren

Schritt 5: Service betreiben

Diese Phasen sind angelehnt an die von Meiren und Barth beschriebenen Entwicklungsprozesse zur Umsetzung des Service Engineering in Unternehmen.^[40] Während die erste Phase (Ideen finden und bewerten) flexibel und kreativ ausgestaltet werden kann, wird der Serviceentwurf im weiteren Verlauf des „Fünf-Phasen-Vorgehensmodells“ zunehmend formalisiert und konkretisiert. Die lineare Grundausrichtung wird nach jedem Schritt von Revisionspunkten unterbrochen und bietet damit Raum, einzelne oder mehrere Phasen in der Praxis mit dynamischen oder zyklisch verlaufenden Vorgängen und Methoden an die jeweiligen Anforderungen anzupassen.

Durchläuft ein Service diesen strukturierten Prozess inklusive der im Vorgehensmodell beschriebenen Anforderungen, so erlangt dieser den Zustand der „Marktreife“. Übertragen auf forschungsunterstützende Dienstleistungen in Hochschulbibliotheken bedeutet die Marktreife, dass das digitale Produkt fertig ausgestaltet und implementiert sowie der Zielgruppe der Forschenden mit einem Angebot einer zugehörigen Dienstleistung zur Verfügung steht.

Gerade im wissenschaftlichen Umfeld kann das digitale Produkt teils direkt auf eine Anfrage der Forschenden zurückgeführt werden, sodass neben generischen Basisdiensten wie einer Repository Platform auch experimentelle Anwendungen, Demonstratoren und Prototypen für wissenschaftliche Präsentationen stehen können, die in der unmittelbaren Interaktion mit Forschungsgruppen stetig weiterentwickelt werden. Methodisch kann hier beispielsweise auf Interviews, User Stories oder Personas zurückgegriffen werden, um Anforderungen, Use Cases und Perspektiven adäquat zu erfassen.^[41]

3.4 Zusammenfassung

Bislang wurden in erster Linie die Grundzüge des Service Engineering umrissen. Zusammenfassend kann das Konzept als ein Versuch gesehen werden, das Service Management bereits von der ersten Idee an zu begleiten. Unter diesen Voraussetzungen kann das Konzept des Service Engineering, wie Richter und Tschandl argumentieren, einerseits die Qualität der Dienstleistungen in allen Phasen des Entwicklungsprozesses gewährleisten, andererseits die Innovations- und Wettbewerbsfähigkeit der servicegebenden Einrichtung befördern und sichern.^[42] Doch wie kann diese Theorie gelebte Praxis werden?

4.1 Transfer in die Praxis des Arbeitsalltags

Für die wissenschaftlichen Bibliotheken ist das formalisierte Service Engineering im Bereich der Forschungsunterstützung bisher kaum nutzbar gemacht worden, wenn es darum ging, ein Portfolio digitaler Produkte verbunden mit Dienstleistungen hervorzubringen. Im Allgemeinen werden Dienstleistungen häufig „‚aus dem Bauch heraus‘ entwickelt und sind daher nur unzureichend durchdacht“.^[43] Trotz dieser Fundamentalkritik, die nicht auf die Bibliothekswelt oder Hochschulen abzielt, kann ein intuitives Verhältnis zur Gestaltung von Dienstleistungen auch viel erfahrungsbasierte Praxistauglichkeit mit sich bringen. Was es dagegen vermissen lässt, ist Belastbarkeit über Einzelprozesse hinweg. Für Interoperabilität und gleichbleibende Qualitätssicherung wird Standardisierung benötigt. Doch gerade Belastbarkeit in den Prozessen und Standardisierungen halten wir im Service Engineering für geboten. Nur in einem formal strukturierten Vorgehensmodell lassen sich strategische Maßgaben, etwa im Kontext von Hochschulentwicklungsplänen, effektiv umsetzen. Die Belastbarkeit liegt in der Tatsache, dass eine Vielzahl von verbundenen Einzelprozessen aus den Bereichen der Geschäftsebene, der Informationen und Daten sowie der Anwendungsebene und Infrastruktur gleichzeitig in Anspruch genommen werden, wenn eine neue Dienstleistung hervorgebracht werden soll. Um ein Bild zu gebrauchen, könnte man sagen, dass das Service Engineering entgegen dem ungeordneten, intuitiven Dienstleistungsgeschäft einer standardisierten Fertigungsstraße gleicht, auf der stets neue Services von gleichbleibend hoher Qualität gefertigt werden, vom Fließband rollen und sich direkt auf allen relevanten Ebenen integrieren lassen. Obwohl hochspezialisiert in ihrer Funktion, weisen sie einen gemeinsamen Nenner und Notwendigkeiten der Begleitung bis zur Produkt- und Servicereife auf. Mit dem geordneten Service Engineering liegt ein wichtiger Baustein zur Anpassung an die rasante Innovationsgeschwindigkeit der digitalen Transformation vor. Die Formalisierung und Standardisierung des Service Engineering schafft einen Ordnungsrahmen für diese prozessorientierte Belastbarkeit und die eingeforderte hohe Anpassungsfähigkeit. Arbeitsabschnitte in diesem Rahmen werden validierbar und steuerbar.

Als konkretes Beispiel für die Umsetzung des Service Engineering möchten wir den 2024 veröffentlichten Service eLab – Elektronisches Laborbuch (ELN) nennen.^[44] Dieses Angebot eines Elektronischen Laborbuchs ist insofern interessant, als es unmittelbar aus den Anforderungen des Forschungsdatenmanagements hervorgegangen ist und mit der Open-Source-Anwendung eLabFTW^[45] ein passendes digitales Produkt für die Serviceidee gefunden wurde. Blicken wir zunächst auf die frühen Phasen des Service Engineering: Zu Beginn stehen die Ideenfindung und das Ermitteln der konkreten Anforderungen im Mittelpunkt. Der Bedarf eines Elektronischen Laborbuchs wurde seitens der Wissenschaftler*innen deutlich in Beratungsgesprächen zum Forschungsdatenmanagement geäußert, weshalb die Ideenfindungsphase sehr kurz abgehandelt wurde. In der nächsten Phase des Vorgehensmodells, der Konkretisierungsphase, konnten dann die verschiedenen Use Cases für ein elektronisches Laborbuch weiter fokussiert und ausgearbeitet werden. Hierzu wurden Forschende aus den Naturwissenschaftlichen Fakultäten, die in ihrem Alltag mit traditionellen Laborbüchern arbeiten, befragt. So konnten sie ihre Vorstellungen, Wünsche und vor allem praxistauglichen Erfahrungen miteinbringen. Genannt wurden etwa Wünsche nach verbesserter Übersicht, Persistenz, Discovery, Qualitätssicherung sowie Möglichkeiten der Kollaboration in der digitalen Laborbuchvariante. Auf diese Weise wurde die Serviceidee durch User Stories angereichert und geschärft (Konkretisierungsphase). Der zukünftige Betrieb wurde dann durch die Abwägung von Ressourcen vorbereitet (Konzeptierungsphase). Über eine Marktanalyse kristallisierte sich dabei die Open-Source-Anwendung eLabFTW heraus, deren Einsatz dem erarbeiteten Wertekanon hinsichtlich Open Science entspricht. Auf Grundlage der technologischen Gegebenheiten des Standorts, wie beispielsweise der vom CIT Münster betriebenen Computerinfrastruktur (Kubernetes) oder dem universitären Nutzermanagement, konnte das digitale Produkt installiert, konfiguriert und in Betrieb genommen werden.

Vor dem Hintergrund der gemachten Erfahrungen sehen wir die Umsetzung des Vorgehensmodells als kontinuierliche Herausforderung an, der es parallel zum fortschreitenden digitalen Wandel der Hochschul- und Wissenschaftslandschaften zu begegnen gilt. Im Pilotversuch der ULB Münster ist deutlich geworden, dass zahlreiche Vorgehensweisen historisch gewachsen sind und eine intuitive Herangehensweise etabliert ist. Wir gehen davon aus, dass dieser Umstand zu einem gewissen Grad für die ganze Hochschullandschaft verallgemeinerbar ist. Der systematische Aufbau eines digitalen forschungsunterstützenden Serviceportfolios bedingt die Auflösung einiger dieser fest etablierten Eigenschaften. Die Art und Weise, wie Services entworfen und umgesetzt werden, muss hierfür geändert werden. Aus diesem Grund begreifen wir unseren Beitrag als Werkstattbericht, der vor allem die Stellschrauben und Instrumente für solche notwendigen Anpassungen in den Blick nimmt.

Zu unseren Lessons Learned bei der schrittweisen Einführung dieses Konzepts zählen wir die konkrete Kommunikation, das Prozessbewusstsein sowie die Interaktion zwischen Teams und im Team. Der Kommunikation kommt dabei eine wesentliche Rolle zu, da sie einerseits den Transport der neuen Ideen und Konzepte ermöglichen muss, andererseits für das Zusammenspiel der verschiedenen Rollen und Teams von größter Wichtigkeit ist. Kommuniziert werden müssen auch komplexe Sachverhalte an der Schnittstelle von Dienstleistung und Software Engineering. Dabei hilft eine klare Rollenverteilung und insbesondere die Rolle des Product Owners, in der wir den bzw. die Organisator*in aller Managementvorgänge rund um die Erarbeitung des digitalen Produkts sehen. Die Person mit der Rolle Product Owner ist also per se im Zentrum der notwendigen Kommunikation rund um den Serviceentwurf.^[46]

Bei der Einführung des Service Engineering ist mit Schwierigkeiten in Bezug auf Arbeitsabläufe, -strukturen und -gewohnheiten sowie mit Verständnisschwierigkeit hinsichtlich der neuen Konzepte zu rechnen, da diese die bisherigen Abläufe überformen. Bei der Lösung dieser Problematiken geht es damit auch um die Fähigkeit, Arbeitsvorgänge neu zu reflektieren, sowie in der Prozessbegleitung exakter zu erfassen und verständlich zu beschreiben, um ggf. fehlende Kompetenzen aufzubauen.^[47]

Die Entwicklung eines Benutzerhandbuchs zur Anleitung des Service Engineering ist ein wesentliches Ergebnis der praktischen Umsetzung. Als lebendes Dokument steht es im Dokumentationsbereich der ULB für alle Involvierten bereit und wird kontinuierlich weiterentwickelt. Die Veröffentlichung des von Anfang an auf Nachnutzbarkeit angelegten Handbuchs ist vorgesehen. Überwundene Hürden bei der Umsetzung des Service für Elektronische Laborbücher wie das Zusammenführen von LDAP-Authentifizierung und der Nutzerorganisation von kleinteiligen Teamstrukturen wie Laborpartner*innen können anderen Serviceentwürfen mit vergleichbaren Anforderungen unmittelbar zugutekommen. Voraussetzung hierfür ist eine sehr deutliche, praxisnahe Dokumentation und eine Verallgemeinerung von Problemlösungen durch das Redaktionsteam des Benutzerhandbuchs für das Service Engineering. Eine Leitfrage hinsichtlich des Prozessbewusstseins an alle Involvierten in der Entwicklung eines Serviceportfolios lautet: „Wie sehen die Abläufe und Vorgänge in eurer Abteilung, in eurem Team aus?“ Eine Frage, die in der Praxis nicht immer leicht zu beantworten ist und etwa durch Interviews erarbeitet werden kann.

4.2 Teamkultur und Change Management

Den fehlenden Fokus auf die Interaktion im Team und zwischen verschiedenen Teams haben wir als eine weitere Lesson Learned ausgemacht. Die Verwendung unseres Vorgehensmodells und unserer Anleitungen in der Praxis zeigen, dass es nicht ausreicht, existierende Vorgehensmodelle einzig auf die Situation einer Universitätsbibliothek anzupassen, sondern dass vielmehr eine Erweiterung der Vorgehensweise notwendig ist. Diese Erweiterung sehen wir in dem Aspekt der Agilität (vgl. Abschnitt 5).

Doch zunächst präsentiert sich in der skizzierten Ausgangslage am Münsteraner Standort ein viel praktischeres Problem: Die Umstellung aller Arbeitsabläufe und damit einhergehend die Annahme agiler Mindsets durch die Mitarbeitenden macht ein tiefgreifendes Change Management notwendig. Hochschulbibliotheken entwickeln Software. Diese Aussage allein verdeutlicht, dass Veränderungen im Gang sind, die sich in der Teamkultur widerspiegeln müssen. Um dieser Anforderung zu begegnen, ist es hilfreich, sich an der Vorgehensweise großer (internationaler) Unternehmen mit IT-Bezug aus der Privatwirtschaft zu orientieren, die in der etablierten IT-nahen Arbeitskultur gewissermaßen einen Kulturvorsprung aufweisen, von dem Hochschulen, Hochschulbibliotheken und Hochschulrechenzentren lernen können. Hierbei sind Matrixorganisationsformen bzw. projektbezogene Teamorganisation den Linienorganisationsformen vorzuziehen und teils bereits seit vielen Jahren und unter der Belastungsprobe der Wirtschaftlichkeit erfolgreich angewendet und verfeinert worden.^[48] Die Ablösung von unverbundenen, oft als unflexibel empfundenen Arbeitsprozessen in Linienorganisationsformen stellt eine große Herausforderung dar. Bei der kritischen Nachahmung neuer Organisations- und Arbeitsformen kommt es auf die Vermittlung von Kompetenzen und Mindset an. So kann etwa die Idee eines flexibel und spontan zusammengestellten, abteilungsübergreifenden Teams parallel neben einer dienstlich vorgegebenen hierarchischen Organisationsform existieren. Mit Fokus auf das Rollenkonzept können Mitarbeitende des Software Engineering, des Anwendungsbetriebs und der Projektleitung nach Erwerb der nötigen Methodenkompetenzen erfolgreich projektbasiert zusammenarbeiten und den Arbeitsalltag aller Involvierten mit positiver Wirkung formen.^[49]

Aus der Perspektive der Institution lässt sich festhalten, dass notwendiger Kompetenzerwerb, Kommunikation sowie die Verfügbarkeit von Personal und Teamkultur die entscheidenden Hürden für eine erfolgreiche Umsetzung des Konzepts sind und daher bestenfalls als Teil des institutionellen Change Managements^[50] sind. Blicken wir auf das Vorgehensmodell, so erscheint es unter den genannten Aspekten auf der Oberfläche zunächst als zu statisch und linear. In der praktischen Erprobung muss den Revisionspunkten daher eine hohe Gewichtung zukommen. Diese sind als Gelenkpunkte und somit als Steuerungsinstrumente zu verstehen. Das Service Engineering konstituiert sich aus einer Menge an Prozessen, Rollen, Entscheidungen, Tätigkeiten und Projekteigenschaften. Dieses Gefüge erfordert insbesondere für forschungsnahe Serviceportfolios, die Bezug zu Forschungssoftware aufweisen, Anpassungen am Vorgehensmodell.

Was also macht die Tragfähigkeit eines solchen Ansatzes aus? Einerseits soll das Vorgehensmodell generisch genug sein, um es in alle involvierten Abteilungen und Teams zu übertragen, andererseits soll es so spezifisch sein, dass eine gemeinsame Standardvorgehensweise und ein homogenes Serviceportfolio entstehen. Auch die Praktikabilität der erarbeiteten Anleitungen im Arbeitsalltag muss erprobt und dem Redaktionsteam des Benutzerhandbuchs für das Service Engineering zurückgespiegelt werden. Daneben wird eine erfolgreiche Umsetzung des Ansatzes durch persistente Probleme im Hochschul- und im Hochschulverwaltungsumfeld erschwert. Einerseits liegen diese Einschränkungen beim Kompetenzaufbau und -erhalt: Zu nennen sind hier die geringe Verfügbarkeit von hochqualifiziertem IT-Personal auf dem Arbeitsmarkt, weniger angemessene Gehaltsaussichten für das IT-Personal im Vergleich zum Arbeitsmarkt, sowie fehlende Karrierepfaden für IT-Kompetenztragende. Andererseits erschweren projektförmige Förderstrukturen und befristete Beschäftigungsverhältnisse den nachhaltigen Aufbau von Expertise und Services. Das Verlassen gewohnter Pfade weg vom riskanten Ansatz „Eine Person – ein Softwareprojekt“ gelingt nur als geordneter Transformationsprozess unter Einsatz der Mitarbeitenden und der Leitenden.

Wir sind zu der Erkenntnis gelangt, dass durch Einbindung agiler Prozesse ein tragfähigeres Vorgehensmodell für das Service Engineering entsteht, das wir im Folgenden besonders unter diesem Gesichtspunkt näher beschreiben.