Читать книгу Entwicklung eines Vorgehens zum Safety Assessment für sicherheits-kritische Informationssysteme - Christina Schäfer - Страница 13

2 Handlungsbedarf – Nutzungsperspektive

Ein Handlungsbedarf ergibt sich zum einen aus identifizierten Lücken im aktuellen Stand der Technik und zum anderen aus beobachtbaren Problemen in der entsprechenden Domäne.

An dieser Stelle setzt Kapitel 2 an und diskutiert beobachtete bzw. identifizierte Probleme aus der Domäne „zivile Gefahrenabwehr“ bzw. aus der Nutzung von SKIS, sodass ein erster Handlungsbedarf abgeleitet werden kann. Dazu legt Kapitel 2.1 erste Grundsteine zur Definition von Problemen und Komplexität in der besagten Domäne. Darüber hinaus werden die Rolle von Erfahrung und Wissen zum Problemlösen beschrieben und schließlich individuelle Faktoren in der Systemgestaltung identifiziert.

Zur Einordnung des Handlungsbedarfs werden im Verlauf des Kapitels Annahmen (Annahme 1 bis Annahme 6) in Bezug zur Entwicklung und Nutzung von SKIS aufgestellt. Die Annahmen werden in Kapitel 4 wieder aufgegriffen, um den Handlungsbedarf mit dem Hintergrund des Stands der Technik zu vervollständigen. Diese Annahmen basieren auf den identifizierten Bedarfen, die im Folgenden vorgestellt werden.

Der Handlungsbedarf wird hier in zwei Aspekten aufgezeigt:

• Zunächst soll ein grundsätzlicher Bedarf der IT-Unterstützung und Potentiale für SKIS auch in komplexen Situationen aufgezeigt werden (siehe Kapitel 2.1)

• Neben dem grundsätzlichen Potential an IT-Unterstützung stehen bereits identifizierte Probleme in der Nutzung. Hier sollen in den folgenden Kapiteln 2.2 und 2.3 Beispiele aufgeführt werden, die zum einen den Differenzierungsbedarf zwischen einzelnen Nutzern, insbesondere mit Berücksichtigung von unterschiedlichen Wissens- und Erfahrungsständen, in den Mittelpunkt stellen (siehe Kapitel 2.2 und 2.3)

2.1 Bedarf an IT-Unterstützung im Problemlösungsprozess zur Erhöhung des Wissens von Akteuren in der zivilen Gefahrenabwehr

Probleme lassen sich im Allgemeinen mit dem „Kopf“ oder dem „Bauch“ lösen und insbesondere mit wachsender Erfahrung kann der „Bauch“ zur Entscheidungsfindung und so zur Problemlösung beitragen [Bund12].

Nicht immer ermöglicht der Handlungsrahmen (z. B. eines Feuerwehreinsatzes) die nötige Zeit für lang andauernde Analysen. Speziell Akteure, die SKIS in komplexen Kontexten verwenden, müssen schnell und effektiv auf Unerwartetes reagieren und dabei in einer risikobehafteten Umgebung nahezu fehlerfrei agieren, da ein Fehlverhalten der Akteure schwerwiegende Auswirkungen haben kann. [Mist05] Daraus kann folgende Annahme abgeleitet werden:

Annahme 1:. Fehler im Umgang mit zeit- und sicherheits-kritischen Informationssystemen verursachen gravierende Folgen für den Menschen und das Umfeld.

Im Folgenden werden Eigenschaften und Definitionen von Komplexität sowie Problemen dargestellt, um ein grundlegendes Verständnis für die vorliegende Arbeit zu bilden und den Bedarf an IT-Unterstützung bzw. der Nutzung von SKIS im Problemlösungsprozess aufzuzeigen.

Wohland und Wiemeyer (siehe [WoWi07]) beschreiben die Differenz zwischen kompliziert und komplex wie folgt: “Mit Wissen kann man komplizierte Aufgaben lösen, aber nur mit Können kann man komplexe Aufgaben lösen.” Detaillierter wird die Unterscheidung, wenn man sie auf die Möglichkeit der Beschreibbarkeit des Problems zurückführt. Während komplizierte Sachverhalte deterministisch beschreibbar sind, können komplexe Systeme selbst dann nicht beschrieben werden, wenn Informationen über Subsysteme und deren Abhängigkeiten vollständig vorliegen. Für das Lösen von komplexen Problemen in der zivilen Gefahrenabwehr kann damit die anschließende Annahme getroffen werden:

Annahme 2: Komplexität (bezogen auf ein Problem oder auf die Umgebung mit dem Problem) erschwert den Problemlösungsprozess und muss in die Entwicklung potentieller IT-Unterstützung einbezogen werden.

