 |
 |
|||
| Home | ||||
| ||||
|
|
|||
| News | ||||
| ||||
|
|
|||
| Produkte | ||||
| ||||
 |
Basiswissen |  |
||
| ||||
|
|
|||
| Download | ||||
| ||||
|
|
|||
| Über uns | ||||
| ||||
|
|
|||
| Kontakt | ||||
| ||||
| Advanced Technical Software Simmeringer Hauptstraße 24 1110 Wien / Österreich Tel.: (+43) 1 815 66 75 Fax: (+43) 1 815 66 75 - 9 labor@ats-vienna.com |
|||
| ||||
|
Basiswissen >> Aktive Benutzerbeteiligung ... |  |
 |
 |
|
Aktive Benutzerbeteiligung bei der Einführung eines LIMS
Kurzfassung:
Die Einführung eines Laborinformationssystems (LIMS) bringt - besonders im Zuge einer Ausschreibung - durch unklare Vorstellungen der späteren Anwender oft Probleme durch geringe Benutzerakzeptanz und unvorsehbaren Entwicklungsaufwand für den Hersteller. In dieser Arbeit wird ein - der modernen Softwareentwicklung nachempfundener, aber stark vereinfachter - Weg beschrieben, wie die Anwender selbst zu einer eindeutigen, EDV-gerechten Anforderungsaufstellung gelangen können, um die genannten Probleme zu vermeiden.  Die Problematik Steigendes Probenaufkommen und höherer Kostendruck zwingen viele Laboratorien, über die Einführung eines EDV-gestützten Systems zur Organisation / Verwaltung der Analysen bzw. des Laborbetriebs im allgemeinen nachzudenken. Diese als "Laborinformationssystem" (LIMS) bekannten Systeme können jedoch normalerweise nicht "von der Stange" (als Standardsoftware) angeschafft werden, da sie in diesem Fall nicht den bisherigen Arbeitsabläufen entsprechen und daher wenig zur Verbesserung der bisherigen Situation beitragen können. Die umgekehrte Möglichkeit, die bisherigen Arbeitsabläufe eines gesamten Labors an eine neue Software anzupassen, muss als reichlich problematisch (unter Umständen sogar existenzgefährdend) angesehen werden und wird daher oft nicht einmal diskutiert. Der übliche Weg zur Einführung eines LIMS - zumindest bei seriösen Anbietern - sieht in etwa folgendermaßen aus:
(A = Anwender, H = Hersteller bzw. Entwickler des LIMS) Häufig wird noch - in etwa parallel zu den Phasen 4 und 5 - ein sogenannter Prototyp erstellt. Darunter ist eine Minimalversion des späteren Programms zu verstehen, die keineswegs voll lauffähig sein muss, aber den späteren Anwendern eine Vorstellung vermitteln soll. Zweck des Prototyps ist es, bereits jetzt etwaige vergessene Anforderungen zu erkennen und spätere, aufwendigere Änderungen zu vermeiden. Wie unschwer zu erkennen ist, beschränkt sich die Funktion der Anwender eher auf eine passive Rolle, nämlich in der Befragung durch den Hersteller bezüglich der Anforderungen, in der Entscheidung (meist nur ja oder nein) sowie im Testen, der Einschulung und der weiteren Betreuung. Eine aktivere Rolle der Anwender (die ja im Gegensatz zum Hersteller tagtäglich damit arbeiten müssen) im Zuge der LIMS-Einführung erscheint sinnvoll, wobei unter anderem folgende Vorteile zu erwarten wären:
In den meisten Fällen wird die Auswahl des geeigneten LIMS-Herstellers im Zuge einer - mehr oder weniger formellen - Ausschreibung stattfinden, da nur wenige, große Unternehmen eine EDV-Abteilung mit der notwendigen personellen Kapazität sowie der fachlichen Kompetenz unterhalten, um das Projekt unternehmensintern durchführen zu können. Nun wird jeder einigermaßen betriebswirtschaftlich denkende LIMS-Anbieter bei der Erstellung eines verbindlichen Angebots auf ein unklares oder mehrdeutiges Leistungsverzeichnis bzw. Anforderungsaufstellung in der Weise reagieren, dass er dem Angebotspreis einen "Unsicherheitszuschlag" hinzufügt. Damit soll der wegen der unklaren Anforderungen schwer abschätzbare Aufwand kompensiert werden. Durch aktive Benutzerbeteiligung erstellte Angebotsunterlagen sollten - bei Beachtung einer sinnvollen Vorgangsweise - die Anforderungen präziser, vollständiger und auch EDV-orientiert erfassen, was sich in geringeren Preisen niederschlagen sollte. Naturgemäß gibt es viele verschiedene Methoden, zu vernünftigen Ausschreibungsunterlagen zu gelangen. Hier soll ein Verfahren vorgestellt werden, das auf weitverbreiteten Software-Entwicklungs-Prinzipien basiert (wie sie von seriösen Software-Anbietern eingesetzt werden), aber diese soweit vereinfacht und reduziert, dass sie auch problemlos von Nicht-EDV-Spezialisten eingesetzt werden können. Klarerweise endet dieses Verfahren bei Phase 4 der Tabelle oben (Systemanalyse), da der Rest - wie auch die Präzisierung der Systemanalyse - Aufgabe des LIMS-Herstellers ist und bleiben soll. Konkret geht es darum, die folgenden 6 Fragen zu beantworten: Organisatorisch scheint es am vernünftigsten, eine Projektgruppe zur Klärung dieser Fragen (was wohl kaum in einem einzelnen Meeting zu schaffen ist) zu bilden, die sich aus zumindest einem Vertreter aus jeder Abteilung zusammensetzt. Zusammen sollten diese Vertreter einen Überblick über alle notwendigen Abläufe haben und Details bei Bedarf mit den entsprechenden Mitarbeitern klären können. Ob diese Projektgruppe einen klar definierten Projektleiter besitzen soll oder nicht, ist nicht allgemeingültig zu beantworten. Am besten wird diese Frage so wie sonst im Unternehmen üblich gehandhabt. Die 6 Fragen sollten in der angegebenen Reihenfolge besprochen und die Ergebnisse schriftlich niedergelegt werden. Sofern sich zeigt, dass in einer früheren Phase etwas vergessen wurde oder sich inzwischen geändert hat, müssen alle nachfolgenden Phasen ebenfalls noch einmal durchgesprochen werden, um festzustellen, ob die Änderungen auch hier Konsequenzen hinterlassen. Bei der nun folgenden Detailbeschreibung der 6 Phasen / Fragestellungen soll jeweils beispielhaft eine - stark vereinfachte und gekürzte - Beantwortung für ein fiktives Auftragslabor folgen. 1. Welche Ziele werden verfolgt ? Hier müssen sich die Anwender zunächst klar werden, aus welchem Grund überhaupt die Einführung eines neuen Systems in Angriff genommen werden soll. Es gilt, die Schwächen der momentanen Vorgangsweise aufzudecken und zu überlegen, ob ein EDV-gestütztes System diese beseitigen kann. Weiters ist eine grobe Kosten / Nutzenabwägung vorzunehmen. Da zu diesem Zeitpunkt eine auch nur ungefähre Kostenschätzung schwierig ist, erscheint es am vernünftigsten, den erwarteten Nutzen so gut wie möglich in Geldwerten zu bewerten und diesen Betrag später als Höchstgrenze für die Kosten der LIMS-Einführung anzusetzen. Natürlich müssen diese Kosten nicht nur den Angebotspreis des LIMS-Herstellers, sondern auch die internen Kosten durch die Umstellung o.ä. abdecken. Die Bewertung des Nutzen durch das LIMS ist in manchen Teilbereichen relativ einfach, wenn es sich z.B. um den dadurch verringerten Arbeitsaufwand je Probe handelt. Andere Faktoren sind naturgemäß wesentlich schwieriger zu bewerten, so z.B. die dadurch verbesserte Kundenzufriedenheit, dass nach LIMS-Einführung alle Analysenaufträge zeitgemäß abgeschlossen werden. Ähnliches gilt für Qualitätssicherungs-Überlegungen (z.B. die jederzeitige Auffindbarkeit jahrelang zurückliegender Analysen). Trotz dieser Schwierigkeiten ist eine - ungefähre - Bewertung des Gesamtnutzens wie bei jeder anderen Investition sinnvoll, um eine Entscheidungsgrundlage zu haben. In unserem fiktiven Beispiel könnte die Liste der Ziele folgendermaßen aussehen:
2. Wer hat mit dem System zu tun ? Nachdem jetzt - hoffentlich - Klarheit darüber herrscht, was vom neuen System erwartet wird, besteht der nächste Schritt darin zu erkennen, mit wem oder was das LIMS kommunizieren soll. In erster Linie handelt es sich dabei um die eigentlichen Anwender, die meistens in verschiedene Benutzergruppen mit unterschiedlichen Erfordernissen eingeteilt werden können. Dies wird als Liste der Benutzergruppen und ihren Charakteristika erfolgen, wobei zweckmäßigerweise die Funktion, nicht aber der konkrete Name des Anwenders dokumentiert werden (also "Laborleiter" anstatt von "Herr Dr. Müller"). Neben den Anwendern können in manchen Fällen auch noch andere Personen hier aufscheinen, so z.B. wenn Kunden die Möglichkeit gegeben werden soll, Analysenaufträge elektronisch zu plazieren oder Ergebnisse abzufragen. Schließlich fallen in diese Aufstellung auch nicht-menschliche Systeme (z.B. "intelligente" Laborgeräte), die automatisch oder halbautomatisch Daten mit den LIMS austauschen können sollen. In unserem Beispiel würde diese Tabelle folgendermaßen aussehen:
3. Auf welche Ereignisse ist zu reagieren ? Diese Phase stellt meistens den größten Zeitaufwand dar. Es geht hier um die Aufgabe, zu definieren, was das LIMS im Detail für den Anwender leisten soll. Wie dies softwaremäßig zu realisieren ist, betrifft hingegen nur den LIMS-Hersteller. Die Erstellung einer Liste der Anforderungen über sogenannte Ereignisse - wie es hier beschrieben wird - ist eine Vereinfachung der "modernen strukturierten Analyse" nach Yourdon und bietet im Vergleich mit anderen Verfahren den Vorteil, dass man leicht zu einer detaillierten und vollständigen Anforderungsliste gelangt, ohne jedoch sich überlegen zu müssen, wie dies EDV-mäßig zu bewerkstelligen ist. Aus diesem Grund ist dieses Verfahren auch für "EDV-Laien" gut geeignet. Konkret werden von allen Mitarbeitern der Projektgruppe "Ereignisse" diskutiert und schriftlich festgehalten, auf die das LIMS reagieren soll. Ereignisse werden entweder von einer der in Phase 2 identifizierten Personen oder Geräte ausgelöst (z.B. Eingabe einer neu eingelangten Probe) oder aber zu bestimmten, vorher festgelegten Zeitpunkten (z.B. automatischer, täglicher Ausdruck von Analysenlisten). Für jedes Ereignis sind folgende Daten anzugeben:
Um bislang übersehene Ereignisse zu finden, ist es beispielsweise möglich, den "Lebenszyklus aller Geschäftsobjekte" im einzelnen durchzugehen. Unter "Geschäftsobjekte" werden z.B. Proben, Kundenadressen oder Analysenzertifikate verstanden, während der Lebenszyklus den Zeitraum zwischen Einlangen und Ausscheiden dieser Daten darstellt. Nun muss für jedes Geschäftsobjekt überlegt werden, was mit ihm innerhalb dieses Zeitraumes geschehen kann (bei Proben z.B.: Einlangen/Registrierung, Analyse, Freigabe der Ergebnisse durch den Laborleiter, Ausdruck eines Analysenzertifikates, weitere Lagerung, ...). Dieses Verfahren ist zwar zeitaufwendig, stellt aber einen systematischen Ansatz dar, zu einer vollständigen Ereignisliste zu gelangen. Nun ist es noch ratsam, die bisher ungeordnete Ereignisliste nach sachlichen Zusammenhängen zu ordnen. Welches Kriterium konkret dafür herangezogen wird, ist einigermaßen frei wählbar und von geringerer Bedeutung. Für unser fiktives Labor könnte die Ereignisliste (stark gekürzt) z.B. so aussehen:
( A = Analysenpersonal, L = Laborleiter, S = Sekretariat, C = Chromatographie-Datensystem) 4. Mit welchen Daten ist zu rechnen ? Nachdem in der vorhergehenden Phase definiert wurde, was das System aus Anwendersicht leisten soll, müssen noch die zu verarbeitenden Daten näher beschrieben werden (die Bezeichnung "Eingabe einer neuen Probe" ist ohne Erklärung, wodurch eine Probe beschrieben wird, noch nicht vollständig). Zunächst gilt es, voneinander abgrenzbare "Objekte" (Geschäftsobjekte, siehe oben) zu erkennen. Dies ist nicht immer ganz eindeutig - z.B. könnte sich die Frage stellen, ob Name und Adresse des Auftraggebers einer Analyse zur betreffenden Probe gehören oder ein eigenständiges Objekt darstellen. Aufgrund der Abgrenzbarkeit von Auftraggeber (Person oder Firma) und Probe werden diese jedoch normalerweise als zwei unterschiedliche Objekte angesehen. Trotz dieser Abgrenzung stehen die Objekte im allgemeinen in einer bestimmten Beziehung zueinander (siehe unten). Sobald Klarheit über Anzahl und Bezeichnung der unterschiedlichen Objekte herrscht, müssen die einzelnen "Attribute" (Felder) identifiziert werden. Bei einem Auftraggeber (Kunden) könnten dies z.B. "Firmenname", "Ansprechpartner", "Adresse", "Telefonnummer" und "Telefaxnummer" sein. Zu jedem Attribut sind folgende Charakteristika zu überlegen:
Die Attribute und ihre Charakteristika der verschiedenen Objekte (Auftraggeber, Proben etc.) werden nun als Liste oder Tabelle schriftlich dokumentiert. An dieser Stelle ist es auch empfehlenswert, das Datenaufkommen grob abzuschätzen. Dies betrifft neben der Anzahl der Proben, Auftraggeber (insgesamt oder pro Jahr) auch die durchschnittliche Anzahl von Wiederholungen einzelner Felder (siehe oben). Als letzter Teilschritt ist es nun nur mehr notwendig, die Beziehungen zwischen den Objekten kurz festzuhalten. Unter einer Beziehung zwischen Objekten ist beispielsweise zu verstehen, dass für jede Probe ein (oder auch kein) genau festgelegter Auftraggeber existiert, umgekehrt aber jeder registrierte Auftraggeber eine oder mehrere Proben in Auftrag gegeben hat. Diese Art der Beziehung wird als 1:N (ein Auftraggeber - viele Proben) bezeichnet; in ähnlicher Weise können auch 1:1 - und M:N - Beziehungen vorkommen. Sobald auch die Beziehungen beschrieben sind, ist auch diese Phase für den Anwender abgeschlossen, da aus diesen Daten der LIMS-Anbieter mit geringem Aufwand die computergerechte Form der Daten erstellen kann. Dies geschieht meist mit Hilfe der Entity-Relationship-Modellierung (übersichtliche, grafische Darstellung). Für Interessierte sind die Grundlagen dieses Verfahrens in Datenbank-Einsatz im Labor beschrieben. Die Ergebnisse dieser Phase würden für unser Beispiel wie folgt aussehen (aus Platzgründen nur für die Objekte "Probe" und "Auftraggeber" dargestellt): Probe:
Erklärungen:
Auftraggeber:
Beziehungen:
5. Kann das System sinnvoll aufgeteilt werden ? Nach der jetzt abgeschlossenen Aufstellung der gesamten Anforderungen an das LIMS ist zu diskutieren, ob diese zum gegenwärtigen Zeitpunkt vollständig oder nur zum Teil realisiert werden sollen. Dies kann z.B. aus budgetären Gründen oder um eine Einführung in mehreren Schritten zu erreichen, sinnvoll sein. Wenn die Realisierung eines Teils sinnvoll oder zumindest diskussionswürdig erscheint, müssen diejenigen Ereignisse (Phase 3) zusammengefasst werden, die zweckmäßigerweise nicht getrennt werden sollen, ohne die Effizienz des Systems zu gefährden. Es wäre z.B. prinzipiell möglich, die Probeneingabe über das LIMS vorzunehmen, die Analysenzertifikate aber weiterhin manuell zu schreiben (die Ergebnisse werden vom Bildschirm abgeschrieben). Ob eine solche LIMS-Realisierung von großem Nutzen für die Anwender sein wird, ist wohl mehr als fraglich. Wenn auf diese Weise die Ereignisse zu zwei oder mehreren Gruppen (oft als "Subsysteme" bezeichnet) zusammengefasst wurden, werden Prioritäten vergeben, wodurch dann bei beschränktem Budget o.ä. sofort klar wird, welche Teile derzeit zu realisieren sind. Bei der Prioritätenvergabe ist folgendermaßen vorzugehen: Subsysteme, die von anderen abhängig sind, haben immer geringere Priorität als letztere zu erhalten. Ansonsten empfiehlt sich eine Kosten / Nutzenbetrachtung, wie sie bereits in Phase 1 - für das Gesamtsystem - erfolgt ist. Allerdings ist an dieser Stelle eine ungefähre Kostenschätzung für die Subsysteme nicht zu vermeiden, so man nicht eine Ausschreibung mit mehreren möglichen Realisierungsausmaßen beabsichtigt. Die Ereignisliste unseres fiktiven Labors lässt sich eigentlich nur in 2 Subsysteme sinnvoll auftrennen, nämlich die gesamte manuelle Probenverarbeitung (die ersten 6 Ereignisse) sowie die automatische Übernahme vom Chromatographie-Datensystem. Da letzteres vom ersten Subsystem abhängig ist, sind auch die Prioritäten sofort klar. 6. Welche Nebenbedingungen sind zu beachten ? Schließlich sind noch eventuelle Nebenbedingungen schriftlich festzuhalten, die nicht unmittelbar aus der Ereignisliste und der Datenbeschreibung hervorgehen, aber durchaus großen Einfluss auf die Effizienz und Benutzerakzeptanz des LIMS haben können. Manche Nebenbedingungen lassen sich aus der Aufstellung der Ziele (Phase 1) ableiten, so z.B. die durchschnittliche Antwortzeit (wenn nach jeder Eingabe minutenlange Wartezeiten auftreten, wird die gewünschte Reduktion der Bearbeitungszeit schwer zu erreichen sein) oder auch der Grad der Wartung durch den LIMS-Hersteller. Weitere Bedingungen entsprechen den persönlichen Präferenzen der Anwender, die Weiterverwendbarkeit bereits existierender Computer und Software etc. Unser Labor könnte z.B. die folgenden Nebenbedingungen festgehalten haben:
Die hier beschriebene Vorgangsweise bringt überdies Vorteile sowohl für die späteren Anwender (da sie durch die genaue Anforderungsanalyse genau das System erhalten, das sie wirklich brauchen) als auch für den LIMS-Hersteller (da die Anforderungen bereits in einer eindeutigen, EDV-gerechten Weise dokumentiert sind, wodurch eine gute Aufwandsabschätzung möglich wird). Literatur: Yourdon, E.N., Modern Structured Analysis, Prentice Hall, Englewoods Cliffs, N.J., 1989 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||