Laborausstattung und Gerätemanagement

Das echte Ausmaß des Problems

Das Logbuch-Problem ist kein Ausnahmefall. Es ist die Regel.

Laut einer Analyse von IntuitionLabs (2024) zeigen 85 Prozent aller kritischen Laborgeräteausfälle nachweisbare Degradationsmuster drei bis achtzehn Monate vor dem Zusammenbruch — in Logbüchern, Kalibrierprotokollen und Fehlercodes, die routinemäßig aufgezeichnet, aber nie systematisch ausgewertet werden. Ein GC-MS, das in der dritten Woche vor dem Ausfall zehnmal neu gestartet werden musste, wäre für ein System, das diese Daten liest, eine rote Flagge. Für einen Laborleiter, der jeden Montag einen Wochenbericht schreibt, ist es unsichtbar.

An Universitäten und Hochschulen verschärft sich das Problem durch eine Eigenart der Infrastruktur: Geräte werden von wechselnden Nutzenden bedient — Doktoranden, Masterstudierende, Gastwissenschaftler. Jede Person macht ihre Einträge anders. Niemand hat den vollständigen Überblick. Der einzige Mensch, der alle Einträge kennt, ist niemand.

Die Folgen sind systematisch:

• Ungeplante Ausfälle treffen immer dann, wenn Messzeitfenster nicht mehr verschiebbar sind — kurz vor Einreichungsfristen, nach Bewilligungen, während Probenzyklen
• Kalibrierfristen werden in Excel-Tabellen oder Papierlisten verfolgt, die je nach Zuständigkeit mal aktuell sind und mal nicht. Nach einem Personalwechsel klaffen Lücken von Monaten
• Geräteauslastung liegt laut Schätzungen aus Hochschullaboren oft bei 30–50 Prozent der theoretisch verfügbaren Zeit — während für manche Messzeiten wochenlange Wartelisten entstehen, stehen andere Geräte seit Tagen

Die direkten Reparaturkosten für ein LC-MS oder GC-MS liegen bei 10.000–30.000 Euro pro kritischem Schadensfall (Quelle: LabTechSupport, 2024). Dazu kommen die indirekten Kosten: verlorene Proben, verzögerte Publikationen, Nacharbeitsaufwand für Doktoranden — Größenordnungen, die nie in einem Reparaturticket auftauchen.

Mit vs. ohne KI — ein ehrlicher Vergleich

Die Suchaufwands-Vergleichswerte im Logbuch-Szenario stammen aus Erfahrungsberichten aus Forschungslaboren (IntuitionLabs, 2024). Die Auslastungsschätzung basiert auf Befragungen von Hochschulinstituten (Oxmaint, 2024).

Einschätzung auf einen Blick

Zeitersparnis — niedrig (2/5) Das ist der ehrlichste Score in dieser Kategorie: Ein KI-gestütztes Gerätemanagementsystem spart keine täglichen Arbeitsstunden in dem Sinne, wie es ein Schreibassistent tut. Was es tut: Es verhindert den Totalausfall am falschen Tag — und die eine Woche Nacharbeit, die folgt. In der Forschung ist das keine kleine Zahl, aber sie tritt selten auf. Wer täglich Zeit sparen will, braucht andere Ansätze. Wer kritische Ausfälle verhindern will, braucht diesen.

Kosteneinsparung — mittel (3/5) Die Einsparung ist real, aber episodisch: Sie materialisiert sich nicht monatlich, sondern dann, wenn ein Ausfall verhindert wurde. Die Reparaturkosten bei einem GC-MS oder HPLC liegen typischerweise bei 10.000–30.000 Euro pro kritischem Schaden — das ist ein konkreter Betrag, den man vergleichen kann. Was schwieriger zu beziffern ist: der wissenschaftliche Schaden durch verzögerte Ergebnisse, verlorene Proben, nicht eingehaltene Fristen. Die laufenden Kosten für präventive Wartungsverträge sind dagegen planbar und bei systematischer Analyse oft um 15–25 Prozent reduzierbar.

