Von ineffektiven IT-Lösungen und sozialen Problemstellungen - Drei Forschungsansätze im direkten Vergleich

Diese Gruppe setzte sich näher mit den Forschungsmethoden Action Research (kurz: AR) und Action Design Research (kurz: ADR), sowie deren Einordnung im Vergleich zum Design Science Research (kurz: DSR) auseinander.

Grundsätzlich ließ sich die Aufgabenstellung in die drei Phasen "Grundwissens akquirieren", "Abgrenzen" und "Detailarbeit" aufgliedern.
Zu Anfang galt es, anhand gebener Literatur ein Grundwissen zum Action Research und Action Design Research aufzubauen. Auf Basis der so erarbeiteten Grundlagen sollten die beiden Methoden daraufhin in ihren Grundzügen voneinander, sowie vom Design Science Research abgegrenzt werden, wobei besonderes Augenmerk auf den Anwendungsbereichen jedes Ansatzes zu legen war. Im Anschluss sollte noch einmal gesondert auf den Ansatz des Action Design Research eingegangen werden. Dies umfasste die Erläuterung der die Methode ausmachenden Phasen und Prinzipien, eine Veranschaulichung über ein Beispiel aus dem Software Engineering sowie eine Gegenüberstellung potenzieller Vor- und Nachteile des Ansatzes.

Motivation: 

Mithilfe des Design Science Research lassen sich viele Problemstellungen in der Forschung zuverlässig behandeln und Lösungsansäte können effizient gefunden werden. Bei näherer Betrachtung wird allerdings schnell deutlich, dass DSR nicht die Lösung aller Probleme herbeiführen kann. Wie lassen sich die Schwächen umgehen, die der Ansatz mit sich bringt? Wie ist z. B. mit Problemstellungen in vorrangig sozialen Forschungsbereichen umzugehen? Die folgende Vorstellung und der Vergleich der drei Forschungsansätze – DSR, AR und ADR – soll die Gemeinsamkeiten und Unterschiede dieser zeigen. Ziel ist es, die Auswahl eines Forschungsansatzes zu erleichtern um die Anwendung eines falschen Ansatzes zu vermeiden. Außerdem soll dieser Eintrag einen groben Leitfaden zu den zwei Forschungsansätzen AR und ADR in Gegenüberstellung zum bereits in vorherigen Einträgen eingehend behandelten DSR bieten, der dem Leser zur Orientierung dient.

Zentrale Untersuchungsergebnisse: 

Design Science Research (DSR)
In diesem Forschungsansatz steht das Generieren von neuen Artefakten und vom neuem Designwissen im Mittelpunkt. Die Entwicklung erfolgt mit Hilfe von qualitativen und quantitativen Methoden. Im wesentlichen besteht DSR aus drei Zyklen, die aufeinander aufbauen. Der erste Zyklus ist der Relevance Cycle, bei dem die Probleme und die Möglichkeiten der Umgebung identifiziert werden sollen. Jeder Zyklus in DSR endet in diesem, sobald Feldversuche in der Umgebung erfolgreich waren. Der Rigor Cycle gibt strenge Werkzeuge und Methoden (Wissensbasis) zur Konstruktion oder Evaluation von Artefakten vor, die dann in dem Design Cycle entwickelt werden. (vgl. Hevner (2007))

DSR eignet sich dann hervorragend, wenn es sich um rein technische Systeme handelt und das soziale Umfeld nur von minimaler Bedeutung ist.  (vgl. Hevner (2007))

Action Research (AR)
Bei dem Ansatz des AR handelt es sich um eine qualitative Forschungsmethode. Dies bedeutet, dass im Gegensatz zu der möglichst neutralen Außenperspektive, die bei quantitativen Methoden eingenommen wird, hier die "Sicht des Betroffenen" im Mittelpunkt steht. Dementsprechend sind im Rahmen einer solchen Methodik erhobene Daten eher als "weich" und realitätsnah anzusehen, sind dafür in der Regel allerdings auch kaum replizierbar. AR beschäftigt sich entsprechend dieser Prämissen mit der Erkenntnisgewinnung im Rahmen sozialer Phänomene. Solche Phänomene zeichnen sich auf Grund ihrer Abhängigkeit vom Menschen vor allem dadurch aus, dass sie nicht beständig sind, also bei gleichem Input nicht zwangsläufig immer den gleichen Output zurückgeben. AR ist damit nicht Wiederholbar (stattdessen Konzentration auf Wiederherstellbarkeit), kann aber überall dort von Nutzen sein, wo naturwissenschaftliche Methoden auf Grund der für sie nötigen Vorraussetzung der Replizierbarkeit von Experimenten nicht oder nur schwer anwendbar sind. (vgl. Checkland u. Holwell (2007))

