Design Science Research

Design Science Research (DSR) ist ein forschungsmethodischer Ansatz, der darauf abzielt, innovative Artefakte zu entwickeln, um relevante Probleme an der Schnittstelle zwischen Technologie, Organisation und Mensch zu lösen. Anders als rein beobachtende oder erklärende Forschungsparadigmen richtet sich DSR auf das Gestalten, also auf die Entwicklung von Modellen, Systemen oder Prototypen, etc., die sowohl theoretisch fundiert als auch praktisch einsetzbar sind. In der Forschung zu Informationssystemen spielt dieser Ansatz seit Jahren eine zentrale Rolle, weil er es erlaubt, praxisrelevante Herausforderungen strukturiert und wissenschaftlich legitimiert zu adressieren (Hevner et al., 2004; Peffers et al., 2006). 

Der Einsatz von DSR ist besonders sinnvoll in Situationen, in denen neue technologische und organisatorische Konzepte benötigt werden, etwa zur Unterstützung von Entscheidungen, zur Verbesserung von Geschäftsprozessen oder zur Entwicklung von IT-Systemen (siehe Beispiel im Sozialwesen und in der Bildung). Während traditionelle Forschungsansätze darauf abzielen, Phänomene zu beobachten, zu erklären oder vorherzusagen, greift DSR aktiv in eine Problemstellung ein und möchte eine bessere Gestaltungsalternative hervorbringen. Der Erkenntnisgewinn entsteht dabei nicht nur durch theoretische Analyse, sondern auch durch das Entwickeln und Erproben eines Artefakts. 

Die Motivation für DSR ergibt sich also aus der Notwendigkeit, Probleme in realen Organisationen nicht nur zu verstehen, sondern wirksam zu lösen. Durch die explizite Verbindung von Theorie und Artefakt schafft DSR einen hohen Praxisbezug und ermöglicht gleichzeitig die Ableitung allgemeinerer Gestaltungsprinzipien, die über den konkreten Einzelfall hinaus nutzbar sind. 

Das Vorgehensmodell von Peffers et al. (2006) beschreibt den Ablauf von DSR in sechs Schritten, die nicht zwingend linear durchlaufen werden müssen (Abb. 1). Zwar bildet der Problemfokus die logische Ausgangsbasis, dennoch lässt sich in der Praxis an unterschiedlichen Stellen einsteigen, z.B. wenn bereits ein Artefakt existiert, das wissenschaftlich weiterentwickelt werden soll. Dennoch bietet die lineare Darstellung eine nützliche Orientierung. 

Abbildung 1. Das Design Science Research Prozessmodell (Peffers et al., 2006, S. 93).  

1. Problemidentifikation und Motivation 

Am Anfang steht die präzise Bestimmung eines relevanten Problems. Damit ist nicht nur die Beschreibung einer unerwünschten Situation gemeint, sondern auch deren theoretische und praktische Relevanz. Peffers et al. (2006) betonen, dass ein fundiertes Verständnis des Problemfeldes notwendig ist, um die spätere Konstruktion eines Artefakts zu rechtfertigen und zu leiten. Eine sorgfältige Analyse des Problems, die idealerweise durch Literatur, empirische Daten oder Beobachtungen untermauert wird, verhindert später die Entwicklung einer Lösung, die am Bedarf vorbeigeht. Die Zielgruppe sollte frühzeitig eingebunden werden und Probleme möglichst aus erster Hand identifiziert. Dazu sollten Stakeholder aktiv in die Lösungsgestaltung einbezogen werden, mindestens durch kontinuierliches Einholen von Feedback. Hier können u.a. Stakeholder-Maps, Customer Journey Analysis Maps, SWOT-Analysen sowie Literatursammlungen (z.B. Citavi) eingesetzt werden. Ein häufiger Fallstrick besteht darin, das Problem zu allgemein oder zu oberflächlich zu formulieren. Dadurch kann der DSR-Prozess seine Richtung verlieren und es entstehen Artefakte, deren Nutzen nur schwer belegbar ist. 

2. Ziele einer Lösung 

Aus dem definierten Problem werden konkrete Ziele für eine Lösung abgeleitet. Diese können qualitativer oder quantitativer Natur sein, müssen jedoch stets nachvollziehbar aus der Problemstellung hervorgehen. Während das Problem beschreibt, was nicht zufriedenstellend ist, beschreiben die Ziele, wie eine verbesserte Situation aussehen könnte. Diese Designprinzipien (DPs, engl. Design Principles) werden idealerweise atomar formuliert, um gegenseitige Beeinflussung zu verhindern. Typischerweise sind die DPs eng mit Kriterien verknüpft, anhand derer die spätere Evaluation erfolgen wird. Visualisierungs-Boards (z.B. Miro, Mural) oder einfache Task-Mappings (z.B. Kanban-Boards) können hier unterstützend eingesetzt werden. 

