Design Science Research in der Wirtschaftsinformatik-Abschlussarbeit 2026: vom Problem zum evaluierten Artefakt

Wirtschaftsinformatik-Arbeiten passen selten in das Schema, das die meisten Leitfäden anbieten. Du willst weder nur Literatur zusammenfassen noch eine Umfrage auswerten — du willst etwas bauen: ein Vorgehensmodell, ein Datenmodell, ein Bewertungsraster, einen Prototyp. Genau dafür gibt es einen anerkannten Forschungsansatz, und wer ihn beim Namen nennt und sauber durchhält, hat die methodische Diskussion in der Verteidigung schon zur Hälfte gewonnen: Design Science Research.

Warum dein Vorhaben ein eigenes Paradigma braucht

Hevner, March, Park und Ram haben den Ansatz in MIS Quarterly 28 (2004), S. 75–106 für die Wirtschaftsinformatik systematisiert. Ihre Ausgangsbeobachtung: Zwei Paradigmen prägen das Fach. Das verhaltenswissenschaftliche „seeks to develop and verify theories that explain or predict human or organizational behavior“ — das ist die klassische empirische Arbeit mit Hypothesen und Signifikanztests. Das gestaltungsorientierte dagegen „seeks to extend the boundaries of human and organizational capabilities by creating new and innovative artifacts„.

Der entscheidende erkenntnistheoretische Satz der Arbeit lautet: Im Design-Science-Paradigma entstehen „knowledge and understanding of a problem domain and its solution […] in the building and application of the designed artifact“. Das Bauen ist also nicht die Vorstufe zur Erkenntnis, sondern ihr Ort. Wer das im Methodenkapitel benennt, muss sich nicht mehr rechtfertigen, warum keine Hypothesen getestet werden.

Damit ist auch die Frage entschieden, an der viele WI-Studierende hängen bleiben: Deine Arbeit ist weder eine reine Literaturarbeit noch eine empirische Studie im engeren Sinn. Der Vergleich zwischen empirischer und theoretischer Bachelorarbeit beschreibt die zwei üblichen Wege — Design Science ist der dritte, und er hat eigene Regeln.

Was als Artefakt zählt — und was nicht

In der Wirtschaftsinformatik werden traditionell vier Artefakttypen unterschieden:

• Konstrukte — das Vokabular eines Problembereichs: Begriffe, Klassifikationen, Kennzahlendefinitionen.
• Modelle — Darstellungen von Zusammenhängen: ein Referenzprozess, ein Datenmodell, eine Architekturskizze.
• Methoden — Vorgehensweisen: ein Auswahlverfahren, ein Migrationsleitfaden, ein Reifegradmodell.
• Instanziierungen — die funktionierende Umsetzung: der Prototyp, das Werkzeug, die konfigurierte Systemlandschaft.

Für eine Bachelorarbeit ist die Instanziierung oft der teuerste und methodisch schwächste Weg, weil die Zeit für die Evaluation fehlt. Ein sauber hergeleitetes und geprüftes Modell oder eine Methode ist in der Regel die klügere Wahl — und bleibt vollwertige Design Science.

Nicht als Artefakt zählt eine Marktübersicht, ein Anforderungskatalog ohne Gestaltungsentscheidung oder ein Prototyp, der nur zeigt, dass eine Technologie funktioniert. Das sind Vorarbeiten, keine Beiträge.

Der Prozess: die sechs Schritte nach Peffers und Kollegen

Die verbreitetste Prozessvorlage ist die Design Science Research Methodology (DSRM) von Peffers, Tuunanen, Rothenberger und Chatterjee (Journal of Management Information Systems 24, 2007, S. 45–77). Die Autoren beschreiben sie selbst so: „The DS process includes six steps: problem identification and motivation, definition of the objectives for a solution, design and development, demonstration, evaluation, and communication.“

1. Problemidentifikation und Motivation. Welches konkrete Problem hat wer, und warum lohnt sich eine Lösung? Hier gehört eine belegte Problembeschreibung hin, keine allgemeine Digitalisierungsrhetorik.
2. Ziele der Lösung definieren. Was soll das Artefakt können — und woran wird das gemessen? Diese Ziele sind später deine Evaluationskriterien, weshalb sie hier schon operationalisierbar formuliert sein müssen.
3. Entwurf und Entwicklung. Das eigentliche Bauen, dokumentiert als Kette begründeter Gestaltungsentscheidungen. Jede Entscheidung braucht eine Alternative, die du verworfen hast, und einen Grund.
4. Demonstration. Der Nachweis, dass sich das Artefakt auf mindestens einen Fall anwenden lässt.
5. Evaluation. Der Vergleich der beobachteten Leistung mit den Zielen aus Schritt 2.
6. Kommunikation. Die Darstellung für Fachpublikum und Praxis — in deinem Fall die Abschlussarbeit selbst.

