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:

Vorgang Beteiligte
1. Definition der Projektziele
(welche Verbesserungen werden vom neuen System erwartet)
A, evtl. H
2. Durchführbarkeits- (feasibility-) Studie
(Aufsstellung der Anforderungen, ein oder mehrere Realisierungsvorschläge, Kosten/Nutzen-Betrachtungen)
meist H
3. Entscheidung
(wird das Projekt durchgeführt - wenn ja und mehrere Realisierungsvorschläge: Auswahl eines Vorschlags)
A
4. Systemanalyse
(genaue Untersuchung und Beschreibung der organisatorischen Abläufe -> "Detailspezifikation")
H
5. Systemdesign
(Festlegung, wie sich die Ergebnisse aus der Systemanalyse EDV-gestützt realisieren lassen)
H
6. Implementierung
(Programmierung etc.)
H
7. Installation H
8. Probebetrieb
(Überprüfung durch einige Anwender, ob die gewünschten Ziele mit dem neuen System erreicht werden; gegebenenfalls weitere Anpassungen durch den Hersteller)
H, A
Einschulung
(komplette Erklärung des neuen Systems für alle Anwender)
H, A
10. Übernahme
(offizielles Ende des eigentlichen Projekts)
H, A
11. fortgesetzte Wartung
(Fehlerbehebung, Anpassungen an zuvor "vergessene" Details oder neu hinzugekommene Anforderungen etc.)
H, A