Der grundlegende Prozessablauf des AR beläuft sich auf folgende Schritte.
Der Forscher findet Interesse an einem abgesteckten Themenbereich. Hierbei handelt es sich nicht um ein konkretes Problem, da sich die Interessenlage im Laufe der Forschung noch verändern kann. Daraufhin entwickelt der Forscher Ideen zu dem gewählten Thema und wählt entsprechend dieser passende Methodiken aus. An diese Schritte schließt sich der Eintritt in eine soziale Situation an​, in der das Thema / die Problematik relevant ist. Zentrales Merkmal ist hier das Verschwimmen der Trennlinie zwischen Forscher und Zuerforschendem. Da der Forscher mit Eintritt in die Situation selbst Teil von dem wird, was er erforscht, kann er Reaktionen nicht nur in seinem Umfeld, sondern auch an sich selbst feststellen. Der Forscher nimmt am Änderungsprozess, der über die Situation auftritt, teil und passt seine Ideen und Methoden fortlaufend daran an. Nach einem vom Forscher selbst beliebig festlegbaren Zeitraum folgt dann der Wiederaustritt aus der Situation und die Reflektion des Gelernten. Aus den so gewonnenen Erkenntnissen können dann wiederum neue potenzielle Fragen und Interessen entstehen, die den Prozess erneut starten. (vgl. Checkland u. Holwell (2007))

Action Design Research (ADR)
Der Action Design Research Ansatz ist eine designorientierte Forschungsmethode, die als Ziel die Erzeugung eines IT-Artefaktes hat. Dies bedeutet, dass es bei dieser Methode nicht ausschließlich um die Erzeugung des Artefaktes geht, sondern auch um dessen Gestaltung. Gleichzeitig verfolgt der ADR-Ansatz mit der Erzeugung des Artefaktes die Lösung einer Problemklasse. Es wird also nicht nur ein spezifisches Problem gelöst werden, sondern es werden mehrere Probleme, die Ähnlichkeiten untereinander aufweisen, betrachtet. Grundsätzlich beschäftigt sich die ADR-Methode sowohl mit technischen, als auch sozialen Problemen. Sie ist somit für soziotechnische Systeme ausgelegt. (vgl. Sein et al. (2011))

Abb. 1: Phasen und Prinzipien des ADR

Wie Abb. 1 verdeutlicht baut ADR auf vier Phasen auf, die durchlaufen werden müssen, um am Ende ein Artefakt zu erhalten. Jede Phase verfolgt hierbei ein bis mehrere Prinzipien, die beachtet werden sollten. Die erste Phase ist die Problemformulierung: Sie wird durch die Entdeckung eines Problems ausgelöst. Das Problem wird empirisch untersucht und anschließend ausformuliert. Es können z. B. Umfang oder der Geltungsbereich der Forschung festgelegt werden. Des Weiteren wird das entdeckte, spezifische Problem verallgemeinert, um so eine breite Problemklasse (s. o.) anzusprechen. (vgl. Sein et al. (2011)) Während dieser Phase kann sowohl nach dem Prinzipien der praxisbezogenen Forschung als auch der theoriebasierten Artefakten nachgegangen werden.                                                                                                                
Die praxisbezogene Forschung legt den Kern der Problemidentifikation auf den Organisationskontext. Die Problemaktivität wird demnach nicht nach dem theoretischen Wissen aufgebaut, sondern durch die Betrachtung der Aktivität. Hierbei können Schnittstellen von Technik- und Organisationsdomäne aufzeigt werden. 
Das theoriebasierte Artefakt entsteht aus 3 wesentlichen Theorien: Problemstrukturierung, Lösungsraumidentifikation und dem Designguide. Dadurch wird das Problem auf eine höhere Problemklasse abstrahiert, wodurch das Artefakt in eine bekannte Darstellungsform überführt wird (vgl. Sein et al. (2011)). Außerdem werden grundsätzliche Aktivitäten unabhängig von den Prinzipien durchgeführt. Hierzu gehört u. a. die Rollenverteilung.

