Big Bang oder schrittweise Einführung?

OSIRIS ist ein modulares System. Es besteht aus vielen Komponenten und Funktionen. Das macht es selbst für erfahrene Nutzende schwierig, den Überblick zu behalten. Wenn ich eine Live-Demo des Systems gebe, habe ich meist nur wenig Zeit. Vielleicht eine halbe Stunde. Oder eine ganze. Das reicht meist gerade einmal, um die Kernfunktionen zu zeigen: das Personenprofil, die verschiedenen Aktivitäten, wie man neue Einträge hinzufügt und miteinander verknüpft. Vielleicht bleibt noch Zeit für einen kurzen Blick auf die Projekte – und je nach Publikum für einen Vorgeschmack auf die vielen Auswertungsmöglichkeiten.

Doch auch damit kratze ich nur an der Oberfläche. Einstellungsmöglichkeiten, Zitationen, Berichte, Pivottabellen, Verschlagwortung, Organisationsstruktur, Forschungsbereiche, das Forschungsspektrum und weitere Entitäten wie Infrastrukturen oder Lehrveranstaltungen bleiben meist unerwähnt. Deshalb gibt es danach fast immer viele Fragen: Kann OSIRIS auch das? Und was ist hiermit? Nicht selten lautet die Antwort: Ja, natürlich.

Doch was bedeutet diese Vielfalt für eine Einrichtung, die OSIRIS einführen möchte?

Die vielen Funktionen von OSIRIS sind manchmal eine Falle. Sie verleiten uns dazu, alles auf einmal zu wollen.

Das ist nicht grundsätzlich schlecht. Man sollte sich nur über die Konsequenzen im Klaren sein. Vorweg sei jedoch gesagt: Es gibt nicht die eine goldene Strategie für die Einführung eines Forschungsinformationssystems. Ich habe inzwischen etwa 20 Einrichtungen bei diesem Prozess begleitet und kann mit Sicherheit sagen, dass jede Einführung so einzigartig ist wie die Einrichtung selbst. Dennoch gibt es einige Muster, die ich hier gern mit euch teilen möchte.

Der Big Bang

Das Ziel ist klar: Wir wollen alles auf einmal. Die Einführung wird strategisch geplant, alle Funktionen, die langfristig gebraucht werden, werden von Anfang an berücksichtigt. Das System wird implementiert und konfiguriert, vorhandene Daten werden migriert. Häufig folgt die Einführung dabei diesem bewährten Schema:

Organisationsstruktur ➡️ Personen ➡️ Projekte, Infrastrukturen und Events ➡️ Publikationen und andere Aktivitäten

Dann kommt der große Go-live: ein festgelegter Termin, zu dem alles bereitsteht. Von diesem Zeitpunkt an wird OSIRIS genutzt. Die Nutzenden werden geschult, alle wissen Bescheid.

Die Vorteile liegen auf der Hand: Von Anfang an sind alle relevanten Bereiche in OSIRIS abgebildet. Parallel gepflegte Systeme oder Tabellen können zu einem klar definierten und kommunizierten Termin abgelöst werden.

Für Einrichtungen, die bereits ein FIS nutzen und dieses ablösen möchten, kann das ein guter Weg sein. Sie kennen viele ihrer Anforderungen, Prozesse und Daten bereits. Idealerweise werden alle notwendigen Daten migriert und das neue System übernimmt zu einem festen Stichtag.

Dabei sollte jedoch klar sein: Der Big Bang ist oft nicht der schnellste Weg. Er erfordert erhebliche Vorarbeit bei der Konfiguration, der Gestaltung von Prozessen und der Begleitung des organisatorischen Wandels. Nicht die technische Konfiguration kostet dabei zwangsläufig die meiste Zeit, sondern die gemeinsame Klärung von Anforderungen, Zuständigkeiten und Abläufen. Besonders in Einrichtungen, die ganz von vorn anfangen, kann das die Einführung erheblich in die Länge ziehen.