Daraus resultiert für SKIS und deren Nutzung in komplexen Kontexten, dass eine ausschließlich technische Betrachtungsweise vom Senden von Informationen, von Kommunikation als Sender – Empfänger - Modell wie es von Weaver und Shannon [ShWe98] beschrieben wird, nicht ausreichend ist, um die Komplexität des menschlichen Verstehens und Kommunizierens zu beschreiben. Welche Wirkung die gesendeten Informationen bei dem Empfänger auslöst und welche Assoziationen hervorgerufen werden, lässt sich schwer vorhersagen. Dieses Verhältnis hat auch Bestand, wenn ein Kommunikationspartner ein Informationssystem ist und die bereitgestellten Informationen zum Handeln in komplexen, sicherheits-kritischen Situationen befähigen.

Es existieren unterschiedliche Strategien zur Reduktion von Komplexität, die von „trial and error“ bis zum Handeln durch Intuition reichen (siehe auch [DKRS94, Dörn11]). Die Intuition eines Menschen basiert auf den Erfahrungen, die er gemacht hat und diese erweitern sich stetig. Informationssysteme können ebenfalls zur Reduktion von Komplexität einen hinreichenden Beitrag leisten. Allerdings ergeben sich in Kontexten, die dynamischen Veränderungen unterliegen (verursacht auch durch den Menschen und sein Umfeld) neue bzw. erweiterte Anforderungen an ein Informationssystem.

Nach der Auseinandersetzung mit Komplexität folgt im Weiteren die Verbindung zwischen Problemen und Komplexität. „Von Problemen ist […] die Rede, wenn die Mittel zum Erreichen eines Zieles unbekannt sind oder die bekannten Mittel auf neue Weise zu kombinieren sind, aber auch dann, wenn über das angestrebte Ziel keine klaren Vorstellungen existieren.“ ([DKRS94], S. 302 f.). Es werden in dieser Arbeit Arbeitswelten betrachtet, in der komplexe Probleme zu lösen sind. Nach [Dörn11] liegen hierfür Kriterien in der:

• Variablenzahl - Es liegen eine hohe Zahl variierbarer Größen vor

• Variablenvernetzung - Variablen sind voneinander abhängig

• Transparenz - Nicht alle Einflussfaktoren und Abhängigkeiten sind bekannt

• Eigendynamik - Situation ändert sich auch ohne das Handeln des Problemlösers

• Dialektische Barriere - Weder Ausgangszustand noch Zielzustand sind genau bekannt

Darüber hinaus setzt [Berg02] die Bedingung für ein komplexes Problem wie folgt fest:

• Im benötigten Aufwand für die Lösung

• Im erforderlichen Wissen und der benötigten Erfahrung für die Lösung

• In der Anzahl der an dem Lösungsprozess beteiligten Personen

• In der Größe des Lösungsraums

• In einer ungenauen Problembeschreibung

Diese Arbeit folgt der Definition von [Dörn11]. Um im Folgenden den Umgang mit komplexen Problemen zu verdeutlichen, wird ein grundsätzliches Vorgehen zum Problemlösen in Anlehnung an den Risikomanagementprozess in der Abbildung 2-2 dargestellt. Grundsätzlich besteht ein Zusammenhang zwischen Risiko und Problem (siehe Abbildung 2-1), da nach Eintreten eines Risikos ein Problem vorliegt.

Quelle: Verfasser

Abbildung 2-1 Zusammenhang zwischen Risiko und Problem

Sowohl das Risikomanagement wie auch das Krisenmanagement folgen in der Lösungsstrategie einem einfachen „Plan, Do, Check, Act“-Zyklus. Daher wird zur Detaillierung des Problemlösungsprozesses auf den Risikomanagementprozess der IS031000 zurückgegriffen.

Quelle: Verfasser nach ISO 31000 [Iso318]

Abbildung 2-2 Prozess zur Problemlösung in Anlehnung an den Risikomanagementprozess gemäß ISO 31000

Der daraus resultierende Prozess zur Problemlösung sieht grundlegend fünf Schritte vor, die von zwei weiteren Prozessschritten begleitet werden.

Zunächst wird der Kontext hergestellt, um das Problem zu identifizieren. Wenn das Problem aus der Erfahrung bekannt ist und somit valide Lösungsstrategien bestehen, wird die entsprechende Person nach bewährtem Muster agieren [Iso318]. Sollte das Ergebnis nicht den Erwartungen entsprechen, wird nach neuen Wegen gesucht das Problem wird weitgehend analysiert, bewertet und entsprechend behandelt.

Auch hier hilft ein großer Erfahrungsschatz bei der Analyse und Suche nach Lösungen. Zu jedem Zeitpunkt besteht die Möglichkeit, sich Anregungen oder Lösungsvorschläge bei Dritten einzuholen. (Teil-)Ergebnisse werden stetig überwacht und mit den eigenen Erwartungen verglichen.