3. Design und Entwicklung des Artefakts 

Dieser Schritt bildet das Herzstück des DSR-Prozesses. Er umfasst sowohl den theoretisch fundierten Entwurf als auch die konkrete Realisierung eines Artefakts. Hevner et al. (2004) fassen Artefakte systematisch als Konstrukte, Modelle, Methoden oder Instanziierungen zusammen. 

Die Entwicklung erfolgt oft iterativ (bzw. agil, v.a. bei Softwareentwicklungen). Während der Gestaltung kommen theoretische Erkenntnisse und praktisches Wissen zusammen. Dabei können u.a. Modellierungs-Tools (BPMN, UML, etc.), Mockup-Tools (Figma, Sketch, etc.), Visualisierungs-Boards, Task-Mappings sowie Entwicklungs-Tools (v.a. für Software) genutzt werden. Iterationen sollten eingeplant werden, da häufig Teilschritte oder sogar komplette DSR-Zyklen wiederholt werden müssen, bis die entstandenen Artefakte überzeugen können. Ein Risiko besteht dennoch darin, ein Artefakt zu entwickeln, das zwar technisch interessant, aber nicht wirklich problemangemessen ist. Eine starke Bindung an die entwickelten DPs der Lösung wirkt dieser Gefahr entgegen. 

4. Demonstration 

In der Demonstration wird gezeigt, dass das Artefakt grundsätzlich dazu geeignet ist, das Problem zu adressieren. Dies kann in Form von Simulationen, Fallstudien, Experimenten oder prototypischen Anwendungen geschehen. Die Demonstration ist dabei mehr als eine technische Präsentation; sie zeigt, dass das Artefakt in einem realistischen oder zumindest realitätsnahen Szenario funktioniert. 

5. Evaluation 

Die Evaluation prüft, in welchem Maß das Artefakt die definierten DPs tatsächlich erfüllt. Hevner et al. (2004) unterscheiden unterschiedliche Evaluationsmethoden wie analytische, experimentelle oder empirische Verfahren. Die Auswahl hängt von Art und Reifegrad des Artefakts sowie vom Forschungsdesign ab. 

Die Evaluation dient nicht allein der Überprüfung, sondern liefert häufig neue Erkenntnisse, die eine Rückkehr zum Designschritt auslösen. Zur Dokumentation und Organisation der Arbeit können hier ebenfalls Task-Mappings (z.B. Kanban) oder Visualisierungs-Boards hilfreich sein. 

6. Kommunikation 

Zum Abschluss müssen die Ergebnisse des Projekts zielgruppengerecht kommuniziert werden. Für die wissenschaftliche Community steht die theoretische Fundierung, die methodische Strenge und der Beitrag zur Wissensbasis oft im Fokus. Für Praktiker:innen hingegen liegt der Schwerpunkt auf Nutzen, Umsetzbarkeit und Anwendungsszenarien. Je nach Grad der Exposition (öffentlich <-> intern) sind unterschiedliche Kommunikationskanäle und Formate anzuwenden. Peffers et al. (2006) betonen, dass die Struktur des DSR-Prozesses oft als Gliederungsrahmen für wissenschaftliche Beiträge dient, ähnlich wie es empirische Arbeiten mit Hypothesen und Analysen tun. 

Outcomes 

Der Output von DSR besteht nicht nur aus einem Artefakt, sondern aus einem doppelten Erkenntnisgewinn. Einerseits entsteht eine konkrete Gestaltungslösung: ein Modell, ein System oder ein Prototyp, die unmittelbar zur Bewältigung eines Problems beiträgt. Andererseits werden durch den Prozess neue Einsichten darüber gewonnen, warum und unter welchen Bedingungen das Artefakt wirksam ist. 

Hevner et al. (2004) betonen, dass dabei nicht nur das Artefakt selbst zählt, sondern auch die generierten DPs, die als wiederverwendbare Wissensbausteine in die Wissensbasis einfließen. DSR schafft somit nicht nur Lösungen, sondern auch theoretisch fundierte Gestaltungswissen, das für weitere Forschung fruchtbar ist.