Was es wirklich braucht, um wissenschaftliche Managementplattformen in großem Maßstab zu implementieren

Ich kenne den Laboralltag. Ich weiß, wie es ist, wenn Systeme nicht miteinander kommunizieren, wenn Dinge ohne ersichtlichen Grund ausfallen und wenn man den halben Nachmittag damit verbringt, dieselben manuellen Aufgaben wie am Vortag zu wiederholen. In den letzten Jahren habe ich Plattformen für das wissenschaftliche Management implementiert (einschließlich SciSure) in Umgebungen, die von Krebsforschungsinstituten bis hin zu universitätsweiten Rollouts mit Tausenden von Nutzern reichen.

Durch meine Erfahrung als Forscher, Mitarbeiter in der Forschungsunterstützung, Softwareanbieter und Business Analyst für Unternehmen habe ich gelernt, dass eine erfolgreiche digitale Transformation selten an der Technologie scheitert. Sie scheitert an der Fähigkeit einer Organisation, Technologie in wiederholbare Arbeitsabläufe zu übersetzen.

In diesem Beitrag zeige ich Ihnen, wie eine Implementierung auf Unternehmensebene wirklich aussieht: Wer muss mit am Tisch sitzen, was bedeutet ein realistischer Zeitplan und warum ein Change-Management-Plan keine Option, sondern eine Notwendigkeit ist. Wenn Sie Laborleiter, IT-Leiter in der Forschung oder Business Analyst sind und mit der Digitalisierung einer komplexen wissenschaftlichen Umgebung betraut wurden, ist dieser Beitrag für Sie.

Warum scheitern Software-Implementierungen in Laboren auf Unternehmensebene?

Rollouts von Laborsoftware auf Unternehmensebene scheitern oft daran, dass das Ausmaß des organisatorischen Wandels von Anfang an unterschätzt wird. Ich habe noch keinen Projektsponsor getroffen, der freiwillig die Zeit seiner Mitarbeiter zur Verfügung stellt, um die nächsten sechs Monate mit der Migration von dreißig Jahren Tabellenkalkulationen und der Schulung Tausender Nutzer zu verbringen.

Genau in dieser Lücke zwischen organisatorischem Anspruch und tatsächlichem Engagement beginnt das Scheitern einer Implementierung. Wenn Sie das Gesamtbild von Warum die Einführung von ELN und LIMS auf Unternehmensebene scheitert, läuft es oft auf diesen Punkt hinaus.

Der Übergang von „Wir brauchen das“ zu „Wir werden das zum Erfolg führen“ erfordert etwas, für das die meisten Unternehmen nur ungern ein Budget bereitstellen: ein dediziertes Projektteam. Nicht nur ein Projektmanager mit zehn anderen Aufgaben, sondern ein echtes Team mit klar definierten Rollen und der nötigen Zeit für die Umsetzung.

Wer muss bereits vor der Softwareinstallation eingebunden werden?

Executive Sponsors: Diejenigen, die unterschreiben und am Ball bleiben

Die Zustimmung der Geschäftsführung signalisiert dem gesamten Unternehmen, dass dieses Vorhaben ernst gemeint ist. Doch allzu oft unterschreibt die Führungsebene den Vertrag und zieht sich dann zurück. Unternehmensweite Implementierungen benötigen einen Executive Sponsor, der während des gesamten Rollouts sichtbar bleibt – jemanden, der den Forschungsgruppen vermittelt, dass die Teilnahme nicht optional, sondern zumindest dringend empfohlen ist. Diese Botschaft hat deutlich mehr Gewicht, wenn der Sponsor aufzeigen kann, dass ein dediziertes Projektteam bereitsteht, um die Anwender während der Umstellung zu unterstützen.

Ein Business Analyst, der das Labor versteht

Bevor ein Anbieter überhaupt eine Demo präsentieren darf, muss ein Business Analyst den Ist-Zustand erfassen: wie Proben gelagert werden, wie Forscher sie finden, welche Vorschriften gelten und über welche Aspekte ein erfolgreiches System berichten können sollte, die heute noch nicht abgedeckt sind. Diese Ist-Analyse bildet die Grundlage für das Anforderungsdokument – und auf Unternehmensebene sprechen wir hier von hunderten Anforderungen, die nach Priorität klassifiziert sind.