In der zweiten Phase erfolgt das Gestalten, Intervenieren und Evaluieren (kurz: GIE). Durch einen iterativen Prozess, angewandt auf die drei genannten Operationen, kommt es zur Erstellung eines Artefaktes. Unterschieden wird zwischen dem IT-Dominant GIE und dem Organizational-Dominant GIE. Beim IT dominierenden Prozess entsteht zuerst eine α-Testversion, welche durch das Intervenieren und Evaluieren innerhalb der Forschergruppe stetig getestet und verbessert wird bis ein endgültiges Design zustande gekommen ist. Dies bildet die β-Testversion, welche in einem größeren Rahmen getestet wird. Oft entspricht dieser Rahmen dem tatsächlichen Einsatzgebiet des Artefaktes. Beim organisationsdominierenden Prozess werden hingegen von allen am Forschungsprozess beteiligten Personen stetig Verbesserungsvorschläge unterbreitet bis ein Artefakt-Zustand angenommen wird.(vgl. Sein et al. (2011)) In dieser Phase werden den die Prinzipien der gegenseitigen Formgebung, der gegenseitigen Einflussnahmen der Rollen sowie der authentischen und gleichzeitigen Bewertung berücksichtigt.                   
Die gegenseitige Formgebung betont die Untrennbarkeit von den beiden Domänen. Das IT-Artefakt wir immer hinsichtlich einer sozialen Umgebung betrachtet. Man kann hierzu z. B. ausgewählte Designstrukturen nutzen, um die Organisationumgebung zu gestalten. Diese kann wiederum genutzt werden, um neue Designstrukturen zu entwickeln. Dieser Prozess verläuft rekursiv und wird von der anfänglichen Domänenwahl beeinflusst. 
Die Rollenverteilung erfüllt in diesem Prinzip ihre Kernfunktion. Durch die unterschiedlichen Rollen kann jeder Teilnehmer sein Wissen einbringen. Der Forscher vermittelt dabei sein Wissen von Theorien und seiner technischen Erfahrung, während die Teilnehmer praktische Hypothesen und Organisationswissen mitbringen. Außerdem wird auch die Verantwortungszugehörigkeit klar verteilt. 
In dem Prinzip der authentischen und gleichzeitigen Bewertung werden die beiden Evaluierungsphasen durchgeführt. Die α-Version ist der Output der ersten Konfrontation des Artefakts mit den End-Usern. Mit Hilfe von Designprinzipien und der gemeinsamen Weiterentwicklung aller Teilnehmer, entsteht  die β-Version. Diese wird zunächst ebenfalls von End-Usern getestet. Die Iteration kann sich wiederholen, bis eine finale Version entsteht. (vgl. Sein et al. (2011))

Die dritte Phase – Reflexion und Lernen – wird parallel zur ersten und zweiten Phase ausgeführt. Hier werden die gewonnen Ergebnisse reflektiert, um eine Lösung für das zuvor spezifisch entdeckte Problem zu finden. Anschließend wird die spezifische Lösung auf die breite Problemklasse übertagen.(vgl. Sein et al. (2011)) Hierbei wird das Prinzip der geführten Entstehung beachtet.
Dieses Prinzip unterscheidet nach beabsichtigten oder unbeabsichtigten Änderungen im Artefakt. Änderungen resultieren aus erwarteten oder unerwarteten Anforderungen an das Artefakt. Z. B. im laufe der Tests können unerwartete, neue Erkenntnisse gewonnen werden, die unabsichtlich erzielt wurde und angepasst werden müssen. Gleichzeitig können Tests absichtlich auf bestimmte Änderungen abzielen, um das bestmögliche Ergebnis zu erhalten. Diese erwarteten Änderungen müssen in dieser Phase festgehalten werden. Es erfolgt ein Rücksprung in die GIE-Phase. Wird aber bspw. ein neues Problem identifiziert, wird zur Problemformulierungsphase zurückgesprungen.(vgl. Sein et al. (2011)) 

