LIMS-Einführung

Das (beherrschbare) Risiko der Extrawurst

Wie viel Standard, wie viele Extras bei der LIMS-Einführung? Guido von Dahlen, Geschäftsführer von Icd, zeigt auf, was beim Einführen von LIM-Systemen zu beachten ist.

Kein standardisiertes Labor-Informations- und Management-System (LIMS) kommt ohne Anpassungen aus. Doch mit jedem Extra steigt das Risiko, ein nicht mehr wartbares und Geld verschlingendes Konstrukt zu erzeugen. Wie lässt sich dieses Risiko managen und senken? Welche Rolle spielt die IT-Abteilung dabei und welche spielen die Laborspezialisten? Und ist überhaupt überall Standard drin, wo Standard draufsteht?

Standard ist „in“. Sei es LIMS, ELN (Electronic Lab Notebook) oder LES (Lab Execution System) – wenn es um die Einführung einer Software für die Labordatenverarbeitung geht, wollen Unternehmen heute in der Regel so viel Standard wie möglich. Das ist wohl die Folge aus der Erfahrung aus der Zeit, als es hieß: „Alles, was das Labor wünscht, soll die Software auch abbilden.“ Denn daraus entstanden hochkonfigurierte, zum Teil kaum wartbare und kostenträchtig gewordene Systeme, bei denen es oft nur noch einen Ausweg gibt: sie komplett zu ersetzen.

Risikoeinschätzung auf Basis von GAMP

Eine gute Basis, um das Risiko einer Laborsoftware einschätzen zu können, bieten die fünf Software-Kategorien der Good Automated Manufacturing Practice (GAMP). Kategorie 3 führt Systeme auf, mit denen Unternehmen ihre Standardfunktionalitäten und ihre Kernprozesse abdecken und somit Anpassungen größtenteils vermeiden können. Mit solchen Systemen erfüllen die Anwenderunternehmen nicht nur die Voraussetzungen für eine erfolgreiche Validierung. Sie sind auch mit Blick auf Kosten und Risiken auf der sicheren Seite. Wohl müssen sie die Stammdaten für das neue System aufsetzen. Doch dabei handelt es sich um ein Standardvorgehen und keine Konfiguration.

Anzeige
Das Risiko bei Einführung und Wartung von Standardsoftware steigt mit Zahl und Art der Anpassungen. © iCD. Vertriebs GmbH

Doch hundertprozentige Standardsoftware findet man in Unternehmen praktisch nie. Deshalb führt GAMP in ihrer Kategorie 4 konfigurierte Software auf, bei der Anpassungen über Parametrisierung erfolgen. Das heißt: Bestimmte Funktionen lassen sich zum Beispiel über die Einstellung von Feldwerten anpassen. Das damit verbundene Risiko mit Blick auf Kosten und Beherrschbarkeit steigt dabei wenig an. Die Software an sich bleibt unangerührt. Ein weiterer Vorteil: Über Parametrisierungen können die Anwender einfache Konfigurationen selbst und damit auch kostengünstig durchführen. Die Software-Lösung bleibt damit aber immer validiert und im Standard, und das auch bei Upgrades und neuen Produktversionen seitens des Herstellers.

Wenn Programmierung nötig wird

Nun gibt es aber Anforderungen, die sich nicht über reine Parametrisierung bewerkstelligen lassen. Dies sind zum Beispiel Schnittstellen zu externen Systemen wie ERP (Enterprise Resource Planning) oder MES (Manufacturing Execution System), die zumeist über sog. „RESTful Web-

services“ programmiert werden. Dabei ist anzuraten, die Funktionalität der jeweiligen Schnittstelle zuvor mit dem Anbieter genau zu besprechen und im Rahmen einer agilen Software-Entwicklung (zum Beispiel SCRUM) zu planen und zu entwickeln. Wichtig ist zudem, dass der Software-Lebenszyklus die Vorgaben eines QM-Handbuches wie ISO 9001 : 2015 erfüllt und dass der Anbieter eine qualifizierte und gut dokumentierte Funktionalität liefert. Dies stellt ein ebenfalls beherrschbares Risiko sicher, da die Aufwände und Risiken auf den Anbieter verlagert sind und nicht beim Kunden verbleiben.

Eine derart angepasste Lösung („customized“) führt GAMP in ihrer Software-Kategorie 5. Je nach Produkt finden sich häufig genutzte Schnittstellen, etwa die zu SAP oder zu Messgeräten, bereits in der Standardversion – und zwar als parametrisierbare Schnittstelle. Auf diese Weise verfügt der Anwender eventuell bereits über alle wichtigen Schnittstellen, die er benötigt. Er muss sich aber nicht auf das erhöhte Risiko einlassen, die eine Software nach GAMP 5 mit sich bringt.

Risikofaktor Makrosprache

In der Praxis existiert nun noch eine weitere Kategorie, die GAMP gar nicht aufführt – nämlich sehr umfangreich angepasste Software, die zumeist mithilfe einer proprietären Makrosprache immer und immer wieder verändert wurde. Diese Systeme erfüllen zwar nahezu alle Anforderungen, die sich ein Labor nur wünschen kann. Doch ist diese „Freiheit“ durchaus mit hohen Kosten und zeitlichem Aufwand für die Implementierung erkauft. Außerdem macht dieses Vorgehen den Support durch einen Administrator nahezu unmöglich, da diese Art der Konfiguration proprietär ist und die notwendigen Wartungsressourcen auf Anwenderseite oft nicht vorhanden sind.