Diese Rolle wird oft unterschätzt. Es geht nicht nur um die Dokumentation von Prozessen, sondern auch darum, die Bedürfnisse der Forscher („Ich möchte meine DNA-Probe finden, ohne drei Tabellen zu durchsuchen“) in eine Governance-Struktur zu übersetzen („Probentyp-Vorlagen müssen gruppenübergreifend standardisiert und gegen unkontrollierte Änderungen gesperrt werden“). Diese beiden Aspekte hängen zusammen, erfordern aber sehr unterschiedliche Gespräche mit sehr unterschiedlichen Ansprechpartnern.

Bei einer Plattform wie SciSurehat dieser Übersetzungsprozess echte technische Konsequenzen.

Die wissenschaftliche Management-Plattform von SciSure übernimmt die Experimentdokumentation, das Probenmanagementsowie die Protokollstandardisierungund deckt dabei die Forschungsdokumentation über das elektronische Laborbuch (ELN) sowie die Bestandsführung über die Proben- und Lagerverwaltungab.

Der Business Analyst muss verstehen, welche dieser Module zum Projektumfang gehören, wie sie interagieren und welche Datenstandardisierung erforderlich ist, bevor der erste Nutzer das System produktiv einsetzt. Funktionen und Arbeitsabläufe variieren je nach lizenzierten Modulen und Systemkonfiguration, daher muss dieses Gespräch über den Projektumfang frühzeitig stattfinden.

Eine Schlüsselgruppe, die das Unternehmen tatsächlich repräsentiert

Bei einem großen Universitätsprojekt, an dem ich mitgearbeitet habe, stellten wir eine Schlüsselgruppe von 36 bis 40 Personen zusammen: Einrichtungsleiter, Forscher, Forschungsleiter sowie Mitarbeiter aus verschiedenen Fakultäten und Instituten. Diese Gruppe traf Konfigurationsentscheidungen, etwa ob für jedes Experiment eine Unterschrift erforderlich sein sollte oder wie Lagereinheiten benannt werden. Ihre Entscheidungen wurden dokumentiert und das System entsprechend konfiguriert.

Ohne eine repräsentative Gruppe, die diese Entscheidungen trifft, landet man bei einem Systemadministrator (oft eine einzelne Person), der willkürliche Entscheidungen trifft, die 5.000 Nutzer entweder befolgen oder stillschweigend ignorieren werden.

Dies ist besonders wichtig bei einer Plattform wie SciSure, deren System bewusst darauf ausgelegt ist, nach Organisation, Gruppe und Rolle konfiguriert zu werden. Der Zugriff wird über ein Berechtigungsmodell gesteuert, das auf Gruppen-, Organisations- oder Systemadministratorebene verwaltet wird. Was eine Gruppe sieht und bearbeiten kann, unterscheidet sich von dem, was eine andere Gruppe sieht. Diese Grenzen müssen vor der Einführung bewusst festgelegt, dokumentiert und fixiert werden. Die Hauptnutzergruppe entscheidet darüber, wer diese Vorgaben trifft.

‍IT-Support mit der richtigen Qualifikation

Datenmigration in großem Maßstab ist keine Aufgabe für eine einzelne Person und erst recht nichts, das man einem Forscher übertragen kann, der gerade einen freien Nachmittag hat. Eine saubere Migration erfordert jemanden, der Tools entwickeln kann. In unserem Fall bedeutete das ein benutzerdefiniertes Excel-Makro, das unübersichtliche Probendaten in gemischten Formaten aufnehmen und in der korrekten Importstruktur ausgeben konnte. Diese Fähigkeit muss vor Beginn der Einführung geplant und mit Ressourcen ausgestattet werden, anstatt erst auf halbem Weg festzustellen, dass sie fehlt.

Über die Migration hinaus benötigen Sie IT-Expertise für die Konfiguration von Single Sign-On, die Einhaltung von Cybersicherheitsrichtlinien und Integrationsentscheidungen bei sich überschneidenden Systemen. Bei SciSure bedeutet dies auch, sich Gedanken über die Wahl des Bereitstellungsmodells zu machen. SciSure unterstützt Public Cloud, Private Cloud, On-Premises sowie ein hybrides Speichermodell, bei dem die Plattform in der Cloud läuft, große Dateipakete jedoch je nach Bereitstellung auf einem vom Kunden verwalteten lokalen Server gespeichert werden. Jede Option hat unterschiedliche Auswirkungen auf Infrastruktur und Sicherheit, die von der IT vor Abschluss der Beschaffung bewertet werden müssen.