Insbesondere Mitarbeiter in der zivilen Gefahrenabwehr, auch wenn sie innerhalb eines Stabes tätig sind, haben nur bedingt Zeit, um Entscheidungen auf der Basis verlässlicher Informationen und Überlegungen zu treffen. Darüber hinaus vergeht zwischen der Entscheidungswahl eines Krisenstabes und einem messbaren Ergebnis viel Zeit, was eine Korrektur und den Gewinn von Verständnis in Bezug auf Handlung und Wirkung erschwert [Bund12].

Insgesamt erfüllen Mitarbeiter der Feuerwehr Aufgaben, die risikobehaftet sind, sodass ein Fehlverhalten zu drastischen Folgen führen kann. Ein robustes und verlässliches Informationssystem ist in diesem Kontext von Bedeutung, um eine hinreichende Unterstützung in der Aufgabenerfüllung zu geben und das Vertrauen der Nutzer in das System zu gewährleisten. Ein Informationssystem kann ein Werkzeug sein, um bestehende Hindernisse auf dem Lösungsweg zu umgehen, wie es in der nachfolgenden Abbildung dargestellt ist. Hier wurden von Frensch und Funke (siehe [FrFu95]) im Kontext des komplexen Problemlösens Werkzeuge identifiziert, die als Potential zur Überwindung von Hindernissen auf dem Weg zum Ziel angesehen werden können. Damit wird ein Spannungsfeld aufgebaut, das Zusammenhänge zwischen dem Problemlöser, seinem aktuellen Potential zum Lösen solcher Probleme (z.B. Wissen, Motivation…), der entsprechenden Aufgabe und der Umgebung erklärt (siehe Abbildung 2-3).

Quelle: Verfasser nach Frensch und Funke [FrFu95]

Abbildung 2-3 Zusammenhänge zwischen Problemlöser, Kontext und Aufgabe1

Aufbauend darauf wurde in Abbildung 2-4 der bereits genannte Prozess zur Problemlösung weiter ausgearbeitet und bettet sich damit in den Prozess in Abbildung 2-2 ein. Darüber hinaus werden Potentiale zur IT-Unterstützung aufgezeigt und entsprechende Elemente grau hinterlegt. Dazu wurden weiterführend ebenfalls [Dörn14], [Dörn11] und [Funk03] verwendet.

1. Im Rahmen der Identifizierung des Problems müssen Informationen gewonnen, aber auch nach bestehenden Mustern verdichtet werden, um eine erste Zieldefinition vorzunehmen. Insbesondere bei der Informationsgewinnung und der Selektion von wesentlichen Fakten kann eine IT-Unterstützung wertvoll sein und den Einsatzkräften Zeit und Sicherheit für ihre Aufgaben geben.

2. Auf der Basis des definierten Ziels kann eine weitere Ausarbeitung stattfinden und die Situation entsprechend analysiert werden. Dazu kann auf eigene Erfahrungen zurückgegriffen werden, um das aktuelle Problem mit bekannten Problemen und Lösungsstrategien zu vergleichen. Letztlich können auch erste Maßnahmen geplant werden, die auf der Analyse fußen. Eine IT-Unterstützung, in der z.B. über die eigenen Erfahrungen hinaus, auch Erfahrungen anderer im System aufgenommen, gepflegt und bereitgestellt werden, erzeugt einen großen Mehrwert.

3. Das Aufzeigen und Abschätzen von Handlungsalternativen (z.B. auch durch Simulation von potentiellen alternativen Verläufen) kann durch geeignete Informationssysteme begleitet werden.

4. In sicherheits-kritischen Systemen übernimmt das System viele Aufgaben und die Verantwortung für die Sicherheit wird an das System übergeben. In sicherheits-kritischen Mensch-Maschine-Systemen erfolgt das vielfach nicht auf diese Weise. Während Automatisierung dem Menschen an vielen Stellen die Arbeit abnimmt, kann sie auch Probleme auslösen. Wie bereits in vorherigen Abschnitten erwähnt, ist mit einem hohen Grad der Automatisierung für die Feuerwehr nicht zu rechnen.

Alle Schritte werden durch ein Selbstmanagement des Akteurs begleitet, wodurch die eigene Regulation von Stress wie auch psychischer und zeitlicher Druck zu verstehen ist.

Aus dem grundsätzlichen Bedarf an IT-Unterstützung und der Bedeutungsschwere der Aufgaben im komplexen Problemlösen kann ein grundsätzlicher Handlungsbedarf abgelesen werden, die Entwicklung von benötigten SKIS zu optimieren. Dazu verfolgt die vorliegende Arbeit eine Kombination aus risikobasiertem Softwareentwicklungsansatz und der Verwendung von verschiedenen Methoden – auch des Usability Engineerings. Um den Bedarf weiter auszuführen werden in den folgenden Abschnitten Nutzungsprobleme aufgezeigt.

Quelle: Verfasser nach [Dörn14], [Dörn11] und [Funk03]

Abbildung 2-4 Detaillierter Problemlösungsprozess