Schnelle Umsetzung — niedrig (2/5) Bis ein System tatsächlich verwertbare Anomalien erkennt, braucht es eine Datengrundlage. Logbuchmigration, Kalibrierhistorien erfassen, Geräte anlegen, Nutzerrechte konfigurieren — das dauert in einem realen Institut mit zehn bis zwanzig Geräten realistisch zehn bis vierzehn Wochen. Wer in drei Wochen ein funktionierendes Dashboard will, wird enttäuscht. Wer zwölf Wochen investiert und danach mit strukturierten Daten arbeitet, hat eine deutlich andere Ausgangslage.

ROI-Sicherheit — mittel (3/5) Man kann die mittlere Betriebsdauer zwischen Ausfällen (MTBF) messen, Kalibrierfristen überwachen und Reparaturkosten vergleichen. Was sich nicht messen lässt: der Ausfall, der nicht stattgefunden hat. Das ist das klassische Präventions-Paradox — ein gutes System macht sich selbst unsichtbar. Der ROI ist real, aber retrospektiv schwer zu beziffern. Labore, die ihn explizit belegen wollen, müssen Baselinedaten aus den ersten sechs Monaten vor dem System festhalten.

Skalierbarkeit — hoch (4/5) Ein digitales Gerätemanagementsystem wächst gut: mehr Geräte, mehr Nutzer, weitere Labore im selben Institut — das ist kein separates Projekt, sondern eine Erweiterung der Datenbank. Für Universitätsinstitute mit mehreren Arbeitsgruppen und geteilter Infrastruktur ist das ein echter Vorteil. Nicht maximal bewertet, weil Multi-Campus-Rollouts koordinierten Datenschutzaufwand mit sich bringen.

Richtwerte — stark abhängig von Geräteanzahl, vorhandener Dokumentationsbasis und Datenschutzkonfiguration.

Was das System konkret macht

Der technische Kern ist weniger glamourös als das Wort „KI” suggeriert — und deswegen funktioniert es.

Das System erfasst alle Logbucheinträge digital: Fehlermeldungen, Wartungsmaßnahmen, Druckwerte beim GC-MS, Kalibrierungsabweichungen beim HPLC, Reparaturnotizen vom Servicetechniker. Diese Einträge werden nicht nur gespeichert, sondern zeitlich und gerätespezifisch ausgewertet. Machine Learning-Algorithmen erkennen Muster, die ein Mensch übersieht — nicht weil der Mensch unaufmerksam ist, sondern weil er nicht gleichzeitig elf Geräte im Blick hat und Monatsverläufe im Kopf behalten kann.

Was das konkret bedeutet:

• Anomalieerkennung im Logbuch: Wenn ein Gerät innerhalb eines Monats sechsmal mit „leichtem Druckabfall” notiert wird und normalerweise ein Eintrag pro Woche üblich ist, flaggt das System diese Häufung. Der Laborleiter sieht eine Warnung — nicht nach dem Ausfall, sondern davor.
• Kalibrierungsplanung: Das System überwacht alle Kalibrierfristen automatisch und sendet Erinnerungen gestaffelt — 30 Tage, 7 Tage, 1 Tag vor Fälligkeit. Wenn eine Kalibrierung überfällig ist, erscheint sie in der Geräteübersicht rot. Wenn ein Gerät eine systematische Drift zeigt (beim letzten Mal war der Messfehler 0,3 %, beim vorletzten 0,1 %), erkennt das System den Trend und empfiehlt einen kürzeren Kalibrierungszyklus.
• Buchungsoptimierung: Der integrierte Buchungskalender zeigt, wann welches Gerät wirklich genutzt wird — und wann es steht. Das ermöglicht evidenzbasierte Entscheidungen: Lohnt sich eine zweite Schicht? Welches Gerät braucht eine Nutzungsregel? Wann ist der beste Zeitpunkt für Wartungsarbeiten ohne Messunterbrechung?
• Reparaturhistorie: Bei einem Ausfall zeigt das System alle zurückliegenden Einträge zu diesem Gerät — Wartungsmaßnahmen, Fehlercodes, Kalibrierungsdaten. Das macht die Diagnose des Servicetechnikers schneller und die Entscheidung „reparieren oder ersetzen” datenbasierter.