Governance beginnt nicht erst beim Go-Live

Eines der größten Missverständnisse bei der Implementierung von Unternehmenssoftware ist, dass die Governance erst mit der Inbetriebnahme des Systems beginnt. In Wirklichkeit startet sie viel früher.

Bevor sich der erste Forscher anmeldet, müssen sich Organisationen auf Namenskonventionen, Organisationsstrukturen, Standards für Probentypen, Benutzerrollen, die Verantwortung für Vorlagen, Änderungskontrollprozesse und Entscheidungswege einigen. Diese Entscheidungen bestimmen, ob die Plattform mit zunehmender Nutzung konsistent bleibt.
‍

Ohne eine vereinbarte digitale System-Governance führen Organisationen nicht nur zu inkonsistenten Daten. Sie führen zu inkonsistenten Arbeitsweisen. 

Verschiedene Gruppen entwickeln ihre eigenen Standards, das Berichtswesen wird unzuverlässig und jede zukünftige Änderung wird schwieriger umzusetzen. Diese Inkonsistenzen selten werden sofort sichtbar, summieren sich jedoch mit der Zeit, was Berichterstattung, Zusammenarbeit und zukünftige Systemänderungen zunehmend erschwert.

Die Software bietet die Funktionalität. Die Governance bestimmt, ob diese Funktionalität über die Zeit hinweg konsistent, vertrauenswürdig und skalierbar bleibt.

Meiner Erfahrung nach in Forschungsinstituten, Universitäten und bei der Implementierung wissenschaftlicher Unternehmenssoftware bildete die Governance stets das Fundament für alle nachfolgenden Aktivitäten – von der Standardisierung der Probentypen und Organisationsstrukturen bis hin zu Schulungen, der Reihenfolge der Einführung und dem Übergang in den laufenden Betrieb. Sobald diese Governance-Entscheidungen getroffen waren, ließ sich die Implementierung deutlich einfacher skalieren, da jede neue Forschungsgruppe, jedes Labor und jede Organisationseinheit nach demselben vereinbarten Betriebsmodell eingebunden werden konnte.

Wie ein realistischer Zeitplan für eine Unternehmensimplementierung aussieht

Phase 1: Anforderungen und Beschaffung (typischerweise 3–12 Monate)

Der Beschaffungsprozess auf Unternehmensebene ist keine bloße Formalität. In Institutionen mit formellen Ausschreibungspflichten umfasst diese Phase die Erstellung eines Beschaffungspakets (einschließlich Anforderungsdokumenten, Cybersicherheitsfragebögen und Vertragsentwürfen), das anschließend in gestaffelten Wellen an mehrere Anbieter gesendet wird. Sie evaluieren viele, treffen eine Vorauswahl und senden das vollständige Paket an die Finalisten.

Allein diese Phase kann sechs Monate bis ein Jahr in Anspruch nehmen, wenn die Organisation stark governance-orientiert ist. Planen Sie dies entsprechend ein. Nutzen Sie vor der Ausgabe eines vollständigen Beschaffungspakets unseren Leitfaden zu Benchling-Alternativen für Unternehmenslabore um zu prüfen, ob die jeweilige Plattform zu Ihrem Betriebsmodell passt.

Phase 2: Benutzerakzeptanztests (2–3 Monate)

Bevor ein einziger Benutzer mit dem System arbeitet, müssen Sie überprüfen, ob es tatsächlich die Anforderungen erfüllt. Benutzerakzeptanztests bedeuten, detaillierte Testfälle und Schritt-für-Schritt-Anleitungen für jeden Kernarbeitsablauf zu schreiben und Freiwillige aus der gesamten Organisation zu rekrutieren, die diese durchlaufen. Ziel ist es, etwaige Lücken im System aufzudecken und diese entweder zu beheben oder eine fundierte Entscheidung zu treffen, dennoch fortzufahren.

Wenn das System kritische Tests nicht besteht, benötigen Sie eine vertragliche Ausstiegsklausel. Stellen Sie sicher, dass diese im Vertrag enthalten ist.

Phase 3: Systemdesign und Konfiguration