2.2 Erfahrung und die Bedeutung des Wissens des Designers / Entwicklers über den Nutzer

Der Mensch macht Fehler, ist ungenau und variiert seine Strategie für die Lösung von komplexen Aufgaben. Zwar weicht eine Maschine in ihrem Vorgehen nicht ab, dennoch kann auch hier ein Fehler auftreten, insbesondere verursacht durch unerwartete Einflüsse aus der Umwelt. Das Zusammenspiel aus Mensch, Maschine und Umwelt ist von großer Bedeutung für ein funktionierendes Gesamtsystem [ShPl10]. Die Umwelt lässt sich oftmals nur schwer beeinflussen, sodass die Optimierung der Schnittstelle, also des Zusammenspiels zwischen Mensch und Maschine, thematisiert wird.

Die Menschen, die hier betrachtet werden, müssen komplexe Probleme bzw. Aufgaben unter hohem Zeitdruck erfüllen. Dabei bewegen sie sich in komplexen, dynamischen Kontexten, was eine Problemlösung nicht vereinfacht. Die Schnittstelle zu einem unterstützenden Informationssystem ist daher von entscheidender Bedeutung für eine zeitgerechte, korrekte Aufgabenerfüllung. Daraus ergibt sich folgende Annahme, die auch durch das anschließende Beispiel gestützt wird.

Annahme 3: Komplexe Kontexte beeinflussen maßgeblich die Analyse im Softwareentwicklungsprozess, sowohl in Bezug auf die Auswahl als auch die Durchführung von Methoden.

Im Arbeitsverhalten gibt es zwischen dem Technischen Service und Arbeiten in der zivilen Gefahrenabwehr Parallelen (siehe [LiSK11]). Daher werden hier auch als Beispiel Störungen im Produktionsprozess betrachtet, die selten planbar sind und ein schnelles Eingreifen erfordern, um wirtschaftliche Verluste für ein Unternehmen so gering wie möglich zu halten. Es lassen sich daran weitere Aspekte für die Entwicklung von SKIS ableiten.

Es werden divergierende Geschäftsmodelle zur Realisierung des technischen Service verfolgt und sie verändern sich stetig, insbesondere durch die beginnende Etablierung von Industrie 4.0 [EmDö15]. Der Technische Service kann an externe Unternehmen ausgelagert werden, die speziell für diesen Zweck geschult und ausgerüstet sind. Des Weiteren kann die Fehlerbehebung von spezifischen Mitarbeitern im entsprechenden Unternehmen selbst oder in erster Instanz auch von den Bedienern der betroffenen Maschine durchgeführt werden. Alle Modelle bieten Vor- und Nachteile und es konnten hierzu Beobachtungen im In- und Ausland in unterschiedlichen Firmen, die dieselbe Maschine nutzen, getätigt werden [Reck07].

Stakeholder sind in verschiedenen Bereichen zu finden, vertreten jedoch alle das Interesse nach einer schnellen Lösungsfindung für ein aktuelles Problem.

Quelle: Verfasser

Abbildung 2-5 Stakeholder Analyse

Für das Management der Firma bis zum Bediener der Maschine steht eine adäquate Behandlung des Problems im Vordergrund². Aber auch externe Parteien wie Zulieferer oder der Hersteller der Maschine sind an einem reibungslosen Betrieb interessiert. Eine weitere Analyse der Stakeholder ist Abbildung 2-5 zu entnehmen und zeigt Akteure, die auf unterschiedliche Art und Weise auf einen Störungsbehebungsprozess einwirken. Einige nehmen bereits vor dem Eintritt einer Störung bei der Entwicklung der Maschine selbst Einfluss, andere durch die Bestimmung von organisatorischen Rahmenbedingungen und wieder andere, wie der Bediener, direkt im Lösungsprozess.

Nachfolgend wird durch einen Fehlerbaum ein spezifischer Fehler an einer Verpackungsmaschine analysiert. Es wird deutlich, dass Ursachen für das gegebene Problem sehr vielschichtig sein können. Um eine zielgerichtete Fehlerbehebung durchführen zu können, müssen Abhängigkeiten zwischen Ursache und Wirkung bekannt sein. Zentrale Aufgabe ist es daher im Störungsfall, das Problem zu identifizieren, unter Berücksichtigung von möglichen Fehlerketten und Abhängigkeiten in der Maschine eine Ursache herzuleiten und den Fehler schließlich zu beheben. In einem Ursache-Wirkungsdiagramm werden die Kategorien Management, Mensch, Material, Maschine, Mitwelt und Methode betrachtet. Da die Hauptursachen für die Störung „620 Seitenlaschenumleger“, in den Komponenten Mensch, Maschine, Methode und Material zu finden sind, wurden diese in Abbildung 2-6 verwendet.

Quelle: Reck [Reck07]

Abbildung 2-6 Beispiel Ursachen-Wirkungs-Diagramm

