Projektcoaching III – Auswertung & Dokumentation

Lernziele

Sie haben Ihren Prototyp systematisch ausgewertet und können zwischen „funktioniert gut”, „funktioniert noch nicht” und „würde sich mit Verbesserungen ergeben” unterscheiden.

Sie sind in der Lage, KPIs für Ihren Use-Case zu schätzen — auch wenn noch keine Produktivdaten vorliegen — und diese Schätzungen methodisch zu begründen.

Sie haben die drei Kategorien von Learnings (technisch, prozessbezogen, Governance) für Ihren Use-Case dokumentiert.

Sie haben den Rohentwurf der Kapitel 5–8 Ihrer Projektarbeit erstellt.

Sie kennen die typische Struktur einer KI-Umsetzungs-Roadmap für die nächsten 90 Tage.

Sie können die 6-Dimensionen-Risikobewertung auf Ihren Use-Case anwenden.

Auf einen Blick

Worum geht es? — Der didaktische Einstieg

Der Prototyp ist gebaut. Jetzt kommt die oft unterschätzte Phase: die ehrliche Auswertung. Viele Teilnehmende beschreiben in der Projektarbeit ihren Prototyp und halten dann inne — als wäre das Bauen die Hauptleistung. Tatsächlich ist die Auswertung das intellektuell anspruchsvollste Kapitel der Projektarbeit.

Eine gute Auswertung beantwortet nicht nur „Was hat funktioniert?“, sondern auch: „Was hat nicht funktioniert — und warum?” und „Was würde sich bei vollständiger Umsetzung ändern?” Diese Fragen erfordern kritisches Denken und ehrliche Selbstreflexion. Sie zeigen, dass Sie nicht nur KI-Tools bedienen können, sondern die Grenzen und Voraussetzungen von KI-Lösungen verstehen.

Die zweite Aufgabe dieser UE ist strukturiertes Schreiben. Nutzen Sie diese Zeit, um die Kapitel 5–8 Ihrer Projektarbeit zu skizzieren.

Lerntext — Theorie und Konzepte

Was bedeutet Evaluation im Kontext der Projektarbeit?

Die Evaluation des Prototyps ist nicht dasselbe wie ein formales wissenschaftliches Experiment. Sie ist eine strukturierte, ehrliche Bestandsaufnahme. Ein Evaluations-Framework für KI-Prototypen umfasst drei Ebenen:

Ebene 1 — Funktionale Prüfung: Tut das System das, was es soll? Testen Sie mindestens 5–8 repräsentative Eingaben und dokumentieren Sie, wie viele Outputs als „akzeptabel” zu bewerten sind.

Ebene 2 — Grenzfall-Prüfung: Wie verhält sich das System bei ungewöhnlichen, unvollständigen oder mehrdeutigen Eingaben? Dokumentieren Sie mindestens 2–3 Grenzfälle.

Ebene 3 — Compliance-Prüfung: Hält das System die definierten Verhaltensregeln ein? Wenn die Systemanweisung definiert, dass der Assistent keine Preisaussagen macht — macht er sie auch wirklich nicht?

Abb. 112.1 — Auswertungs-Framework für KI-Prototypen in der Projektarbeit

Merksatz

Evaluation = strukturierte Bestandsaufnahme, kein wissenschaftliches Experiment. Eine Akzeptanzrate von 70 %+ bei Standardtests ist ein guter Richtwert für Prototyp-Reife. KPI-Schätzungen immer mit Ausgangsbasis, Prototyp-Messung und explizitem Vorbehalt formulieren.

KPI-Schätzung ohne Produktivdaten

Für die meisten Projektarbeiten ist eine exakte Messung zum Zeitpunkt der Abgabe nicht möglich. Die Prüfungskommission akzeptiert begründete Schätzungen, wenn sie methodisch transparent sind:

Ausgangsbasis: Was ist der aktuelle Aufwand oder die aktuelle Fehlerquote?

Messung am Prototyp: Was zeigt der Prototyp unter kontrollierten Bedingungen?

Hochrechnung mit Vorbehalt: „Wenn diese Ergebnisse reproduzierbar sind, erwarten wir…”

Beispiel: „Aktuell verbringen wir pro Angebot ca. 90 Minuten mit der Formulierung (gemessen über 5 Angebote). Mit dem Prototyp wurde ein erster Entwurf in durchschnittlich 12 Minuten erstellt (3 Testinteraktionen). Das entspricht 75 % Zeitersparnis. Vorbehalt: Die Nachbearbeitung erfordert ca. 20–30 Minuten, sodass die Netto-Ersparnis auf 45–60 Minuten geschätzt wird.”

Merksatz

Drei Learnings-Kategorien für Kapitel 6–8: Technisch (Was haben Sie über das KI-Tool gelernt?), Prozess (Was würde bei der Einführung organisatorisch schwierig werden?), Governance (Welche AI-Act- oder DSGVO-Anforderungen wurden erst im Laufe des Projekts erkannt?).

Die 6-Dimensionen-Risikobewertung für die Projektarbeit

Für Kapitel 6 (Evaluation und Risikobewertung) wird das Risikobewertungsschema aus Modul 9 angewendet:

Vertiefung — Wirtschaftlichkeitsbetrachtung und KI-gestütztes Schreiben

Wirtschaftlichkeitsbetrachtung:

Kapitel 7 der Projektarbeit verlangt eine Wirtschaftlichkeitsbetrachtung:

Kosten: API-Kosten (Tokens × Preis), ggf. Plattformlizenz (z. B. OpenAI API: ca. 0,002 $ pro 1.000 Token), Einführungsaufwand

Nutzen: Monetarisierte Zeitersparnis, Qualitätsverbesserungen, Skalierungseffekte

Break-Even: Einführungskosten / (Monatlicher Nutzen − Monatliche Betriebskosten)

Beispiel: Break-Even-Berechnung: API-Kosten GPT-4o ca. 0,15 €/1.000 Output-Token. Bei 15 Angeboten/Monat = ca. 1,80 €/Monat. Einführungsaufwand: 16 Stunden × 80 €/h = 1.280 €. Nutzen: 15 Angebote × 50 Min Netto-Ersparnis / 60 × 80 €/h = 1.000 €/Monat. Break-Even: 1.280 / (1.000 − 2) ≈ 1,3 Monate.

KI-gestütztes Schreiben:

Die Projektarbeit darf und soll mit KI-Unterstützung geschrieben werden — unter einer klaren Bedingung: Sie sind für jede Aussage inhaltlich verantwortlich. Erlaubt: KI für Gliederungsvorschläge, Formulierungsentwürfe, Korrekturlesen, Strukturierung der Risikobewertungstabelle. Nicht erlaubt: Vollständige Kapitel unverändert aus KI-Ausgaben übernehmen. Ein kurzer Transparenz-Abschnitt am Ende der Projektarbeit beschreibt, wie KI-Tools eingesetzt wurden — das ist selbst ein Kompetenznachweis und verankert in Art. 4 EU AI Act.

Dokumentation als Argumentationskette: Die Projektarbeit ist keine Ansammlung von Fakten — sie ist eine Argumentationskette. Jedes Kapitel baut auf dem vorherigen auf: Die Problemdefinition (Kap. 1) begründet die Use-Case-Auswahl (Kap. 3), die Use-Case-Auswahl begründet den Prototyp-Ansatz (Kap. 5), der Prototyp-Ansatz begründet die Evaluationsmethode (Kap. 7). Wer diese Kette in der Dokumentation explizit macht — durch Verweise auf frühere Kapitel und kurze Rückkopplungssätze (“Wie in Kapitel 3 beschrieben…”) — produziert eine deutlich kohärentere Arbeit.

