Wenn ein Labor digitalisiert werden soll, läuft es meistens nach demselben Muster ab: Irgendjemand stellt fest, dass die Papierprotokolle oder das über Jahre gewachsene Excel-Chaos so nicht mehr tragbar sind, also wird ein Lastenheft geschrieben, eine Beratung oder ein Anbieter beauftragt und die obligatorische Feature-Demo terminiert. Anschließend fällt die Entscheidung für ein bestimmtes LIMS, das System wird eingeführt, und ein halbes Jahr später ist die Hälfte der Mitarbeitenden frustriert, während ein Viertel das System ganz anders nutzt, als es ursprünglich gedacht war.

Kommt einem bekannt vor?

Das ist kein Einzelfall, sondern die Regel, und das Erstaunliche daran ist nicht, dass es passiert, sondern dass die Branche weiter so tut, als handle es sich um ein reines Technikproblem.

Die Zahlen lügen nicht

53 % der Labore kämpfen mit Datencompliance-Problemen, 51 % mit Integrationsschwierigkeiten, und das, obwohl LIMS-Software seit Jahrzehnten existiert und der Markt hart umkämpft ist. In manchen Laboren laufen allein für die Analytik bis zu 100 verschiedene IT-Systeme parallel, und man könnte meinen, dass die Branche nach so vielen Jahren und Projekten inzwischen herausgefunden hätte, wie Labordigitalisierung funktioniert.

Hat sie aber nicht, zumindest nicht vollständig.

Der Grund dafür ist eigentlich naheliegend: Digitalisierungsprojekte scheitern fast nie an der Technologie, sondern an Menschen, Prozessen und Organisationsstrukturen, die im Vorfeld nicht mitgedacht wurden. Das ist kein gut gehütetes Geheimnis, sondern steht in jedem zweiten Artikel über Change Management, und trotzdem wird bei LIMS-Einführungen munter weiter über Datenbankarchitektur, API-Schnittstellen und Feature-Listen diskutiert, während die Frage „Wie nehmen wir die Leute eigentlich mit?" irgendwo hinten in der Projektplanung unter dem Stichwort „Schulungen" versteckt bleibt.

Was klassische IT-Beratung übersieht

Die typische Beratungsleistung bei Labordigitalisierung läuft nach einem vertrauten Schema ab: Anforderungsanalyse, Marktübersicht, Systemauswahl, Implementierung, Go-Live, alles sauber strukturiert und mit Gantt-Chart und Meilensteinen versehen.

Das Problem ist, dass diese Struktur ein Labor behandelt, als wäre es eine Maschine, bei der man ein Zahnrad austauscht, während es in Wirklichkeit ein soziales System mit ganz unterschiedlichen Akteuren ist. Da gibt es die Laborleiterin, die das neue System zwar befürwortet, aber im Tagesgeschäft keine Zeit findet, sich wirklich damit auseinanderzusetzen, den Laboranten mit zwanzig Jahren Erfahrung, der seine eigenen Excel-Sheets für unverzichtbar hält (nicht aus Sturheit, sondern weil er genau weiß, was dort drinsteckt und welche Annahmen sich über die Jahre eingeschlichen haben), und den IT-Verantwortlichen, der das Projekt vor allem als zusätzliche Last in einem ohnehin überfüllten Backlog empfindet. Mittendrin steht dann ein Hersteller, der versprochen hat, dass sein System praktisch alle Probleme löst.

Über Erfolg oder Misserfolg entscheiden am Ende diese Dynamiken, und eben nicht die Frage, ob das LIMS eine REST-API hat oder nicht.

Ich habe das selbst oft genug in Beratungsgesprächen erlebt: Man spricht in den ersten Minuten über Systemanforderungen und merkt nach einer halben Stunde, dass das eigentliche Gespräch gar nicht über Systeme geht, sondern über ungeklärte Verantwortlichkeiten, unterschiedliche Vorstellungen davon, wie das Labor in drei Jahren aussehen soll, oder über eine Führungsebene, die Digitalisierung primär als Kostensenkungsprojekt versteht, während die Mitarbeitenden den Eindruck gewinnen, dass ihre Erfahrung dabei keine Rolle mehr spielt.

Was systemische Beratung anders macht

Systemische Beratung ist kein Modewort aus dem Coaching-Bereich, auch wenn man das auf den ersten Blick vermuten könnte, sondern ein grundlegend anderer Ansatz: Statt Expertenlösungen von außen in die Organisation hineinzutragen, geht es darum, die ohnehin vorhandenen Ressourcen und das Wissen im System selbst zu aktivieren und nutzbar zu machen.

