Aufbau einer Wirtschaftsinformatik-Bachelorarbeit 2026: Kapitel für Kapitel, mit Artefakt und Evaluation

Wirtschaftsinformatik-Arbeiten scheitern selten am Prototyp. Sie scheitern an der Gliederung. Wer das Schema einer empirischen Sozialwissenschaftsarbeit übernimmt — Einleitung, Theorie, Methode, Ergebnisse, Diskussion — landet zwangsläufig bei der Frage, wo eigentlich die Software hingehört. Und wer nur ein Softwareprojekt dokumentiert, bekommt zurück: «Wo ist der wissenschaftliche Beitrag?»

Der Grund ist, dass die Wirtschaftsinformatik zwei Forschungstraditionen bedient. Die verhaltenswissenschaftliche Seite erklärt, wie Menschen mit Informationssystemen umgehen; die gestaltungsorientierte Seite baut etwas und zeigt, dass es funktioniert. Für den zweiten Fall — den häufigeren bei Bachelorarbeiten mit Praxispartner — gibt es ein eigenes Gliederungsmuster: den Design-Science-Research-Aufbau. Dieser Leitfaden geht ihn Kapitel für Kapitel durch, mit Richtwerten für den Umfang, konkreten Formulierungen und den Stellen, an denen Punkte verloren gehen.

Zuerst: Welchen der drei Arbeitstypen schreibst du?

Bevor du eine Gliederung anlegst, musst du deinen Arbeitstyp bestimmen. Danach richtet sich alles Weitere.

Typ 1 — Gestaltungsorientierte Arbeit mit Artefakt. Du entwickelst ein Konzept, ein Modell, einen Prototyp oder eine Methode und evaluierst sie. Das ist der Standardfall bei Arbeiten mit Unternehmenskooperation. Aufbau nach Design Science.

Typ 2 — Empirisch-erklärende Arbeit. Du untersuchst zum Beispiel, welche Faktoren die Nutzung eines Systems erklären. Aufbau klassisch: Theorie, Hypothesen, Methode, Ergebnisse, Diskussion. Ein etabliertes Rahmenmodell wie UTAUT mit seinen vier Kernkonstrukten spart dir hier das halbe Theoriekapitel.

Typ 3 — Systematische Literaturarbeit. Du synthetisierst den Forschungsstand zu einem Thema. Aufbau nach Review-Protokoll mit Suchstring, Ein- und Ausschlusskriterien und Flussdiagramm.

Der Rest dieses Leitfadens behandelt Typ 1 im Detail und weist an den passenden Stellen darauf hin, was sich bei Typ 2 und 3 unterscheidet.

Kapitel 1: Einleitung (8 bis 10 Prozent)

Die Einleitung einer gestaltungsorientierten Arbeit muss vier Dinge leisten, in dieser Reihenfolge.

Praxisproblem. Ein konkretes, belegtes Problem — nicht «Digitalisierung schreitet voran», sondern «Die Auftragserfassung im untersuchten Handelsbetrieb erfolgt in drei getrennten Systemen; die manuelle Übertragung verursacht laut internem Fehlerprotokoll durchschnittlich 14 Korrekturvorgänge pro Woche.»

Forschungslücke. Warum lösen bestehende Ansätze das Problem nicht? Zwei bis drei Sätze mit Belegen.

Zielsetzung und Forschungsfrage. Bei Design Science formulierst du eine Gestaltungsfrage: «Wie muss ein X beschaffen sein, damit Y erreicht wird?» Ergänzend eine Evaluationsfrage: «Inwieweit erreicht das entwickelte X das Ziel Y?»

Aufbau der Arbeit. Ein Absatz, der die Kapitel benennt und begründet — nicht das Inhaltsverzeichnis in Prosa.

Punkteverlust hier: Eine Forschungsfrage, die mit Ja oder Nein zu beantworten ist. «Ist ein Chatbot sinnvoll?» ist keine Gestaltungsfrage.