Reflexion als Kompetenznachweis: Das Reflexionskapitel (Kap. 8) ist für viele Teilnehmende das unbeliebteste — weil es Selbstkritik erfordert. Tatsächlich ist es eine der größten Chancen zur Differenzierung. Eine flache Reflexion: “Das Projekt war erfolgreich und wir haben viel gelernt.” Eine starke Reflexion: “Der Prototyp erreichte in Testfall 1 und 2 die definierten KPIs, in Testfall 3 jedoch nicht — weil [spezifischer Grund]. Daraus folgt, dass der Use-Case für Datenlage X besser geeignet ist als für Datenlage Y. Beim nächsten ähnlichen Projekt würde ich früher eine Datenverfügbarkeitsprüfung einplanen.” Diese Reflexion zeigt analytisches Denken und Transfer-Kompetenz — Qualitäten, die in der Berufspraxis direkt anwendbar sind.

Governance-Kapitel: Was gehört rein? Das Governance-Kapitel (Kap. 7 oder integriert in Kap. 5–6) adressiert drei Bereiche: (a) EU AI Act Einordnung — welche Risikoklasse hat der Use-Case, welche Pflichten folgen daraus? (b) Datenschutz — DSFA erforderlich oder nicht, AVV vorhanden, Datenkategorien. (c) Interne Governance — wer darf das System nutzen, wer hat Audit-Zugang, wie werden Incidents gemeldet? Diese drei Bereiche können in einer kompakten Tabelle dargestellt werden: je eine Spalte für “Anforderung”, “Status” und “Maßnahme”.

Branchen-Anwendungen

IT-Dienstleistung & Beratung

Die Evaluation des Angebots-Assistenten in einem IT-Beratungshaus zeigt ein differenziertes Bild: Bei strukturierten Anfragen mit klarem Leistungsumfang liefert der Assistent in 8 von 10 Testfällen einen Entwurf, der mit minimaler Überarbeitung verwendbar war. Bei sehr kurzen oder mehrdeutigen Eingaben neigt das Modell zu generischen Formulierungen — ein typischer Grenzfall. Die Compliance-Prüfung ergibt: Der Assistent hält die Grenze „keine Preisaussagen” in allen Tests ein.

KPI-Schätzung: Aktuelle Formulierungszeit 90 Minuten; Prototyp generiert Erstentwurf in 12 Minuten; Nachbearbeitung geschätzt 20 Minuten → Netto-Ersparnis 58 Minuten je Angebot. Bei 15 Angeboten/Monat = 14,5 Stunden/Monat Zeitgewinn.

Industrie & Fertigung

Die Evaluation des Wartungsprotokoll-Assistenten in einem Fertigungsunternehmen ergibt: Das System liefert bei strukturierten Maschinenparametern (Betriebsstunden, Fehlercodes, Wartungsarbeiten) in 9 von 10 Fällen vollständige, formatierungstreue Protokolle. Grenzfall: Bei fehlenden Pflichtfeldern im JSON-Input generiert das System entweder Platzhalter oder fragt nach — das Verhalten muss in der Systemanweisung explizit definiert werden.

Governance-Learnings: Die Einhaltung der internen Datenschutzklassifizierung (Maschinendaten als „intern”) erfordert eine klare Anweisung in der Systemanweisung, keine Produktionsparameter nach außen zu geben. AI Act: minimales Risiko — keine Entscheidungen über Personen.

Finanzdienstleistung & Versicherung

Die Evaluation des Beschwerde-Klassifizierers in einer Versicherung zeigt erhöhten Compliance-Aufwand: Das System klassifiziert Beschwerde-Art und Dringlichkeit mit einer Akzeptanzrate von 78 %. Grenzfälle entstehen bei unklaren oder gemischten Beschwerden (z. B. gleichzeitig Prämienbeschwerde und Beratungsbeschwerde). Compliance-Prüfung: Besonders kritisch ist, dass der Assistent keine Aussagen über mögliche Schadensersatzansprüche macht — diese Grenze hält in 100 % der Tests.

Wirtschaftlichkeit: 80 Beschwerden täglich × 3,5 Minuten Zeitersparnis bei Erstklassifizierung = 280 Minuten/Tag = fast 5 Stunden täglich. Bei 3 Sachbearbeitern und internem Stundensatz von 60 €/h = 300 €/Tag → 6.600 €/Monat potenzieller Nutzen.

Öffentliche Verwaltung

Die Evaluation des Wissens-Assistenten in einer Gemeindeverwaltung zeigt besondere Stärken bei gut strukturierten Wissensdatenbanken: Das System findet relevante Paragraphen und Verfahrensschritte mit einer Trefferquote von 82 % in der RAG-Datenbank. Schwäche: Bei sehr spezifischen Ausnahmefällen (seltene Verwaltungsverfahren) fehlt das nötige Kontextwissen — der Assistent eskaliert korrekt an einen Fachexperten.

Governance-Learnings: Die Transparenzpflicht gegenüber Bürgerinnen und Bürgern, dass ihre Anfrage KI-gestützt bearbeitet wurde, erfordert eine klare Disclosure-Regelung — in der öffentlichen Verwaltung besonders relevant für das Vertrauen der Bürgerinnen und Bürger. Grundlage: DSGVO Art. 13 (Informationspflicht).

Übung 1 — Evaluation strukturiert dokumentieren

Übung 1 — Evaluation strukturiert dokumentieren

Aufgabe: Führen Sie eine strukturierte Evaluation Ihres Prototyps durch und dokumentieren Sie die Ergebnisse nach dem dreistufigen Framework.

Material: Prototyp aus UE 111; Testdaten; Evaluations-Template

Schritt-für-Schritt: 1. Definieren Sie vorab, was „akzeptable Ausgabe” bedeutet (Canvas-Feld 5). Notieren Sie 3–5 Kriterien. 2. Führen Sie 5–8 Standard-Testinteraktionen durch. Tabelle: Input / Output (Kurzfassung) / Bewertung / Kommentar. 3. Berechnen Sie die Akzeptanzrate: X von Y Tests akzeptabel. 4. Führen Sie 2–3 Grenzfall-Tests durch. Dokumentieren Sie das Verhalten. 5. Prüfen Sie die Compliance: Hält der Assistent seine definierten Grenzen ein? 6. Formulieren Sie 3 Stärken und 3 Schwächen des Prototyps. 7. Erstellen Sie eine KPI-Schätzung mit explizitem Vorbehalt.

Erwartetes Ergebnis: Vollständig dokumentiertes Kapitel 6 (Evaluation und Risikobewertung) als Rohentwurf.

Musterlösung (Auszug):

Übung 2 — Roadmap und Wirtschaftlichkeit ausarbeiten

Übung 2 — Roadmap und Wirtschaftlichkeit ausarbeiten

Aufgabe: Erstellen Sie Kapitel 7 (Wirtschaftlichkeit) und Kapitel 8 (Fazit und nächste Schritte) als vollständige Rohentwürfe.

Material: Canvas aus UE 110 (KPIs); Evaluationsergebnisse aus Übung 1; Kostenangaben zum KI-Tool