Das klingt auf den ersten Blick vielleicht weich, ist aber in der Sache knallhart pragmatisch. Wenn ich als Berater ein Labor begleite, weiß ich technisch zwar in der Regel mehr über LIMS als die meisten dort, aber ich weiß so gut wie nichts über die spezifischen Abläufe, die informellen Kommunikationswege, die latenten Konflikte und die stillen Experten, deren Erfahrungswissen nirgends dokumentiert ist. Dieses Wissen sitzt im Labor selbst, und meine Aufgabe besteht nicht darin, eine fertige Lösung zu liefern, sondern die richtigen Fragen zu stellen, damit die Organisation auf eine Lösung kommt, die sie anschließend auch wirklich trägt.

Konkret heißt das:

• Stakeholder früh einbinden, nicht als Pflichtübung am Ende, sondern von Anfang an als Mitgestalter des Prozesses
• Widerstand ernst nehmen: Wer sagt „das brauchen wir nicht", hat meistens einen guten Grund, den es zu verstehen gilt, bevor man ihn überstimmt
• Piloten statt Big Bang: lieber klein anfangen, lernen und anpassen, als ein Mammutprojekt durchzupeitschen und am Ende mit einer Lösung dazustehen, die niemand wirklich will
• Rollen und Verantwortlichkeiten klären, bevor überhaupt über konkrete Software gesprochen wird

Das eigentliche Ziel ist nicht, das beste LIMS am Markt einzuführen, sondern dafür zu sorgen, dass das Labor danach besser funktioniert als vorher, und das gelingt nur, wenn die Menschen darin das System irgendwann als ihres betrachten.

Die Marktlücke

Hier liegt aus meiner Sicht das eigentlich Interessante: Wer sich heute als Berater für Labordigitalisierung positioniert, macht im Wesentlichen eines von zwei Dingen. Entweder ist man LIMS-Anbieter und hat naturgemäß ein Interesse daran, die eigene Software als Lösung zu verkaufen, oder man kommt aus der klassischen IT-Beratung und bringt jemanden mit, der sich vor allem in Anforderungsdokumenten und Ausschreibungsverfahren auskennt.

Was es dagegen kaum gibt, ist jemand, der das technische Verständnis mitbringt (was ist ein LIMS, was ist ein ELN, worin unterscheiden sie sich, was muss bei der Datenmigration bedacht werden) und den Beratungsschwerpunkt trotzdem bewusst auf die organisatorische Seite legt, der also nicht einfach ein System einführt, sondern begleitet, wie ein Labor überhaupt erst lernt, digital zu arbeiten.

Das ist ausdrücklich keine Kritik an den vorhandenen Anbietern und Beratern, die in ihrem jeweiligen Bereich oft gute Arbeit machen. Was aber häufig unterbleibt, ist der Blick auf die Gesamtsituation, auf das System Labor inklusive seiner Menschen und Strukturen, und genau dieser Blick fehlt dann am meisten, wenn Projekte in Schwierigkeiten geraten und niemand so recht erklären kann, woran es eigentlich hakt.

Was das in der Praxis bedeutet

Wenn ich heute mit einem Labor über Digitalisierung spreche, fange ich nur selten mit der Frage an, welches System am besten passen würde. Stattdessen beginne ich lieber mit Fragen wie: Was genau soll sich durch die Digitalisierung verbessern, und für wen? Wer im Labor hat Sorge vor dem Projekt, und woher kommt diese Sorge? Was hat beim letzten Anlauf nicht funktioniert, und welche Erfahrungen sind aus diesem Scheitern noch im kollektiven Gedächtnis?

Das sind keine Fragen, die man auf einem Beratungs-Pitch gerne stellt, weil sie den Prozess auf den ersten Blick komplizierter erscheinen lassen, als ihn potenzielle Kunden gerne hätten. In Wirklichkeit sind aber genau das die Fragen, die später darüber entscheiden, ob das Projekt in zwei Jahren als Erfolg verbucht oder als teures Lehrprojekt abgehakt wird.

Labordigitalisierung ist immer beides gleichzeitig, ein Technikthema und ein Menschenthema, und wer nur das eine beherrscht, löst das Problem bestenfalls zur Hälfte.

Falls Du gerade ein Labordigitalisierungsprojekt planst oder mittendrin steckst und das Gefühl hast, dass die technische Seite irgendwie vorankommt, aber die organisatorische immer wieder auf der Strecke bleibt, dann melde Dich gerne.