lims.wien

Wir wollen uns einmal mit einer Art "Dogma" ein bisschen aus dem Fenster lehnen: Ein Laborinformationssystem (LIMS), das nicht genau an die konkreten Anforderungen und Arbeitsabläufe des Labors angepasst wird, ist keine große Hilfe. Sicherlich mag der eine oder andere LIMS-Anbieter, dessen Geschäftsmodell auf "LIMS von der Stange" ausgerichtet ist, das anders sehen, aber zumindest unsere Kunden und Interessenten sehen das jedenfalls so wie wir.

Nun gibt es aber doch unterschiedliche Vorgangsweisen, wie man diese Anpassungen konkret bewerkstellen kann. Besonders die großen, internationalen LIMS-Anbieter haben weder Interesse noch die faktische Möglichkeit, diese Anpassungen selbst beim Endkunden durchzuführen. Manche setzen auf geeignete Vertriebspartner, die diese Änderungen durchführen, andere gehen davon aus, dass der Endkunde (bzw. seine IT-Abteilung) dazu selbst in der Lage sein sollte, wenn man ihn mit ausreichend Konfigurationsmöglichkeiten und Dokumentation versorgt.

Hier kommen wir schon der heutigen Fragestellung näher: Angenommen, bestimmte Funktionen eines LIMS werden in mehr oder weniger ähnlicher Form von mehreren Anwenderlabors benötigt, wie sollte der Anbieter damit umgehen? Bei jedem Anwender individuell programmieren oder aber ein "Modul" anbieten, das man bei mehreren Anwenderlabors dann einsetzen kann?

Naheliegend ist natürlich die letztgenannte Variante, sie entspricht eigentlich allen gängigen Prinzipien der Softwareentwicklung wie z.B. "DRY" ("don´t repeat yourself", also dass man dieselbe Aufgabe nicht mehrfach entwickeln sollte, sondern nur einmal als Modul, das man dann in verschiedenen Umgebungen einsetzen kann).

Doch leider ist es in der Praxis doch nicht immer so eindeutig. Denn im Normalfall haben viele LIMS-Anwender ähnliche, aber im Endeffekt doch mehr oder weniger unterschiedliche Anforderungen. Und wenn das eine Modul dann alle diese Optionen enthalten soll, wird es wieder unübersichtlich und kompliziert.

Gut funktioniert die Modul-Methodik, wenn die Unterschiede nur darin liegen, ob man bestimmte angebotene Funktionen benötigt oder nicht, quasi ein "Werkzeugkasten" mit vielen verschiedenen Werkzeugen. Dies entspricht auch recht gut dem Gedanken einer in einem früheren Beitrag besprochenen "LIMS-API". Konkret könnte hier das Berichtmodul im LIMS "uniLIME" Erwähnung finden, wo man bestimmte Ausgabevarianten und Darstellungen anfordern kann oder auch nicht. Wenn LIMS-Anwender A beispielsweise die Entwicklung der Messwerte als dreidimensionales Balkendiagramm benötigt, Anwender B hingegen mit dieser Art "Schnickschnack" nichts am Hut hat, dafür aber komplexere Kreuztabellen mit verschiedenen Summenspalten wünscht, dann lässt sich das gut mit einem einzigen Modul realisieren.

Schwieriger wird es, wenn das Modul eine bestimmte Aufgabe erfüllen soll, je nach Anwender aber hier sehr viele Details anders ablaufen sollen, beispielsweise bei Anwender A mit einem zusätzlichen Zwischenschritt, bei Anwender B hingegen mit Verbindungen zu anderen Datensätzen, bei Anwender C noch unter Einbindung eines Fremdsystems. Wenn man alle diese Detailvarianten (die sich oft auch gegenseitig ausschließen) in einem einzigen Modul abbilden möchte, wird es anbieterseitig derart kompliziert, dass der Entwicklungsaufwand um vieles höher sein kann als wenn man die gewünschten Details individuell bei jedem LIMS-Anwender extra programmiert. Und auch für die Anwender selbst kann eine solche Lösung sehr unübersichtlich werden.

Unser Fazit: jede Variante hat ihre Vor- und Nachteile, man muss - wie so oft - situationsbezogen entscheiden.

< Früherer Beitrag     Neuerer Beitrag >