Der Big-Bang-Ansatz eignet sich besonders für Einrichtungen, die bereits ein FIS nutzen und ihre Anforderungen und Prozesse gut kennen. Für andere kann er die Einführung unnötig verzögern.

Wann ein Big Bang sinnvoll sein kann

Ein Big Bang kann sinnvoll sein, wenn bestimmte Voraussetzungen erfüllt sind:

Es gibt einen verbindlichen Ablösetermin des Altsystems.
Die Prozesse sind erprobt und gut dokumentiert.
Es sind ausreichend Ressourcen für die Einführung vorhanden.
Die Datenqualität ist hoch.
Der Entscheidungsweg ist klar.
Es bleibt genügend Zeit für Tests und Schulungen.

Nicht alle Einrichtungen erfüllen diese Voraussetzungen. Deshalb kann in vielen Fällen ein schrittweiser Ansatz sinnvoller sein.

Die Falle

Der häufigste Fehler besteht darin, zu viel auf einmal zu wollen. Ehrlich gesagt kann ich das verstehen. Man hat dieses glänzende neue Werkzeug und möchte plötzlich alle Probleme damit lösen. Ein Kunde sagte einmal: „Ich möchte alles in OSIRIS haben. Wenn es nach mir geht, benutzt hier niemand mehr Excel für die Datensammlung.“

Ich glaube fest daran, dass OSIRIS viele Probleme im Forschungsmanagement lösen kann. Wir haben es schließlich genau dafür geschaffen. Aber vielleicht nicht alle sofort.

Viele Einrichtungen, die ihr Berichtswesen in den vergangenen 20 Jahren mit Excel organisiert haben, glauben, sie müssten mit einem Ruck vollständig umsteigen – oft auch noch unter enormem Zeitdruck. Schließlich fängt die neue Mitarbeiterin im Berichtswesen nächsten Monat an. Oder im nächsten Jahr steht eine Evaluierung an. Oder der Launch der neuen Webseite steht bevor. Oder alle sind einfach müde von den vielen Excel-Tabellen.

Genau darin liegt die Falle: Nur weil OSIRIS all das kann, heißt das nicht, dass es bei euch sofort und ohne Vorbereitung funktioniert. Wenn ihr die Funktion „Projekte“ einschaltet, habt ihr noch lange keinen funktionierenden Prozess für Drittmittelprojekte an eurer Einrichtung. Projekte müssen genau wie Aktivitäten konfiguriert werden. Welche Datenfelder braucht ihr in welcher Antragsphase? Müssen für diesen Projekttyp überhaupt Anträge angelegt werden? Wer muss benachrichtigt werden? Wer darf was sehen und bearbeiten? Wer setzt einen Antrag auf „bewilligt“? Wer pflegt die Finanzdaten? Kommen vielleicht auch Daten aus einem anderen Stammsystem herein? Mit all diesen Fragen solltet ihr euch beschäftigen, bevor ihr mit der Funktion live geht.

Wenn ihr während der Einführung nicht genug Zeit habt, euch gründlich mit einer Funktion zu beschäftigen, solltet ihr sie vielleicht noch nicht einführen.

Das ist ein ernst gemeinter Rat. Natürlich heißt das nicht, dass ihr die Funktion nicht später einführen könnt – vielleicht schon im nächsten Monat, vielleicht im nächsten Jahr. Entscheidend ist, dass ihr euch die nötige Zeit dafür nehmt.

Ein solches Szenario habe ich schon häufiger erlebt: Eine Einrichtung führt OSIRIS unter Zeitdruck ein, weil im nächsten Jahr die Leibniz-Evaluierung ansteht und noch die Daten der vergangenen drei Jahre erfasst werden sollen. Es fehlt also die Zeit, sich mit jeder Funktion im Detail zu beschäftigen. Trotzdem wird zunächst alles eingeschaltet, weil man schließlich alles irgendwie braucht.