Kapitel 2: Grundlagen und Forschungsstand (20 bis 25 Prozent)

Dieses Kapitel hat in der Wirtschaftsinformatik zwei Teile, die viele Arbeiten vermischen.

Teil A — Begriffliche und technische Grundlagen. Definitionen, Architekturkonzepte, Referenzmodelle. Halte dich kurz und definiere nur, was du später tatsächlich brauchst. Wenn im ganzen weiteren Text kein einziges Mal auf deine Definition von «Cloud Computing» zurückgegriffen wird, gehört sie nicht in die Arbeit.

Teil B — Verwandte Arbeiten. Hier zeigst du, was andere zum selben Problem bereits gebaut oder untersucht haben. Das ist der Teil, der über die Note entscheidet. Arbeite mit einer Konzeptmatrix: Zeilen sind die Quellen, Spalten sind die Vergleichsdimensionen (Anwendungsdomäne, Artefakttyp, Evaluationsmethode, offene Punkte). Diese Matrix gehört als Tabelle in die Arbeit und endet mit einem Absatz, der die Lücke benennt, die du füllst.

Die Literatursuche dokumentierst du nachvollziehbar — auch in einer gestaltungsorientierten Arbeit. Wie das mit Suchstring, Trefferkette und Recherchetagebuch funktioniert, steht im Leitfaden zum Dokumentieren der Literaturrecherche. Für Konferenzbeiträge in der Wirtschaftsinformatik gilt zusätzlich: Prüfe die Qualität der Publikationsorte, bevor du zitierst. Die Checkliste zum Erkennen von Predatory Journals braucht in diesem Fach zehn Minuten und verhindert peinliche Referenzen.

Punkteverlust hier: Ein Grundlagenkapitel, das aus aneinandergereihten Definitionen besteht, ohne dass eine Argumentationslinie erkennbar ist.

Kapitel 3: Methodisches Vorgehen (8 bis 12 Prozent)

Kurz, aber unverzichtbar. Hier legst du offen, nach welchem Forschungsparadigma du arbeitest, welchen Prozess du durchläufst und wie du die Qualität sicherst.

Ein bewährter Aufbau in vier Absätzen:

1. Forschungsparadigma: Design Science Research, mit Verweis auf den zugrunde gelegten Prozessrahmen und dessen Phasen.
2. Konkreter Ablauf in deiner Arbeit: Welche Phase entspricht welchem Kapitel? Eine kleine Abbildung mit Phase, Aktivität und Kapitelnummer spart eine Seite Text.
3. Datenerhebung für die Anforderungsanalyse: Zum Beispiel vier Leitfadeninterviews mit Prozessverantwortlichen plus Dokumentenanalyse der bestehenden Systemdokumentation.
4. Evaluationsstrategie: Vorab festgelegt, nicht im Nachhinein. Welche Kriterien, welche Messgrössen, welche Vergleichsbasis?

Wenn du Interviews führst, brauchst du ein Kategoriensystem und musst dich entscheiden, ob und wie du transkribierst. Für Gespräche in der Deutschschweiz ist die Frage nicht trivial — der Beitrag zum Transkribieren von Interviews auf Schweizerdeutsch zeigt, was ins Transkript gehört und was du weglassen darfst.

Punkteverlust hier: Die Evaluationskriterien tauchen erst in Kapitel 6 auf. Dann wirken sie so, als hättest du sie passend zum Ergebnis gewählt.

Kapitel 4: Problemanalyse und Anforderungen (15 Prozent)

Das ist das Kapitel, das schwache Arbeiten überspringen. Es beantwortet: Was genau soll das Artefakt können, und woher weisst du das?

Struktur:

• Ist-Analyse: Der bestehende Prozess oder das bestehende System, modelliert. In der Schweizer Hochschullandschaft ist BPMN 2.0 der Standard für Prozesse, UML für Systemstruktur. Ein Modell ohne begleitenden Text ist wertlos; erkläre, was die Abbildung zeigt und wo der Schmerzpunkt liegt.
• Anforderungserhebung: Woher stammen die Anforderungen? Aus Interviews, aus der Literatur, aus regulatorischen Vorgaben. Jede Anforderung bekommt eine Quelle.
• Anforderungskatalog: Tabellarisch, mit ID, Beschreibung, Typ (funktional / nicht-funktional), Quelle und Priorisierung. Diese IDs — A1, A2, A3 — verwendest du später in der Evaluation wieder. Genau diese Rückverfolgbarkeit macht den Unterschied zwischen einer Projektdokumentation und einer wissenschaftlichen Arbeit.

Punkteverlust hier: Anforderungen ohne Quelle. Wenn nicht erkennbar ist, ob eine Anforderung aus dem Interview oder aus dem Bauchgefühl stammt, ist die spätere Evaluation wertlos.

Kapitel 5: Entwurf und Umsetzung des Artefakts (20 bis 25 Prozent)

Hier kommt die eigentliche Gestaltungsleistung. Wichtig: Du dokumentierst Entwurfsentscheidungen, nicht Code.

Ein tragfähiger Aufbau:

• Gestaltungsprinzipien: Aus den Anforderungen abgeleitete, allgemein formulierte Prinzipien. Sie sind der Teil deiner Arbeit, der über den Einzelfall hinaus gilt — und damit der Kern des wissenschaftlichen Beitrags.
• Architektur: Komponentendiagramm, Datenmodell, Schnittstellen. Erkläre die Alternativen, die du verworfen hast, und warum.
• Umsetzung: Technologiestack mit Begründung, zentrale Implementierungsentscheidungen, Screenshots der wichtigsten Ansichten.

Code gehört in den Anhang oder in ein Repository, auf das du im Text verweist. In die Arbeit selbst kommen höchstens kurze, illustrative Ausschnitte von wenigen Zeilen. Wenn du mit LaTeX schreibst — in technischen Fächern der Regelfall —, hilft die Anleitung zur LaTeX-Vorlage für technische Abschlussarbeiten beim Einrichten von Listings, Abbildungen und Literaturverzeichnis.

Punkteverlust hier: Dreissig Seiten Klassendokumentation. Das ist keine Forschungsleistung, das ist eine Auslagerung der Arbeit an den Leser.

Kapitel 6: Evaluation (15 bis 20 Prozent)

Die Evaluation ist der Punkt, an dem sich eine gute von einer mittelmässigen Wirtschaftsinformatik-Arbeit trennt. Du hast im Wesentlichen vier Optionen, gestaffelt nach Aufwand.

Option A — Anforderungsabgleich. Du gehst den Anforderungskatalog durch und weist für jede Anforderung nach, ob und wie sie erfüllt ist. Minimalstandard, aber sauber machbar. Tabellarisch mit Anforderungs-ID, Erfüllungsgrad und Beleg.

Option B — Expertenevaluation. Drei bis fünf Fachpersonen testen das Artefakt und bewerten es anhand eines strukturierten Leitfadens. Aussagekräftiger als A, weil eine externe Perspektive dazukommt.

Option C — Nutzungsstudie mit standardisiertem Instrument. Du lässt eine Gruppe von Testpersonen Aufgaben lösen und misst mit einem etablierten Fragebogen. Etablierte Usability-Skalen sind hier attraktiv, weil du Vergleichswerte aus der Literatur hast. Wie du die Antworten korrekt auswertest, hängt davon ab, ob du eine Gesamtskala oder Einzelitems berichtest — der Beitrag zum Auswerten von Likert-Skalen klärt genau diese Unterscheidung.

Option D — Vergleichsmessung. Du misst eine Prozesskennzahl vor und nach Einsatz des Artefakts. Methodisch am stärksten, aber nur machbar, wenn das Artefakt produktiv läuft. Für die Auswertung brauchst du dann ein Design mit Messwiederholung — siehe die Erläuterung zum Prä-Post-Design.