Hinzu kommt: Oft werden diese hochkonfigurierten Systeme als standardisierte Speziallösungen verkauft – etwa als Branchenpakete für Pharma, Prozessindustrie, Auftragslabor oder Biobanken. Auf diese Weise wiegen sich Kunden oft in der trügerischen Sicherheit, einen Standard nach GAMP-Kategorie 3 oder 4 zu erwerben. Doch „unter der Haube“ befinden sich dann zum Beispiel hoch und individuell angepasste Datenbanken. Das Risiko mit solchen Systemen schießt dann schnell durch die Decke – es sei denn, der jeweilige Anbieter kann Garantien zu seinem System anbieten, indem er zusichert, dass das Gelieferte voll unter seinen Standardsupport fällt. Zum Beispiel in Form von Wartungs- oder Kundendienstverträgen. Auf keinen Fall sollten sich Unternehmen darauf einlassen, dass die Berater des Anbieters die Software mithilfe von Makrosprachen konfigurieren und individualisieren, das Risiko dafür aber beim Kunden belassen. Doch selbst wenn dies nicht der Fall ist, bleibt das Risiko, dass solche Systeme mittel- und langfristig bei Upgrades zu Schwierigkeiten führen.

Der Einsatz proprietärer Makrosprachen bringt vor allem auch ein hohes und stetig steigendes Risiko mit sich, wenn eine Software-Lösung sich bereits im Einsatz befindet. Oft tritt die Unternehmens-IT ins zweite Glied zurück, wenn eine Software einmal läuft. Und da sich Makrosprachen auch von Nicht-Informatikern gut bedienen lassen, führen die Laborspezialisten mit ihrer Hilfe immer wieder neue Konfigurationen durch – immer dann, wenn sie sich neue oder erweiterte Funktionen wünschen. Dies ist ein schleichender Prozess, der jedoch von Anfang an unterbunden oder zumindest systematisch gemanagt werden sollte. Immer unter dem Aspekt der Risikobetrachtung: Lohnt die gewünschte Funktion wirklich eine weitere Konfiguration? Oder ist sie verzichtbar und treibt nur die Systemkomplexität weiter nach oben?

Disziplin gefragt

Es empfiehlt sich deshalb, einen risikobasierten Ansatz zu wählen. Und zwar auch nach Inbetriebnahme unter dauerhafter Beteiligung der IT-Spezialisten im Unternehmen. Diese können in der Regel besser als ihre Laborkollegen einschätzen, welche Änderungen das Risiko für schlecht wartbare Systeme nach oben treiben. Letztlich geht es darum, die notwendige Disziplin im Unternehmen zu etablieren. Die Fachseite sollte nicht in der Lage sein, nachträgliche Konfigurationen selbst vorzunehmen. Diese sollten vielmehr eine strikte Risikobewertung und Priorisierung durchlaufen: Ist die jeweilige Anpassung wirklich unverzichtbar? Und in welcher Form?

Im Zweifelsfall gilt eigentlich immer, die jeweils geplante Änderung gar nicht umzusetzen. Denn die Projektpraxis hat gezeigt: Werden Änderungswünsche zunächst auf „hold“ gesetzt, fragt bei den meisten nach einem halben Jahr niemand mehr danach. In diesen Fällen spart die Nicht-Umsetzung viele Aufwände und das System bleibt schlanker.

Entsprechend reicht die Pflege eines Lastenhefts über die Systemeinführung hinaus und sollte auch Grundlage der Systemwartung sein. Als Leitlinie empfiehlt sich: Ein LIMS ist mit Blick auf das Risiko gut ausbalanciert, wenn mindestens 80 Prozent der Funktionen dem Standard folgen, während maximal 20 Prozent Anpassungen sind.

Verantwortlich für diesen Mix ist in der Regel der Projektleiter des Anwenderunternehmens, der den gesamten Prozess steuert. Wichtig ist, wie viel Projekterfahrung er mitbringt. Weniger wichtig ist, ob er von seinem Hintergrund IT-, Labor- oder Qualitätsspezialist ist. 

Die Verantwortung des Anbieters

Der Projektleiter ist auch derjenige, der sicherstellt, dass alle Anpassungen vonseiten des Anbieters durch einen Wartungsvertrag abgedeckt sind und dass sie per Parametrisierung erfolgen. Denn das Risiko bei der Einführung und Weiterentwicklung von Laborsoftware sollte eigentlich nie zu Lasten des Anwenderunternehmens gehen. Vielmehr sollte der jeweilige Softwareanbieter Anpassungen möglichst kostenneutral anbieten können und das System inklusive Änderungen komplett qualifiziert ausliefern.

(Was das Risiko bei der LIMS-Einführung gering hält - auf den Punkt gebracht: Übersicht s. Anhang)

Guido von Dahlen. © iCD.­Vertriebs GmbH

AUTOR
Guido von Dahlen
Geschäftsführer
iCD. Vertriebs GmbH, Frechen
info@icd.eu
www.icd.eu

Anzeige
333.8 KB
LIMS-Einführung - Was das Risiko gering hältTipps zur Vorgehensweise bei der Einführung eines LIMS (Quelle: iCD. Vertriebs GmbH)

Das könnte Sie auch interessieren

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige

Newsletter bestellen

Immer auf dem Laufenden mit dem LABO Newsletter

Aktuelle Unternehmensnachrichten, Produktnews und Innovationen kostenfrei in Ihrer Mailbox.

AGB und Datenschutz gelesen und bestätigt.
Zur Startseite