In der Schulung heißt es dann: „Hier könnt ihr Projekte anlegen. Das ist aber noch nicht fertig.“ Aus Sicht der Kommunikation ist das schwierig, denn die Forschenden bleiben mit offenen Fragen zurück. Was bedeutet „nicht fertig“? Sollen sie trotzdem schon etwas eintragen? Werden sie informiert, sobald die Funktion fertig ist? Wie lange wird das dauern? Das schafft Unsicherheit und Frust.

Bei einer FIS-Einführung geht es im Kern auch darum, die Mitarbeitenden, die das System pflegen und nutzen sollen, dafür zu gewinnen. Deshalb solltet ihr unbedingt vermeiden, dass Forschende schon zu Beginn frustriert sind oder – noch schlimmer – dem System nicht vertrauen.

Denn was passiert nun mit den Projekten aus unserem Beispiel?

Eine Gruppenleiterin ist sehr engagiert und begeistert sich leicht für neue Systeme. Sie trägt die Projekte des gesamten Jahres in OSIRIS nach. Ein Postdoc ist dagegen nur verhalten begeistert. Er tut lediglich, was unbedingt notwendig ist.

Nun stellt ihr fest, dass die Standardkonfiguration für Projekte nicht zu euren Anforderungen passt. Sie bildet weder eure Prozesse ausreichend ab noch enthält sie alle Daten, die ihr für eure Berichte benötigt. Ihr überarbeitet nach und nach die Formulare für die verschiedenen Antragsphasen, entwickelt einen Prozess und aktiviert die Nagoya-Protokoll-Compliance. Im schlimmsten Fall vergesst ihr dabei, die Forschenden mitzunehmen und über die Änderungen zu informieren.

Die Gruppenleiterin aus unserem Beispiel ist frustriert. Ihr müsst sie bitten, alle ihre Projekte noch einmal zu überarbeiten, weil wichtige Informationen fehlen. Den Postdoc habt ihr längst verloren: Bei jedem Login, so sein Eindruck, sieht alles anders aus. Er wollte ein Projekt anlegen, hatte aber noch nicht alle Informationen zur Hand. Als er den Eintrag später vervollständigen möchte, gibt es plötzlich viel mehr Datenfelder. Er fühlt sich überfordert, und niemand hat ihm erklärt, was im Feld „Interne ID“ erwartet wird.

Vermeidet Frust bei den Forschenden. Im schlimmsten Fall verlieren sie das Vertrauen in das System – dabei hängt die Qualität eurer Daten häufig von ihrer Mitarbeit ab.

Die schrittweise Einführung

Wie sieht also die Alternative aus? Die Antwort ist denkbar einfach: Die Funktion bleibt zunächst ausgeschaltet.

Ihr führt OSIRIS ein und beschränkt euch auf das Wichtigste: Forschungs- und Transferaktivitäten mit allem, was dazugehört. Auch Lehrveranstaltungen und Events können bereits Teil dieses ersten Schritts sein. Die Organisationsstruktur habt ihr sauber abgebildet. Projekte bleiben vorerst ausgeschaltet. In der Schulung erwähnt ihr, dass die Projektverwaltung für eine spätere Phase geplant ist und es dazu eine eigene Einführung geben wird. Damit ist das Thema angekündigt, ohne dass sich die Nutzenden schon damit beschäftigen müssen.

Gleichzeitig könnt ihr euch zunächst auf das Wesentliche konzentrieren. Die Einführung selbst wird euch vielleicht mehr Energie kosten als gedacht. Forschende stellen Rückfragen. Möglicherweise müsst ihr noch etwas nachkonfigurieren, weil ihr einen Sonderfall nicht bedacht habt. Solche kleineren Anpassungen lassen sich meist schnell erledigen und fallen den Forschenden kaum auf.

Anschließend widmet ihr euch den Projekten. Ihr holt gegebenenfalls die Drittmittelabteilung an Bord und konfiguriert erste Projekttypen. Zunächst hat außerhalb des Projektteams niemand das Recht, diese Testeinträge zu sehen oder selbst etwas hinzuzufügen. Ihr sprecht mit Forschenden, die jedes Jahr viele Projekte beantragen, und stellt ihnen das Konzept vor. Ihr klärt, welche Auswertungen benötigt werden, und testet die Abläufe gemeinsam. Erst dann geht die Funktion live und die Mitarbeitenden werden gezielt geschult.