Bergmann (siehe [Berg02]) beschreibt als Kriterium für ein komplexes Problem den benötigten Aufwand, das erforderliche Wissen und Erfahrung für die Lösung des Problems. Die hohe Komplexität von aktuellen Maschinen durch hinreichend viele Abhängigkeiten von Baugruppen und Bauteilen erschweren die Ermittlung einer Fehlerursache, sodass vielfach unnötige Aktionen durchgeführt werden, die auch das eigentliche Problem verschärfen können.

Im Folgenden wird ein Störungsbehebungsprozess zu dem zuvor dargestellten Problem aufgezeigt, der im Verlauf einer Beobachtung durch den Verfasser der Arbeit in einem Unternehmen aufgenommen werden konnte. In diesem Fall sind die Bediener der Maschine in erster Instanz ebenfalls für den Technischen Service verantwortlich und können nur im Notfall Rücksprache mit anderen Mechanikern oder dem Hersteller der Maschinen halten. In der Abbildung 2-7 ist der optimale Pfad zur Beseitigung der Störung dargestellt und ebenfalls beobachtete Pfade, die insbesondere als negativ zu bewerten sind.

Quelle: Verfasser nach Reck [Reck07]

Abbildung 2-7 Störungsbehebungsprozess

Der Verlauf des dargestellten Prozesses zeigt deutlich, dass neben dem „Ignorieren“ der Störung (siehe Zyklus 1; 2; 3; 4) und der Durchführung von nicht notwendigen Operationen an der Maschine (siehe Zyklus 5; 6; 7; 8; 9 oder 10; 11; 12; 13; 14), auch zwei weitere Mechaniker um Hilfe gefragt wurden, um die tatsächliche Lösung herzuleiten. Dabei wurden auch Lösungsstrategien angestrebt, die weitere Störungen verursacht haben (siehe Zyklus 18; 19; 20; 21; 22; 23; 24; 25). Nach Schritt 30 konnte die Lösung herbeigeführt werden, die Störung wurde quittiert, die Produktion gestartet und die Störungsmeldung trat nicht wieder auf.

Wäre eine ideale Herangehensweise an die Störmeldung verfolgt worden, hätte das Problem identifiziert, angemessen analysiert, bewertet und anschließend behandelt werden müssen (siehe Abbildung 2-2 und Abbildung 2-4).

Hier ist ein Scheitern im Prozess schon in den ersten beiden Schritten festzustellen. Nicht alle Ursachen, die zu dieser Fehlermeldung führen, waren bei dem entsprechenden Bediener bekannt. Daher wurde zunächst mehrfach dieselbe Lösung angestrebt, die nicht zum Erfolg geführt hat. Ein größerer Erfahrungsschatz und Wissen über Ursache und Wirkung in Bezug auf die Maschine hätte Handlungsalternativen aufgezeigt und daher dem Mitarbeiter die Sicherheit zum eigenständigen Lösen des Problems gegeben.

Zu jedem Zeitpunkt hat der entsprechende Mitarbeiter die Möglichkeit seine Handlungen zu reflektieren, zu kontrollieren und zu bewerten oder sich bei anderen Mitarbeitern Rat zu suchen. Es zeigt sich deutlich, dass eine hinreichende Erfahrung des jeweiligen Mitarbeiters eine zielgerichtete Problemlösung erst möglich macht und damit ein wichtiger Baustein im Lösen komplexer Probleme ist [Funk04], was die nachfolgende Annahme verdeutlicht.

Annahme 4: Wissen des Problemlösers ist individuell an die Person gebunden, aber entscheidend für eine schnelle und nachhaltige Lösung.

Ein weiterer Aspekt eines komplexen Problems liegt in der Problembeschreibung an sich. Oftmals ist der Fehler am Produkt, was aktuell hergestellt wird, optisch zu sehen oder die Maschine bietet eine Fehlerausgabe an einem Terminal an. Aber auch hier kann eine Beschreibung von einer einfachen Ausgabe „Fehler 0815 ist aufgetreten“ bis zu einer detaillierten Lokalisation an der Maschine mit Angabe von Gründen für die entsprechende Meldung reichen. Je exakter die Fehlerbeschreibung ist, desto leichter ist für den Mechaniker die Herleitung der Ursache und somit die Behebung der Störung. Ein Mangel an der Problembeschreibung erhöht die Komplexität für den Menschen, der das Problem lösen muss.

Darüber hinaus nimmt hier die Umwelt (Rahmenbedingungen im Betrieb) Einfluss auf die Komplexität des Problems. Mehrschichtbetrieb, Fehler in der Übergabe zwischen den Schichten, Lärm in der Fertigungshalle und u.U. erforderliche Arbeitskleidung erschweren die Arbeit und somit eine effiziente Problemlösung. Zudem arbeiten oftmals Bediener, Mechaniker, Elektroniker und teilweise noch weiteres Personal an ein und derselben Maschine. In anderen Betrieben hingegen erfüllt eine Person nahezu alle diese Aufgaben. Daher haben die unterschiedlichen Benutzertypen auch verschiedene Wissensstände, zumal sie nicht die gleiche Ausbildung erhalten haben. Mechaniker und Elektroniker haben in der Regel die übliche Berufsausbildung ihrer Sparte absolviert, wobei Bediener unter Umständen auch ungelernt sein können und ihre Qualifikationen nur über die Arbeit an der Maschine gewonnen haben. Es ist auch möglich durch eine Teilnahme an einer Schulung oder anderen Weiterbildungen höhere Eignungen zu erreichen, was nicht jeder Bediener bzw. nicht jeder Betrieb in Anspruch nimmt. Die Erfahrung in Bezug auf die Maschine, mit der Arbeitsaufgabe und der allgemeinen Organisation des Betriebs variiert bei jedem, je nach Ausbildung, aber auch nach Dienstalter in dem jeweiligen Unternehmen. Es lässt sich allerdings auch feststellen, dass jüngeren Mitarbeiter der Umgang mit neuen Gegebenheiten leichter fällt, wie Bedienung der Maschine über einen Touchscreen und IT-Unterstützung in der Handhabung der Maschine. Die persönlichen Merkmale der Mitarbeiter, wie Alter oder Geschlecht, hängen natürlich auch stark von dem Betrieb, aber auch von dem Land, in dem das Unternehmen tätig ist, und dessen üblichen Standards ab. [Reck07]

Aus diesem Beispiel und der Differenzierung der einzelnen Mitarbeiter kann die nachfolgende Annahme gefolgert werden.

Annahme 5: Eine hohe Gebrauchstauglichkeit eines Informationssystems basiert auf einer hinreichenden Analyse des Nutzungsrahmens (Benutzer, Aufgabe, Kontext).

In diesem Abschnitt der Arbeit wurden die Bedienung einer Mensch-Maschine-Schnittstelle und die Relevanz von Erfahrung im Umgang mit der Maschine thematisiert. Basierend auf dem gegenwärtigen Standpunkt fehlt die Verknüpfung von Risikobetrachtungen und der Entwicklung von gebrauchstauglichen Systemen in dem Kontext und eröffnet daher den Handlungsbedarf.

2.3 Benutzerspezifische Qualitätseigenschaften

Um die Differenzierung zwischen den verschiedenen Einsatzkräften zu verdeutlichen, wird hier die Evaluation eines BMBF-Projektes herangezogen. Das Projekt AirShield³ hatte zum Ziel, Feuerwehr-Einsatzkräfte in einem Einsatz mit Gefahrstoffen (Atomar, Biologisch, Chemisch) zu unterstützen, durch die Nutzung unbemannter Flugroboter, die eine Gefahrstoffmessung des potentiell kontaminierten Gebiets teilautomatisiert durchführen können. Hierzu wurde eine Benutzungsschnittstelle konzipiert, die die Steuerung und Koordination der Flugroboter realisierte, eine Lagedarstellung liefert, die (zukünftige) Prognose simuliert und darauf basierend eine Entscheidungsunterstützung anbietet.

Es wurden drei Rollen mit unterschiedlichen Systemsichten definiert, um eine rezipierbare Unterstützung für die operative Einheit (ABC), die operativ-taktische Führungsstelle (EAL) und die technische Einsatzleitung (TEL) zu erzeugen [SPLR10]. Da jede Rolle einen abweichenden Informationsbedarf aufweist, wurden insbesondere für die Komponente der Entscheidungsunterstützung diese verschiedenen Sichten realisiert. Dazu wurden für jede Rolle relevante Ereignisse identifiziert und die Abhängigkeit zwischen einem Ereignis und einem daraus resultierenden Bedarf an neuen Informationen hergeleitet. Es wurden sowohl externe Ereignisse, wie die Detektion von Gefahrstoffen berücksichtigt, als auch interne Ereignisse, wie das Abschließen einer vorherigen Handlungsempfehlung oder Definieren eines Gefahrengebiets im System betrachtet. Zur Realisierung ist im AirShield-System ein regelbasierter Ansatz verfolgt worden, in dem periodisch die Gültigkeit von Prämissen geprüft wurde. Letztlich wurden so für jede Rolle abweichende Inhalte erzeugt, die Präsentation und Navigation im System wurde aber nicht variiert [KSFS11].

In der System - Evaluation wurden zwölf Probanden im Rahmen von semistrukturierten, offenen Interviews unter der Nutzung von vordefinierten Szenarios bezüglich Inhalt, Präsentation und Navigation des Systems befragt [FrSK12]. In den Szenarien wurde ein für die entsprechende Rolle typischer Ablauf definiert, in dem zu Beginn allgemeine Fertigkeiten in Bezug auf die Nutzung eines Geo-Informationssystems (GIS) abgefragt wurden (z.B. Zoomen, …). Im Weiteren wurden die Aufgaben spezifischer, in Relation zur Nutzung des Systems von der entsprechenden Rolle in der ABC-Gefahrenabwehr. Zur Erhöhung der Validität der Testergebnisse wurde sowohl schriftlich als auch durch eine Kamera protokolliert. Für die Auswertung wurden die Aussagen digitalisiert und entsprechend in vorher definierten Kategorien gruppiert. Die Evaluation diente zum einen der Prüfung der Erfüllung von Benutzeranforderungen und zum anderen der Priorisierung der weiterführenden Entwicklungsarbeiten. Das genaue Vorgehen wurde von Friberg und Schäfer in [FrSK12] beschrieben.

Auch wenn das System in seiner Gesamtheit auf Zustimmung gestoßen ist, konnten inner-halb einzelner Komponenten stark divergierende Äußerungen festgestellt werden. Für einige war der Informationsgehalt schon zu hoch, andere wünschten sich darüber hinaus noch viele weiterreichende Angaben. Während ein Teil der Probanden sich schon auf bestehendes Wissen bezüglich GIS-Anwendungen berufen konnte, war für andere die Navigation im System eine Herausforderung. Um Abweichungen zwischen den Probanden insbesondere für die Komponente der Entscheidungsunterstützung feststellen zu können, wurden im Rahmen dieser Arbeit die Aussagen nochmal in die übergeordneten Kategorien Inhalt, Navigation der Benutzungsschnittstelle und Präsentation untergliedert. Die Ergebnisse in Bezug auf die detaillierte Analyse werden im Folgenden dargestellt.

Navigation. Im Rahmen der Navigation sind zwei Aspekte zu betrachten. Das Entscheidungsunterstützungssystem ist nur eine Teilkomponente des Gesamtsystems von AirShield. Daher ist der eine relevant zu untersuchende Aspekt die Navigation zur Komponente und des Weiteren ist die Navigation innerhalb der Komponente zu betrachten. Die Realisierung der Integration des Entscheidungsunterstützungssystems (DSS) erfolgte mittels eines dritten Tabs in der unteren Navigationsleiste, wie es in der nachfolgenden Abbildung dargestellt ist (gekennzeichnet durch einen roten Pfeil).

Quelle: Verfasser siehe auch Koch et al. [KSFS11]

Abbildung 2-8 Gesamtsystem AirShield

Das DSS als Komponente kann auf verschiedene Weise in das Gesamtsystem integriert werden. Es wurde entschieden das DSS als Komponente gekapselt einzubinden. Drei grundlegende Einstellungen in Bezug auf die Platzierung des DSS im Gesamtsystem können daher angenommen werden.

• Gleichbleibende Kapselung (z.B. DSS als eigenständiger „Tab“, wie in der Abbildung oben dargestellt)

• Reduzierung der Kapselung (z.B. Integration in das User Interface des Gesamtsystems)

• Steigerung der Kapselung (z.B. DSS wird im eigenständigen Fenster präsentiert)

Vier Probanden haben die bestehende Kapselung als vorteilhaft empfunden, ein Proband forderte eine Verstärkung der Trennung zwischen den einzelnen Komponenten durch die Nutzung eines zweiten Bildschirms und drei Probanden haben eine Reduzierung der Aufteilung präferiert, indem die Entscheidungsunterstützung direkter Teil des Hauptsystems wird. Die anderen Teilnehmer an der Evaluation haben zu diesem Punkt keine Angaben getätigt. Die nachfolgende Grafik veranschaulicht die Verteilung der Aussagen bezogen auf die Rolle der Probanden. Betrachtet man z. B. die Rolle des Einsatzabschnittsleiters (EAL), ist eine gleiche Verteilung zwischen den drei Alternativen zu sehen. Es konnten damit nicht nur unterschiedliche Ansichten zwischen den einzelnen Rollen abgeleitet werden, auch innerhalb der jeweiligen Rolle waren starke Abweichungen festzustellen.

Quelle: Verfasser

Abbildung 2-9 Verteilung der Aussagen zur Kapselung auf Rollen

Im Weiteren wird zunächst die Navigation innerhalb der Entscheidungsunterstützungskomponente betrachtet.

Aufgabe dieser Komponente ist es, dem Nutzer durch die Bereitstellung von Informationen und empfohlenen Maßnahmen gezielt eine Entscheidungshilfe zu bieten. Der Prozess zum Umgang mit Maßnahmen stellt sich wie folgt dar:

• Maßnahmen werden automatisch vom System vorgeschlagen, weil eine entsprechende Regel auf die Umgebungsparameter zutrifft oder

• Maßnahmen können vom Nutzer explizit angefordert werden. Dazu werden vordefinierte Suchwörter angeboten, um potentielle Bedarfe ersichtlich zu machen.