Was ihr datenseitig braucht

Das ist der entscheidende Abschnitt — und der, der in Verkaufspräsentationen gerne übersprungen wird.

KI-gestütztes Gerätemanagement ist kein Werkzeug, das man in ein Papierlabor einführt und das ab sofort alles weiß. Es braucht eine Datengrundlage. Und die ist in vielen Forschungslaboren entweder nicht vorhanden, nicht strukturiert oder nicht zugänglich.

Was vorhanden sein muss, bevor ein System Mehrwert liefert:

Mindestens zwölf Monate Wartungshistorie pro Gerät — also Einträge zu Fehlermeldungen, Reparaturen und Auffälligkeiten. Diese können aus Papierdokumenten migriert werden, aber jemand muss das tun. Für ein Labor mit zwanzig Geräten und je einem Papierbuch der letzten drei Jahre: kalkuliere drei bis vier Wochen interner Aufwand.

Eine vollständige Geräteliste: Hersteller, Modell, Seriennummer, Standort, wer das Gerät betreut, welche Kalibrierintervalle gelten. Das klingt trivial, aber in Instituten ohne zentrales System fehlen diese Stammdaten überraschend oft.

Eine klare Entscheidung, wer Daten einträgt und wer sie auswertet. Ein System, in das Einträge gemacht werden, wenn jemand Lust hat, ist kein System — es ist eine Sammlung zufälliger Daten. Ohne benannte Verantwortliche für jedes Gerät läuft das System leer.

Was nicht vorhanden sein muss:

Sensortelemetrie. Viele Laborgeräte geben keine Echtzeit-Sensorwerte aus, die sich extern abgreifen lassen — das ist keine Voraussetzung für diesen Ansatz. Das Logbuch-basierte Anomalie-Erkennen funktioniert ohne Sensoren, es braucht nur strukturierte Einträge.

Eigenes IT-Personal. Moderne Labormanagementwerkzeuge sind als SaaS betreibbar und in einem vernünftigen Browser konfigurierbar — ohne Systemadministrator.

Kalibrierungsmanagement und DIN EN ISO 17025

Für akkreditierte Prüf- und Messlabore — oder für Labore, die auf dem Weg zur Akkreditierung sind — ist Kalibrierungsmanagement keine Kür, sondern Pflicht.

Wichtiger Hinweis vorab: DIN EN ISO/IEC 17025 stellt spezifische Anforderungen, die von einem Softwaresystem allein nicht erfüllt werden können. Die Norm fordert unter anderem: dokumentierte Kalibrierverfahren, rückverfolgbare Referenznormale, kompetentes Personal, das die Kalibrierungen durchführt, und Messunsicherheitsbetrachtungen. Ein digitales Verwaltungswerkzeug unterstützt die Dokumentation und Fristüberwachung — es ersetzt nicht die inhaltliche Kalibrierungsarbeit und nicht die externe Akkreditierung durch die DAkkS (Deutsche Akkreditierungsstelle). Wenn ihr nicht sicher seid, welche Anforderungen in eurem Fall gelten, sprecht zunächst mit eurem Qualitätsmanagementbeauftragten oder einem akkreditierten Prüfinstitut.

Was ein gutes digitales System konkret leisten kann:

Kalibrierhistorien vollständig, revisionssicher und mit Prüfer-Signatur dokumentieren. Kalibrierfristen automatisch überwachen und Eskalationspfade bei Überschreitung einrichten. Drifttrends über mehrere Kalibrierzyklen hinweg erkennen und dokumentieren. Alle Unterlagen audit-ready bereitstellen — keine Suche in Schubladen mehr bei einer Inspektion.