Die DSRM ist ausdrücklich als nominelles Prozessmodell gedacht, also als Rahmen und nicht als Zwangsablauf. In der Praxis springst du zwischen Schritt 3 und 5 mehrfach hin und her. Dokumentiere diese Iterationen, statt sie zu verstecken — sie sind Teil des Ergebnisses.

Demonstration ist nicht Evaluation — hier scheitern die meisten Arbeiten

„Der Prototyp läuft“ ist eine Demonstration. Eine Evaluation beantwortet die Frage, ob er die in Schritt 2 gesetzten Ziele erreicht — und zwar an Kriterien gemessen, die vor dem Bauen feststanden. Genau diese Reihenfolge ist der häufigste Mangel: Wer erst baut und dann überlegt, was er bewerten könnte, findet zuverlässig Kriterien, die das eigene Artefakt gut aussehen lassen.

Realistische Evaluationsformen für eine Abschlussarbeit, nach steigendem Aufwand:

• Kriterienbasierter Abgleich. Anforderungen aus Schritt 2 werden systematisch abgehakt, jede Abweichung begründet. Minimum, aber sauber machbar.
• Vergleich gegen eine Baseline. Dein Artefakt gegen den bisherigen Weg oder gegen ein bestehendes Verfahren, an messbaren Größen wie Bearbeitungszeit, Fehlerquote oder Aufwand.
• Expertenbewertung. Drei bis fünf Fachleute beurteilen das Artefakt entlang eines strukturierten Leitfadens. Wie ein solches Gespräch aufgebaut und ausgewertet wird, beschreibt der Beitrag zum Experteninterview mit Leitfaden.
• Anwendung im Realfall. Einsatz bei einem Praxispartner mit dokumentierten Ergebnissen — der stärkste Nachweis und zugleich der terminlich riskanteste. Der Beitrag zur Abschlussarbeit im Unternehmen beschreibt die organisatorischen Hürden.

Was du nicht tun solltest: dich selbst als einzigen Nutzer evaluieren, oder Zufriedenheit abfragen, ohne sie an ein Ziel zu koppeln. „Die Testpersonen fanden das Werkzeug hilfreich“ ist keine Evaluation, sondern eine Stimmungsabfrage.

Wie sich das in eine Gliederung übersetzt

Der große Vorteil der DSRM ist, dass sie die Kapitelstruktur gleich mitliefert. Eine bewährte Zuordnung:

1. Einleitung — Problem, Relevanz, Forschungsfrage, Aufbau.
2. Grundlagen und Stand der Forschung — die Wissensbasis, aus der du schöpfst, idealerweise als strukturierte Literaturrecherche.
3. Methodisches Vorgehen — DSRM benennen, zitieren, die sechs Schritte auf deine Arbeit abbilden, Evaluationskriterien festlegen.
4. Anforderungen und Gestaltungsziele — Schritt 2, hergeleitet aus Literatur und Problemanalyse.
5. Entwurf und Umsetzung — Schritt 3, mit dokumentierten Gestaltungsentscheidungen.
6. Demonstration und Evaluation — Schritte 4 und 5, getrennt und in dieser Reihenfolge.
7. Diskussion und Fazit — Beitrag zur Wissensbasis, Grenzen, weiterer Forschungsbedarf.

Diese Struktur weicht deutlich vom Standardaufbau ab, den viele Prüfungsordnungen als Beispiel abbilden. Kläre sie deshalb früh mit deiner Betreuung ab; die allgemeinen Regeln für den Aufbau stehen im Beitrag zur Gliederung Schritt für Schritt.

Die Literatur ist nicht Beiwerk, sondern die Wissensbasis

Design Science steht auf zwei Beinen: Relevanz kommt aus der Praxis, Rigorosität aus der bestehenden Forschung. Praktisch heißt das, dass deine Gestaltungsentscheidungen aus Literatur begründet sein müssen und nicht aus Bauchgefühl — und dass dein Ergebnis am Ende in diese Literatur zurückgespielt wird.

Für die Grundlagenrecherche lohnt ein systematisches Vorgehen mit dokumentierter Suchstrategie; der Beitrag zum systematischen Literaturreview beschreibt das Verfahren. Wenn deine Hochschule zentrale WI-Zeitschriften nicht lizenziert hat, führt der Weg über die Fachinformationsdienste. Und wie sich der theoretische Unterbau in ein eigenes Kapitel bringt, zeigt der Beitrag zum theoretischen Rahmen.

Zeitplan: wie zwölf Wochen auf sechs Schritte passen