In der letzten Phase kommt es zur Formalisierung des Problems. Dieser Schritt beinhaltet die endgültige Übertragung des spezifischen Problemfalls mit seinen Erkenntnissen auf eine allgemeine Lösung der Fälle der Problemklasse. (vgl. Sein et al. (2011)) Das Prinzip des generalisierten Ergebnisses hilft dabei.                                                                                                                                                                
Zunächst wird die Probleminstanz generalisiert, anschließend wird die Lösungsinstanz generalisiert. Das Ergebnis aus Phase 3 kann dann so formuliert werden, dass es ein neues Design Prinzip darstellt und die Überführung von der Probleminstanz zur Lösungsinstanz bietet. (vgl. Sein et al. (2011))

Vorteile
Entsprechend der beschriebenen Natur des ADR-Ansatzes lassen sich schnell Vorteile bw. Limitationen lokalisieren, von denen an dieser Stelle einige näher erläutert werden. Bezüglich der Vorteile lässt sich sagen, dass ADR vor allem für gesamtheitliche Artefaktlösungen geeignet ist, da es wegen der ständigen Iteration durch die Evaluation (Phase 3) Anpassungen an und den Umgang mit Artefakten auch über längere Zeiträume hinweg analysieren kann. Dies ist gerade bei IT Artefakten wichtig, da bei diesen meist erst während der Arbeit an und mit ihm alle benötigten Eigenschaften zutagetreten. Viele andere Design-Research-Methoden decken diesen Faktor nur schlecht ab, da Entwicklung und Evaluation meist sequenziert werden. Auch schränkt die kontinuierliche Evaluation potenziell die Gefahr von Fehlschlägen oder qualitativ unausreichenden Ergebnissen ein. Nach Sein et al. (2011) ist ADR zusätzlich auch für offene bzw. unbefristete Forschungsprobleme im Bereich der Informationssysteme geeignet, für die mehrere Eingriffe in Organisation nötig sind.
Weiterhin ist durch die Rollenvergabe an viele verschiedene Personen mit unterschiedlichen Schwerpunktgebieten größtenteils gesichert, dass divergentes Expertenwissen innerhalb der Forschung vertreten ist. Aufgrund der Generalisierung und anschließenden genauen Dokumentation von allen Forschungsaspekten, ist es mithilfe des ADR darüber hinaus möglich, zur Lösung einer ganzen Problemklasse beizutragen, anstatt nur einzelne, konkrete Probleme zu behandeln (potenziell hoher Nutzen für die Allgemeinheit). (vgl. Baskerville u. Wood-Harper (1998); Cole et al. (2005))

Nachteile
Im Tausch für die oben genannten Vorteile, die die Methode mit sich bringt, muss sich der Forscher darüber im Klaren sein, dass mit der vollständigen Durchführung von ADR ein relativ großer Aufwand einhergeht. AR zu praktizieren ist beispielsweise sicherlich schneller und tendenziell einfacher, als die umfangreichen Evaluationsiterationen und Nachbesserungen am Artefakt im ADR zu durchlaufen bzw. die genaue Formalisierung aller Ergebnisse zwangsläufig vorzunehmen.
Auch ist an dieser Stelle klar zu betonen, dass die Durchführung von ADR keiner Garantie für die Hervorbringung neuen Designwissens gleichkommt. Dieser Punkt ist insofern von großer Bedeutung als Kontrapunkt, da er letztendlich die Erreichung der gesetzten Forschungsziele gefährdet. (vgl. Baskerville u. Wood-Harper (1998))

Vergleich der 3 Ansätze
Gemeinsamkeiten
Grobes Ziel: DSR, AR und ADR sind Forschungsmethoden und haben dementsprechend zum Ziel, Wissen zu einem bestimmten Forschungsgegenstand zu akquirieren, wenn die jeweiligen Strategien dazu auch in einigen Punkten voneinander abweichen.