Klare Kommunikation, klare Zuständigkeiten und so wenig Frust wie möglich: Das ist meine eindeutige Empfehlung. Und obwohl ich in diesem Beispiel immer von Projekten spreche, gilt der Ansatz ebenso für andere umfangreiche Funktionen, etwa die Verwaltung von Infrastrukturen.

Phasen der schrittweisen Einführung

Ein mögliches Phasenmodell könnte wie folgt aussehen:

Kernsystem und Stammdaten mit Einheiten, Personen und den wichtigsten Aktivitäten.
Pilot mit ausgewählten Nutzenden, sowohl Power-User als auch Entscheidungstragende, idealerweise breit gestreut über verschiedene Abteilungen und Hierarchieebenen. Wichtig: holt in dieser Phase frühzeitig den Betriebsrat oder andere relevante Gremien an Bord.
Erste Berichtsprozesse ausprobieren und etablieren. Bekommen wir alle benötigten Informationen und funktioniert der Ablauf reibungslos?
Projekte/Infrastrukturen einführen und testen. Zunächst nur für ausgewählte Nutzende sichtbar, bevor die Funktion für alle freigegeben wird.
Weitere Auswertungen und Integrationen schrittweise einführen und auf ihre Praxistauglichkeit prüfen.

Wichtig: Dies ist nur ein Beispiel. Jede Einrichtung sollte die Phasen an ihre eigenen Bedürfnisse anpassen.

Woran ihr die passende Strategie erkennt

Ob ein Big Bang oder eine schrittweise Einführung besser passt, hängt weniger von der Zahl der verfügbaren Funktionen ab als von euren Voraussetzungen. Hilfreich sind unter anderem diese Fragen:

Sind eure Anforderungen und Prozesse bereits dokumentiert und erprobt?
Wie gut und vollständig sind die Daten, die ihr migrieren möchtet?
Gibt es einen festen Termin, zu dem ein Altsystem abgelöst werden muss?
Stehen genügend Zeit und Personal für Konfiguration, Tests, Schulungen und Kommunikation zur Verfügung?
Sind Zuständigkeiten und Entscheidungswege geklärt?
Könnt ihr mit einer Pilotgruppe testen, bevor alle Nutzenden mit dem System arbeiten?
Welche Funktionen müssen zum Start wirklich einsatzbereit sein – und welche können warten?

Je mehr dieser Fragen noch offen sind, desto eher spricht das für ein schrittweises Vorgehen. Ein kleinerer, verlässlicher Start schafft meist mehr Vertrauen als ein großes Versprechen, das zum Go-live noch nicht vollständig eingelöst werden kann.

Ein kurzes Fazit

Ich möchte nicht den Eindruck erwecken, als hätte ich die eine perfekte Lösung. Wie bereits erwähnt, ist jede Einrichtung einzigartig. Was bei der einen funktioniert, kann bei einer anderen scheitern. Zwei Punkte solltet ihr aus diesem Beitrag jedoch mitnehmen:

OSIRIS ist modular und erlaubt euch, einzelne Funktionen schrittweise einzuführen.
Bezieht bei der Planung alle relevanten Stakeholder ein – einschließlich der Forschenden – und achtet darauf, was ihr wann und wie kommuniziert. Das kann am Ende den Unterschied zwischen Erfolg und Misserfolg ausmachen.

Ihr seid nicht sicher, welche Einführungsstrategie für eure Einrichtung die richtige ist? Dann zögert nicht, uns zu kontaktieren, um mehr über die Möglichkeiten von OSIRIS und die passende Vorgehensweise zu erfahren. Wir bieten individuelle Beratung und Unterstützung bei der Planung und Umsetzung eurer Einführung.

Titelfoto: Sébastien Lavalaye auf Unsplash.