Nach erfolgreichem UAT gehen Sie in die Designphase über. Hier zahlt sich die Arbeit der wichtigsten Nutzergruppe aus. Konfigurationsentscheidungen werden getroffen, dokumentiert und fixiert – zumindest so weit, wie es das System zulässt. Das System wird mit Ihrer Organisationsstruktur, Ihren Probentyp-Vorlagen, Ihrer Lagerhierarchie und Ihrem Benutzerzugriffsmodell eingerichtet.

Bei SciSure ist dies auch die Phase, in der Sie modulspezifische Konfigurationen durcharbeiten. 

• Das Proben- und Bestandsmanagement von SciSure erfordert, dass Ihre Lagerhierarchie und Ihre Probentyp-Vorlagen finalisiert sind. 
• Die Protokollbibliothek von SciSure erfordert, dass Ihre SOPs geladen und standardisiert sind, bevor Gruppen beginnen, davon abzuweichen. 
• Wenn Sie Inspektionen, Abfallmanagement oder Schulungsnachverfolgungaktivieren, müssen diese Arbeitsabläufe konfiguriert werden, bevor die Benutzer in der Praxis damit in Berührung kommen.

Einige dieser Funktionen variieren je nach Modul und Bereitstellung. Es lohnt sich daher, zu prüfen, was in Ihrer Instanz aktiviert ist, bevor Sie die Schulungsunterlagen erstellen.

Dies ist auch die Phase, in der Sie möglicherweise feststellen, dass Ihr organisatorischer Kontext bestimmte Workarounds oder benutzerdefinierte Konfigurationen erfordert. Keine Unternehmensbereitstellung ist Plug-and-Play. Wenn Sie sich dessen von Anfang an bewusst sind und dies als Anlass nehmen, sich eng mit dem Implementierungsteam Ihres Anbieters abzustimmen, verhindern Sie, dass solche Momente später zu bösen Überraschungen führen.

Phase 4: Phasenweiser Rollout nach Gruppen

Die Einführung für Tausende von Benutzern auf einmal ist selten eine effektive Strategie. Ein nachhaltigerer Ansatz ist die sequenzierte Implementierung: Priorisieren Sie Organisationen, dann Gruppen innerhalb dieser Organisationen und legen Sie anschließend die Reihenfolge der Gruppen basierend auf Bereitschaftskriterien fest.

Bei einem großen Unternehmensprojekt, das ich leitete, haben wir die Abteilungen nach dem Anteil der Forschungsgruppen bewertet, die regulierte Proben verwalteten, da behördliche Meldepflichten der Hauptgrund für die Einführung im Unternehmen waren. Innerhalb jeder Organisation wurden die Gruppen danach sortiert, ob ihr Probeninventar für eine Migration in einem angemessenen Zustand war und ob sie innerhalb des Zeitfensters für die Einführung verfügbar waren.

Für jede Gruppe folgte der Onboarding-Prozess einer einheitlichen Struktur: Bestätigung des Projektumfangs, Einrichtung der Lagereinheiten, Probenmigration, Benutzerschulung, Go-Live und eine Phase intensiver Betreuung mit engmaschiger Überwachung der Akzeptanz. Erst danach gingen die Gruppen in den regulären Support über.

Dieses Modell bedeutete die Einführung von etwa 60 Nutzern pro Monat, was ein zweiköpfiges Team nachhaltig betreuen kann. Wenn Ihr Team größer ist, können Sie skalieren. Die Struktur bleibt jedoch dieselbe.

Was Forscher benötigen, um das System zu nutzen

Bei einer Implementierung hatten wir 290 Lizenzen vergeben, aber nur 170 aktive Nutzer. Wir hatten im gleichen Zeitraum 175 Nutzer geschult. Der Zusammenhang war offensichtlich.

Schulungen müssen nicht nur vermitteln, wie die Software allgemein funktioniert, sondern wie sie in Ihrem Unternehmen konfiguriert wurde. Bei SciSure passt sich die Benutzeroberfläche dynamisch an , basierend auf den lizenzierten Modulen Ihres Unternehmens und den Berechtigungen Ihrer Rolle. Ein Forscher und ein Gruppenadministrator in derselben Gruppe sehen zwar dieselben Module, stoßen aber auf völlig unterschiedliche Menüs, Schaltflächen und verfügbare Aktionen. Beide sehen wiederum etwas anderes als ein Organisationsadministrator, der die Lagerung und den Zugriff über mehrere Gruppen hinweg verwaltet.