Iterationen: Trotz der unterschiedlichen Herangehensweisen berufen sich alle drei Ansätze auf Iteration, um ihr Ziel zu erreichen. So hat DSR drei Zyklen, um einerseits den Designprozess, andererseits die Verbindung des Ansatzes mit der Forschungsumgebung und Wissensbasis zu gewährleisten. AR bedient sich eines iterativen Anpassungsprozesses für anzuwendende Ideen und Methoden und ADR führt wie erwähnt ebenfalls eine kontinuierliche Evaluation während der Forschung durch.

Verwandschaft: Bezüglich ADR ist zusätzlich beobachtbar, dass der Ansatz Teile von sowohl DSR als auch AR aufgreift und damit bildlich gesprochen beide Ansätze in sich vereint. Mit Phase 3 und vor allem 4 hat ADR den eher formalen Charakter von DSR, andererseits legt die Forschungsmethodik aber auch einen Teilfokus auf soziale, „weiche“ Faktoren wie AR es praktiziert (z.B. 2 Ansätze zur Artefaktentwicklung: IT-dominant, organisationsdominant).

Unterschiede
Output: DSR bringt als Endprodukt ein Artefakt zur Lösung eines spezifischen Problems hervor. ADR ist hier spezifischer, es wird ein IT-Artefakt generiert, welches ein spezifisches Problem löst, sich aber für eine größere Problemklasse generalisieren lässt. AR bringt im Kontrast zu diesen beiden Ansätzen kein greifbares Endprodukt hervor, der Fokus liegt hier auf Erkenntnissen.

Thematik: AR beschäftigt sich anders als DSR und ADR nicht mit einem konkreten Problem, sondern mit einem klar definierten Themenfeld. DSR und ADR sind in dieser Hinsicht  konkreter in der Definition eines genauen Problems.

Anforderungen: ADR benötigt Designprinzipien, die eine ganze Klasse von Problemen adressieren. Ergebnisse innerhalb dieses Ansatzes sollten innovativ sein, um das Forschungsziel zu erreichen. AR beispielsweise hat keine dieser Anforderungen und ist generell wesentlich weicher in der Durchführung.

Replizierbarkeit: AR ist auf Grund seines sozialen Fokusses nicht Wiederholbar. Stattdessen wird hier Wiederherstellbarkeit angestrebt. DSR und ADR sind im Gegenzug (immerhin begrenzt) wiederholbar.

Anwendungsbereich: Aus dem zuvor dargelegten Grundwissen und weiterführenden Fakten lässt sich schließen, dass die drei vorgestellten Forschungsmethodiken in unterschiedlichen Kontexten Anwendung finden. DSR ist vor allem für technische Systeme geeignet, AR vor allem für soziale Themengebiete. ADR bildet als Ansatz, der insbesondere für soziotechnische Systeme nützlich ist, eine Verbindung zwischen diesen Bereichen.

Beispiel zur Veranschaulichung: 

Um das Prinzip von ADR zu verdeutlichen, folgt ein Beispiel anhand des Kompetenzmanagementsystems (kurz: CMS) von Volvo-IT. (vgl. Sein et al. (2011))

Am Anfang stand für Volvo die Feststellung, dass das von ihnen zu dieser Zeit genutzte CMS nicht den Anforderungen des Konzerns entspricht und einige Schwächen aufweist. Unter Nutzung des ADR-Ansatzes lässt sich für die Phase der Problemformulierung hier beispielhaft das folgende Problem aufführen: Einige Nutzer des Systems wollen ihre Kompetenzen nicht veröffentlichen lassen. Dieses Problem lässt sich der Problemklasse „Datenschutz“ zuordnen. Auch weitere Probleme werden in dieser Phase identifiziert und festgehalten.
Hierzu mussten zunächst die notwendigen Stakeholder identifiziert werden, wodurch dann das ADR-Team gezielt zusammengestellt wurde. Um die Probleme zu identifizieren, führte das Team Interviews, machte Beobachtungen, Workshops uvm. Daraus konnten dann Usecases generiert werden, die dazu verwendet wurden, das Problem zu formulieren und auf das CMS zurückzuführen. (vgl. Sein et al. (2011))