Der häufigste Grund, warum eine gestaltungsorientierte Arbeit knapp wird, ist nicht die Programmierung, sondern die falsche Reihenfolge des Zeitverbrauchs. Eine tragfähige Aufteilung für eine zwölfwöchige Bachelorarbeit sieht so aus:

• Wochen 1–3: Schritte 1 und 2. Problem belegen, Literatur sichten, Anforderungen und Evaluationskriterien schriftlich festlegen. Am Ende dieser Phase steht ein unterschriebenes Verständnis darüber, was am Schluss gemessen wird.
• Wochen 4–7: Schritt 3. Entwurf und Umsetzung, mit einem laufenden Entscheidungsprotokoll. Jede getroffene Gestaltungsentscheidung wird am selben Tag notiert — nachträglich rekonstruierst du die Begründungen nicht mehr.
• Wochen 8–9: Schritte 4 und 5. Demonstration am Anwendungsfall, dann die Evaluation. Diese zwei Wochen sind nicht verhandelbar; wenn der Entwurf sie auffrisst, wird das Artefakt gekürzt, nicht die Evaluation.
• Wochen 10–12: Schritt 6. Ausformulieren, Diskussion, Grenzen, Formalia. Erfahrungsgemäß ist das Methodenkapitel schon geschrieben, weil es in Woche 3 entstanden ist.

Wer einen Praxispartner einbindet, verschiebt alles um die Vorlaufzeit für Zugänge, Freigaben und Terminfindung — realistisch zwei bis vier Wochen, die vor Woche 1 liegen müssen. Wie sich das als Balkenplan darstellen lässt, zeigt die Anleitung zum Zeitplan mit Gantt-Diagramm.

Das Einseitenpapier für das erste Betreuungsgespräch

Gestaltungsorientierte Themen werden oft abgelehnt, weil im ersten Gespräch nicht klar wird, worin die Forschungsleistung liegt. Nimm deshalb ein einzelnes Blatt mit fünf Angaben mit:

1. Das Problem in zwei Sätzen, mit einer Quelle oder einem konkreten Fall als Beleg.
2. Der Artefakttyp — Konstrukt, Modell, Methode oder Instanziierung, ausdrücklich benannt.
3. Drei bis fünf Gestaltungsziele, jeweils so formuliert, dass sich prüfen lässt, ob sie erreicht wurden.
4. Die geplante Evaluationsform samt Zugang: Wenn du Expertinnen befragen willst, steht dort, welche und wie du sie erreichst.
5. Der Abgrenzungssatz: was die Arbeit ausdrücklich nicht leistet.

Dieses Blatt beantwortet die drei Fragen, die in dieser Situation immer kommen — was ist neu, woran misst man es, und passt es in die Zeit —, bevor sie gestellt werden.

Vier Fehler, die in WI-Arbeiten immer wieder vorkommen

1. Zu groß geschnitten. Ein Prototyp mit fünf Modulen wird in zwölf Wochen nicht evaluierbar fertig. Schneide das Artefakt so klein, dass Schritt 5 noch in den Zeitplan passt — die Evaluation ist der Teil, der die Note macht.
2. Die Methode nur im Titel. „Nach Peffers et al.“ im Methodenkapitel zu schreiben und dann klassisch durchzuschreiben, fällt sofort auf. Jeder der sechs Schritte muss im Text sichtbar sein.
3. Gestaltungsentscheidungen unbegründet. Warum PostgreSQL und nicht MongoDB, warum BPMN und nicht EPK? Ohne Alternative und Begründung ist es Implementierung, keine Forschung.
4. Kein Beitrag über den Einzelfall hinaus. Am Ende muss stehen, was andere aus deinem Artefakt mitnehmen können — eine übertragbare Gestaltungsregel, nicht nur „bei Unternehmen X hat es funktioniert“.

Fazit

Design Science Research ist für die Wirtschaftsinformatik kein exotischer Sonderweg, sondern das etablierte Paradigma für Arbeiten, die etwas gestalten. Zwei Zitate tragen deine Methodenbegründung: Hevner und Kollegen für die Legitimation des Bauens als Erkenntnisweg, Peffers und Kollegen für den sechsschrittigen Ablauf. Halte Ziele und Evaluationskriterien vor dem Bauen fest, trenne Demonstration und Evaluation sauber, begründe jede Gestaltungsentscheidung — und schneide das Artefakt klein genug, dass für Schritt 5 noch Zeit bleibt.

Der Rest ist Schreibarbeit: sieben Kapitel, die aufeinander aufbauen, mit konsistenter Terminologie und durchgehender Argumentation vom Problem bis zum Beitrag. Mit Tesify strukturierst du deine Abschlussarbeit entlang genau dieser Kette — von der Gliederung über die Literaturverwaltung bis zum fertigen Text.