Anforderungsmanagement als Kern von KI‑Projekterfolg — Überblick

Kernaussage: Gutes Anforderungsmanagement ist der wichtigste Erfolgsfaktor bei KI-Projekten in komplexen Umgebungen; klare Ziele, iteratives Verifizieren und enge Einbindung der Fachbereiche reduzieren Risiko, Zeitaufwand und Kosten.

Warum Anforderungsmanagement bei KI anders ist

KI-Projekte sind keine Softwareprojekte wie früher. Anforderungen sind oft unklar, Datenqualität entscheidet über Machbarkeit, und Modelle verändern Verhalten im Betrieb. Bei KMU entstehen zusätzliche Komplexitäten: begrenzte Ressourcen, heterogene IT-Landschaft und breite Rollenverteilung. Anforderungsmanagement muss diese Eigenschaften aktiv berücksichtigen. Beginnen Sie mit messbaren Zielgrössen (z. B. Genauigkeit, Auslieferzeit, Fehlerraten) statt mit technischen Wünschen. Definieren Sie die Erfolgskriterien vor dem Modelltraining.

Struktur: Rollen, Daten und Schnittstellen klar definieren

Legt fest, wer welche Verantwortung trägt: Fachverantwortlicher (Domäne), Datenverantwortlicher, Modellverantwortlicher, Betrieb/IT und Compliance. Dokumentiert Schnittstellen zu bestehenden Systemen, Datentransformationsregeln und erlaubte Datenquellen. Beispiel KMU: Die Produktion liefert Sensordaten, der Vertrieb Kundendaten; es braucht klare Regeln, wer Daten vorbereitet und wer sie freigibt. Ohne Rollen entsteht Stillstand beim Zugriff auf Trainingsdaten.

Anforderungsanalyse mit Fokus auf Daten und Messbarkeit

Erfasst Anforderungen in drei Ebenen: Geschäftswert (z. B. 20% weniger Ausschuss), Qualitätsmetriken (Precision/Recall, F1, Drift-Rate) und Umsetzungsrandbedingungen (Rechenressourcen, Datenschutz). Prüft die Datenverfügbarkeit früh durch eine «Data Readiness»-Prüfung: Stichproben, fehlende Werte, Labelqualität. Beispiel: Ein KMU plant vorausschauende Wartung. Die Anforderung «Fehler vorhersagen» wird konkret: Vorhersagehorizont 48 Stunden, Recall ≥ 0.85 bei FPR ≤ 0.1, Modelllaufzeit ≤ 500 ms pro Gerätegruppe.

Iteratives Vorgehen und Verifikation

Arbeitet iterativ: Hypothese formulieren, Prototyp bauen, messen, Anforderungen anpassen. Das reduziert Investitionen in ungeeignete Ansätze. Führt für jede Iteration Verifikationsschritte ein: Testdatensätze, Metriken, A/B-Tests im Live-Betrieb. Beispiel: Erste Iteration erreicht nur Recall 0.6 — statt grosse Architekturwechsel prüfen Sie zuerst Datenerweiterung, Labelverbesserung oder Feature-Engineering.

Compliance, Transparenz und Betriebssicherheit

Berücksichtigt Datenschutz und Nachvollziehbarkeit von Entscheidungen. Definiert, welche Erklärungen das Modell liefern muss (z. B. Feature-Attribution bei Entscheidung über Kreditfreigabe). Plant Monitoring für Modell-Drift, Fehlerraten und Datenverschiebung. Beispiel KMU: Ein Modell im Kundenservice muss innerhalb von 24 Stunden eine Begründung liefern, weshalb eine Anfrage priorisiert wurde, und Logs müssen 90 Tage aufbewahrt werden.

Typische Fehler und Korrekturen

Fehler: Vage Erfolgskriterien («besseres Modell»). Korrektur: Definiert messbare KPIs wie Genauigkeit, Recall, Durchsatz und Business-KPI (z. B. Kostenreduktion). Verbindet Modell-KPIs mit Geschäftszielen.

Fehler: Datenzugriff zu spät oder unvollständig. Korrektur: Führt eine Data-Readiness-Prüfung als erste Aktivität durch und plant Datenpipelines sowie Verantwortlichkeiten vor Modellbau.

Fehler: Keine Betriebsplanung (Monitoring, Updates). Korrektur: Plant Operationalisierung parallel zum Prototyp: Logging, Drift-Detection, Rollback-Prozesse und Verantwortliche für den Betrieb.

14–30-Tage-Handlungsanleitung (konkret und nummeriert)

Tag 1–2: Kick-off mit Stakeholdern. Bestimmt Rollen (Fach, Daten, Modell, IT, Compliance) und definiert ein erstes Business-Ziel in messbaren KPIs.

Tag 3–5: Data-Readiness-Check. Holt Stichproben, dokumentiert Quellen, Qualität, Bereinigungsbedarf. Schätzt Labelaufwand.

Tag 6–8: Anforderungen präzisieren. Legt Metriken, Erfolgskriterien und Grenzen (Latenz, Ressourcen, Datenschutz) fest. Dokumentiert Schnittstellen.

Tag 9–12: Prototyp-Plan erstellen. Wählt minimalen techn. Stack, Testdaten und Eval-Metriken; vereinbart Iterationslänge (z. B. 2 Wochen).

Tag 13–20: Erste Prototyp-Iteration. Entwickelt Proof-of-Concept, misst KPIs, dokumentiert Probleme und Abhängigkeiten.

Tag 21–24: Review mit Fachbereichen. Validiert Resultate gegen Geschäftsziel. Entscheidet: weiter iterieren, Datenanpassung oder Stopp.

Tag 25–30: Betriebsplanung und Risikomanagement. Legt Monitoring-Metriken, Alarmgrenzen, Rollback- und Update-Prozesse fest. Erstellt kurze Checkliste für Datenschutz und für Verantwortlichkeiten im Betrieb.

Kurz, präzise und iterativ arbeiten: Klare KPIs, frühe Datenprüfung und Betriebsplanung sind in KMU die Schlüssel zum Erfolg bei KI-Projekten in komplexen Umgebungen.