Spezialisierte Software für diesen Zweck: Beamex CMX ist auf Kalibrierungsmanagement ausgelegt, erzeugt auditfeste Berichte nach ISO 17025 und erkennt Drifttrends automatisch. Für Labore mit Beamex-Kalibriergeräten lässt sich ein vollständig papierloser Kalibrierworkflow aufbauen.

Konkrete Werkzeuge — was wann passt

Es gibt keinen Single-Stack-Gewinner. Was passt, hängt davon ab, wie groß das Labor ist, ob GxP-Compliance eine Rolle spielt und ob man primär Logbücher digitalisieren oder Kalibrierungen verwalten will.

LabThunder — für Forschungslabore und Hochschulinstitute Deutsches Produkt der Be2Byte GmbH aus Magdeburg, entwickelt für genau diesen Kontext: Forschungs- und Analyselabore mit wechselnden Nutzenden. Digitale Logbücher, automatische Wartungsplanung, Thunder AI für Anomalieerkennung in Eintragshistorien, integrierter Buchungskalender. ISO 17025, ISO 15189 und GMP/GLP-konform dokumentiert. Kunden u. a. JGU Mainz. Preise: keine öffentliche Preisliste, Demo auf Anfrage. Stärke: vollständig auf Deutsch, ausdrücklich für akademische Kontexte konzipiert. Einschränkung: keine Echtzeit-Sensorintegration — das System arbeitet auf Basis von Logbucheintragen, nicht Gerätesensorik.

Limble CMMS — für größere Institute mit Predictive-Maintenance-Ambitionen Cloud-CMMS, das neben Wartungsmanagement auch Predictive-Maintenance-Module enthält, inklusive IoT-Sensor-Anbindung. Standard ab 28 USD pro Nutzer/Monat. Stärke: Wenn Geräte Sensor-Telemetrie ausgeben und man diese anbinden will, ist Limble deutlich leistungsfähiger als logbuchbasierte Systeme. Einschränkungen: ausschließlich auf Englisch, Datenhaltung in den USA (kein EU-Hosting), für stark regulierte Umgebungen nicht geeignet.

MaintainX — als Einstieg ohne Budget Freemium-CMMS mit kostenlosem Basispaket (unbegrenzte Nutzer). Geeignet für den ersten Schritt: Geräteinventar anlegen, Wartungsaufträge erstellen, Ausfälle dokumentieren. Kein KI-Auswertemodul im freien Plan. Nützlich als Datensammlungsphase, bevor man in ein spezialisiertes System investiert. Ebenfalls englischsprachig, US-Hosting.

Beamex CMX — für Kalibrierungsmanagement nach ISO 17025 Spezialisiertes Tool ausschließlich für Kalibrierungsmanagement — nicht für allgemeines Gerätemanagement. Wenn das Primärproblem Kalibrierfristen und Drift-Erkennung sind, ist das die richtige Wahl. Integration mit LabWare LIMS möglich. Ab ca. 2.000 € Einmallizenz, Cloud-Version als Jahresabonnement.

LabArchives — für elektronische Laborbücher mit Geräte-Referenzierung Primär ein Electronic Lab Notebook (ELN), kein CMMS. Geeignet, wenn das Ziel ist, Versuchsprotokolle zu digitalisieren und dabei Gerätenutzungen zu referenzieren. Kein eigenes Predictive-Maintenance-Modul. Sinnvoll in Kombination mit einem separaten CMMS, wenn beides gebraucht wird.

Zusammenfassung: Wann welcher Ansatz

• Hochschulinstitut, Sprache Deutsch, keine GxP-Pflicht → LabThunder
• Institut mit GxP-Anforderungen und Kalibrierungsdokumentation im Vordergrund → Beamex CMX
• Einstieg ohne Budget, erste Digitalisierung → MaintainX (freier Plan)
• Größeres Institut, IoT-Sensorik gewünscht, Englisch kein Hindernis → Limble CMMS
• ELN zusätzlich nötig (Versuchsprotokolle) → LabArchives parallel zu einem CMMS

Datenschutz und Datenhaltung