In der zweiten Phase entstehen das neue Kompetenzmanagementsystem: Die α-Testversion und die β-Testversion. Erstere wird ausschließlich im Forscherteam erstellt, während Letztere von Volvo-IT-Testmitarbeiter evaluiert und mitgestaltet wird.
Bevor die ersten Testversion entwickelt wurde, mussten vom Forscher-Team zunächst die hinreichenden Kriterien für das CMS aufgestellt werden. Mit Hilfe der Problemformulierung entschloss sich das Team eine neue Richtung einzuschlagen, geprägt durch die unterschiedlichen Rollen, die sich gegenseitig beeinflussten (Prinzip der gegenseitigen Formgebung). Daraus resultierten drei wichtige Kompetenztypen. Aus diesen wurden  neue Design Prinzipien entwickelt und in das CMS eingebunden um es effizienter zu gestalten. Beispielsweise wurden die Kompetenzen (Erfahrungen und Fähigkeiten), die ein Mitarbeiter erlangt hat, unter Berücksichtigung des Design Prinzips Transparenz eingebunden. Eine weitere Erkenntnis war die Competence of use. Darunter fällt die inakkurate Verwaltung der Daten, die auf das Design Prinzip Echt-Zeit-Erfassung hindeutet. 
Das Prinzip der stetigen Evaluation konnte mit Hilfe des bereits existierenden CMS hervorragend eingesetzt werden. Das Team konnte selbst gegenseitig eine Alpha-Version entwickeln und testen. Damit entstand die Beta-Version, die allen Mitarbeitern im Intranet zur Verfügung gestellt wurde. Die darausresultierenden Änderungen konnten dann in Zusammenarbeit letztlich noch durchgeführt werden.(vgl. Sein et al. (2011)) 

Die dritte Phase läuft parallel zu den ersten Beiden ab. Hier werden neue Anforderungen für das Tool entdeckt und implementiert. Außerdem werden verschiedene Versionen zusammengeführt um eine neue komplettere Version zu erhalten, welche dann wieder die zweite Phase durch laufen wird. Erst wenn in der dritten Phase keine neuen Anforderungen mehr für das System gefunden wurden, kommt es zur vierten Phase vom ADR. Nach einer kritischen Auseinandersetzung gelangte das Team zu dem Entschluss eine eigene Profilverwaltung für jeden Mitarbeiter anzubieten. So sollte jeder seine Kompetenzen eigenständig verwalten.(vgl. Sein et al. (2011))

Die letzte Phase bringt das finale Kompetenzmanagementsystem hervor, welches bei Volvo-IT eingesetzt werden soll. Die generalisierte Problemklassen konnte zu einer Lösungsinstanz überführt werden: Die Benutzer können ihr Profil eigenständig verwalten und somit selber entscheiden welche Kompetenzen für wen sichtbar sind. Dieses Prinzip wurde auf sämtliche Datenschutz-Probleme übertragen. Die Lösung eines spezifischen Problems wurde somit erfolgreich auf eine Problemklasse übertragen.(vgl. Sein et al. (2011))

Somit konnte das Team von Volvo-IT folgende Überführungen erreichen:
1. Inakkurate Daten - eigenständige Profilverwaltung -Transparenz 
2. Mitarbeiter unzufrieden und besorgt - eigenständige Profilverwaltung - Datenschutz

Bedeutung für Wissenschaft und Praxis: 

Wie schon die Motivation zur Bearbeitung des Themas zeigt, ist es besonders für die Praxis von Vorteil, den richtigen Ansatz zur Entwicklung von Artefakten schnell auszuwählen. Hierdurch werden Effektivität und Effizienz der Prozesse positiv beeinfluss. Bei Auswahl eines falschen Ansatzes könnte es hingegen zum unnötigen Verbrauch von Ressourcen wie Arbeitskraft, Zeit oder Geld kommen.

Für die Wissenschaft ist vor allem die Unterscheidung der Ansätze von Bedeutung. Somit kann bei Weiterentwicklung oder auch Neuentwicklung der vorhandenen Methoden eine zu starke Überschneidung vermieden werden.

Datei: 

Kategorie: 

Bilder: