Die vorliegende Bachelor-Thesis befasst sich mit der Identifikation der häufigsten Probleme im IT- Supportumfeld der Firma easyzone und analysiert, was bei diesen Problemen im Detail Schwierigkeiten bereitet. Die Erkenntnisse sollen easyzone helfen, ein Online-Hilfesystem zur optimalen Unterstützung ihrer Kunden zu entwickeln.
Zunächst wird mittels qualitativer Inhaltsanalyse ein grober Überblick über die vorhandenen Probleme erstellt. Anschliessend werden diese in Interviews mit Experten weiterführend ausdifferenziert. Kern der Arbeit bildet die Durchführung einer Applied Cognitive Task Analysis, durch die bei konkreten Aufgaben beziehungsweise Problemen die schwierigen kognitiven Elemente herauskristallisiert werden. Abschliessend werden Empfehlungen abgegeben, wie die Erkenntnisse bei der Entwicklung des Online- Hilfesystems verwendet werden können.
Unterstützend werden der Leserin, dem Leser die notwendigen psychologischen Grundlagen in Bezug auf das Prozessmodell Usability Engineering, Kognition, Wissensformen, Expertise sowie Cognitive Task Analysis (CTA) beziehungsweise Applied Cognitive Task Analysis (ACTA) vermittelt.
Inhaltsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
Abkürzungen
1 Einleitung
1.1 easyzone
1.2 Ausgangslage
1.3 Psychologische Perspektive
1.4 Fragestellung
2 Theoretische Grundlagen
2.1 Prozessmodell Usability Engineering
2.2 Kognition und kognitive Elemente
2.3 Wissensformen
2.3.1 Deklaratives Wissen
2.3.2 Prozedurales Wissen
2.3.3 Implizites Wissen
2.3.4 Explizites Wissen
2.3.5 System- und Steuerungswissen
2.4 Experten und Laien
2.4.1 Aspekte der Expertise
2.5 Cognitive Task Analysis (CTA)
2.6 Applied Cognitive Task Analysis (ACTA)
2.6.1 Task Diagram Interview.
2.6.2 Knowledge Audit
2.6.3 Simulation Interview.
2.6.4 Cognitive Demand Table
3 Durchführung
3.1 Voranalyse
3.1.1 Methodenwahl
3.1.2 Durchführung
3.1.3 Ergebnisse
3.2 Problemanalyse
3.2.1 Methodenwahl
3.2.2 Durchführung
3.2.3 Ergebnisse
3.3 Wissensanalyse
3.3.1 Methodenwahl
3.3.2 Durchführung
3.3.3 Aufgabe 1 DNS-Domain registrieren und einrichten
3.3.4 Aufgabe 2 E-Mail Postfach einrichten
3.3.5 Aufgabe 3 Dateien auf Webserver laden via FTP
4 Empfehlungen
4.1 Nutzung der Ergebnisse
4.1.1 Task Diagram.
4.1.2 Knowledge Audit
4.1.3 Simulation Interview.
4.1.4 Cognitive Demand Table
4.2 Nächste Schritte
4.2.1 Antrag Folgeprojekt
4.3 Ergänzende Empfehlung
4.3.1 Inhaltliche Erweiterung
4.3.2 Wissenschaftliche Fragestellungen
5 Fazit
6 Quellenverzeichnis
6.1 Literaturverzeichnis
6.2 Web-Quellen
7 Anhang
A Interviewleitfaden Task Diagram.
B Interviewleitfaden Knowledge Audit
C Interviewleitfaden Simulation Interview.
D Kategorisierungen der E-Mail-Korrespondenz (Voranalyse)
E Einzelantworten der Experten (Problemanalyse)
F Einzelantworten der Experten (Wissensanalyse)
Abstract
Die vorliegende Bachelor-Thesis befasst sich mit der Identifikation der häufigsten Probleme im IT-Supportumfeld der Firma easyzone und analysiert, was bei diesen Problemen im Detail Schwierigkeiten bereitet. Die Erkenntnisse sollen easyzone helfen, ein Online-Hilfesystem zur optimalen Unterstützung ihrer Kunden zu entwickeln.
Zunächst wird mittels qualitativer Inhaltsanalyse ein grober Überblick über die vorhandenen Probleme erstellt. Anschliessend werden diese in Interviews mit Experten weiterführend ausdifferenziert. Kern der Arbeit bildet die Durchführung einer Applied Cognitive Task Analysis, durch die bei konkreten Aufgaben beziehungsweise Problemen die schwierigen kognitiven Elemente herauskristallisiert werden. Abschliessend werden Empfehlungen abgegeben, wie die Erkenntnisse bei der Entwicklung des Online-Hilfesystems verwendet werden können.
Unterstützend werden der Leserin, dem Leser die notwendigen psychologischen Grundlagen in Bezug auf das Prozessmodell Usability Engineering, Kognition, Wissensformen, Expertise sowie Cognitive Task Analysis (CTA) beziehungsweise Applied Cognitive Task Analysis (ACTA) vermittelt.
Zeichen : 96‘640 (ohne Deckblatt, Verzeichnisse und Anhang)
Keywords
Wissensanalyse, Wissen, Problemanalyse, Tätigkeitsanalyse, Arbeitsanalyse, Problemlösung, Kognition, kognitive Elemente, Hilfesystem, Support, Informatik, Cognitive Task Analysis, Applied Cognitive Task Analysis, Hilfesystem, Support
Abbildungsverzeichnis
Abbildung 1 Gebrauchstauglichkeit (Usability) im Kontext (Fischer, 2010)
Abbildung 2 Prozessmodell Usability-Engineering nach Sarodnick und Brau (2006)
Abbildung 3 Wissensformen für Prozesssteuerung (nach Kluwe, 1997, zitiert nach Kluwe, 2006)
Abbildung 4 Beispiel Task Diagram
Abbildung 5 Teilschritte der Bachelor-Thesis
Abbildung 6 Resultierende Kategorien der Voranalyse
Abbildung 7 Aufgabe 1 Task Diagram „DNS-Domain registrieren und einrichten“
Abbildung 8 Aufgabe 2 Task Diagram „E-Mail Postfach einrichten“
Abbildung 9 Aufgabe 3 Task Diagram „Dateien auf Webserver laden via FTP“
Abbildung 10 Nächste Schritte im Rahmen des Usability-Engineerings nach Sarodnick und Brau (2006)
Tabellenverzeichnis
Tabelle 1 Beispiel Knowledge Audit
Tabelle 2 Beispiel Simulation Interview
Tabelle 3 Beispiel Cognitive Demand Table
Tabelle 4 Zusammengefasste Antworten der Problemanalyse
Tabelle 5 Aufgabe 1 Knowledge Audit „DNS-Domain registrieren und einrichten“
Tabelle 6 Aufgabe 1 Simulation Interview „DNS-Domain registrieren und einrichten“
Tabelle 7 Aufgabe 1 Cognitive Demand Table „DNS-Domain registrieren und einrichten“
Tabelle 8 Aufgabe 2 Knowledge Audit „E-Mail Postfach einrichten“
Tabelle 9 Aufgabe 2 Simulation Interview „E-Mail Postfach einrichten“
Tabelle 10 Aufgabe 2 Cognitive Demand Table „E-Mail Postfach einrichten“
Tabelle 11 Aufgabe 3 Knowledge Audit „Dateien auf einen Webserver laden via FTP“
Tabelle 12 Aufgabe 3 Simulation Interview „Dateien auf einen Webserver laden via FTP“
Tabelle 13 Aufgabe 3 Cognitive Demand Table „Dateien auf Webserver laden via FTP“
Tabelle 14 Umsetzung der Ergebnisse des Cognitive Demand Table im Hilfesystem
Tabelle 15 Vorschlag Projektantrag „Konzeptionierung des easyzone Online-Hilfesystems“
Abkürzungen
Abbildung in dieser Leseprobe nicht enthalten
1 Einleitung
Im folgenden Abschnitt werden das Umfeld, die Ausgangslage sowie die Problemstellung für die vorliegende Thesis erläutert. Anschliessend wird eine psychologische Perspektive eingenommen, aus welcher dann die Fragestellungen abgeleitet werden.
1.1 easyzone
Die KMU easyzone ist eine Schweizer Informatikdienstleisterin mit insgesamt vier Mitarbeitern. Zu ihren Dienstleistungen gehören Angebote wie Internetanbindungen via Glasfaser, Hosting für Webseiten, Backuplösungen sowie Serverangebote. Die Firma hat 2010 ihre aktive Geschäftstätigkeit aufgenommen. Es handelt sich somit um eine junge Firma mit einem noch eher kleinen Kundenstamm.
1.2 Ausgangslage
Easyzone stellt die Zufriedenheit und die bestmögliche Unterstützung ihrer Kunden ins Zentrum. Sie ist bestrebt, die Hilfeleistungen für Kunden in Problemsituationen zu optimieren. Weiter versucht easyzone, den Kunden Mittel zur Verfügung zu stellen, damit diese im besten Fall ihre Probleme selbst lösen können.
Basierend auf diesen Zielen plant easyzone die Entwicklung eines auf dem Internet frei zugänglichen Hilfesystems, welches neben der telefonischen Hotline eine weitere Anlaufstelle für Kunden bietet. Später soll das Hilfesystem die primäre Kontaktmöglichkeit für die Kunden sein. Neben der Optimierung der Kundenunterstützung, soll dadurch auch die Beanspruchung der Mitarbeiter reduziert werden, da die Kunden ihre Probleme gegebenenfalls selbständig lösen können.
Weiter soll den Benutzern die Möglichkeit geboten werden, Neues zu lernen und für zukünftige Problemsituationen Lösungsstrategien zu erhalten. Durch die geplante öffentliche Verfügbarkeit des Hilfesystems soll es auch als Marketinginstrument eingesetzt werden können.
Die Entwicklung eines solchen Systems ist mit einem enormen Aufwand verbunden, der aufgrund personeller und zeitlicher Ressourcen-Einschränkungen in dieser Thesis nicht abgedeckt werden kann. Im Rahmen des Prozessmodells Usability Engineering nach Sarodnick & Brau (2006, siehe 2.1 Prozessmodell Usability Engineering, S. 8) sind alle Arbeiten der Thesis in der Phase der Arbeits-, Prozess- und Systemanalyse angesiedelt. Es wird kein Konzept für die Entwicklung beziehungsweise kein Prototyp eines solchen Hilfesystems erstellt. Die Erkenntnisse dieser Thesis sollen für die nächsten Phasen entsprechende Arbeitsgrundlage sein.
1.3 Psychologische Perspektive
Die Grundidee des Hilfesystems ist die optimale Unterstützung eines Benutzers in einer Problemsituation. Durch die Nutzung des Systems werden bestenfalls die Mitarbeiter des IT-Supports weniger beansprucht (zum Beispiel via Telefon oder E-Mail), da Benutzer Antworten auf ihre Fragen via dem Hilfesystem erhalten und so allenfalls die Probleme gleich selber lösen können. In diesem Sinne darf also durchaus von einer Automatisierung der helfenden Person gesprochen werden (Mitarbeiter des IT-Supports werden durch das System ersetzt). Somit muss geklärt werden, was ein solches System überhaupt „können“ und „wissen“ muss, um entsprechende Hilfestellungen anbieten zu können.
Um diese Frage zu beantworten, muss zunächst geklärt werden, welche Probleme bei Kunden von easyzone überhaupt auftreten und in welcher Häufigkeit dies geschieht. Als nächster Schritt muss eruiert werden, weshalb diese Probleme auftreten und was in den konkreten Problemsituationen effektiv zu Schwierigkeiten führt.
Neben der Fokussierung auf das Problem, ist weiter relevant, welche Strategien und welches Wissen von Experten (zum Beispiel Mitarbeitern des IT-Supports) angewendet werden, um diese Probleme zu lösen. Ebenfalls hilfreich ist die Kenntnis, wie solche Aufgaben im Normalfall durchgeführt werden (zum Beispiel wie wird ein E-Mail Postfach korrekt eingerichtet?).
Ergebnisse solcher Analysen können bei der Entwicklung eines Hilfesystems einen unterstützenden Beitrag leisten, indem sie Erkenntnisse generieren über den Benutzer (also Kunde), die technische Komponente (also Hilfesystem) sowie über die Aufgabe selbst (zum Beispiel Unterstützung bei der Einrichtung eines E-Mail Postfachs). In diesem Sinne wird durch die Optimierung der Benutzbarkeit, Funktionalität und Aufgabenbewältigung die Gebrauchstauglichkeit (Usability, vgl. Richter & Flückiger, 2009; Fischer, 2010) gesamthaft verbessert.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung1Gebrauchstauglichkeit (Usability) im Kontext (Fischer, 2010)
Zusammengefasst kann gesagt werden, dass für die Entwicklung eines Hilfesystems relevant ist, welche Probleme überhaupt auftreten, weshalb diese auftreten beziehungsweise wo die Schwierigkeiten liegen und welche Strategien und welches Wissen zur Lösungsfindung angewendet werden. Weiter müssen Erkenntnisse gesammelt werden in Bezug auf potentielle Benutzer, die technische Komponente sowie die Aufgabe selbst, besser gesagt die damit zusammenhängende Benutzbarkeit, Funktionalität und Aufgabenbewältigung.
1.4 Fragestellung
Basierend auf der oben beschriebenen Ausgangslage werden in dieser Thesis folgende Fragestellungen untersucht:
Abbildung in dieser Leseprobe nicht enthalten
2 Theoretische Grundlagen
Die nachfolgenden theoretischen Grundlagen sollen den Leser dabei unterstützen, die Inhalte der vorliegenden Thesis zu verstehen. Spezifische psychologische Methoden werden jeweils in den entsprechenden Kapiteln bei der Anwendung erläutert.
2.1 Prozessmodell Usability Engineering
Um Systeme (zum Beispiel Software) für Benutzer gebrauchstauglich zu machen, damit diese eine hohe Benutzbarkeit aufweisen, die dienlich zur Bewältigung der Aufgabe sind und eine passende Funktionalität bieten (vgl. Fischer, 2010), schlagen Sarodnick und Brau (2006) ein Vorgehen nach dem Prozessmodell „Usability Engineering“ vor. Ein solches systematisches Vorgehen verspricht nach Kalbach (2003, zitiert nach Sarodnick & Brau, 2006) Erfolgssicherheit, Zeit- und Kostenersparnis für die Durchführung der Entwicklung.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung2Prozessmodell Usability-Engineering nach Sarodnick und Brau (2006)
Während der Analysephase (1) sollen die Rahmenbedingungen für das Projekt geklärt werden, damit das zu entwickelnde System optimal an die Aufgabe der Benutzer angepasst werden kann. Im Rahmen einer Arbeits-, Prozess- und Systemanalyse, müssen zunächst die zu erledigenden Aufgaben und deren Häufigkeit identifiziert werden. Weiter müssen die Bedingungen (zum Beispiel Strukturen, Umgebung, usw.) berücksichtigt werden, unter welchen die Aufgaben durchgeführt werden sollen. Ebenfalls muss transparent sein, welche Arbeitsprozesse und Systeme (Hard- / Software) dazu zum Einsatz kommen.
Als nächstes folgt die Erhebung von Nutzeranforderungen. Diese Informationen sind insofern wertvoll, da zukünftige Nutzer ihre Arbeitssituation am besten kennen und für die Praxis Ideen und Wissen einbringen können, welche Potential für die Verbesserung der Prozesse beinhalten.
In der Konzeptphase (2) gilt es, die Erkenntnisse der Analysephase ins System einfliessen zu lassen. Zuerst wird im Rahmen der Arbeitsgestaltung und Prozessdefinition klargestellt, wie das neue System in die bestehende Umgebung eingegliedert werden soll, das heisst welche Veränderungen der bestehenden Aufgaben, Prozesse oder Rahmenbedingungen vorgenommen werden müssen. Anschliessend erfolgt die Entscheidung über Systemfunktionalitäten. Dabei wird definiert, welche Funktionen das neue System beinhalten soll. Dies bedeutet auch, dass entschieden werden muss, welche Aufgaben vom System (Maschine) und welche vom Mensch durchgeführt werden sollen (Mensch-Maschine Funktionsteilung). Auf dieser Grundlage ist nun eine fundierte Konzepterstellung möglich. Sarodnick und Brau weisen speziell darauf hin, dass gerade in der Konzepthase bereits möglichst früh betroffene Nutzer (sowohl Kunden als auch Mitarbeiter) mit einbezogen werden, da diese von den veränderten Aufgaben, Prozessen und Rahmenbedingungen massgeblich betroffen sein werden.
In der Entwicklungsphase (3) wird das eigentliche System umgesetzt, beginnend mit der Entwicklung von Prototypen, die ausführlich geprüft werden müssen. Sollten sich bei der Evaluation der Prototypen markante Schwächen zeigen, müsste die Konzeptphase (2) oder sogar die Analysephase (1) nochmals durchgegangen werden. In der Entwicklungsphase kommen zunehmend auch ästhetische Aspekte hinzu (zum Beispiel Gestaltung der Benutzeroberfläche). Ist das System basierend auf den Erkenntnissen des Prototyps und entsprechenden Evaluationen fertig entwickelt, kann die Integration des Systems in die Umgebung erfolgen (Systemintegration).
Zum Schluss wird in der Einführungsphase (4) ein Piloteinsatz durchgeführt, bei welchem in ein einem ausgewählten Bereich mit wenigen Nutzern das neue System getestet wird. Parallel dazu sollten mit Arbeitsgestaltungsmassnahmen die vorgeschlagenen Änderungen aus der Arbeitsgestaltung und Prozessdefinition (Konzeptphase) umgesetzt werden. Dazu gehören Arbeits- oder organisatorische Aspekte sowie Massnahmen in Bezug auf das Personal, wie etwa Schulungen, neue Selektionskriterien für Mitarbeiter, usw.
Einen zentralen Platz in diesem Modell nimmt die Evaluation ein. In jeder Phase müssen immer wieder Überprüfungen und gegebenenfalls Korrekturmassnahmen vorgenommen werden. Besonders zu betonen ist dabei das möglichst frühe Einbeziehen von (potentiellen) Nutzern. Dies sollte am besten noch vor dem eigentlichen Testen des Systems erfolgen (etwa bereits in der Konzeptphase), um den zukünftigen Nutzern dadurch ein Mitspracherecht bei der Gestaltung der Arbeits- und Prozessdefinition zu gewähren. Es darf nicht vergessen werden, dass die Nutzer Experten für ihre Arbeitssituationen sind.
Da es sich beim ganzen Prozessmodell um multidisziplinäre Arbeiten handelt, ist es umso wichtiger, dass alle Tätigkeiten mittels einer sauberen Projektplanung und einem klaren Projektmanagement (Projektplanung und –management) geführt werden. Dazu gehören die klassischen Projektmanagementtätigkeiten wie Rollenverteilung, Arbeitspakete definieren, Termine festlegen, Controlling, usw.
2.2 Kognition und kognitive Elemente
Kognition wird nach Fröhlich (2008, S. 280) definiert als: „[…] Gesamtheit aller Funktionen und Prozesse, die mit dem Erwerb, der Speicherung und Wiederverwendung von anschaulichen und abstrakten Erkenntnissen, Einsichten und Wissen zu tun haben “.
Weiter beschreibt Fröhlich kognitive Elemente als Grundeinheiten der Informationsverarbeitung, des Denkens, der Erinnerung und des Wissens. Solche Elemente können beispielsweise Buchstaben, Worte, Begriffe, Klänge, Silben, Melodien, geometrische Formen, Such- und Entscheidungsstrategie und so weiter sein.
2.3 Wissensformen
Wissen, welches im Gedächtnis abgespeichert ist, wird in folgende Wissensformen unterteilt (vgl. Schacter, Wagner & Buchner, 2000, zitiert nach Kluwe, 2006; Fröhlich, 2008):
2.3.1 Deklaratives Wissen
Deklaratives Wissen umfasst Kenntnisse über Personen, Ereignisse, Prozesse, Handlungen, Sachverhalte, usw. Diese Wissensbestände können durch Sprache oder Schrift vermittelt werden. Deklaratives Wissen wird weiter in episodisches (raumzeitlicher Kontext) und semantisches (abstrakt, begrifflich) Wissen unterteilt.
Beispiel für episodisches Wissen: Die Mitarbeiterin des Informatik-Supports erinnert sich daran, mit welchen Kunden sie welches Problem vor drei Tagen bearbeitet hat.
Beispiel für semantisches Wissen: Der Mitarbeiter des Informatik-Supports weiss, wie das DNS (Domain Name System) im Detail funktioniert.
2.3.2 Prozedurales Wissen
Prozedurales Wissen sind Kenntnisse über Handlungsabläufe, welche schlecht verbalisierbar sind. Diese Form von Wissen wird vor allem beim Verknüpfen von Ereignissen (assoziatives Lernen) erworben.
Beispiel für prozedurales Wissen: Die Mitarbeiterin des Rechenzentrums weiss, dass sie ihren Daumen auf den Scanner legen muss, damit sich die Sicherheitstüre zum Serverraum öffnet.
2.3.3 Implizites Wissen
Implizites Wissen sind Erinnerungen oder Erinnerungsleistungen, welche unbewusst genutzt werden. Dies kann auf kürzlich vorher wahrgenommene, aber nicht bewusst erinnerte Informationen zurückgeführt werden.
Beispiel für implizites Wissen: Ein Knabe lernt Fahrrad fahren. Er kann jedoch nicht erklären, „wie“ und „weshalb“ er die Balance auf dem Fahrrad halten kann.
2.3.4 Explizites Wissen
Beim expliziten Wissen handelt es sich um das Gegenteil des impliziten Wissens. Hier werden Informationen bewusst erinnert und später wieder bewusst aufgerufen.
Beispiel für explizites Wissen: Der Mitarbeiter merkt sich eine Telefonnummer (bewusste Erinnerung) und tippt diese anschliessend ins Telefon ein (bewusster Gedächtnisaufruf).
2.3.5 System- und Steuerungswissen
In Bezug auf die Bedienung von technischen Systemen können die beschriebenen Wissensformen nach Kluwe (1997, zitiert nach Kluwe 2006) auf folgende Art übertragen werden:
Systemwissen ist deklaratives Wissen über das Display sowie über die allgemeine Funktionalität und den Aufbau des technischen Systems. Das Steuerungswissen beinhaltet deklaratives sowie prozedurales Wissen bezüglich der Bedienung des Systems und des Kausalwissens (Wenn-Dann-Wissen).
Beispiel Systemwissen: Der Benutzer weiss, dass für das Versenden einer E-Mail in das Textfeld „An:“ der gewünschte Empfänger eingetragen werden muss (Display Wissen). Weiter ist er sich bewusst, dass er für das Veröffentlichen von Webseiten-Dateien nicht mit dem E-Mail Programm arbeiten kann, weil dieses nicht die entsprechenden Funktionen bietet. (Systemwissen beziehungsweise Anlage-Wissen).
Beispiel Steuerungswissen: Der Benutzer weiss, dass mittels Schaltknopf „X“ die Applikation geschlossen wird (Bedienungswissen) und es ist ihm klar, dass nach dem Ausschalten des Computers, ein Bild in der Zwischenablage nicht mehr verfügbar ist (Kausalwissen).
Abbildung in dieser Leseprobe nicht enthalten
Abbildung3Wissensformen für Prozesssteuerung (nach Kluwe, 1997, zitiert nach Kluwe, 2006)
2.4 Experten und Laien
Experten sind Fachleute, die komplexe Anforderungen bewältigen müssen (Bromme, Jucks und Rambow, 2004). Weiter sind Experten Personen, welche in einer bestimmten Situation oder einem bestimmten Bereich fähig sind, verschiedene sinnhafte Muster zu erkennen und diese entsprechend zu nutzen. Sie können also aufgrund ihrer Wahrnehmung planen, entscheiden und handeln und sind sich im Klaren über das Wie, Was und Warum (Flaach, 2000; J.R. Anderson, 1996, zitiert nach Hortz, 2010).
Die Merkmale von Experten werden nach Hortz (2010) zusammenfassend wie folgt beschrieben:
- Sie besitzen die Fähigkeit zum Erkennen von Mustern
- Sie betrachten nicht nur einzelne Problemaspekte
- Sie erkennen Beziehungen zwischen unterschiedlichen Aspekten
- Sie erkennen die Prinzipien eines Problembereichs
- Sie orientieren sich nicht nur an Oberflächenmerkmalen eines Problems
- Sie können aus der Problemsituation Handlungs- und Lösungsmöglichkeiten ableiten
Betrachtet man nun die Eigenschaften von Laien, wäre es jedoch falsch, ihnen grundsätzlich Fähigkeiten und Wissen abzusprechen. Laien „[…] kennen die Anforderungen, die an eine mögliche Lösung gestellt werden, oft besser als der Experte selbst “ (Bromme, Jucks & Rambow, 2004, S. 183). In diesem Sinne können Laien als Experten für ihr Problem beziehungsweise für ihre Situation betrachtet werden. Jedoch fehlt ihnen die professionelle Struktur für die Problembeschreibung und es fällt ihnen eher schwer, die „richtigen Fragen“ zu stellen (Hortz, 2010).
2.4.1 Aspekte der Expertise
Militello et al. (1997) beschreiben folgende Aspekte der Expertise und stützen sich dabei auf verschiedene Autoren (de Groot 1946/1978; Shanteau, 1985; Dreyfus & Dreyfus, 1986; Chi, Hutchinson & Robin, 1988; Glaser & Chi, 1988; Klein, 1989; Klein & Hoffman, 1993; Endsley, 1995; Klein & Crandall, 1995; Cohen, Freeman & Wolf, 1996, Klein, 1997):
2.4.1.1 Past & Future
Experten sind in der Lage, zu beurteilen, wie sich eine bestimmte Situation bis hin zum aktuellen Zeitpunkt entwickelt hat („ Past“) und wohin sich die Situation noch entwickeln wird („ Future“). Weiter können sie zukünftige Entwicklungen antizipieren und Probleme abfangen bevor sie entstehen.
Beispiel: Aufgrund einer bestimmten Fehlermeldung kann ein Experte eher einschätzen, was die Ursache für den Fehler ist oder er ist in der Lage, abzuschätzen, was nun weiter getan werden muss.
2.4.1.2 Big Picture
Laien tendieren dazu, nur einzelne Aspekte zu sehen und sind in dem Sinne blind für den Gesamtüberblick. Experten hingegen können sich schnell ein Bild der gesamten Situation machen (Big Picture) und können beurteilen, wie einzelne Aspekte zum Ganzen beitragen.
Beispiel: Unerfahrene Personen sehen den Zusammenhang zwischen E-Mail und Internet nicht und prüfen daher nicht, wenn eine E-Mail nicht versendet werden kann, ob der Internetzugang überhaupt funktionstüchtig ist.
2.4.1.3 Noticing
Erfahrenen Personen ist es eher möglich, nützliche Hinweise zu erkennen und darin nützliche Informationen oder Muster zu finden als weniger erfahrene Personen.
Beispiel: Laien übersehen eine wichtige Meldung oder lesen diese nicht, weil sie denken, diese sei für die Situation nicht relevant.
2.4.1.4 Tricks of the Trade (Job Smarts)
Experten können verschiedene Abläufe miteinander kombinieren oder sinnvoll abkürzen („Tricks of the Trade“). Dadurch erreichen sie ein sehr effizientes Arbeitsverhalten.
Beispiel: Für Einstellungen einer Applikation nimmt ein Experte Anpassungen direkt in der entsprechenden Konfigurationsdatei vor, ohne den dazu vorgesehenen Assistenten zu verwenden.
2.4.1.5 Oppurtunities / Improvising
In Situationen, in denen der vorgesehene Standardweg nicht zum Ziel führt, ist es Experten möglich, zu improvisieren und neue beziehungsweise andere Wege der Zielerreichung zu erkennen.
Beispiel: Eine Applikation, die mit einer bestimmten Programmiersprache erstellt ist, funktioniert auf dem vorgegeben System nicht. Es wird deshalb ein Zusatzsystem in Betrieb genommen und eingebunden, so dass die Applikation trotzdem funktioniert.
2.4.1.6 Self Monitoring
Experten erkennen, wenn ihre Massnahmen nicht zum gewünschten Ziel führen, kontrollieren ihre Ergebnisse und nehmen, falls notwendig, entsprechende Anpassungen vor.
Beispiel: Durch die Verwendung bestimmter Kontrollinstrumente kann ein Experte seine Massnahmen überprüfen und sicherstellen, dass diese erfolgreich waren.
2.4.1.7 Anomalies
Laien wissen oftmals nicht, was für eine bestimmte Situation typisch ist. So haben sie auch Schwierigkeiten, zu erkennen, wenn etwas nicht so ist, wie es sein sollte. Experten erkennen schneller Anomalien und können entsprechend handeln.
Beispiel: Standardmässige Warnhinweise einer Applikation werden als Fehlermeldungen missverstanden. Es wird fälschlicherweise angenommen, dass es nicht funktioniert.
2.4.1.8 Equipment Difficulties
Verwendetes Equipment (Hardware, Software, usw.) kann manchmal durch falsche oder missverständliche Outputs für Verwirrung sorgen. Unerfahrene Personen vertrauen eher darauf, dass die Angaben korrekt sind und stellen diese weniger in Frage. Für sie ist es mit eingeschränktem Equipment schwierig, das gewünschte Ziel dennoch zu erreichen.
Beispiel: Es ist auf dem System kein E-Mail-Programm installiert.
2.5 Cognitive Task Analysis (CTA)
Die Cognitive Task Analysis (CTA) dient zur Identifizierung von kognitiven Fähigkeiten oder Ansprüchen, um eine Aufgabe (Task) gut durchführen zu können. Die Ergebnisse einer solchen Analyse können als Unterstützung für die Entwicklung von Systemen, Benutzerschnittstellen sowie Trainingsprogramme genutzt werden (Militello & Hutton, 1998).
Bei der Beobachtung eines Menschen, der eine Tätigkeit ausführt, ist es meist nur oberflächlich möglich zu verstehen, was in dessen Kopf vorgeht. Man kann zwar beobachten, was jemand tut, jedoch ist die Frage nach dem „Warum“ schwieriger zu beantworten.
Auch Befragungen decken nur teilweise die kognitiven Strukturen einer Person. Durch die steigende Automatisierung der Unterstützung von Menschen in ihren Tätigkeiten, werden solche Analysen zunehmend schwieriger, da der Mensch zunehmend nur noch Kontrolltätigkeiten übernimmt. Die eigentliche Ausführung der Aufgabe übernimmt die Maschine, zum Beispiel ein Computersystem (Schraagen, Chipman & Shalin, 2000).
Unter den Begriff Cognitive Task Analysis sind mehrere spezifische Methoden subsumiert. Es gibt daher keinen standardisierten Weg, eine CTA durchzuführen. Bonaceto und Burns (2004) verweisen allein in ihrer Übersicht auf 13 verschiedene Methoden. Daher ist es notwendig, für jeden Fall von Neuem zu prüfen, welche Methoden im Kontext Sinn machen.
2.6 Applied Cognitive Task Analysis (ACTA)
Eine Methode zur Durchführung der Cognitive Task Analysis (CTA) ist die Applied Cognitive Task Analysis (ACTA), welche von Militello et al. (1997) entwickelt wurde. Ziel der Methode ist die Identifikation von kritischen kognitiven Elementen bei der Bearbeitung von Aufgaben. Die Ergebnisse können konkret für die Entwicklung von Systemen (System Design) oder Lernumgebungen (Instructional Design) verwendet werden.
Die Methode ist in insgesamt drei Teile aufgegliedert, in welchen verschiedene Aspekte untersucht werden. Als Interviewpartner kommen Experten aus dem zu untersuchenden Feld zum Einsatz. In den folgenden Abschnitten werden die einzelnen Teile der ACTA der Reihe nach kurz beschrieben:
2.6.1 Task Diagram Interview
Anhand des Task Diagram Interviews wird zunächst eine grobe Übersicht über die zu analysierende Aufgabe erstellt. Dabei werden Stellen markiert, die aus Sicht der Experten potentiell schwierig zu bearbeiten sind und aus diesem Grund am meisten Expertise erfordern.
Die Experten werden aufgefordert, die Aufgabe in drei bis sechs Schritten zu beschreiben und zu erörtern, welche dieser Schritte am meisten Expertise (Urteile, Bewertungen, Problemlösungen, usw.) erfordern. Diese Schritte werden anschliessend nochmals je in drei bis sechs Teilschritte unterteilt und ebenfalls auf ihre Anforderungen hin geprüft und entsprechend markiert.
Das resultierende Diagramm kann für die späteren Interviewteile als Ausgangsmaterial verwendet werden.
Beispiel Task Diagram Interview: Bei einer Aufgabe sollen Daten in einer Datenbank mittels entsprechendem Client geöffnet und bearbeitet werden. Die schwierigen Stellen „2.1 Daten selektieren“ sowie „2.3 Daten bearbeiten“ sind rot markiert.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung4Beispiel Task Diagram
2.6.2 Knowledge Audit
Um ein genaues Bild zu bekommen, wie die Expertise in Bezug auf die jeweilige Aufgabe aussieht, werden Beispielsituationen, Hinweise, Strategien, usw. gesammelt. Zusätzlich kann vom Experten eine Einschätzung abgegeben werden, weshalb Laien in Bezug auf diese Aspekte Schwierigkeiten bekunden.
Beispiel Knowledge Audit:
Abbildung in dieser Leseprobe nicht enthalten
2.6.3 Simulation Interview
Das Simulation Interview soll helfen, die kognitiven Prozesse der Experten innerhalb eines bestimmten Kontexts zu verstehen. Dies bedeutet, dass ein Szenario (zum Beispiel kürzlich ereigneter Supportfall) besprochen wird. Zunächst wird das Szenario vom Experten erläutert (Ablauf, etc.) und anschliessend werden die wichtigsten Ereignisse, Urteile, Entscheidungen, Situationseinschätzung, Handlungen, kritische Hinweise und potentiell auftretende Fehler bestimmt.
Beispiel Simulation Interview:
Abbildung in dieser Leseprobe nicht enthalten
2.6.4 Cognitive Demand Table
Im letzten Schritt werden die Daten aus dem Task Diagram, Knowledge Audit und dem Simulation Interview dahingehend sortiert und analysiert, dass in Bezug auf die Aufgabe schwierige kognitive Elemente identifiziert werden können. Dabei soll jeweils geklärt werden, warum diese schwierig sind, welche Fehler häufig entstehen und welche Hinweise und Strategien bestehen, um mit den Elementen umzugehen.
Beispiel Cognitive Demand Table:
Abbildung in dieser Leseprobe nicht enthalten
3 Durchführung
Die Thesis ist in Bezug auf das Prozessmodell Usability Engineering von Sarodnick und Brau (2006, siehe 2.1 Prozessmodell Usability Engineering, S. 8) im Bereich der Arbeits-, Prozess- und Systemanalyse anzusiedeln.
Die Durchführung ist in insgesamt vier Teile gegliedert: Die Voranalyse (1) dient zur Orientierung und gibt einen ersten Überblick über die vorhandenen Problemfelder. Bei der Problemanalyse (2) werden die Problemfelder mit dem grössten Problempotential genauer analysiert, welche die Grundlage für die weiterführenden Arbeiten legen. Darauf folgend werden Problemfelder beziehungsweise Aufgaben für die späteren Analysen ausgewählt. Der Kern der Arbeit bildet die Wissensanalyse (3), bei welcher konkrete Aufgaben in Bezug auf die kritischen kognitiven Elemente analysiert werden. Die Ergebnisse der Analyse werden so aufbereitet, dass sie Erkenntnisse für die Entwicklung eines Online-Hilfesystems liefern, um in Problemfällen den Benutzern optimale Hilfestellung bieten zu können. Abschliessend werden Empfehlungen (4) für die Nutzung der Resultate sowie für weiterführende Arbeiten abgegeben.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 5 Teilschritte der Bachelor-Thesis
Nachfolgend werden die einzelnen Teilschritte im Detail beschrieben. Es werden jeweils Informationen zur entsprechenden Ausgangslage, Methodenwahl sowie den Ergebnissen gegeben.
3.1 Voranalyse
Zu Beginn muss die Frage beantwortet werden, welche Probleme bei den Supporttätigkeiten von easyzone überhaupt auftreten und in welcher Häufigkeit dies geschieht. Es soll dadurch ein grober Überblick über die aktuelle Situation im easyzone-Supportumfeld geschaffen werden.
Sarodnick und Brau (2006) schlagen für die Arbeitsanalyse eine Informationsanalyse vor, bei welcher schriftliche Dokumente untersucht werden. Seitens easyzone stehen diesbezüglich ausschliesslich Unterlagen in Form von E-Mails mit Kundenkorrespondenz zur Verfügung. Es existiert keine Datenbank oder ähnliches, die Supportanfragen dokumentiert (im Sinne eines Trouble-Ticket-Systems).
3.1.1 Methodenwahl
Abgeleitet von der Ausgangslage bietet sich für die Analyse der E-Mail-Korrespondenz eine qualitative Inhaltsanalyse nach Mayring (2010) an. Die Methode verweist explizit auf einen Analysefokus auf Kommunikationsmaterialien. Die Ergebnisse sollen helfen, Rückschlüsse in Bezug auf die Kommunikation machen zu können (zum Beispiel Abläufe, Gedankengänge, Schlussfolgerungen, usw.).
Nach Flick (2007) ist die qualitative Inhaltsanalyse eine der klassischen Vorgehensweisen für die Analyse von Textmaterialien. Flick argumentiert, dass dabei Material reduziert und zugleich überschaubar gemacht werden kann.
3.1.2 Durchführung
Bei der Anwendung der qualitativen Inhaltsanalyse gibt es verschiedene Varianten, wie die Methode im Detail durchgeführt werden kann (vgl. Mayring, 2010, S.63). Im vorliegenden Fall wird eine Häufigkeitsanalyse angewendet, bei welcher Bestandteile des Textes (Codes) herausgefiltert und in Kategorien eingeordnet werden. Aufgrund der Häufigkeit solcher Codes lassen sich dann Aussagen über die Gewichtung der Kategorien im Gesamtkontext machen.
Das gesamte Datenmaterial, welches für die Voranalyse zur Verfügung gestellt wurde, umfasst 72 E-Mails von easyzone. Dabei handelt es sich um 53 E-Mails mit Antworten und 19 E-Mails ohne Antworten. Die E-Mails mit Antworten beinhalten die Korrespondenz zwischen easyzone und ihren Kunden. E-Mails ohne Antworten sind blosse Anfragen der Kunden. Es kann vorkommen, dass sich die untersuchten E-Mails inhaltlich überschneiden. Eine detaillierte Dokumentation der Kommunikation zwischen Firma und Kunde liegt nicht vor. So sind zum Beispiel Telefongespräche oder andere Medienbrüche (Wechsel des Mediums in einer Kommunikation, beispielsweise von E-Mail auf Telefon) anhand des vorhandenen Datenmaterials nicht überprüfbar.
Da die Voranalyse nur zur groben Orientierung für das weitere Vorgehen dient, wird nicht das gesamte Material (72 E-Mails) analysiert. Für die Analyse werden lediglich 30 E-Mails (mit Antwort) verwendet, die welche zufällig ausgewählt werden.
Für die Durchführung ist besonders relevant, dass die Analyserichtung („Was möchte man heraus interpretieren können?“) klar festgelegt wird. In diesem Fall liegt der Fokus auf den Problemen beziehungsweise Problemsituationen der easyzone-Kunden.
Die einzelnen Analyseschritte sind:
1. Durchlesen des Textes (jede E-Mails einzeln)
2. Auswahl und Markierung eines interessanten Textbestandteils (Codierung)
3. Für den Textbestandteil wird eine Kategorie gebildet. Falls der Textbestandteil in eine der bereits ermittelten Kategorien passt, wird er dieser zugeordnet (induktive Kategorienbildung)
Die Schritte 1 – 3 wiederholen sich für jedes der 30 E-Mails. Pro E-Mail können durchaus mehrere Codes und entsprechende Zuordnungen in die Kategorien erfolgen. Somit kann eine E-Mail beispielsweise Codes in den Bereichen „E-Mail“ sowie auch „Kundenfreundlichkeit“ enthalten. Nachdem alle E-Mails bearbeitet sind, folgen noch die zwei letzten Analyseschritte:
4. Reduktion der gebildeten Kategorien durch Zusammenfassung von ähnlichen Kategorien
5. Für jede Kategorie einen konkreten Code als Beispiel festlegen (Ankerbeispiele)
1.1.1
3.1.3 Ergebnisse
Die ermittelten Kategorien lassen sich grob in die Hauptkategorien Mensch, Technik und Organisation unterteilen. Diese sind in Abbildung 6 „Resultierende Kategorien der Voranalyse“ (S. 20) abgebildet. Dabei ist auffallend, dass im Bereich Technik vor allem Probleme in den Bereichen DNS (n=10), E-Mail (n=8) und Netzwerk (n=6) auftreten. Bei den Problemen im Bereich E-Mail handelt es sich vor allem um Kategorien in Bezug auf Fehlermeldungen von E-Mail-Servern. Probleme im Bereich DNS sind meist auf Schwierigkeiten mit DNS-Einträgen (zum Beispiel Konfiguration von DNS-Servern bei Switch1 ) zurückzuführen. Im Bereich Netzwerk sind die Kategorien auf verschiedene kleinere Probleme verteilt.
In der Hauptkategorie Mensch ist vor allem die Kompetenz (n=11), das Experten-Laien-Verhältnis (n=9) sowie Medienbrüche (n=7) ein Thema. So haben die Kunden zum Beispiel das Gefühl etwas falsch gemacht zu haben oder verstehen die Erklärungen des Supports nicht beziehungsweise nur teilweise. Den Korrespondenzen kann entnommen werden, dass oftmals auch telefonischer Austausch parallel dazu stattfindet (Medienbruch).
Im Bereich Organisation werden Abläufe / Prozesse (n=7) sowie Probleme mit Switch (n=6) erwähnt. Beispielsweise mussten Kunden an Dritte verwiesen werden, da easyzone für das vorliegende Problem keine entsprechende Zuständigkeit hatte und deshalb nicht zur Problemlösung beitragen konnte. Im Zusammenhang mit Switch tauchten oftmals Fragen und Komplikationen auf bezüglich Zahlung von Rechnungen.
Mit den gewonnenen Daten kann also grob die Frage beantwortet werden, in welchen Bereichen häufiger Probleme auftreten. So zeigt sich, dass vor allem im Bereich E-Mail und DNS (Technik) sowie Kompetenz und Experten / Laien (Mensch) eher Probleme auftreten, als in anderen Bereichen.
Es gilt nun jedoch zu klären, weshalb diese Probleme auftreten, und ob die gewonnenen Ergebnisse noch weiter präzisiert werden können.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung6Resultierende Kategorien der Voranalyse
3.2 Problemanalyse
Im Rahmen der Problemanalyse werden die Ergebnisse der Voranalyse weiterführend geprüft. Dabei sollen nachfolgende Fragen geklärt sowie zusätzliche Informationen gesammelt werden, welche helfen sollen, die Ergebnisse und deren Zusammenhänge besser verstehen zu können:
- Entsprechen die Ergebnisse der Voranalyse der Realität (Validierung der Daten)?
- Was sind mögliche Gründe, weshalb die Probleme auftreten?
- Weshalb stellen die Probleme für Kunden (Laien) überhaupt ein Problem dar?
3.2.1 Methodenwahl
Unter der Anforderung, dass die Ergebnisse der Voranalyse präzisiert werden sollen und wegen der geringen Anzahl zur Verfügung stehenden Personen (Mitarbeiterzahl easyzone = 4), wird für die Problemanalyse die qualitative Methode des Interviews gewählt.
Dabei kommt ein Experteninterview zum Einsatz, bei dem gezielt Personen befragt werden, die für ein bestimmtes Handlungsfeld (Problemsituationen / IT-Support bei easyzone) Expertise aufweisen. Die Methode eignet sich weiter für Explorationen und Orientierungen in solchen Handlungsfeldern, kann helfen, Zusatzinformationen von anderen Methoden (Voranalyse) zu gewinnen und schafft die Möglichkeit, Wissen von verschiedenen Experten zu rekonstruieren (Flick, 2007).
3.2.2 Durchführung
Die Interviews wurden jeweils einzeln mit den Experten durchgeführt. Von den vier Personen, welche bei easyzone tätig sind, wurden drei als Experten für die Interviews ausgewählt. Die vierte Person ist ausschliesslich im Programmierbereich tätig und hat keinen direkten Kontakt mit Kunden in Bezug auf Problemsituationen. Die drei befragten Personen sind alle männlich und sind 25 sowie je 31 Jahre alt.
Es wurde darauf geachtet, dass die Interviews in einem möglichst störungsfreien Umfeld durchgeführt werden konnten. Dies bedeutet, dass die Experten nicht durch andere Einflüsse (zum Beispiel Telefonate) abgelenkt werden sollten. Da es sich um ein Grossraumbüro handelt und keine separaten Räume zur Verfügung standen, war dies nur zu einem gewissen Grad möglich.
Der Interviewleitfaden (siehe 3.2.3 Ergebnisse, S. 22) setzt sich aus fünf Fragen zusammen, welche sich in Einstiegs-, Haupt- und Abschlussfragen gliedern lassen. Mit der ersten Frage (1) wurden zugleich die Ergebnisse aus der Voranalyse präsentiert, um dem Befragten den Einstieg zu erleichtern und das Gespräch möglichst rasch auf den Punkt zu bringen (Erzählstimulus). Die Hauptfragen (2 – 4) dienen einer möglichen Klärung der eingangs erwähnten Fragestellungen (Gründe für die Probleme, Schwierigkeiten für Laien). Die letzte Frage (5) lässt die Möglichkeit offen, dass noch eigene Ergänzungen durch den Experten vorgenommen werden können.
Das Interview wurde halbstrukturiert durchgeführt, was bedeutet, dass zwar ein Leitfaden verwendet wurde, aber auch weitergehende Ausführungen der Experten Platz fanden.
Alle Interviews wurden mittels Audiogerät aufgezeichnet und anschliessend transkribiert.
3.2.3 Ergebnisse
In der folgenden Tabelle finden sich die zusammengefassten Expertenantworten. Die zusätzlichen Ergänzungen der Experten, welche sich nicht direkt auf die gestellten Fragen beziehen, sind am Schluss angefügt.
Abbildung in dieser Leseprobe nicht enthalten
Es zeigt sich, dass die Ergebnisse der Voranalyse im Wesentlichen bestätigt werden konnten (Validierung). Durch die erste Einschätzung der Experten lassen sich bereits erste Problemstellen und Lösungsansätze erkennen. So wäre es aus Sicht der Experten hilfreich, wenn Laien ein besseres technisches Verständnis hätten, so dass gewisse Probleme gar nicht erst auftauchen würden. Oftmals haben Laien aber nicht das Selbstvertrauen, um solche Problemlösungen selbständig anzugehen. Weiter weisen die Experten darauf hin, dass Anleitungen oft nur ungenau gelesen werden.
Die Ergebnisse der durchgeführten Problemanalyse sind noch zu offen und unspezifisch, als dass sie konkrete Schlüsse für konkrete Lösungsmöglichkeiten zulassen würden. Allerdings können nun präziser sinnvolle Aufgaben für eine detaillierte Wissensanalyse ausgewählt werden.
3.3 Wissensanalyse
Basierend auf der Vor- und Problemanalyse sowie auf Rücksprachen mit den Experten, wurden die folgenden drei Aufgaben für die Wissensanalyse ausgewählt:
1. DNS-Domain registrieren und einrichten
2. E-Mail Postfach einrichten
3. Dateien auf Webserver laden via FTP
Abgesehen von der Häufigkeit der auftretenden Probleme bei diesen Aufgaben, ist weiter relevant, dass die Aufgaben in gewissem Masse miteinander verknüpft sind und sich teilweise gegenseitig beeinflussen. So ist zum Beispiel Aufgabe 1 „DNS-Domain registrieren und einrichten“ notwendig damit Aufgabe 2 „E-Mail Postfach einrichten“ und Aufgabe 3 „Dateien auf Webserver laden via FTP“ überhaupt durchgeführt werden können.
3.3.1 Methodenwahl
Ziel der Wissensanalyse ist die effektive Identifikation der schwierigen kognitiven Elemente bei der Erfüllung der Aufgabe. Es soll also herausgefunden werden, was die schwierigen kognitiven Aspekte sind, weshalb diese schwierig sind, wie und aufgrund von was Entscheidungen getroffen werden. In diesem Sinne dient die Wissensanalyse ebenfalls dazu, implizites Wissen in explizites Wissen umzuwandeln und somit für die Gestaltung des Systems nutzbar zu machen.
Bonaceto und Burns (2004) geben einen umfangreichen Überblick über mögliche Analysemethoden und geben weiter Hinweise, in welchen Phasen eines System Engineering Prozesses (Entwicklung von komplexen technischen Systemen) diese am besten zum Einsatz kommen.
In Anbetracht des Ziels der Wissensanalyse lässt sich eine hohe Eignung der Methode ACTA (Applied Cognitive Task Analysis) erkennen. Eine ausführliche Beschreibung der Methode ist dem Abschnitt 2.6 Applied Cognitive Task Analysis (S. 14) zu entnehmen. Aus den inhaltlichen Argumenten von Bonaceto und Burns lässt sich zusammenfassend folgendes über den Verwendungszweck von ACTA sagen:
- Analyse der kognitiven Anforderungen der Aufgaben
- Aufzeigen, welche Informationen, Hinweise und Strategien für wichtige Entscheidungen (key decisions) notwendig sind
- Identifikation von Informationen, die für die Entscheidungsfindung sowie Orientierung in der Situation (Situationsbewusstsein) hilfreich sind
- Analyse, welche Funktionen durch das System und welche weiterhin durch den Menschen abgedeckt werden sollen
- Sicherstellung, dass die Systemfunktionen den Anforderungen entsprechen
- Hinweise, welche Informationen für den Benutzer notwendig sind (Gestaltung des Interfaces)
- Aufdecken von Differenzen zwischen Experten und Laien
Weiter argumentieren Bonaceto und Burns, dass die ACTA Methode im Vergleich zu anderen Methoden mit weniger Aufwand und somit schneller durchgeführt werden kann. In Anbetracht der knappen personellen sowie zeitlichen Ressourcen, die zur Erstellung dieser Thesis zur Verfügung stehen, ist dies ein wichtiger Aspekt.
3.3.2 Durchführung
Die Interviewteile der ACTA wurden gleich der Problemanalyse mit drei der vier Mitarbeiter in den Räumlichkeiten von easyzone durchgeführt. Teilweise war es nicht möglich, dass sich die Mitarbeiter vollständig von ihrer Arbeit entbinden konnten (etwa wegen Telefondienst). Entsprechend konnte das Ablenkungspotential nicht vollständig eliminiert werden. Im Allgemeinen traten aber nur wenige Unterbrechungen auf.
In allen drei Interviews war die Reihenfolge der Aufgaben dieselbe:
1. DNS-Domain registrieren und einrichten
2. E-Mail Postfach einrichten
3. Dateien auf Webserver laden via FTP
Wie in der Ausgangslage bereits erwähnt, sind die verschiedenen Aufgaben massgeblich miteinander verknüpft und beeinflussen sich teilweise in der Funktionalität. Besonders Aufgabe 1 stellt eine wesentliche Grundlage für Aufgaben 2 und 3 dar. Aus diesem Grund wurde immer zuerst Aufgabe 1 besprochen und anschliessend die beiden weiteren. Eine Beeinflussung der Ergebnisse durch die Reihenfolge, wie die Aufgaben besprochen wurden, kann in diesem Fall nicht vollständig ausgeschlossen werden (Positionseffekte). Durch die kleine Anzahl Interviews darf jedoch angenommen werden, dass solche Effekte eher gering sind.
Die Teile Task Diagram Interview und Knowledge Audit wurden jeweils mit den Experten einzeln und das Simulation Interview in der Gruppe durchgeführt. Somit bestand die Möglichkeit, zunächst die Wissensstände der einzelnen Experten ganzheitlich zu erfassen und Einzelmeinungen zu erhalten. Für die Besprechung der Fallbeispiele (Simulation Interview) erschien eine Diskussion in der Gruppe sinnvoll, um die im Fallbeispiel gemachten Erfahrungen diskutieren zu können und sich durch Aussagen anregen zu lassen. Weiter mussten auch die Kapazitäten der Mitarbeiter berücksichtigt werden, so dass mittels Gruppendiskussion eine effiziente Abwicklung möglich war.
Die Erstellung des Leitfadens orientiert sich an den Vorschlägen von Militello und Hutton (1998). Dazu werden zu jedem Aspekt der Expertise verschiedene Fragen gestellt, welche sich teilweise inhaltlich bewusst überschneiden. Da alle drei Aufgaben in hohem Mass Wissen in Bezug auf technische Systeme und deren Bedienung erfordert, wurden zusätzlich Fragen eingebaut, welche sich an das Konzept System- und Steuerungswissen nach Kluwe (2006) anlehnen (vgl. Abschnitt 2.3.5 System- und Steuerungswissen, S. 11). Diese zusätzlichen Fragen wurden im Aspekt „Big Picture“ eingeordnet und sollen helfen, noch präzisere Angaben in Bezug auf die relevante technische Funktionalität und insbesondere auch auf die Bedienung machen zu können.
Die Interviewdaten wurden aufgezeichnet und transkribiert. Die Zusammenfassungen wurden den Experten zwei Wochen später für eine Rückprüfung der Aussagen sowie für allfällige Ergänzungen zugesandt.
Nachfolgend werden die Ergebnisse, geordnet nach den drei Aufgaben, detailliert vorgestellt.
3.3.3 Aufgabe 1 DNS-Domain registrieren und einrichten
Bei der ersten Aufgabe handelt es sich um die Registrierung und korrekte Konfiguration einer DNS-Domain. DNS (Domain Name System) ist eine Technologie, welche es ermöglicht, IP-Adressen in Namen (zum Beispiel www.easyzone.ch) und umgekehrt umzuwandeln. Dies ist für viele Dienste im Internet wie E-Mail, Webseiten, usw. eine essentielle Grundlage für deren fehlerfreien Betrieb.
3.3.3.1 Task Diagram
Als erster Schritt erfasst der Kunde die gewünschte Domain im easyzone Kundencenter, damit die DNS-Einträge auf den Serversystemen von easyzone vorhanden sind. Anschliessend wird die Domain auf die Verfügbarkeit geprüft und registriert. Für „.ch“- oder „.li“-Domains ist der Schweizer Anbieter nic.ch zuständig, für die übrigen Domains gibt es unzählige Anbieter. Gemäss easyzone arbeiten die meisten Kunden mit „.ch“-Domains, so dass andere Domains für diese Analaysen vernachlässigt werden können.
Für die Registrierung sind die Postanschrift des Halters (Besitzers) sowie der Rechnungskontakt erforderlich. Für die Vereinfachung von technischen Wartungsarbeiten ist die Angabe von easyzone als technischen Kontakt hilfreich. Dieser kann mittels einer so genannten „Switch ID“ automatisiert konfiguriert werden. Abschliessend müssen zwei IP-Adressen der easyzone DNS-Server bei Switch eingetragen werden, da die easyzone Server für die neue Domain effektiv zuständig sind.
Die Domain bleibt solange inaktiv, bis die Rechnung der Jahresgebühr bezahlt ist. Je nach Bezahlungsart erfolgt die Aktivierung schneller (bei Zahlungen mit Kreditkarte innert wenigen Stunden, bei Bankzahlung kann die Aktivierung mehrere Tage dauern). Im Anschluss an die Aktivierung kann nun getestet werden, ob die Domain beziehungsweise Website über den Webbrowser verfügbar ist.
Die Schritte 3.2 „easyzone Switch ID eingeben“ sowie 3.3 „Einstellung der DNS-Server“, benötigen aus Sicht der Experten am meisten Expertise (rot markiert).
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 7 Aufgabe 1 Task Diagram „DNS-Domain registrieren und einrichten“
3.3.3.2 Knowledge Audit
Für die Aufgabe „DNS-Domain registrieren und einrichten“ zeigen sich zusammengefasst folgende Antworten in Bezug auf die Aspekte der Expertise:
Abbildung in dieser Leseprobe nicht enthalten
3.3.3.3 Simulation Interview
Im vorliegenden Fallbeispiel handelt es sich um einen Kunden, dem es nicht gelang, die DNS-Domain selbständig korrekt zu konfigurieren:
Abbildung in dieser Leseprobe nicht enthalten
3.3.3.4 Cognitive Demand Table
Basierend auf den Daten aus den Interviews, wurden die folgenden fünf schwierigsten kognitiven Elemente bei der Aufgabe „DNS-Domain registrieren und einrichten“ identifiziert:
Abbildung in dieser Leseprobe nicht enthalten
3.3.4 Aufgabe 2 E-Mail Postfach einrichten
Die zweite Aufgabe ist die Konfiguration eines E-Mail Postfachs in einem E-Mail Client wie Microsoft Outlook, Mozilla Thunderbird oder ähnliche. Die Einstellungen für das Postfach sollen gemäss den Vorgaben von easyzone eingerichtet werden, um eine möglichst sichere E-Mail-Kommunikation zu gewährleisten.
3.3.4.1 Task Diagram
Um ein E-Mail Postfach lokal im E-Mail Client einrichten zu können, muss das Postfach auf dem E-Mail Server erstellt werden. Dies wird mit den entsprechenden Funktionen im easyzone Kundencenter durchgeführt.
Für die Konfiguration des E-Mail Postfachs im lokalen E-Mail Client wird von easyzone eine Schritt-für-Schritt Anleitung zur Verfügung gestellt, welche wichtige Informationen in Bezug auf die Einstellungen (Posteingang- / Postausgangserver, SMTP Authentifizierung, usw.) beinhaltet.
Um das Postfach einrichten zu können, muss zwischen den E-Mail Protokollen POP und IMAP ausgewählt werden. Mit den entsprechenden Zugangsdaten (Benutzername, Passwort, Server, usw.) kann dann das Postfach konfiguriert werden. Damit der Versand von E-Mails fehlerfrei funktioniert, muss die SMTP Authentifizierung aktiviert werden.
Abschliessend wird die Konfiguration getestet, indem zwei Mails verschickt werden. Dabei wird ein E-Mail an eine Adresse mit der gleichen Mailadressen-Domain geschickt (internes Mailing) und eine zweite E-Mail an eine Adresse mit einer anderen Mailadressen-Domain (externes Mailing). Kommen beide Mails fehlerfrei an, ist sichergestellt, dass die Konfiguration korrekt ist.
Die Schritte 2.3 „Auswahl POP oder IMAP“, 2.4 „E-Mail Konto einrichten“ und 2.5 „SMTP Authentifizierung aktivieren“ benötigen aus Sicht der Experten am meisten Expertise (rot markiert).
Abbildung in dieser Leseprobe nicht enthalten
Abbildung8Aufgabe 2 Task Diagram „E-Mail Postfach einrichten“
3.3.4.2 Knowledge Audit
Für die Aufgabe „E-Mail Postfach einrichten“ zeigen sich zusammengefasst folgende Antworten in Bezug auf die Aspekte der Expertise:
Abbildung in dieser Leseprobe nicht enthalten
3.3.4.3 Simulation Interview
Als Fallbeispiel diente eine Supportanfrage eines Kunden, der durch eine falsche Konfiguration keine externen E-Mails versenden konnte:
Abbildung in dieser Leseprobe nicht enthalten
3.3.4.4 Cognitive Demand Table
Basierend auf den Daten aus den Interviews wurden die folgenden fünf schwierigsten kognitiven Elemente bei der Aufgabe „E-Mail Postfach einrichten“ identifiziert:
Abbildung in dieser Leseprobe nicht enthalten
3.3.5 Aufgabe 3 Dateien auf Webserver laden via FTP
Bei der dritten Aufgabe sollen Dateien (zum Beispiel eine Webseite) auf einen Webserver via FTP hochgeladen werden. FTP (File Transfer Protokoll) ist eine Technologie, welche es erlaubt, Dateien zwischen zwei Computersystemen zu transferieren.
3.3.5.1 Task Diagram
Um sich am Webserver via FTP anzumelden, werden Login-Daten benötigt (welche gegebenenfalls via das easyzone Kundencenter beschafft werden müssen beziehungsweise dort konfiguriert werden können). Ist noch kein FTP Client auf dem Computer installiert, muss ein entsprechendes Programm installiert werden.
Um die Login-Daten nicht jedes Mal wieder neu eingeben zu müssen, können diese Informationen in einem Profil abgespeichert und für spätere Logins verwendet werden.
Ist der Login am Webserver erfolgt, können die gewünschten Dateien anschliessend hochgeladen werden. Dabei muss beachtet werden, dass der Webserver nur Dateien aus dem Ordner „/www“ anzeigt. Sind die Dateien einmal erfolgreich hochgeladen, kann mittels Webbrowser getestet werden. Werden die Dateien korrekt angezeigt, war der Datentransfer erfolgreich.
Die Schritte 2.1 „Evaluieren, beschaffen, installieren eines FTP Clients“, 2.2 „Profil einrichten“ sowie 4.1 „Korrekter Ordner auswählen (/www)“, welche aus Sicht der Experten am meisten Expertise benötigten, sind rot markiert.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 9 Aufgabe 3 Task Diagram „Dateien auf Webserver laden via FTP“
3.3.5.2 Knowledge Audit
Für die Aufgabe „Dateien auf einen Webserver laden via FTP“ zeigen sich zusammengefasst folgende Antworten in Bezug auf die Aspekte der Expertise:
Abbildung in dieser Leseprobe nicht enthalten
3.3.5.3 Simulation Interview
In diesem Fallbeispiel wollte ein Kunde Dateien auf einen Webserver laden, jedoch wurden diese im Webbrowser nicht angezeigt.
Abbildung in dieser Leseprobe nicht enthalten
3.3.5.4 Cognitive Demand Table
Im Vergleich zu den beiden anderen Aufgaben („DNS-Domain registrieren und einrichten“, „E-Mail Postfach konfigurieren“) ist die Komplexität dieser Aufgabe geringer. Daher beschränkt sich die Zusammenfassung auf die drei schwierigsten kognitiven Elemente:
Abbildung in dieser Leseprobe nicht enthalten
4 Empfehlungen
Unter Berücksichtigung des übergeordneten Ziels (Optimierung der Unterstützung der easyzone-Kunden), werden im folgenden Abschnitt konkrete Empfehlungen für die Nutzung der Ergebnisse gemacht.
Zunächst wird vorgestellt, wie die Teilergebnisse des Task Diagram, Knowledge Audit, Simulation Interview sowie der Cognitive Demand Table einzeln im weiteren Entwicklungsprozess genutzt werden können. Bei den Empfehlungen der Cognitive Demand Tables werden Vorschläge zur Umsetzung im Hilfesystem beziehungsweise Supportprozess abgegeben.
Anschliessend wird aufgezeigt, wie die nächsten Schritte im Rahmen des Usability Engineering-Prozesses konkret aussehen könnten. Auf die Empfehlungen folgt ein Projektantrag für ein mögliches Folgeprojekt. Darin sind im Wesentlichen die Anforderungen und Ziele für die nächste Entwicklungsphase aufgezeigt.
Die Empfehlungen werden mit ergänzenden inhaltlichen Hinweisen und Vorschlägen für weiterführende Fragestellungen abgeschlossen.
4.1 Nutzung der Ergebnisse
Die Teilergebnisse aus den Analysen können im weiteren Verlauf der Systementwicklung auf verschiedene Arten genutzt werden und können wertvolle Hinweise für die Systemgestaltung liefern. Nachfolgend sind Nutzungsvorschläge der einzelnen Teilergebnisse aufgeführt.
4.1.1 Task Diagram
Beim Task Diagram handelt es sich im Wesentlichen um die Beschreibung des Ablaufs der Aufgabe im Normalfall. Somit können Erkenntnisse für die Erstellung und Optimierung von Anleitungen, Dokumentationen, etc. gewonnen werden (zum Beispiel „Entsprechen die Schritt-für-Schritt Anleitungen dem ermittelten Normalablauf?“).
Weiter lassen sich aus dem Task Diagram Hinweise für die Beschreibung des Anwendungsfalles (Akteure, Handlungen, Inputs, Outputs, usw.) ableiten, welche für die Programmierung des Systems sehr wichtig sind. Dadurch kann auch besser verstanden respektive durch die Software ermittelt werden, wo sich der Benutzer im Prozess aktuell befindet und es kann entsprechend darauf reagiert werden.
Zusammenfassung:
- Beschreibung des Anwendungsfalls
- Lokalisierung und Einschränkung der Problemstelle
- Erstellung von neuen Dokumentationen (zum Beispiel Schritt-für-Schritt Anleitungen)
- Optimierung von bestehenden Dokumentationen
4.1.2 Knowledge Audit
Beim Knowledge Audit handelt es sich um eine Beschreibung der benötigten Expertise, um die Aufgabe zu bearbeiten, sich in Problemfällen entsprechend zu orientieren und gegebenenfalls Lösungen finden zu können.
Aus diesen Erkenntnissen lassen sich in Kombination mit dem Task Diagram Fragen zur genaueren Lokalisierung der Problemstelle ableiten. Es gibt Hinweise auf erste wichtige Kontrollfragen (zum Beispiel „Ist die Internetverbindung aktiv?“, usw.) und allenfalls können Hilfestellungen gegeben werden zum Testen der verschiedenen Lösungsmöglichkeiten. Eventuell lassen sich daraus Interaktionen zwischen dem Hilfesystem und dem Benutzer gestalten, die es erlauben, eine optimale Hilfestellung zu bieten. Weiter kann besser bestimmt werden, ab welchem Punkt der persönliche Kontakt mit einem easyzone Mitarbeiter notwendig ist und bis wann der Support mittels des Hilfesystems gewährleistet werden kann. Ausserdem können die Erkenntnisse in einer Wissensdatenbank verpackt werden, um dem Benutzer zusätzliche Tipps und Hintergrundwissen anzubieten. Besonders hilfreich sind auch die Hinweise bezüglich den häufigsten Fehlern, welche mögliche Anknüpfungspunkte sind, wo das Hilfesystem zu Beginn ansetzen könnte.
Zusammenfassung:
- Aufzeigen der benötigten Expertise
- Aufbau einer Wissensdatenbank (Hintergrundwissen, Tipps, usw.)
- Hinweise zur Abgrenzung des Hilfesystems (Mensch-Maschine Funktionsteilung)
- Hilfe zur Generierung von passenden Fragen an den Benutzer
- Hinweise für die Erstellung und Optimierung von Dokumentationen sowie Schulungen
- Mögliche Anknüpfungspunkte, wo das Hilfesystem ansetzen könnte (häufigste Fehler)
4.1.3 Simulation Interview
Im Rahmen des Simulation Interviews wird ein konkretes Fallbeispiel besprochen und reflektiert. Es stellt sich die Frage, welche Handlungen vorgenommen wird, welche Hinweise zu weiteren Handlungen führen, ob es Alternativen und welche potentiellen Fehler entstehen können.
Im Allgemeinen lassen sich so die Ergebnisse aus dem Task Diagram und dem Knowledge Audit anreichern und dadurch besser verstehen. Insbesondere können Hinweise darüber gewonnen werden, welche Handlungsalternativen in diesen Fällen möglich sind und welche potentiellen Fehler dabei auftreten können. Es wäre somit denkbar, dass mit den Ergebnissen aus dem Simulation Interview konkrete Fallbeispiele erstellt werden, die dem Benutzer aufzeigen wie er vorgehen kann beziehungsweise soll und wobei Fehler auftreten können und wie diese gelöst werden.
Zusammenfassung:
- Anreicherung der Erkenntnisse aus dem Task Diagram sowie Knowledge Audit
- Generierung von konkreten Fallbeispielen mit Hinweise auf potentielle Fehler
4.1.4 Cognitive Demand Table
Die Cognitive Demand Table entspricht einer Zusammenfassung der drei Interviewteile Task Diagram, Knowledge Audit und Simulation Interview.
Die hier gewonnen Erkenntnisse geben Hinweise auf die häufigsten potentiellen Fehler und können erste Ansatzpunkte im Problemlösungsprozess darstellen. Zum Beispiel wäre denkbar, dass das System jeweils zuerst auf diese häufigen Fehler hin prüft, bevor ein umfangreiches Diagnoseprogramm gestartet wird (ganzer Ablauf durchprüfen).
Nachfolgend werden zu den einzelnen kognitiven Elementen Vorschläge für eine mögliche Umsetzung im System gegeben:
Abbildung in dieser Leseprobe nicht enthalten
4.2 Nächste Schritte
Im Sinne des Prozessmodells von Sarodnick & Brau (2006) folgt auf die Analysephase die Konzeptphase. Danach sollte nun ein Konzept für das Hilfssystem erstellt werden, welches dann für die Entwicklung eines Prototyps beziehungsweise des Systems dient.
Um jedoch ein fundiertes Konzept zu erstellen, müssen zunächst die Anforderungen der Nutzer erhoben werden. Dabei gilt es zu klären, welche Vorstellungen, Wünsche, Ansprüche, usw. potentielle easyzone Nutzer an ein solches Hilfesystem stellen. Nicht zu vergessen sind auch jene Anforderungen, welche vom jeweiligen IT-Problem unabhängig sind (zum Beispiel „Welche Warte- oder Bearbeitungszeiten tolerieren Benutzer?“). Für die Erhebung kann auf den bestehenden easyzone-Kundenpool zurückgegriffen werden. Weiterführende Informationsgewinnung kann zum Beispiel mittels Fragebogen erreicht werden.
Die eigentliche Konzeptphase startet mit der Arbeitsgestaltung und Prozessdefinition. easyzone muss klären, wie das neue System in die bestehenden organisatorischen Prozesse eingegliedert wird, und ob diese gegebenenfalls angepasst werden müssen. Beispielsweise sollte definiert werden, ob ein Nutzer immer zuerst das Hilfesystem konsultieren muss, bevor ein telefonischer Kontakt zustande kommt oder, ob die Entscheidung für die Art der Kontaktaufnahme grundsätzlich offen bleibt. An dieser Stelle lohnt es sich, bereits potentielle Nutzer mit einzubeziehen, da diese wertvolle Informationen für die Gestaltung einbringen können. Der Einbezug der Nutzer könnte mittels eines Gruppeninterviews im Rahmen eines Workshops realisiert werden.
Basierend auf den definierten Arbeiten, Prozessen und Rahmenbedingungen lassen sich anschliessend die definitiven Systemfunktionalitäten festlegen. Zwangsläufig muss an dieser Stelle die Frage der Mensch-Maschinen Funktionsteilung geklärt werden, also welche Prozesse durch das Hilfesystem (Maschine) und welche durch den IT-Support (Mensch) übernommen werden und wo sich die entsprechenden Schnittstellen befinden. Die definitive Festlegung der Funktionalitäten sollte sich klar aus den vorangegangenen Arbeiten ableiten lassen, jedoch würde sich eine Evaluation im Rahmen eines weiteren Workshops mit Nutzern sicherlich empfehlen.
Sind diese drei Schritte (Nutzeranforderungen erheben, Prozesse definieren, Funktionsteilung festlegen) erfolgt, kann nun das eigentliche Konzept für das Hilfesystem erstellt werden. Es kann dann mit der Entwicklung des Systems beziehungsweise des Prototypen begonnen werden. Der Prototyp wiederum sollte mittels Usability Evaluation (methodischer Weg, um die Eigenschaft „Usability“ zu erzeugen, Sarodnick & Brau, 2006) getestet werden. Daraus lassen sich wiederum wichtige Erkenntnisse für die weiterführenden Entwicklungen des Systems gewinnen.
Zusammengefasst empfehlen sich folgende nächste Schritte:
1. Erhebung der Anforderungen der potentiellen easyzone-Nutzer mittels Fragebogen.
2. Definition und Überarbeitung der Arbeiten, Prozesse und Rahmenbedingungen inklusive Berücksichtigung von Resultaten aus Gruppeninterviews mit potentiellen Nutzern.
3. Ableitung und Festlegung der Systemfunktionen und entsprechender Evaluation in Rahmen eines weiteren Workshops mit potentiellen Nutzern.
4. Erstellung des Konzepts für das Hilfesystem.
5. Entwicklung eines Prototyps, welcher mittels Usability Evaluation fundiert getestet wird.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung10Nächste Schritte im Rahmen des Usability-Engineerings nach Sarodnick und Brau (2006)
4.2.1 Antrag Folgeprojekt
Im Folgenden wird ein mögliches Folgeprojekt, welches an diese Thesis anknüpfen könnte, in Form eines Projektantrages beschrieben:
Abbildung in dieser Leseprobe nicht enthalten
4.3 Ergänzende Empfehlung
Nachfolgend werden ergänzende Empfehlungen abgegeben, welche sich auf inhaltliche Erweiterung oder mögliche weiterführende wissenschaftliche Arbeiten beziehen.
4.3.1 Inhaltliche Erweiterung
Um das Hilfesystem in Bezug auf das inhaltliche Hilfsangebot zu erweitern, müssten weitere Aufgaben / Problemfelder mittels der ACTA Methode analysiert werden. Gemäss den Ergebnissen aus der Voranalyse könnten dies sinnvollerweise sein:
- Applikationen von Drittanbietern (Typo3, Joomla, usw.)
- Netzwerk (Firewall, IP-Konfigurationen, usw.)
- Zugangsdaten (fehlende oder fehlerhafte Logins, usw.)
- Remote Desktop (Team Viewer, usw.)
4.3.2 Wissenschaftliche Fragestellungen
Abgeleitet aus den Empfehlungen für die nächsten Schritte sowie unter Berücksichtigung der Resultate aus der Vor-, Problem- sowie Wissensanalyse, könnten folgende Fragestellungen in den Bereichen Mensch, Technik und Organisation mögliche Ansatzpunkte sein:
Mensch:
- Wie können Benutzer motiviert werden, um Problemlösungen selbständig anzugehen?
- Welchen Einfluss hat der Einsatz eines Online-Hilfesystems auf die Zufriedenheit der Kunden in Bezug auf den Support von easyzone?
- Wie können die Kompetenzen der Mitarbeiter im Umgang mit Kunden in Problemsituationen verbessert werden?
Technik:
- Wie muss ein Online-Hilfesystem gestaltet sein, um einen Benutzer (Laie) optimal im Problemlöseprozess zu unterstützen?
- Wie müssen Instruktions-Text oder Videos gestaltet sein, damit ein Benutzer (Laie) optimal einen Nutzen daraus ziehen kann (erfolgreiche Problemlösung)?
- Wie wird die Mensch-Maschine Funktionsteilung optimal gestaltet, damit Benutzer die bestmögliche Unterstützung erhalten?
Organisation:
- Wie müssen Support-Prozesse gestaltet sein, damit ein Benutzer (Laie) die optimale Unterstützung erhält?
- Wie müssen die bestehenden Support-Prozesse von easyzone angepasst werden, damit ein Online-Hilfesystem möglichst optimal eingebettet werden kann?
- Welche Konsequenzen haben Änderungen der organisatorischen Prozesse und Strukturen auf das Arbeitsumfeld von easyzone?
5 Fazit
Anhand der durchgeführten Analysen und den dadurch erzielten Ergebnissen konnten erste wichtige und grundlegende Erkenntnisse für den weiteren Entwicklungsprozess des easyzone Online-Hilfesystems gewonnen werden. Es besteht nun eine fundierte Grundlage, welche es erlaubt, die nächsten Schritte einzuleiten.
Die Fragestellungen dieser Thesis konnten weitgehend beantwortet werden. Aufgrund der Ergebnisse der Voranalyse ist anzunehmen, dass sich vor allem im Bereich „Technik“ - zu den Themen DNS und E-Mail - sowie im Bereich „Mensch“ - bezüglich Kompetenz der Kunden und bei der Kommunikation zwischen dem IT-Support und den Kunden (Experten / Laien) - häufiger Probleme zeigen. Diese Erkenntnisse konnten in der Problemanalyse geprüft und weiter ausdifferenziert werden.
Basierend auf der Vor- und Problemanalyse sowie der Rücksprache mit easyzone wurden drei Aufgaben (1. „DNS-Domain registrieren und einrichten“, 2. „E-Mail Postfach einrichten“ und 3. „Dateien auf Webserver laden via FTP“) für die Wissensanalyse ausgewählt und auf die schwierigen kognitiven Elemente analysiert. Dabei zeigte sich, dass öfters Begriffe unklar sind (zum Beispiel die E-Mail Protokolle IMAP und POP) und die Kunden nicht genau wissen, welche Handlungen sie vornehmen müssen (zum Beispiel Aktivierung der SMTP-Authentifizierung), um die Aufgaben erfolgreich zu meistern. Weiter sind teilweise Regeln oder Zusammenhänge nicht bekannt (zum Beispiel, dass wenn die Rechnung von Switch nicht bezahlt wird, die DNS Domain sowie das gesamte E-Mail System nicht funktionieren).
Es ist anzunehmen, dass sich durch die Umsetzung der vorgeschlagenen Massnahmen (siehe Tabelle 14 Umsetzung der Ergebnisse des Cognitive Demand Table im Hilfesystem, S. 46), bereits einige Probleme reduzieren lassen. So sollten entsprechende Hilfestellungen im Online-Hilfesystem angeboten werden und Massnahmen getroffen werden, damit diese Probleme gar nicht erst entstehen (beispielsweise Überarbeitung von Installationsanleitungen).
Es ist darauf hinzuweisen, dass die erarbeiteten Erkenntnisse nur einen Teil der Arbeits-, Prozess- und Systemanalyse im Rahmen des Usability Engineering Prozesses abdecken. Es ist daher zu empfehlen, dass für weitere Aufgaben zusätzliche Analysen mittels ACTA durchgeführt werden.
Weiter zeigt sich, wie wichtig und wertvoll die Anwendung von verschiedenen psychologischen Methoden im Entwicklungsprozess ist. Die Ergebnisse aus der Vor- und Problemanalyse alleine sind für die konkrete Gestaltung des Online-Hilfesystems zu ungenau und hätten keine befriedigenden Resultate geliefert. Erst durch die aufwändige Wissensanalyse (ACTA) konnten die vorangegangenen Erkenntnisse so präzisiert werden, dass sie gezielte und nutzbare Hinweise liefern. Sie leisten so einen wesentlichen Beitrag, um ein gebrauchstaugliches Anwendungssystem zu entwickeln, welches in der Praxis funktioniert.
Kritisch zu betrachten sind die Durchführungen der Interviews. Durch die gegebenen Umstände (Räumlichkeiten und Ressourcen) konnte nicht immer eine störungsfreie Abwicklung garantiert werden. Allgemein mussten die Arbeiten sehr „ökonomisch“ erfolgen und sie sind in Bezug auf psychologische Gütekriterien in gewissem Masse in Frage zu stellen. Beispielweise handelt es sich bei der dieser Thesis um eine Einzelarbeit und es standen somit keine weiteren Analysten oder Interviewer zur Verfügung. Es kann also nicht vollständig ausgeschlossen werden, dass die Ergebnisse durch den Analysten beziehungsweise Interviewer beeinflusst sind (Objektivität). Die Ergebnisse konnten in Anbetracht der zur Verfügung stehenden Ressourcen (zum Beispiel zeitliche Verfügbarkeit der Mitarbeiter von easyzone) nur zum Teil und im Rahmen der durchgeführten Methoden rückgeprüft werden. Die erstellten Leitfäden orientieren sich zwar an wissenschaftlichen Erkenntnissen, jedoch ist dennoch in Frage zu stellen, ob damit wirklich das gesuchte und benötigte Wissen zu Tage gefördert wird (Validität). Auch kann bei qualitativen Analysemethoden (Interviews) die berechtigte Frage nach der Wiederholbarkeit gestellt werden, also ob sich nach jeder Durchführung dieselben Ergebnisse einstellen oder ob sich diese laufend verändern (Reliabilität).
Gesamthaft betrachtet, ist der Aufwand im Verhältnis zu den gewonnen Ergebnissen relativ hoch. Trotzdem handelt es sich um fundierte Erkenntnisse, die für die Entwicklung eines gebrauchstauglichen Hilfesystems von grossem Wert sind. Es ist weiter anzunehmen, dass sich bei der Anwendung der Analysen (ACTA) in neuen Aufgaben- beziehungsweise Problemfeldern durch die nun gesammelten Erfahrungen Optimierungsmöglichkeiten herausbilden.
Es sei an dieser Stelle nochmals speziell darauf hingewiesen, dass die hier vorliegenden Arbeiten im Prozessmodell Usability Engineering bei der Arbeits-, Prozess- und Systemanalyse einzuordnen sind (siehe 2.1 Prozessmodell Usability Engineering, S. 8). Für die erfolgreiche Realisierung des Online-Hilfesystems sollte unbedingt weiter nach dem Prozessmodell verfahren werden. So stehen die Chancen sehr gut, ein gebrauchstaugliches und erfolgreiches Produkt zu entwickeln.
6 Quellenverzeichnis
6.1 Literaturverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
6.2 Web-Quellen
Abbildung in dieser Leseprobe nicht enthalten
7 Anhang
A Interviewleitfaden Task Diagram
Abbildung in dieser Leseprobe nicht enthalten
B Interviewleitfaden Knowledge Audit
Abbildung in dieser Leseprobe nicht enthalten
C Interviewleitfaden Simulation Interview
Abbildung in dieser Leseprobe nicht enthalten
D Kategorisierungen der E-Mail-Korrespondenz (Voranalyse)
Abbildung in dieser Leseprobe nicht enthalten
E Einzelantworten der Experten (Problemanalyse)
Abbildung in dieser Leseprobe nicht enthalten
F Einzelantworten der Experten (Wissensanalyse)
Abbildung in dieser Leseprobe nicht enthalten
[...]
Häufig gestellte Fragen
Was ist der Fokus dieser Bachelor-Thesis?
Die Bachelor-Thesis befasst sich mit der Identifikation der häufigsten Probleme im IT-Supportumfeld der Firma easyzone und analysiert, welche Schwierigkeiten im Detail bei diesen Problemen auftreten. Ziel ist es, easyzone bei der Entwicklung eines Online-Hilfesystems zu unterstützen.
Welche Methoden werden in der Thesis verwendet?
Die Thesis nutzt eine qualitative Inhaltsanalyse zur Erstellung eines Überblicks über die Probleme, Experteninterviews zur weiteren Ausdifferenzierung dieser Probleme und eine Applied Cognitive Task Analysis (ACTA), um die schwierigen kognitiven Elemente bei konkreten Aufgaben herauszukristallisieren.
Was sind die wichtigsten theoretischen Grundlagen, die in der Thesis behandelt werden?
Die Thesis behandelt das Prozessmodell Usability Engineering, Kognition, Wissensformen, Expertise sowie Cognitive Task Analysis (CTA) beziehungsweise Applied Cognitive Task Analysis (ACTA).
Welche Wissensformen werden unterschieden?
Die Thesis unterscheidet deklaratives Wissen (episodisch und semantisch), prozedurales Wissen, implizites Wissen, explizites Wissen sowie System- und Steuerungswissen.
Was ist Applied Cognitive Task Analysis (ACTA)?
ACTA ist eine Methode zur Identifikation von kritischen kognitiven Elementen bei der Bearbeitung von Aufgaben. Sie umfasst das Task Diagram Interview, Knowledge Audit, Simulation Interview und die Cognitive Demand Table.
Welche Aufgaben wurden im Rahmen der Wissensanalyse genauer untersucht?
Die Wissensanalyse konzentrierte sich auf folgende Aufgaben: DNS-Domain registrieren und einrichten, E-Mail Postfach einrichten und Dateien auf Webserver laden via FTP.
Was ist das Task Diagram Interview?
Das Task Diagram Interview dient dazu, eine grobe Übersicht über die zu analysierende Aufgabe zu erstellen und Stellen zu identifizieren, die potentiell schwierig zu bearbeiten sind.
Was wird im Knowledge Audit erfasst?
Der Knowledge Audit sammelt Beispielsituationen, Hinweise, Strategien usw., um ein genaues Bild der Expertise in Bezug auf die jeweilige Aufgabe zu erhalten. Außerdem wird eine Einschätzung abgegeben, weshalb Laien in Bezug auf diese Aspekte Schwierigkeiten bekunden.
Was ist das Ziel des Simulation Interviews?
Das Simulation Interview soll helfen, die kognitiven Prozesse der Experten innerhalb eines bestimmten Kontexts zu verstehen, indem ein Szenario (z.B. Supportfall) besprochen wird.
Was wird in der Cognitive Demand Table zusammengefasst?
Die Cognitive Demand Table fasst die Daten aus dem Task Diagram, Knowledge Audit und dem Simulation Interview zusammen, um schwierige kognitive Elemente in Bezug auf die Aufgabe zu identifizieren.
Welche Empfehlungen werden für die Nutzung der Ergebnisse gegeben?
Die Empfehlungen umfassen die Nutzung des Task Diagrams zur Erstellung von Anleitungen, des Knowledge Audits zum Aufbau einer Wissensdatenbank und des Simulation Interviews zur Generierung von Fallbeispielen. Die Cognitive Demand Table liefert Hinweise auf häufige Fehler und Ansatzpunkte für den Problemlösungsprozess.
Welche nächsten Schritte werden empfohlen?
Die nächsten Schritte umfassen die Erhebung der Nutzeranforderungen, die Definition der Arbeiten, Prozesse und Rahmenbedingungen, die Festlegung der Systemfunktionen, die Erstellung des Konzepts für das Hilfesystem und die Entwicklung eines Prototyps, welcher mittels Usability Evaluation getestet wird.
Welche Fragestellungen könnten in weiterführenden wissenschaftlichen Arbeiten untersucht werden?
Mögliche Fragestellungen betreffen die Motivation der Nutzer zur selbstständigen Problemlösung, den Einfluss des Hilfesystems auf die Kundenzufriedenheit, die Gestaltung des Hilfesystems zur optimalen Unterstützung der Nutzer, die Mensch-Maschine Funktionsteilung und die Anpassung der Support-Prozesse.
- Quote paper
- Luca Honegger (Author), 2011, Identifikation von kritischen kognitiven Elementen bei der Bearbeitung von IT-Aufgaben als Basis für die Entwicklung eines Online-Hilfesystems, Munich, GRIN Verlag, https://www.grin.com/document/936621