Wartungshistorien und Kalibrierprotokolle enthalten zwar in der Regel keine personenbezogenen Daten im DSGVO-Sinne — es gibt keine Gesundheitsdaten, keine Kundendaten. Was vorkommt: Namen von Technikerinnen und Technikern in Logbucheinträgen, Buchungsdaten von Nutzenden, ggf. Projektbezug bei externen Forschungspartnern.

Das ist relevant: Sobald Nutzende im Buchungssystem namentlich erfasst werden und Buchungshistorien gespeichert sind, gelten die DSGVO-Anforderungen für personenbezogene Verarbeitungen. Das bedeutet konkret: Auftragsverarbeitungsvertrag (AVV) mit dem Softwareanbieter, falls der Anbieter Daten verarbeitet — und das tut er, wenn es sich um SaaS handelt.

Was die genannten Tools bieten:

LabThunder ist ein deutsches Produkt, Hosting in Deutschland. Das vereinfacht den DSGVO-Weg erheblich: kein Drittlandtransfer, AVV nach deutschem Standard ohne Sonderregelung.

Limble CMMS und MaintainX hosten in den USA — für Forschungseinrichtungen mit EU-Datenschutzanforderungen relevant. Limble bietet keinen EU-Datenvertrag im Standard; für Hochschulen mit eigenem Datenschutzbeauftragten vor dem Einsatz klären.

Beamex CMX bietet EU-Hosting und ist explizit auf regulierte Umgebungen ausgerichtet.

Für Labore, die Drittmittel verwalten und dabei Nutzungsdaten von Gastwissenschaftlern aus Partnerinstitutionen speichern: Das muss in der Drittmittelvereinbarung oder einer eigenen Datenverarbeitungsabrede geregelt sein.

Was es kostet — realistisch gerechnet

Einmalige Einrichtungskosten

Der aufwendigste Teil ist nicht die Software — es ist die Datenmigration. Papierdokumente einscannen, strukturieren und migrieren: typisch drei bis sechs Wochen interner Aufwand bei einem Labor mit fünfzehn bis zwanzig Geräten. Wenn externe Hilfe herangezogen wird: 1.500–4.000 Euro für einen initialen Einführungsworkshop mit Datenmigration.

Die Softwarekosten selbst sind überschaubar:

• LabThunder: Keine öffentliche Preisliste, Demo auf der Website. Erfahrungsgemäß vergleichbar mit anderen SaaS-Laborplattformen — niedrig dreistellig pro Monat für ein mittelgroßes Institut.
• Limble CMMS: Ab 28 USD pro Nutzer/Monat im Standard-Plan.
• MaintainX: Basispaket kostenlos.
• Beamex CMX: Ab ca. 2.000 Euro Einmallizenz.

Laufende Kosten

Zwischen 100 und 400 Euro pro Monat für eine SaaS-Laborplattform im Institut-Maßstab ist ein realistischer Rahmen. Dazu kommen interne Personalkosten für die Datenpflege: typisch zwei bis vier Stunden pro Woche, wenn Einträge strukturiert gemacht werden.

Was du dagegenrechnen kannst

Ein einzelner vermiedener Kritikalausfall eines GC-MS oder HPLC spart 10.000–30.000 Euro an Reparaturkosten (Quelle: LabTechSupport, 2024). Dazu kommen Folgekosten: Servicetechniker-Notfalleinsatz, Leihgerät, Proben-Neupräparation, Verzögerungskosten.

Für ein Institut mit fünf bis zehn kritischen Messgeräten (GC-MS, HPLC, ICP-MS, Elektronenmikroskop) und einem mittleren Ausfallintervall von einmal alle zwei bis drei Jahre ohne Wartungssystem: Ein einziger verhindeter Ausfall amortisiert zwei bis drei Jahre Systemlizenz. Das ist keine aggressive ROI-Rechnung, das ist konservativ.

Wie du den Nutzen misst

Zwei Kennzahlen, die du schon in Monat drei beginnen kannst zu erfassen:

MTBF (Mean Time Between Failures) pro Gerät — wie oft fällt Gerät X ungeplant aus? Gibt es eine Verbesserung gegenüber der Vor-System-Periode? Und: Wie viele Kalibrierfristen wurden in den letzten zwölf Monaten innerhalb des Soll-Fensters gehalten? Das sind harte Zahlen, die du in einem Jahresbericht oder einem Drittmittelnachweis sauber belegen kannst.

Typische Einstiegsfehler

1. Werkzeug einführen, Daten nicht migrieren.

Der häufigste Fehler: Das neue System wird installiert, Geräte werden angelegt — aber die Wartungshistorie der letzten drei Jahre bleibt im Papierbuch. Das System beginnt bei null. Es kann sechs bis zwölf Monate dauern, bis genug Daten für sinnvolle Anomalieerkennung vorhanden sind. Wer die Migration weglässt, verschiebt den Mehrwert um genau diese Zeit nach hinten.

2. Kein Eintragsstandard vereinbart.

Wenn zwanzig Nutzende im selben System Einträge machen, entstehen zwanzig verschiedene Schreibweisen für dieselbe Fehlerkategorie. „Pump failure”, „Pumpe ausgefallen”, „Druckproblem Pumpe”, „Fehler 0x3F08” — das System kann diese Einträge nicht als gleichwertig behandeln, weil sie es für die KI nicht sind. Vor dem Rollout: Standardkategorien definieren, ein Pflichtfeld für Fehlertyp anlegen, Eintragsvorlage für häufige Ereignisse.

3. Kalibrierungsplan nicht an das System übertragen.

Wenn die Kalibrierfristen weiter in einer Excel-Datei liegen, nützt das Erinnerungssystem der Software nichts. Das Übertragen aller Kalibrierungsintervalle in das System ist keine optionale Aufgabe für „später” — es ist Voraussetzung dafür, dass der Hauptnutzen für akkreditierte Labore eintritt.

4. Niemand ist für die Datenqualität zuständig.

Ein CMMS, in das jeder eintragen kann, aber niemand auswertet, ist nach achtzehn Monaten eine Datenhalde. Das System braucht eine namentlich benannte Person pro Gerätekategorie, die einmal monatlich die Einträge sichtet, offene Punkte eskaliert und die Qualität der Einträge überprüft. Das ist kein IT-Job, das ist ein Labormanagement-Job.

5. Sensor-Euphorie ohne Geräteanalyse.

Manche Institute starten mit dem Plan, alle Geräte mit IoT-Sensoren nachzurüsten. Das ist in der Regel weder nötig noch realistisch: Viele Laborgeräte sind nicht für externe Sensoranbindung ausgelegt, die Nachrüstung ist aufwendig, und der erste Mehrwert kommt fast immer aus strukturierten Logbuchdaten — nicht aus Telemetrie. Die Sensor-Vision kann ein Ziel sein, aber kein Startpunkt.

Was mit der Einführung wirklich passiert — und was nicht

Die Technik ist das Einfachste. Das Schwierigere ist die Verhaltensänderung.

Wer zwanzig Jahre lang einen Zettel ins Papierbuch geschrieben hat, schreibt nicht automatisch in eine App, weil die App jetzt vorhanden ist. Das ist keine Frage des Alters und keine Frage der Bereitschaft — es ist eine Frage der Gewohnheit und des wahrgenommenen Aufwands.

Was in der Praxis funktioniert:

Frühe Beteiligung der Gerätebetreuenden. Die Personen, die am häufigsten Einträge machen — oft technische Mitarbeitende oder erfahrene Postdocs — sollten bei der Einrichtung des Systems mitbestimmen: Welche Felder soll ein Eintrag haben? Welche Kategorien? Wer darf was sehen? Wer das System mitgestaltet hat, verteidigt es statt es zu umgehen.

QR-Code am Gerät. Wenn ein Tablet oder Smartphone die Logbuch-App per QR-Code direkt öffnet und der Eintrag in dreißig Sekunden erledigt ist, sinkt die Hemmschwelle deutlich. Geräte, die noch zwanzig Klicks ins System erfordern, werden weiter auf Papier dokumentiert.

Sichtbarer Nutzen in Woche vier. Zeig der Institutsleitung nach einem Monat das erste Bild: Welches Gerät hat die meisten Einträge? Wo häufen sich bestimmte Fehlercodes? Das ist keine magische KI-Auswertung — das ist einfache Datenvisualisierung, die vorher nicht möglich war. Diese erste Übersicht schafft Vertrauen und Motivation für weiteres Einpflegen.

Klarer Eskalationspfad. Was passiert, wenn das System eine Anomalie flaggt? Wer entscheidet, ob eine Wartung angesetzt wird? Ohne definierten Pfad bleibt die Warnung im System und wird ignoriert. Mit definiertem Pfad — Flagge → E-Mail an Gerätezuständige → Entscheidung binnen 48 Stunden — entsteht eine echte Feedback-Schleife.

Realistischer Zeitplan mit Risikohinweisen

Das System liefert die ersten verlässlichen Muster nach drei bis sechs Monaten im Vollbetrieb, nicht nach drei Wochen.

Häufige Einwände — und was dahintersteckt

„Wir haben schon ein Excel-Sheet für Wartungen.” Das Sheet existiert, wird es auch genutzt? In vielen Laboren liegt zwischen dem Plan und der tatsächlichen Dokumentation eine erhebliche Lücke. Die Frage ist nicht, ob ein Dokument vorhanden ist, sondern ob jemand es systematisch auswertet. Ein System, das automatisch flaggt und erinnert, macht den Unterschied — nicht das Format.

„Unsere Geräte sind so teuer, die lassen wir sowieso regelmäßig vom Hersteller warten.” Herstellerwartungen sind ein Kalibrierungsintervall, keine Garantie gegen ungeplante Ausfälle zwischen den Terminen. Die meisten kritischen Ausfälle ereignen sich nicht kurz vor dem Wartungstermin — sie entstehen aus schleichenden Prozessen, die zwischen zwei Herstellerbesuchen eskalieren. Genau dieses Intervall ist die Lücke, die ein Monitoring schließt.

„Wir sind ein kleines Institut, das lohnt sich nicht.” Stimmt ab einer bestimmten Grenze. Unter acht bis zehn Geräten und bei einem eingespielten Team ist der Einrichtungsaufwand tatsächlich größer als der Nutzen — ein gut geführtes Papierbuch mit einer zuständigen Person kann ausreichend sein. Ab zehn Geräten mit wechselnden Nutzenden und geteilter Infrastruktur kippt die Rechnung zugunsten des Systems.

„Was ist mit den Drittmittelgebern? Dürfen wir überhaupt externe Software für Forschungsdaten nutzen?” Wartungs- und Kalibrierungsdaten sind keine Forschungsdaten im Sinne des Forschungsdatenmanagements — sie sind administrative Infrastrukturdaten. Typischerweise unterliegen sie keiner Datenpublikationspflicht nach FAIR-Prinzipien. Dennoch: Wenn externe Nutzende (Gastwissenschaftler, Kooperationspartner) Buchungsdaten haben, ist eine kurze Klärung mit dem Datenschutzbeauftragten der Einrichtung ratsam.

Woran du merkst, dass das zu dir passt

Das passt:

• Du betreibst zehn oder mehr Geräte in mehreren Arbeitsgruppen oder Laboren, die geteilt genutzt werden
• Ihr dokumentiert Wartungen auf Papier oder in Excel, und diese Aufzeichnungen werden nicht systematisch ausgewertet
• In den letzten zwei Jahren gab es mindestens einen ungeplanten Geräteausfall, der einen Forschungsablauf verzögert hat
• Kalibrierfristen werden reaktiv verwaltet — jemand merkt kurz vorher, dass etwas fällig ist
• Neue Doktoranden und Studierende können nicht nachvollziehen, was mit einem Gerät zuletzt gemacht wurde
• Du möchtest Reparatur- und Wartungskosten in Drittmittelanträgen plausibler belegen können