(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:

  • schnellere Einführung (nachträgliche Änderungen, die erst bei der Arbeit mit dem LIMS urgiert werden, sind unverhältnismäßig zeitaufwendig - das Problem wird auch durch den erwähnten Prototyp nur teilweise beseitigt)
  • Benutzerakzeptanz (eines der häufigsten Gründe einer erfolglosen LIMS-Einführung ist, dass die Anwender das System nicht annehmen, weiterhin "inoffiziell" wie bisher arbeiten etc.; naturgemäß ist bei Projekten, in denen die Benutzer aktiv in der Planung mitgewirkt haben - nicht zuletzt aus psychologischen Gründen - eine wesentlich bessere Akzeptanz zu erwarten)
  • Kostenfaktoren (neben den offensichtlichen Kosteneinsparungen durch eine frühere Einführung ist auch zu bedenken, dass bei klaren Anforderungen dem LIMS-Hersteller/Anbieter ein wesentlich geringerer Zeitaufwand durch den teilweisen Wegfall endloser Besprechungen und Einzelinterviews mit den zukünftigen Anwendern entsteht, was sich im Normalfall auch im Preis widerspiegeln wird; bei Ausschreibungen kommt noch der Entfall des "Unsicherheitszuschlags" dazu - siehe unten)
Besonders der Laborleiter wird seitens der Unternehmensführung an seiner Fähigkeit zum Projektmanagement der LIMS-Einführung gemessen werden. Aus diesem Grund liegt es vor allem in seinem / ihrem Interesse, den Verlauf des Projektes aktiv zu beeinflussen, damit das Labor einen möglichst hohen Nutzen aus dem LIMS erzielen kann.

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:

  • Reduktion des Verwaltungsaufwandes je Probe um 80 %
  • Jederzeitiges Auffinden früherer Analysen
  • Reduktion nicht fristgerecht erstellter Analysenzertifikate um 90 %
Der Nutzen des LIMS wird folgendermaßen grob geschätzt:

  • 10.000 Proben pro Jahr à durchschnittlich 30 Minuten Verwaltungsaufwand je Probe ergeben bei 80 % Reduktion eine Zeitersparnis von 4.000 Mannstunden, was bei einer Bewertung von 100 GE (Geldeinheiten) je Mannstunde 400.000 GE ergibt
  • Die Sicherheit, frühere Analysen jederzeit nachvollziehen zu können, wird sehr grob mit 200.000 GE pro Jahr angenommen
  • Der Verlust an Umsatz durch - wegen verspäteter Analysen verärgerter - verlorener Kunden sowie der Verlust an Image wurde mit 100.000 GE pro Jahr (als Deckungsbeitrag berechnet) angenommen. Eine 90 % Reduktion ergibt also 90.000 GE
Wir erwarten also einen Nutzen von 690.000 GE pro Jahr. Um uns eine detaillierte Investitionsrechnung zu ersparen, wollen wir annehmen, dass die jährlichen Steigerungen der Personalkosten etc. dem allgemeinen Zinssatz entsprechen. Bei einer erwarteten Nutzung des LIMS von 10 Jahren dürfen die Einführungs- und Wartungskosten in Summe maximal 6.900.000 GE betragen, wobei in diesem Betrag auch etwaige Überstunden oder Stillstandskosten zu berücksichtigen wären. Aufgrund der unsicheren Schätzung wählen wir aber als maximale Kosten z.B. 5.000.000 GE.


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:

Laborleiter insb. Endkontrolle und Freigabe der Ergebnisse
Analysenpersonal allgemeine Tätigkeit
Sekretariat insb. Ausdrucken von Analysenzertifikaten und Rechnungen
Chromatographie-Datensystem automatische Übertragung der HPLC-Resultate an das LIMS



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:

  • Bezeichnung / kurze Beschreibung des Ereignisses
  • Wer oder was löst das Ereignis aus ?
  • In welcher Weise soll das LIMS darauf reagieren ?
  • Datenflüsse (welche Informationen werden zu diesem Zeitpunkt in das System eingegeben, welche sollen vom System ausgegeben werden)
Sobald eine erste Liste erstellt ist, werden mehrfach vorkommende, identische Ereignisse gestrichen. Weiters ist anzustreben, dass die Liste möglichst vollständig das Verhalten des LIMS beschreiben kann. Nicht vergessen werden sollte, dass die Reaktion auf ein Ereignis auch in einer Zurückweisung bestehen kann, wenn z.B. der Benutzer für die gewünschte Aktion nicht autorisiert ist.

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:

Bezeichnung Auslöser Reaktion Datenflüsse
Probeneingang A Registrierung der eingelangten Probe, Vergabe einer eindeutigen Nummer und Speicherung der Daten Input: Probeninformationen
Output: -

Erstellung der Analysenlisten täglich automatischer Ausdruck von Analysenlisten (Liste zu analysierender Proben für jede Abteilung, nach Analysenmethoden geordnet) Input: -
Output: Analysenliste (Drucker)

Probenfreigabe L nach Bestätigung durch Laborleiter wird Probenstatus auf "Freigegeben" gesetzt Input: -
Output: aktuelle Probendaten (Bildschirm), evtl. Bestätigung durch Laborleiter

Zertifikat- Ausdruck S für die neu freigegebenen Proben werden Analysenzertifikate erstellt Input: -
Output: Analysenzertifikate (Drucker)

Abfrage früherer Werte A, L Anzeige der Proben, die den Suchkriterien entsprechen Input: Suchkriterien (z.B. Datumsbereich)
Output: entsprechende Proben (Bildschirm, evtl. Drucker)

manuelle Eingabe der Resultate A, evtl. L Speicherung der neu eingegebenen Analysenresultate bei der betreffenden Probe Input: Ergebnisse, Probennnummer
Output: -

automatische Übernahme von Chromatographie- Daten C Speicherung der berechneten Analysenresultate bei der betreffenden Probe Input: Ergebnisse, Probennummer
Output: -



( 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:

  • Bezeichnung (z.B. Firmenname)
  • Datentyp (Text, ganzzahlig, Gleitkomma-Zahl, Datum/Zeit, Ja/Nein, Auswahl aus mehreren Möglichkeiten etc.)
  • Beschränkungen (maximale Zeichenanzahl bei Text, Gültigkeitsbereich bei Zahlen - z.B. wenn negative Zahlen nicht erlaubt sind)
  • Schlüsseleigenschaft (wenn es möglich sein muss, durch Kenntnis dieses Attributs das ganze Objekt eindeutig zu identifizieren, z.B. bei einer eindeutigen Probennummer)
  • Wiederholung (wenn dieses Attribut mehrfach - meist in unbestimmter Anzahl - vorkommen kann, so z.B. wenn der Kunde mehrere Telefonnummern hat)
Bei der Wiederholung kann es auch vorkommen, dass zwei oder mehr Attribute gemeinsam wiederholt werden (z.B. ein Auftraggeber mit mehreren Ansprechpartnern, von denen jeder eine eigene Telefonnummer hat).

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:

Bezeichnung Datentyp Beschränkungen Schlüssel? Wiederholung
Probennummer ganzzahlig >0 ja -
Beschreibung Text max. 80 Zeichen - -
Eingangsdatum Datum - - -
Spätestens Datum nach Eingangsdatum - -
Parameter Text max. 40 Zeichen - 1 oder mehr
Methode Text max. 40 Zeichen - 1 oder mehr
Bearbeitungsstatus Auswahl - - -


Erklärungen:

  • "Parameter" und "Methode" geben die zu bestimmenden Analysenparameter (z.B. Glucose) und die dafür zu verwendende Analysenmethode (z.B. Enzymat. Bestimmung) an; beide Felder werden gemeinsam wiederholt !
  • "Bearbeitungsstatus" - Auswahl: es ist einer der möglichen Werte "Vor Probenahme", "Nach Probenahme", "In Arbeit", "Freigabe erfolgt" und "Abgeschlossen" zu wählen.
Geschätztes Datenaufkommen: 5000 Proben/Jahr, Wiederholungsfelder (Parameter/Methode) durchschnittlich 5 mal je Probe

Auftraggeber:

Bezeichnung Datentyp Beschränkungen Schlüssel Wiederholung
Kundennummer ganzzahlig >0 ja -
Firmenname Text max. 80 Zeichen - -
Ansprechpartner Text max. 80 Zeichen - -
Adresse Text max. 200 Zeichen - -
Telefonnummer Text max. 40 Zeichen - -
Telefaxnummer Text max. 40 Zeichen - -


Beziehungen:

  • Auftraggeber zu Probe ... 1:N
Geschätztes Datenaufkommen: 2000 Auftraggeber anfangs, Zunahme um ca. 500 pro Jahr


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:

  • mittlere Antwortzeit bei Eingaben unter 5 Sekunden
  • telefonischer Support bei Problemen an Werktagen
  • Weiterverwendbarkeit der verwendeten PCs, der Drucker und des Netzwerkes
  • Betrieb der Software unter Windows 95
  • Anschaffung zusätzlich notwendiger Standardsoftware von Fa. XYZ, da mit dieser ein Liefervertrag besteht
Mit Abschluss dieser Phase sollten alle zur eigentlichen Realisierung des LIMS notwendigen Informationen vollständig dokumentiert sein. Die Ergebnisse der Phasen 2, 3, 4 und 6 können direkt in ein Leistungsverzeichnis aufgenommen werden, auf das hin Angebote verschiedener LIMS-Hersteller eingeholt werden (die Phasen 1 und 5 haben eher unternehmensinterne Entscheidungen zum Inhalt und sind für die Ausschreibung meist nicht notwendig, die Schätzung der Maximalkosten sogar wenig sinnvoll).

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