Schritt-für-Schritt: 1. Recherchieren Sie die API-Kosten Ihres gewählten KI-Tools (z. B. https://openai.com/pricing). 2. Schätzen Sie den Einführungsaufwand in Stunden. 3. Berechnen Sie den monetären Nutzen auf Basis Ihrer KPI-Schätzung. 4. Berechnen Sie den Break-Even-Zeitpunkt. 5. Listen Sie 2–3 nicht-monetäre Nutzen auf. 6. Schreiben Sie Kapitel 8 mit: Empfehlung + Begründung + konkreter 90-Tage-Roadmap (6 Schritte) + persönliche Reflexion. 7. Geben Sie den Rohentwurf als One-Pager beim Trainer ab.

Erwartetes Ergebnis: Vollständige Kapitel 7 und 8 als Rohentwurf.

Cheatsheet — Die wichtigsten Punkte

Evaluation = strukturierte Bestandsaufnahme, kein wissenschaftliches Experiment

Akzeptanzrate von 70 %+ bei Standardtests ist ein guter Richtwert

KPI-Schätzung: Ausgangsbasis + Prototyp-Messung + expliziter Vorbehalt

Drei Learnings-Kategorien: Technisch / Prozess / Governance

Break-Even-Berechnung: Einführungskosten / (Monatlicher Nutzen − Monatliche Betriebskosten)

Nicht-monetäre Nutzen explizit nennen

KI-Nutzung beim Schreiben: erlaubt, mit kritischer Prüfung und Transparenz-Abschnitt

Grenzfall-Tests dokumentieren — zeigt Robustheit

Compliance-Tests zeigen, ob die Systemanweisung hält, was sie verspricht

Kapitel 7 und 8 sind oft entscheidend für die Gesamtnote

Reflexionsfragen

Welches Ergebnis der Evaluation hat Sie am meisten überrascht?

Wäre Ihre KPI-Schätzung in einem Gespräch mit der Geschäftsführung überzeugend — warum oder warum nicht?

Was würden Sie an Ihrer Systemanweisung als erstes ändern, wenn Sie noch eine Iteration hätten?

Welches der drei Learnings (technisch / prozessbezogen / Governance) war das wichtigste für Sie?

Was müsste sich in Ihrer Organisation ändern, damit Ihre Lösung in 6 Monaten produktiv eingesetzt wird?

Quellen & Weiterlesen

Vertiefung — Das Dokumentations-Prinzip: Aus dem Prototyp wird Kapitel 5

Viele Teilnehmende unterschätzen den Dokumentationsaufwand für Kapitel 5. Sie bauen einen guten Prototyp — und fragen sich dann, was genau in das Kapitel gehört. Die folgende Struktur zeigt, wie der Prototyp direkt in ein vollständiges Kapitel 5 überführt wird.

Abschnitt 5.1 — Prototyp-Typ und Begründung (1/2 Seite): Welche Prototyping-Option (A–D) wurde gewählt? Warum? Begründen Sie die Wahl mit einem direkten Bezug auf Canvas-Feld 5 (Technischer Ansatz): „Gemäß Canvas-Feld 5 wurde ein LLM-basierter Assistent als am besten geeignet identifiziert. Custom GPT wurde gewählt, weil er ohne API-Kenntnisse konfigurierbar ist, eine persistente Systemanweisung erlaubt und direkt in Copilot-kompatible Unternehmenssysteme integrierbar ist.”

Abschnitt 5.2 — Vollständige Systemanweisung (1–2 Seiten): Die vollständige Systemanweisung nach der 9-Komponenten-Architektur — nummeriert, mit Überschriften. Jede Komponente erklärt, was sie enthält und warum diese Formulierung gewählt wurde. Dieser Abschnitt zeigt, dass die Systemanweisung bewusst gestaltet und nicht zufällig entstanden ist.

Abschnitt 5.3 — Konfiguration und Screenshot (1/2 Seite + Abbildung): Wie wurde der Prototyp konfiguriert? Welche Einstellungen wurden vorgenommen? Screenshot der Prototyp-Konfiguration mit Bildunterschrift. Dieser Abschnitt zeigt, dass ein funktionierendes System besteht.

Abschnitt 5.4 — Dokumentierte Beispielinteraktionen (1–2 Seiten): Mindestens drei vollständige Interaktionen im Format: INPUT: [vollständiger Eingabetext] OUTPUT: [vollständiger Ausgabetext] BEWERTUNG: [1–2 Sätze — Was war gut? Was war schwächer?] Die Bewertung zeigt kritisches Denken und ist für die spätere Evaluation (Kapitel 6) die Datengrundlage.

Abschnitt 5.5 — Iterationsprotokoll (1/2 Seite): Was wurde zwischen Version 1 und der dokumentierten Finalversion geändert? Format: Iteration 1 → Iteration 2 mit je einem Satz Erklärung. Mindestens zwei Iterationen — das zeigt systematischen Entwicklungsprozess.

Abschnitt 5.6 — Datenschutz-Assessment des Prototyps (1/2 Seite): Kurze, strukturierte Beantwortung von drei Fragen: (1) Welche Daten wurden verarbeitet? (2) Liegt ein AVV vor? (3) Ist eine DSFA erforderlich?

Branchen-Vignette — Non-Profit & Sozialwirtschaft

In einer sozialen Organisation (gemeinnütziger Verein, Wohlfahrtsverband, NGO) fallen regelmäßig aufwendige Berichtspflichten an: Förderanträge müssen nach festem Schema formuliert werden, Zwischen- und Abschlussberichte an Fördergeber erstellt werden, und Sachberichte für interne wie externe Stakeholder vorbereitet werden. Ein KI-Assistent, der auf Basis strukturierter Inputdaten (Projektziele, erreichte Meilensteine, Teilnehmendenzahlen) erste Berichtsentwürfe erstellt, würde in diesem Kontext erhebliche Zeit sparen. Besonderheiten für die Projektarbeit: Förderanträge und -berichte folgen oft sehr spezifischen Formaten der Fördergeber. Feld 3 (KI-Methode) des Canvas: LLM-Assistent mit hochgeladenem Fördergeber-Regelwerk als Wissensbasis (RAG) oder als Few-Shot-Beispiele. Datenschutz: Solange keine Personendaten von Begünstigten im Prototyp verarbeitet werden, ist die Datenschutzanforderung überschaubar. AI Act: minimales Risiko. Wirtschaftlichkeit: Wenn eine Projektleiterin monatlich vier Stunden für Berichterstellung aufwendet und der Assistent dies auf eine Stunde reduziert, ergibt sich bei sechs aktiven Projekten eine erhebliche jährliche Zeitersparnis.

Praxis-Einschub — Die Wirtschaftlichkeitsrechnung in der Praxis: Typische Schätzfehler und wie man sie vermeidet

Die Wirtschaftlichkeitsrechnung ist für viele Teilnehmende das unangenehmste Kapitel — weil sie das Gefühl haben, ohne verlässliche Daten keine Aussage machen zu können. Drei typische Schätzfehler und ihre Lösung:

Schätzfehler 1 — Zu optimistischer Nutzen: Wer annimmt, dass die KI-Lösung 90 % der Arbeit abnimmt, unterschätzt die verbleibende Human-Review-Zeit, die Einarbeitungszeit und die anfängliche Qualitätsschwankung. Realistischere Annahme für den Anfang: 50–70 % Zeitersparnis bei gut konfigurierten Assistenten, 30–50 % bei Automatisierungs-Workflows.

Schätzfehler 2 — Vergessene Investitionskosten: Entwicklungskosten werden oft unterschätzt. Realistisch für eine 45-stündige Prototyp-Entwicklung: 45 h × 40 €/h = 1.800 €. Dazu kommen API-Kosten, ggf. Premium-Account-Kosten und Schulungszeit für die Anwendenden.

Schätzfehler 3 — Kein Zeitplan für die Amortisation: „Die Lösung amortisiert sich schnell” ist keine Wirtschaftlichkeitsrechnung. Ein Break-Even in konkret benannten Monaten — auch wenn er eine Schätzung ist — macht die Aussage prüfungsrelevant und überzeugend.

Merksatz

Eine transparente Schätzung mit expliziten Annahmen (“Wir nehmen an, dass X…” und “Diese Annahme basiert auf Y…”) ist prüfungsrelevanter als eine präzise wirkende Zahl ohne Herkunftserklärung. Die Prüfungskommission bewertet die Methodik, nicht die Präzision der Zahlen.

Trainer-Hinweise

Vertiefung: Dokumentation als strategisches Instrument

Dokumentation wird oft als lästige Pflicht betrachtet. Im Kontext von KI-Projekten ist sie jedoch ein strategisches Instrument mit drei unterschiedlichen Funktionen:

Funktion 1 — Reproduzierbarkeit Ohne Dokumentation ist ein KI-Prototyp nicht reproduzierbar. Wer hat welchen Prompt mit welchen Parametern verwendet? Welche Datenversion lag zugrunde? Ohne diese Informationen ist der Prototyp personengebunden und damit fragil.

Funktion 2 — Lernarchiv Fehlgeschlagene Ansätze sind dokumentationswürdig. Ein „Was wir versucht haben und warum es nicht funktioniert hat”-Abschnitt spart zukünftigen Projektbeteiligten Wochen an Doppelarbeit.

Funktion 3 — Entscheidungsgrundlage Eine gute Projektdokumentation ermöglicht es Entscheidungsträgerinnen und Entscheidungsträgern, ohne technisches Verständnis zu beurteilen, ob ein Projekt skaliert werden soll.

Die DARE-Dokumentationsstruktur

Übung 2: Wirtschaftlichkeitsnachweis — Nutzen quantifizieren

Aufgabe (20 Minuten):

Berechnen Sie für Ihren Use-Case einen vereinfachten Return on Investment (ROI) nach folgendem Schema:

Schritt 1 — Zeitersparnis ermitteln: - Wie viele Personen nutzen den Prozess, der automatisiert wird? - Wie viele Minuten/Stunden pro Person und Woche werden eingespart? - Durchschnittlicher Stundensatz (intern): ___ €

→ Jährliche Zeitersparnis = Personen × Stunden/Woche × 52 Wochen × Stundensatz

Schritt 2 — Implementierungskosten schätzen: - Einmalige Einrichtungszeit (Stunden × Stundensatz): ___ € - Monatliche Tool-Kosten (API, Lizenzen): ___ € × 12 Monate - Laufende Wartung (Stunden/Monat × Stundensatz × 12): ___ €

→ Gesamtkosten Jahr 1 = Einmalig + Laufend

Schritt 3 — ROI berechnen: > ROI (%) = (Zeitersparnis − Gesamtkosten) / Gesamtkosten × 100

Erfahrungswert: Ein ROI von über 150 % im ersten Jahr gilt für viele Unternehmen als klarer Business Case für eine Weiterentwicklung zum Produktivsystem.

Branchen-Vignette: Öffentliche Verwaltung — KI-Dokumentation im Revisionsaudit

Behörde: Kommunales Amt für Stadtentwicklung (250 Mitarbeitende)

Situation: Nach einem positiven Pilotprojekt (KI-gestützte Bearbeitung von Bauantragsvorprüfungen) wurde eine Revision angeordnet. Die Prüferinnen und Prüfer verlangten Nachweise für: Welche KI-Systeme wurden genutzt? Auf welchen Daten basieren die Empfehlungen? Wer hat die Ausgaben geprüft?

Ergebnis ohne systematische Dokumentation: Die Revision dauerte 6 Wochen statt der geplanten 2 Wochen, da Informationen mühsam rekonstruiert werden mussten. Das Projekt wurde temporär ausgesetzt.

Ergebnis nach Einführung der DARE-Struktur (zweites Projekt): Revisionsdauer: 8 Tage. Alle verlangten Nachweise lagen im strukturierten Dokumentationsordner vor.

Impuls: In regulierten Umgebungen (Verwaltung, Medizin, Finanzwesen) ist eine lückenlose KI-Dokumentation kein optionales Feature, sondern eine Compliance-Anforderung.

Prompt-Box — UE 112: Automatische Projektdokumentation

Prompt:

Ich möchte eine strukturierte Projektdokumentation für mein KI-Projekt erstellen.



Projekttitel: [TITEL]

Zeitraum: [ZEITRAUM]

Beteiligte Personen: [PERSONEN/ROLLEN]



Folgende Informationen liegen vor:

- Problembeschreibung: [TEXT]

- Gewählter Ansatz: [TEXT]

- Erzielte Ergebnisse: [TEXT]

- Bekannte Schwächen / Einschränkungen: [TEXT]



Bitte erstelle eine vollständige Projektdokumentation nach der DARE-Struktur:

- D: Design (Problem, Scope, Ziele)

- A: Approach (Methode, Tools, Begründung, verworfene Alternativen)

- R: Results (Ergebnisse mit Beispielen, Metriken)

- E: Evaluation (Stärken, Risiken, nächste Schritte)



Füge außerdem einen einseitigen Executive Summary am Anfang hinzu.

Stil: sachlich, professionell, für nicht-technische Entscheidungsträgerinnen und -träger verständlich.

Einsatz: Teilnehmende verwenden diesen Prompt, um ihre handschriftlichen Notizen und Prototyp-Erfahrungen in eine strukturierte Dokumentation zu überführen, die als Basis für die Projektarbeit dient.

Reflexionsfragen

Was wäre das Schlimmste, das passieren könnte, wenn Ihr Projekt nicht dokumentiert ist und Sie in drei Monaten krank werden? Wer könnte weitermachen?

Welche drei Erkenntnisse aus Ihrer Prototyping-Phase sind so wertvoll, dass sie unbedingt festgehalten werden sollten — auch als Warnung für andere?

Wie würden Sie Ihrer Vorgesetzten oder Ihrem Vorgesetzten in 2 Minuten erklären, warum Ihre KI-Lösung funktioniert und wann sie an ihre Grenzen stößt?

Kurzreferenz: Pflichtbestandteile der Projektarbeit

Eine vollständige Projektarbeit enthält mindestens folgende Bestandteile:

Praxis-Tipp: Schreiben Sie den Executive Summary zuletzt — er ist das Erste, was die Prüfungskommission liest.

Hinweise für AI Champions — So vermitteln Sie das Thema — UE 112

Timing (45 Min): 5 Min Einstieg, 10 Min Lerntext (Evaluations-Framework, KPI-Schätzung), 20 Min Übung 1 (Evaluation), 5 Min Übung 2 (Wirtschaftlichkeit skizzieren), 5 Min Trainer-Coaching-Runde.

Methodische Empfehlung: Schreibworkshop-Format — der Trainer ist Coach, kein Frontvortragender. Klare Zeitvorgaben für die Schreibphasen helfen. Zwischenruf nach 10 Minuten: „Haben alle die Akzeptanzrate berechnet?”

Häufige Stolpersteine: (a) Nur Stärken dokumentieren, Schwächen weglassen — explizit auf Prüfungsrelevanz der Grenzen-Beschreibung hinweisen. (b) KPI-Schätzung ohne Vorbehalt — immer den Satz einfordern: „wenn diese Ergebnisse reproduzierbar sind…“. (c) Wirtschaftlichkeit weglassen — Kapitel 7 ist prüfungsrelevant (4 Punkte Gesamtnote).

Tipp zur Branchenauswahl: Für Gruppen aus der Finanzdienstleistung eignet sich die Versicherungs-Vignette als konkretes Beispiel für komplexe Compliance-Anforderungen. Für öffentliche Verwaltung zeigt die Verwaltungs-Vignette den Umgang mit Transparenzpflichten.

Übergang zur nächsten UE: „Kapitel 5–8 sind im Rohzustand — sehr gut. In UE 113 trainieren wir, wie Sie diese Arbeit in 10 Minuten überzeugend kommunizieren.”

Ergänzung — Bewertungsrelevante Dokumentationsstandards

Was “vollständige Dokumentation” bedeutet: Die Projektarbeit muss ohne zusätzliche Erklärungen des Autors verständlich sein. Das klingt selbstverständlich, ist es aber nicht — viele Teilnehmende schreiben für sich selbst, nicht für ein außenstehendes Publikum. Test: Geben Sie Ihre Arbeit einer Person, die Ihre Organisation nicht kennt. Versteht sie (a) das Problem, (b) warum KI die Lösung ist, (c) wie der Prototyp funktioniert, (d) ob das Projekt wirtschaftlich ist? Wenn die Antwort auf eine dieser Fragen “nein” ist, braucht dieses Kapitel mehr Kontext.

Tabellen als Strukturierungsinstrument: Tabellen reduzieren Wortanzahl und erhöhen Klarheit gleichzeitig. Empfohlene Tabellen für die Projektarbeit: (a) In/Out-Matrix (Scope), (b) Stakeholder-Grid (Interesse × Macht), (c) KPI-Tabelle (Ist-Wert, Ziel-Wert, Messmethode), (d) Risikoregister (Risiko, Wahrscheinlichkeit, Auswirkung, Maßnahme), (e) Governance-Checkliste (Anforderung, Status, Maßnahme). Fünf Tabellen sind ausreichend für eine vollständige Projektarbeit — mehr verwässert die Wirkung.

Die wirtschaftliche Argumentation in der Prüfung: Die häufigste Schwäche im Wirtschaftlichkeitskapitel ist das Fehlen einer Gegenüberstellung: Kosten werden beschrieben, Nutzen wird beschrieben, aber die Gegenüberstellung und Schlussfolgerung fehlt. Vollständige Wirtschaftlichkeitsargumentation: “Die Gesamtinvestition beträgt [X Euro]. Der jährliche Nutzen beträgt [Y Euro]. Der Break-Even liegt bei [Z Monaten]. Da [Bedingung], bewerten wir den Use-Case als wirtschaftlich [positiv/mit Einschränkungen/nicht empfehlenswert].” Diese vier Sätze sind die Minimalstruktur für ein vollständiges Wirtschaftlichkeitskapitel.

Merksatz

Wirtschaftlichkeit bedeutet nicht nur Kostenersparnis. Qualitätsverbesserung, Kapazitätsgewinn, Fehlerreduzierung und Mitarbeiterzufriedenheit sind ebenfalls legitime Nutzenkategorien — solange sie quantifiziert oder zumindest plausibel geschätzt werden.

Abschluss-Checkliste für die Projektarbeit:

Lerntext-Vertiefung — Evaluation, Dokumentation und Abschluss der Projektarbeit

Evaluations-Design: Vor der Auswertung festlegen: Ein häufiger Fehler bei der Evaluation: Das Bewertungskriterium wird nach der Beobachtung des Ergebnisses festgelegt — was zu Confirmation Bias führt. Professionelle Evaluationen definieren die Erfolgskriterien vor dem Test. Für die Projektarbeit bedeutet das: Die KPIs und Erfolgsgrenzen (z. B. “Genauigkeit über 85 % = ausreichend”, “über 90 % = gut”, “über 95 % = sehr gut”) werden im Canvas-Feld 7 festgelegt — bevor der Prototyp gebaut und getestet wird.

Drei-Ebenen-Auswertung im Prüfungskontext: Die drei Evaluationsebenen (technisch, Nutzererfahrung, Geschäftswert) müssen in der Projektarbeit nicht alle gleich ausführlich behandelt werden. Empfehlungen je nach Prototyp-Typ: Für technische Prototypen (Custom GPT, n8n): Ebene 1 ausführlich, Ebene 2 und 3 mindestens skizziert. Für Konzept-Prototypen: Ebene 2 und 3 ausführlich, Ebene 1 als hypothetische Abschätzung. Für PoC: Ebene 1 und 3 ausführlich, Ebene 2 optional.

Das Reflexionskapitel schreiben — eine Vorlage: Das Reflexionskapitel (Kap. 8) kann auf folgendem Template aufbauen:

Abschnitt 1 — Ergebnis-Zusammenfassung: “Der Prototyp hat [X von Y Erfolgskriterien] erreicht. Besonders stark war [Aspekt 1]. Nicht wie erwartet funktioniert hat [Aspekt 2].”

Abschnitt 2 — Lernreflexion: “Die überraschendste Erkenntnis war [Erkenntnis]. Das verändert mein Verständnis von [KI-Konzept], weil [Begründung].”

Abschnitt 3 — Methodische Reflexion: “Wenn ich das Projekt wiederholen würde, würde ich [konkretes Element] anders angehen, weil [Begründung].”

Abschnitt 4 — Transfer-Empfehlung: “Für Organisationen in ähnlichem Kontext empfehle ich [Empfehlung], weil [Begründung]. Diese Empfehlung gilt nicht für Kontexte, in denen [Einschränkung].”

Abschluss-Checkliste — 48 Stunden vor Abgabe: In den letzten 48 Stunden vor der Abgabe der Projektarbeit sind drei Aktivitäten wichtiger als weiteres inhaltliches Schreiben: (a) Strukturprüfung: Sind alle acht Pflichtkapitel vorhanden und vollständig? (b) Kohärenz-Check: Folgt Kapitel N logisch aus Kapitel N-1? Gibt es inhaltliche Widersprüche? (c) Formale Prüfung: Rechtschreibung, Quellenangaben (mindestens fünf Quellen), einheitliche Formatierung, korrekter Deckblattinhalt.

Merksatz

Die Projektarbeit ist kein Abschlussbericht über das Perfekte — sie ist ein ehrlicher Bericht über das Gelernte. Eine reflektierte Analyse eines eingeschränkt erfolgreichen Prototyps zeigt mehr Kompetenz als eine übertriebene Erfolgsbeschreibung.

Governance-Dokumentation als Wettbewerbsvorteil: In der beruflichen Praxis ist die Governance-Dokumentation eines KI-Systems oft das, was Führungsentscheidungen für oder gegen einen Pilot entscheidet. Wer in der Projektarbeit ein vollständiges Governance-Kapitel vorlegt — EU AI Act Einordnung, Datenschutz-Assessment, interne Kontrollen — demonstriert nicht nur Prüfungskompetenz, sondern auch die Fähigkeit, KI-Projekte in realen Unternehmenskontexten zu verantworten.

Lerntext-Vertiefung II — KPI-Framework und Wirtschaftlichkeit für verschiedene Branchen

KPI-Design je nach Use-Case-Typ: KPIs sind nicht universell — sie müssen zum Use-Case passen. Drei KPI-Typen für typische KI-Projekte:

Zeit-KPIs: Messen die Reduktion von Bearbeitungszeit. Beispiel: “Durchschnittliche Bearbeitungszeit pro Ticket von 12 auf 4 Minuten.” Vorteil: leicht messbar. Nachteil: erfasst nicht Qualitätsänderungen.

Qualitäts-KPIs: Messen die Reduktion von Fehlern oder die Verbesserung der Ausgabequalität. Beispiel: “Fehlerquote bei Rechnungszuordnung von 9 % auf 1,5 %.” Vorteil: direkt mit Kosten verbindbar. Nachteil: erfordert Baseline-Messung vor Pilot-Start.

Kapazitäts-KPIs: Messen die Bearbeitungskapazität mit gleichen Ressourcen. Beispiel: “Bearbeitung von 200 statt 80 Fälle pro Mitarbeiter pro Tag.” Vorteil: zeigt Skalierungspotenzial. Nachteil: kann als “Weniger Jobs” missverstanden werden — kommunikativ sorgfältig einbetten.

Wirtschaftlichkeit nach Branchen:

IT-Dienstleistung: Hauptnutzen oft Geschwindigkeit (schnellere Angebotserstellung, kürzere Support-Antwortzeiten) und Qualitätssteigerung (weniger Fehler in Dokumentationen). KPI-Empfehlung: Bearbeitungszeit je Prozessschritt, Wiederholungsrate bei Support-Anfragen.

Industrie und Fertigung: Hauptnutzen oft Fehlerreduzierung (weniger Nacharbeit, weniger Ausschuss) und präventive Wartung (weniger ungeplante Ausfallzeiten). KPI-Empfehlung: Ausschussrate, Mean Time Between Failures (MTBF), Wartungskosten pro Einheit.

Finanzdienstleistung: Hauptnutzen oft Compliance-Effizienz (schnellere Dokumentationsprüfung, automatisierte Plausibilitätsprüfungen) und Risikoreduktion. KPI-Empfehlung: Prüfungszeit je Vorgang, Compliance-Findings pro Quartal.

Öffentliche Verwaltung: Hauptnutzen oft Bürgerservice (schnellere Bearbeitung von Anfragen, besser verständliche Antworten) und Effizienz (weniger Weiterleitungen, weniger Rückfragen). KPI-Empfehlung: Durchlaufzeit je Antrag, Kundenzufriedenheit (falls messbar), Weiterleitungsquote.

Wirtschaftlichkeit ohne Vollkosten-Kontrolle: Viele Teilnehmende haben keinen Zugang zu vollständigen Kostendaten ihrer Organisation. Das ist kein Hindernis für eine Wirtschaftlichkeitsbetrachtung — es erfordert transparente Schätzlogik. Empfohlene Quellen für Schätzungen: (a) Befragung von direkt Betroffenen: “Wie viele Stunden pro Woche verbringen Sie mit diesem Prozess?” (b) Branchen-Benchmarks: Für viele Standardprozesse gibt es veröffentlichte Benchmark-Daten (z. B. Fraunhofer-Institut, Bitkom-Studien). (c) Analoge Projekte: Wenn ähnliche Projekte in anderen Unternehmen Ergebnisse publiziert haben, sind diese als Referenz verwendbar.

Merksatz

Eine Wirtschaftlichkeitsbetrachtung mit transparenten Schätzungen und dokumentierten Annahmen ist wissenschaftlich redlicher — und prüfungsrelevanter — als eine ohne Schätzungen oder mit unkommentierten Zahlen.

Praxis-Handlungsfeld — Abgabe der Projektarbeit vorbereiten

Technische Abgabe-Vorbereitung: Klären Sie rechtzeitig: Welches Dateiformat wird für die Abgabe akzeptiert (Word, PDF, beides)? Gibt es eine Seitenanzahl-Begrenzung? Muss ein Deckblatt mit bestimmten Pflichtangaben vorhanden sein? Wie wird abgegeben (E-Mail, Upload-Plattform, persönlich)? Klären Sie diese formalen Anforderungen mindestens 48 Stunden vor der Deadline — nicht am Abgabe-Tag.

Qualitäts-Abschlusscheck mit drei Fragen: Vor der finalen Abgabe beantworten Sie drei Fragen: (1) “Könnte jemand, der meine Organisation nicht kennt, das Problem und die Lösung verstehen?” Wenn nein: Mehr Kontext in Kapitel 1 und 2. (2) “Hätte ich gerne jemanden neben mir, der diese Arbeit erklärt, wenn die Kommission liest?” Wenn ja: Die Arbeit ist noch nicht autonom verständlich. (3) “Bin ich selbst überzeugt, dass dieser Use-Case mit KI besser gelöst wird als ohne?” Wenn nicht: Das Reflexionskapitel ehrlich überarbeiten.

Prompt-Beispiel

Prompt: Wirtschaftlichkeitskapitel prüfen

Persona: Du bist ein kritischer Reviewer von KI-Projektarbeiten mit Schwerpunkt Wirtschaftlichkeit. Aufgabe: Prüfe das folgende Wirtschaftlichkeitskapitel und identifiziere: (a) Was ist stark, (b) Was fehlt, (c) Welche eine Verbesserung hat den größten Einfluss. Kontext: Die Projektarbeit wurde im Rahmen eines 120-UE-KI-Anwenderkurses erstellt. Bewertungskriterien: KPI-Abschätzung, Aufwand-Nutzen-Gegenüberstellung, Break-Even, Reflexion der Unsicherheit. Format: Drei Abschnitte: (a) Stärken, (b) Lücken, (c) Prioritäre Empfehlung. Einschraenkung: Keine allgemeinen Hinweise zur Wirtschaftlichkeit - nur auf den konkreten Text bezogen. Text: [Kapitel hier einfügen]

Abschluss-Betrachtung — Dokumentation als Kompetenznachweis

Die Qualität einer Projektarbeit spiegelt die Qualität des Denkprozesses wider. Wer ein Problem klar definiert, systematisch analysiert, plausibel löst und ehrlich reflektiert, demonstriert Kompetenzen, die über KI hinausgehen: analytisches Denken, Strukturierung komplexer Informationen, wirtschaftliches Urteil, Reflexionsvermögen. Diese Kompetenzen sind in jedem Berufskontext wertvoll.

Typische Schwächen in der Abschlussphase und wie man sie überwindet: Schwäche 1 — Fehlende Kohärenz: Problem in Kap. 1 und Lösung in Kap. 5 passen nicht zusammen, weil der Scope zwischendurch verändert wurde. Lösung: Vor der Abgabe einmal prüfen, ob jede Kapitelaussage noch zur Problemdefinition aus Kap. 1 passt.

Schwäche 2 — Übertriebene Erfolgsbeschreibung: “Das System ist fehlerfrei und vollständig skalierbar.” Prüfungskommissionen schätzen realistische Einschätzungen mehr als Marketingsprache. Stärken benennen, aber Grenzen ebenso klar kommunizieren.

Schwäche 3 — Fehlendes Reflexionskapitel: Kap. 8 besteht aus zwei Sätzen. Das ist verschenktes Bewertungspotenzial — und ein Zeichen, dass die Reflexion nicht ernst genommen wurde. Investieren Sie in Kap. 8 mindestens eine Seite.

Schwäche 4 — Quellenangaben fehlen oder sind unvollständig: Jede Behauptung, die nicht aus eigener Beobachtung stammt, braucht eine Quelle. Mindestens fünf Quellen für eine vollständige Arbeit. Empfohlene Quellen: EU AI Act (Primärquelle), NIST AI RMF, OWASP Top 10 LLMs, branchenspezifische Studien.

Letzte Prüfungsfrage an sich selbst: Bevor Sie abgeben, beantworten Sie diese Frage: “Wenn ich diese Arbeit in einem Jahr wieder lese, werde ich stolz darauf sein, sie eingereicht zu haben?” Wenn nein: Was ist der eine Punkt, der das ändern würde? Dieser eine Punkt ist Ihre letzte Überarbeitungspriorität.

Vertiefung II — Wirtschaftlichkeitsnachweis: Methoden und Grenzen

Der Nachweis der Wirtschaftlichkeit eines KI-Projekts ist eine der anspruchsvollsten Aufgaben in der Projektdokumentation. Dieser Abschnitt bietet einen vertieften Überblick über Methoden, ihre Anwendbarkeit und ihre Grenzen.

Warum Wirtschaftlichkeit schwer zu messen ist

KI-Projekte erzeugen Nutzen auf mehreren Ebenen, von denen viele schwer monetarisierbar sind. Eine einfache Kosten-Nutzen-Rechnung greift deshalb regelmäßig zu kurz. Typische Nutzendimensionen sind:

Direkter finanzieller Nutzen: Einsparungen durch Automatisierung, Umsatzsteigerung durch bessere Vorhersagen, Fehlervermeidung mit direkt messbaren Kosten. Dieser Nutzen ist am einfachsten zu quantifizieren.

Indirekter finanzieller Nutzen: Schnellere Entscheidungsprozesse führen zu besserer Marktreaktionsfähigkeit — dieser Effekt ist real, aber schwer einem einzelnen KI-Projekt zuzuordnen.

Strategischer Nutzen: Kompetenzaufbau, Lerneffekte, verbesserte Wettbewerbsposition. Dieser Nutzen ist langfristig bedeutsam, kurzfristig aber kaum messbar.

Qualitätsbezogener Nutzen: Bessere Kundenzufriedenheit, höhere Mitarbeiterzufriedenheit, weniger Fehler. Auch hier ist die monetäre Bewertung komplex.

Merksatz

Ein ehrlicher Wirtschaftlichkeitsnachweis benennt, was gemessen werden kann, und erklärt, was aus methodischen Gründen nicht gemessen wird. Schein-Präzision durch Schätzungen mit vielen Nachkommastellen wirkt nicht professioneller — sie macht die Analyse unglaubwürdiger.

Die drei Schätzmethoden im Vergleich

Wenn keine Produktivdaten vorliegen (was beim Prototyping die Regel ist), sind Schätzungen unvermeidlich. Drei Methoden haben sich bewährt:

Bottom-up-Schätzung: Einzelne Arbeitsschritte werden analysiert (Wie lange dauert Schritt X?), der KI-Beitrag pro Schritt wird geschätzt (KI reduziert Schritt X um Y %), und die Gesamtauswirkung wird aggregiert. Diese Methode ist aufwändig, aber nachvollziehbar und gut begründbar.

Benchmarking: Vergleichbare KI-Projekte in ähnlichen Organisationen liefern Referenzwerte. Der Vorteil ist die externe Validierung; der Nachteil ist, dass die Vergleichbarkeit oft eingeschränkt ist.

Expertenschätzung (Delphi-Methode): Mehrere Fachexperten schätzen unabhängig voneinander, die Schätzungen werden aggregiert und in Runden verfeinert. Gut geeignet, wenn keine Vergleichsdaten vorliegen, aber qualifiziertes Urteilsvermögen vorhanden ist.

Für die Projektarbeit im Kurs empfiehlt sich die Bottom-up-Schätzung, ergänzt durch eine Sensitivitätsanalyse: Wie verändert sich der Nutzen, wenn die Schätzungen um ±30 % variieren? Eine Nutzenaussage, die auch unter konservativeren Annahmen positiv bleibt, ist überzeugender als eine, die nur unter optimistischen Annahmen funktioniert.

Dokumentationsstandards für den Wirtschaftlichkeitsnachweis

Ein professioneller Wirtschaftlichkeitsnachweis in der Projektdokumentation umfasst typischerweise:

Ausgangssituation: Welcher Prozess wird optimiert? Was sind die aktuellen Kosten/Zeitaufwände?

Annahmen: Welche Schätzparameter wurden verwendet? Woher stammen die Referenzwerte?

Berechnung: Transparente, nachvollziehbare Kalkulation (keine Black Box).

Sensitivitätsanalyse: Was passiert bei abweichenden Annahmen?

Bewertung nicht-quantifizierbarer Nutzen: Explizite Nennung qualitativer Vorteile.

Investitionsrechnung: TCO (Total Cost of Ownership) für Implementierung, Betrieb und Weiterentwicklung.

Amortisationszeitraum: Wann wird der Break-even erreicht?

Merksatz

Wirtschaftlichkeitsnachweise für KI-Projekte müssen explizit mit Schätzungen und Annahmen arbeiten. Machen Sie diese transparent — das stärkt die Glaubwürdigkeit, nicht schwächt sie.

Typische Fehler im Wirtschaftlichkeitsnachweis

Drei Fehler sind besonders häufig: Erstens die Verwechslung von Effizienz und Effektivität — ein KI-System kann sehr effizient (schnell, fehlerfrei) sein, aber die falsche Frage beantworten. Zweitens das Vergessen von Implementierungskosten — der Aufwand für Datenvorbereitung, Testing, Training und Change Management wird systematisch unterschätzt. Drittens das Ignorieren von Opportunitätskosten — was könnte die Organisation mit denselben Ressourcen stattdessen erreichen?

Diese Fehler zu vermeiden erfordert keine komplexen Methoden, sondern vor allem die konsequente Anwendung des kritischen Denkens: Welche Annahme mache ich hier gerade — und wie gut ist sie begründet?

Weiteres Vertiefungsmodul — Dokumentation als Kommunikation

Dokumentation wird oft als administrative Pflichtübung wahrgenommen. Dieser Blickwinkel verkennt ihre eigentliche Funktion: Dokumentation ist Kommunikation mit der Zukunft. Wer in sechs Monaten das Projekt weiterführt, übergeben oder skalieren will, ist auf eine gute Dokumentation angewiesen.

Für KI-Projekte gilt dies in besonderem Maße, weil die Komplexität der Systeme und die Schnelllebigkeit des Felds eine präzise Dokumentation der Designentscheidungen unverzichtbar machen. Warum wurde Modell A und nicht Modell B gewählt? Welche Daten wurden ausgeschlossen und warum? Welche Vereinfachungen wurden im Prototyping akzeptiert?

Diese „Entscheidungsdokumentation” ist mindestens so wertvoll wie die technische Beschreibung des Systems selbst. Sie ermöglicht spätere Teams, Entscheidungen zu überprüfen, anzupassen oder zu revidieren — ohne bei null anfangen zu müssen.

Transferimpuls — Dokumentation als Wissensmanagement-Instrument

Die Projektdokumentation, die Sie im Rahmen dieses Kurses erstellen, ist mehr als ein Prüfungsdokument. Sie ist ein Beispiel dafür, wie Wissen in Organisationen systematisch festgehalten und zugänglich gemacht werden kann. Wissensmanagement — das systematische Erfassen, Strukturieren und Weitergeben von Organisationswissen — ist eine der wichtigsten Managementaufgaben im KI-Zeitalter.

KI-Projekte erzeugen besonders viel implizites Wissen: Warum hat ein Ansatz funktioniert, ein anderer nicht? Welche Dateneigenheiten haben das Modellverhalten beeinflusst? Welche Erkenntnisse aus dem Prototyping würden die nächste Iteration erheblich verbessern?

Dieses implizite Wissen zu externalisieren — in strukturierten Dokumenten, Entscheidungsprotokollen und Lessons-Learned-Formaten — ist eine der wertvollsten Leistungen, die ein KI-Praktiker für seine Organisation erbringen kann.

Merksatz

Wissen, das nur in den Köpfen der Projektbeteiligten existiert, ist für die Organisation verloren, sobald diese Personen das Team wechseln. Systematische Dokumentation ist deshalb kein bürokratischer Aufwand, sondern organisationale Wertschöpfung.

Vertiefung — Evaluation auf drei Ebenen: Ein strukturierter Rahmen

Die Evaluation des Prototyps ist der intellektuell anspruchsvollste Teil der Projektarbeit. Ein strukturiertes Evaluations-Framework hilft, die Qualität systematisch und nachvollziehbar zu dokumentieren.

Ebene 1 — Technische Qualität: Bewertet, ob der Prototyp das technisch tut, was er soll. Kernfrage: Wie konsistent und präzise sind die Ausgaben? Für Klassifikationsaufgaben: Accuracy, Precision, Recall, F1-Score. Für Generierungsaufgaben: Kohärenz, Faktentreue (Halluzinationsrate geschätzt), Formatkonformität. Für Extraktionsaufgaben: Vollständigkeit und Präzision der extrahierten Informationen. Methodik: Testen Sie mit mindestens fünf bis zehn repräsentativen Eingaben und dokumentieren Sie je Output.

Ebene 2 — Nutzererfahrung: Bewertet, ob der Prototyp von Menschen als nützlich und vertrauenswürdig erlebt wird. Methodik: kurze Befragung (3–5 Fragen auf einer Skala 1–5), Think-Aloud-Test mit einer anderen Person. Typische Kernfrage: „Was würde Sie vom regelmäßigen Einsatz abhalten?” Diese Frage deckt Adoptionsbarrieren auf, die in der technischen Analyse nicht sichtbar sind.

Ebene 3 — Geschäftlicher Mehrwert: Bewertet, ob der Prototyp das definierte Problem löst und einen messbaren Nutzen erzeugt. Kern: Vergleich Ist-Zustand (aus Canvas Feld 1) mit gemessenen oder geschätzten Werten nach Einsatz des Prototyps. Methodik: Stoppuhr-Vergleich, Zählung von Fehlern, Nutzerschätzung der Zeitersparnis.

Diese drei Ebenen entsprechen den Prüfungsanforderungen: Technische Qualität → Bewertungsbereich 3, Nutzererfahrung → Teilaspekt von 2 und 4, Geschäftlicher Mehrwert → Bewertungsbereich 4 (Wirtschaftlichkeit).

Merksatz

Evaluation ohne Testfälle ist Selbstlob. Definieren Sie vor der Evaluation mindestens fünf repräsentative Testfälle — mit erwartetem Ergebnis. Die Differenz zwischen erwartetem und tatsächlichem Ergebnis ist Ihre Evaluationsdaten.

Übung 3 — Wirtschaftlichkeitsrechnung Schritt für Schritt

Übung 3 — Wirtschaftlichkeitsrechnung für die Projektarbeit

Aufgabe: Führen Sie eine vollständige Wirtschaftlichkeitsrechnung für Ihren Use-Case in vier Schritten durch und dokumentieren Sie das Ergebnis als Kapitel 7 der Projektarbeit.

Material: Canvas-Feld 1 (Problem mit Zahlen), Prototyp-Evaluationsergebnisse, Taschenrechner

Schritt-für-Schritt: 1. Kosten erfassen: Entwicklungskosten (geschätzte Arbeitsstunden × Stundensatz), Infrastruktur (API-Kosten/Monat geschätzt), Schulungskosten, laufende Wartung (monatlich). 2. Nutzen quantifizieren: Zeitersparnis (Stunden/Monat × Stundensatz × Anzahl Nutzer), Fehlerreduktion (Fehler/Monat × Kosten je Fehler), Kapazitätsgewinn. 3. Break-Even berechnen: Gesamtinvestition ÷ monatlicher Nettonutzen = Break-Even in Monaten. 4. Sensitivitätsanalyse: Was ändert sich am Break-Even, wenn der Nutzen 20 % geringer ausfällt? Was wenn die API-Kosten um 50 % steigen? 5. Formulieren Sie das Ergebnis in drei Sätzen für Kapitel 7.

Erwartetes Ergebnis: Vollständige Wirtschaftlichkeitsrechnung mit Kosten, Nutzen, Break-Even und Sensitivitätsanalyse — als fertiger Kapitel-7-Beitrag.

Musterlösung (Ticket-Triage):

Kosten: Entwicklung 24 h × 40 €/h = 960 €; API-Kosten 30 €/Monat; Schulung 4 h × 40 €/h = 160 €; Gesamtinvestition Jahr 1 = 1.480 €. Nutzen: 2,5 h/Tag × 22 Tage × 35 €/h = 1.925 €/Monat. Break-Even: 1.480 / 1.925 = 0,77 Monate (ca. 3 Wochen). Sensitivität: Bei 20 % geringerem Nutzen (1.540 €/Monat): Break-Even = 0,96 Monate — weiterhin sehr attraktiv. Fazit: Die Investition amortisiert sich innerhalb eines Monats; selbst bei konservativsten Schätzungen ist der Return on Investment im ersten Jahr deutlich positiv.

Prompt-Beispiel

Prompt: Wirtschaftlichkeitsrechnung für KI-Projektarbeit

Persona: Du bist ein Controller mit Erfahrung in KI-Projekten. Aufgabe: Erstelle eine strukturierte Wirtschaftlichkeitsrechnung fuer einen KI-Prototyp auf Basis der folgenden Angaben. Kontext: Use-Case: [Kurzbeschreibung]. Zeitersparnis: [X Stunden/Monat]. Stundensatz: [Y Euro]. Anzahl Nutzende: [Z Personen]. Entwicklungskosten: [geschaetzt A Euro]. Monatliche Betriebskosten: [B Euro]. Format: Vier Abschnitte: Kostenaufstellung (einmalig + laufend) | Nutzenkalkulation (monatlich) | Break-Even-Berechnung | Sensitivitaetsanalyse (Nutzen -20 %, Kosten +30 %). Einschraenkung: Transparente Kennzeichnung aller Schätzwerte als solche. Kein optimistisches Bias.

Branchen-Vignette — Einzelhandel & E-Commerce

In einem mittelständischen Onlinehandel gehen täglich 200–350 Kundenanfragen ein — Bestellstatus, Retouren, Reklamationen, Produktfragen. Das Support-Team mit fünf Mitarbeitenden verbringt 60–70 % der Arbeitszeit mit Standardanfragen, die sich stark wiederholen. Eine Projektarbeit in diesem Kontext könnte sich auf die KI-gestützte Erstklassifizierung und Antwortentwurfserstellung konzentrieren: Der Assistent kategorisiert eingehende Anfragen, ruft den Bestellstatus aus dem ERP ab und generiert einen personalisierten Antwortentwurf, der vom Mitarbeitenden in 30 Sekunden geprüft und gesendet wird — statt in 5 Minuten manuell formuliert. Das Evaluations-Framework wäre hier dreistufig: Klassifizierungsgenauigkeit (technisch), Mitarbeiterzufriedenheit und wahrgenommene Qualität (Nutzererfahrung), Bearbeitungszeit und Kundenzufriedenheit (geschäftlicher Mehrwert). DSGVO-Relevanz: Bestelldaten sind personenbezogen — AVV mit KI-Anbieter und ERP-Integration erforderlich; AI-Act-Einordnung: minimales Risiko.

Quelle: KI-Wissensbasis von MindsMachines, Edition Juni 2026. Vollständige Fassung mit Anhängen und Musterlösungen: als PDF anfordern.