Das passt (noch) nicht:

1. Weniger als acht Geräte, ein eingespieltes Team, eine Zuständige. Bei dieser Größe ist ein strukturiertes Papierbuch mit klarer Verantwortung die effizientere Lösung. Der Einrichtungsaufwand für ein digitales System übersteigt den Gewinn.

2. Keine Wartungshistorie vorhanden. Wenn alle bisherigen Aufzeichnungen unlesbar, verlorengegangen oder nie gemacht worden sind, braucht ihr zunächst sechs bis zwölf Monate Datensammlung, bevor ein System sinnvoll ausgewertet werden kann. Und das geht auch mit einem guten Papierbuch oder einer Excel-Tabelle — ohne sofortigen KI-Einsatz.

3. Geräteschnittstellen nicht zugänglich. Wenn eure teuersten Geräte proprietäre Systeme mit geschlossener Schnittstelle sind und keine Logbuchdaten ausgeben, bleibt nur die manuelle Eingabe. Das ist machbar, aber der Einstiegsaufwand ist dann höher als bei Geräten, die Daten aktiv exportieren.

Das kannst du heute noch tun

Mach eine einfache Übung, die zehn Minuten braucht und oft überraschende Ergebnisse liefert: Öffne dein Papierlogbuch oder deine Excel-Wartungsliste und zähle für die letzten zwölf Monate, wie viele Einträge das Gerät mit den meisten Ausfällen hat. Dann zähle, wie viele davon innerhalb von vier Wochen vor dem letzten Ausfall gemacht wurden.

Wenn die Antwort ist: „Wir haben keine strukturierte Liste” — dann ist das der erste Schritt. Nicht das System, sondern die Entscheidung, Daten überhaupt zu erfassen.

Für die KI-gestützte Analyse kannst du mit folgendem Prompt beginnen, um Muster in deinen bestehenden Wartungsnotizen zu erkennen:

Quellen & Methodik

• 85 % der Geräteausfälle mit Vorwarnsignalen: IntuitionLabs, „Predictive Maintenance for Lab Instruments: An ROI Analysis” (2024). intuitionlabs.ai. Anbieternahes Dokument; Kernaussage durch Oxmaint (2024) für Hochschulkontext bestätigt.
• 85 % kritischer Hochschul-Geräteausfälle mit Degradationsmustern: Oxmaint, „Lab Equipment Compliance and Uptime: AI & Predictive Analytics for Research Campuses” (2024). oxmaint.ai. Anbieternahes Dokument; als Größenordnung plausibel.
• Reparaturkosten LC-MS / GC-MS: LabTechSupport, „Cost Analysis: The Impact of Regular Maintenance vs. Major Repair in LC-MS Systems” (2024). labtechsupport.com. Reparaturdienstleister; Zahlen spiegeln Servicemarktpreise wider.
• iLab Solutions für akademische Core Facilities: Clemson University Research, „iLab Solutions — Core Facility Management Software” (2024). clemson.edu. Implementierungsbeispiel einer US-amerikanischen Hochschule.
• DIN EN ISO/IEC 17025-Anforderungen: DAkkS, „Prüf- und Kalibrierlabore / DIN EN ISO IEC 17025” (aktuell gültige Fassung). dakks.de.
• LabThunder-Produktinformationen: Be2Byte GmbH, labthunder.com, Stand Mai 2026. Keine öffentlichen Preise verfügbar; Funktionsbeschreibungen basieren auf Website-Angaben und Demomaterial.
• Implementierungskosten und Zeitrahmen: Erfahrungswerte aus Digitalisierungsprojekten in Forschungseinrichtungen (Institut-Größe 10–25 Geräte), Stand 2024–2026.

Du willst wissen, welches System zu eurer Institutsgröße passt und wie der realistische Einführungsaufwand bei euch aussieht? Meld dich — das klären wir in einem kurzen Gespräch.