Die nachfolgende Grafik zeigt den Teil der Komponente, der für die Anforderung von Maßnahmen verantwortlich ist.

Quelle: Verfasser

Abbildung 2-10 Anforderung einer Maßnahme

Generierte Maßnahmen werden zunächst unter der Kategorie „Vorgeschlagenen Maßnahmen“ gespeichert. Der Nutzer des Systems kann dann entscheiden, wie er mit der angebotenen Information nachfolgend verfährt, z.B. welche Schutzkleidung der aktuellen Lage entsprechend verwendet werden sollte oder welcher Umgang mit dem gemessenen Gefahrstoff sinnvoll ist. Es können Maßnahmen angenommen und bearbeitet werden, aber auch abgelehnt, wenn sie für den Nutzer nicht als angemessen erscheinen. Auf diese Weise kann der Nutzer die generierten Informationen ordnen, um immer den Überblick zu behalten (vgl. [KSFS11]).

Letztlich sind es drei Kategorien, die eine Maßnahme einnehmen kann: „Neu“, „in Bearbeitung“ und „Beendet“. Angeforderte bzw. vorgeschlagene Maßnahmen sind durch den Nutzer noch nicht reflektiert worden und sind somit als neu im System zu sehen. Angenommen Maßnahmen befinden sich in Bearbeitung durch die Einsatzkraft und abgeschlossene, abgelehnte oder weitergeleitete Maßnahmen sind für den aktuellen Benutzer beendet, auch wenn unterschiedliche Ursachen dafür zu finden sind. Diese Maßnahmen können von dem Benutzer in Form einer Historie allerdings weiterhin eingesehen werden. Der Prozess ist in der Abbildung 2-11 dargestellt und zeigt potentielle Nutzungswege im Umgang mit Maßnahmen auf.

Quelle: Verfasser

Abbildung 2-11 Prozess der Maßnahmenbearbeitung

Um eine Sicht auf die entsprechende Benutzungsschnittstelle zu geben, ist in der nachfolgenden Abbildung das Graphical User Interface (GUI) dargestellt. Die linke Seite der GUI ermöglicht die Maßnahmenverwaltung, der mittlere Bereich gibt eine Sicht auf eine ausgewählte Maßnahme und der rechte Teil bietet zusätzlich Informationen, z.B. in Bezug auf die Georeferenzierung der Maßnahme an.

Quelle: Verfasser siehe auch Koch et al. [KSFS11]

Abbildung 2-12 Benutzungsschnittstelle zur Entscheidungsunterstützung

Durch diesen Prozess lassen sich angebotene Informationen leicht filtern und für die aktuelle Aufgabe angepasst sortieren. In der nachfolgenden Grafik sind die Antworten der Probanden entsprechend ihrer Rolle einsortiert. Hieraus geht hervor, dass Probanden derselben Rolle den Prozess zum einen als gut empfinden und andere Personen in der Rolle ihn für unnötig halten. Betrachtet man z.B. die Rolle „Technische Einsatzleitung“ (TEL), so gibt es gleichviele Probanden, die den Prozess als gut empfinden, wie sie von anderen Probanden der Rolle auch als unnötig oder zu kompliziert angesehen werden. Ein einheitliches Meinungsbild konnte hier nicht festgestellt werden.

Quelle: Verfasser

Abbildung 2-13 Angaben der Probanden zum Prozess in Bezug zu ihrer Rolle

Annahme 6: Durch die unterschiedlichen Wissensstände des Problemlösers ist eine Differenzierung des Systems im angebotenen Inhalt, der Navigation und der Präsentation abzuwägen.

In diesem abschließenden Teil des Kapitels 2 wurde spezifisch auf Effekte der Nutzung von SKIS in der zivilen Gefahrenabwehr geschaut. Auch hier lassen sich Risiken in einer falschen oder umständlichen Nutzung eines SKIS feststellen. Damit kann ein Bedarf an einem veränderten Vorgehen in der Entwicklung und an einer Risikobetrachtung definiert werden, da Auswirkungen bei fehlerhafter Nutzung des Systems oftmals nicht bewusst sind.

Es konnten erst verallgemeinerte Vorgehensweisen im Problemlösen aufgezeigt werden, Untersuchung in verwandten Kontexten (Technischer Service) und in der betrachteten Domäne „Zivile Gefahrenabwehr“ selbst getätigt werden. Damit sind die Untersuchungen ausreichend, um das Problemfeld aufzuspannen.

¹ Englische Abbildungen werden bewusst nicht übersetzt, sondern relevante Details im angrenzenden Text erläutert.

² Der mögliche Wunsch eines Bedieners für eine Arbeitsunterbrechung aufgrund des Maschinenstillstands wird hier außer Acht gelassen

³ Airborne Remote Sensing for Hazard Inspection by Network Enabled Lightweight Drones, gefördert durch das BMBF (Förderkennzeichen: 13N9838)