Bei Optionen C und D mit kleinen Stichproben lohnt sich vorab die Frage, welches Verfahren überhaupt zulässig ist. Der Entscheidungsbaum für den passenden statistischen Test führt dich in vier Fragen zum richtigen Verfahren.

Punkteverlust hier: «Die Testpersonen fanden das System hilfreich.» Ohne Instrument, ohne Zahlen, ohne Vergleichsbasis ist das keine Evaluation, sondern ein Eindruck.

Kapitel 7: Diskussion (8 bis 10 Prozent)

Die Diskussion beantwortet drei Fragen. Erstens: Was bedeuten die Evaluationsergebnisse für die Gestaltungsfrage? Zweitens: Wie ordnet sich dein Artefakt in die verwandten Arbeiten aus Kapitel 2 ein — was kann es besser, was nicht? Drittens: Welche Limitationen hat die Arbeit?

Bei den Limitationen gilt: konkret statt rituell. «Die Stichprobe war klein» ist eine Floskel. «Alle fünf Testpersonen stammten aus derselben Abteilung und kannten den Ist-Prozess; die Ergebnisse sind daher nicht auf Neueinsteigende übertragbar» ist eine Limitation.

Kapitel 8: Fazit und Ausblick (5 Prozent)

Beantworte die Forschungsfrage aus Kapitel 1 in zwei bis drei Sätzen — wörtlich, mit Bezug auf die Formulierung von Seite eins. Fasse den Beitrag zusammen: das Artefakt, die Gestaltungsprinzipien, die Evaluationserkenntnis. Dann der Ausblick, der aus den Limitationen folgt und nicht aus der Fantasie.

Keine neuen Quellen, keine neuen Argumente, keine Zahlen, die vorher nicht vorkamen.

Umfang, Zeitplan und Formalia

Für eine Bachelorarbeit in Wirtschaftsinformatik an einer Schweizer Fachhochschule sind je nach Studienreglement 40 bis 60 Seiten Fliesstext üblich, entsprechend etwa 12 000 bis 18 000 Wörtern. Die Prozentangaben oben beziehen sich auf diesen Textkörper ohne Anhang.

Ein realistischer Zeitplan für zwölf Wochen: zwei Wochen Literatur und Grundlagen, zwei Wochen Problemanalyse und Interviews, vier Wochen Umsetzung, zwei Wochen Evaluation, zwei Wochen Schreiben und Korrektur. Die Umsetzung dauert immer länger als geplant — deshalb evaluierst du das, was am Stichtag läuft, nicht das, was du dir vorgenommen hattest.

Zu den Formalia: Achte auf die Schweizer Rechtschreibkonventionen — doppel-s statt Eszett, Zahlenformate, Anführungszeichen. Und kläre früh, welche Regeln deine Hochschule für den KI-Einsatz vorgibt; die Übersicht zu den KI-Regeln an Schweizer Hochschulen zeigt, wer das entscheidet und wo du deine konkrete Regel findest.

Die Gliederung als Erstes anlegen

Der grösste Fehler bei Wirtschaftsinformatik-Arbeiten ist, mit dem Coden anzufangen und die Gliederung später zu bauen. Dann entsteht eine Arbeit, die den Entwicklungsverlauf nachbetet statt eine Argumentation zu führen. Lege die acht Kapitel mit Überschriften und je zwei bis drei Stichworten an, bevor du die erste Zeile Code schreibst — dann weisst du beim Umsetzen bereits, welche Entscheidungen du dokumentieren musst.

Genau dafür ist Tesify gebaut: Du gibst deine Forschungsfrage und den Arbeitstyp ein, bekommst ein Kapitelgerüst mit Zielen pro Abschnitt, hältst Quellen und Zitate an einem Ort und siehst jederzeit, welcher Teil noch leer ist. Leg deine Wirtschaftsinformatik-Arbeit in Tesify an und starte mit einer Struktur statt mit einem leeren Dokument.