Allgemeine Anbieterdokumentationen decken diese Unterschiede nicht ab. Das ist interne Dokumentation, und jemand muss sie schreiben, pflegen und zugänglich machen.

Wenn Sie ein System ohne interne Schulungsunterlagen einführen und die Person, die es aufgebaut hat, das Unternehmen verlässt, geht das Wissen mit ihr verloren.

Schulungen beseitigen die erste Hürde für die Akzeptanz. Die zweite Hürde betrifft den Fall, dass etwas nicht wie erwartet funktioniert: Forscher und Administratoren benötigen einen strukturierten Weg, um Probleme zu melden, ohne dass alles im Posteingang einer einzelnen Person landet. Wenn die IT-Infrastruktur dies bereits unterstützt (eine ServiceNow-Instanz, Jira Service Management oder Ähnliches), lohnt es sich, frühzeitig eine Service-Desk-Warteschlange für das System einzurichten.

Eine gut konfigurierte Warteschlange leistet mehr als nur das Protokollieren von Tickets. Sie unterstützt die Priorisierung, leitet Probleme an die zuständigen Experten weiter und erstellt einen durchsuchbaren Datensatz was die wiederholte Bearbeitung reduziert. Dies ist besonders bei der Eskalation an Anbieter wertvoll, da ein dokumentierter Reproduktionspfad und eine Referenznummer die Lösung beschleunigen und die Nachvollziehbarkeit gewährleisten können.

Wenn Forschende das System tatsächlich annehmen und als wirklich nützlich empfinden, spricht sich das herum. Proben tauchen auf. Experimente werden protokolliert. Andere Gruppen fragen, wann sie an der Reihe sind. Ein gut implementiertes System verkauft sich intern von selbst, aber nur, wenn die ersten Anwendergruppen eine so positive Erfahrung machen, dass sie darüber berichten.

Für einen genaueren Blick darauf, wie diese Adoptionskurve in der Praxis tatsächlich aussieht, bietet unser Leitfaden zum Thema Implementierung eines ELN in einem bestehenden Labor detaillierte Informationen.

Was Führungskräfte vor der Unterzeichnung wissen müssen

Der Business Case für Labormanagement-Software konzentriert sich meist auf Zeitersparnis und Compliance-Bereitschaft. Beides ist real. Aber der Business Case muss auch die Implementierungskosten ehrlich adressieren, einschließlich nicht nur der Lizenzgebühren, sondern der Gesamtkosten für ein dediziertes Projektteam, IT-Ressourcen, die Entwicklung von Schulungen und eine anhaltende Phase intensiver Betreuung.
‍

Führungskräfte, die die Software genehmigen, ohne die Implementierungsinfrastruktur zu unterstützen, lassen das Projekt von vornherein scheitern.

Das System wird zu einem weiteren Werkzeug, auf das die Forschenden zwar technisch Zugriff haben, dem sie aber nicht vertrauen, das sie nicht nutzen und das sie schließlich durch Tabellenkalkulationen umgehen.

Eine gut durchgeführte Implementierung bietet Ihnen Echtzeit-Transparenz über Ihren regulierten Probenbestand und Ihre gesamten Forschungsabläufe, dokumentiert durch das ELN und die Protokoll-Workflows von SciSure. Der Unterschied zwischen einer Implementierung, die dieses Versprechen einlöst, und einer, die es nicht tut, liegt selten an der Software selbst. Er liegt in der organisatorischen Investition, um sie zum Erfolg zu führen.

Egal, ob Sie gerade erst am Anfang stehen, sich mitten in der Einführung befinden und den Druck spüren oder bereits in den Regelbetrieb übergehen: die entscheidenden Fragen drehen sich um die Verantwortlichkeiten: Wer trifft Entscheidungen, wer leistet Unterstützung, wer eskaliert, wer berichtet und wer stellt sicher, dass die Standards nicht aufgeweicht werden, sobald das Implementierungsteam das Projekt verlässt.
‍
Halten Sie diese Antworten schriftlich fest, bevor Sie live gehen. SciSure ist auf Skalierbarkeit ausgelegt, und mit der richtigen Governance gilt das auch für Ihr Unternehmen.