AI-Projekte erfolgreich planen — Von der Idee zum Go-Live

Laut einer Studie von Gartner erreichen nur 53 % aller AI-Projekte den Weg von der Pilotphase in die Produktion. Mehr als jedes dritte Projekt wird vorzeitig abgebrochen — nicht wegen technischer Unmöglichkeit, sondern wegen organisatorischer Fehlplanung. In unserer Projektpraxis bei cierra erleben wir dieses Muster regelmäßig: Unternehmen investieren sechsstellige Beträge in AI-Initiativen und stehen nach sechs Monaten mit einem Proof of Concept da, der nie produktiv wird.

Dieser Leitfaden ist kein akademisches Framework. Er ist das Destillat aus über 60 AI-Projekten, die wir in den letzten Jahren begleitet haben — vom mittelständischen Fertigungsunternehmen bis zum internationalen Finanzdienstleister. Wir haben gesehen, was funktioniert, und — ehrlich gesagt — auch, was nicht funktioniert.

Warum AI-Projekte fundamental anders sind

Wenn Sie als Projektleiter aus der klassischen IT kommen, bringen Sie wertvolles Handwerkszeug mit. Aber Sie müssen umdenken. Ein ERP-Rollout hat eine klare Zielvorgabe: Das System funktioniert, oder es funktioniert nicht. Bei einem AI-Projekt gibt es dagegen ein Kontinuum von Ergebnissen. Ihr Modell erreicht vielleicht 87 % Genauigkeit statt der erhofften 95 %. Ist das ein Erfolg? Ein Misserfolg? Die Antwort hängt vollständig davon ab, wie Sie Ihre Erfolgskriterien im Vorfeld definiert haben.

Die fünf fundamentalen Unterschiede, die Sie kennen müssen:

1. Ergebnisoffenheit: Bei klassischen IT-Projekten wissen Sie vorher, was rauskommt. Bei AI-Projekten wissen Sie es erst, wenn Sie mit den Daten gearbeitet haben. Es ist möglich, dass die gewünschte Lösung mit den verfügbaren Daten schlicht nicht erreichbar ist — und das erfahren Sie unter Umständen erst nach Wochen der Arbeit.

2. Daten als Bottleneck: In einem klassischen Softwareprojekt ist der Code das Produkt. In einem AI-Projekt sind es die Daten. 60–80 % der Projektzeit fließen in Datenbeschaffung, -bereinigung und -aufbereitung. Ein häufiger Fehler, den wir beobachten: Projektpläne, die 70 % der Zeit für Modellentwicklung vorsehen und 10 % für Daten. Die Realität ist genau umgekehrt.

3. Iterative Natur: AI-Projekte sind keine Wasserfallprojekte mit drei Iterationen. Sie sind eher mit wissenschaftlichen Experimenten vergleichbar. Sie formulieren eine Hypothese ("Dieses Feature verbessert die Vorhersagequalität"), testen sie, und passen Ihren Kurs an. Das erfordert ein fundamental anderes Stakeholder-Management: Ihre Auftraggeber müssen verstehen, dass "Experiment fehlgeschlagen" nicht "Projekt gescheitert" bedeutet.

4. Skill-Knappheit: Gute ML-Engineers sind rar und teuer. Ein Vollzeit-Senior-ML-Engineer kostet Sie zwischen 90.000 und 140.000 EUR Jahresgehalt — wenn Sie denn einen finden. Die Alternative, einen externen Partner wie cierra einzubinden, ist oft die wirtschaftlich und zeitlich sinnvollere Option.

5. Laufende Wartung: Ein klassisches IT-System braucht Updates und Patches. Ein AI-System braucht darüber hinaus regelmäßiges Retraining, weil sich die zugrunde liegenden Daten verändern. Dieses Konzept — Model Drift — ist vielen Entscheidern zu Projektbeginn nicht bewusst und führt zu bösen Überraschungen bei den Betriebskosten.

Was Sie aus diesem Leitfaden mitnehmen

Dieses Whitepaper führt Sie durch die fünf kritischen Phasen der AI-Projektplanung. Sie erhalten keine theoretischen Frameworks, sondern erprobte Templates, konkrete Checklisten und echte Praxisbeispiele. Nach der Lektüre sind Sie in der Lage, ein AI-Projekt realistisch zu scopen, die richtigen Leute an den Tisch zu bringen und einen Projektplan aufzusetzen, der der Realität standhält.

Praxis-Tipp: Lesen Sie diesen Leitfaden nicht von vorne bis hinten durch und legen ihn dann weg. Nutzen Sie ihn als Arbeitsdokument. Drucken Sie die Checklisten aus. Füllen Sie die Templates aus. Die größte Gefahr bei AI-Projekten ist nicht mangelndes Wissen, sondern mangelnde Disziplin in der Anwendung.

Für wen ist dieser Leitfaden?

• Projektleiter, die ihr erstes AI-Projekt verantworten
• Product Owner, die AI-Features in bestehende Produkte integrieren
• IT-Leiter und CTOs, die eine AI-Strategie operationalisieren möchten
• Geschäftsführer, die fundiert über AI-Investitionen entscheiden wollen

Die Anforderungsanalyse ist die Phase, in der über Erfolg oder Misserfolg des gesamten Projekts entschieden wird. Und paradoxerweise ist sie die Phase, die am häufigsten abgekürzt wird. "Wir wissen schon, was wir wollen" — diesen Satz hören wir bei cierra in jedem zweiten Erstgespräch. Und in fast jedem dieser Fälle zeigt sich nach zwei Wochen, dass die tatsächlichen Anforderungen fundamental anders aussehen als die ursprüngliche Vorstellung.

Das Problem Statement: Ihr wichtigstes Dokument

Bevor Sie auch nur einen Gedanken an Technologie, Modelle oder Tools verschwenden, brauchen Sie ein sauberes Problem Statement. Kein Pitch Deck, kein Visionsdokument — ein nüchternes, präzises Problem Statement, das auf eine Seite passt.

Ein häufiger Fehler, den wir beobachten: Das Problem wird technisch statt geschäftlich formuliert. "Wir brauchen ein NLP-Modell für Ticketklassifikation" ist kein Problem Statement. "Unsere Support-Mitarbeiter verbringen 35 % ihrer Zeit mit der manuellen Kategorisierung von Tickets, was zu einer durchschnittlichen Erstantwortzeit von 4,2 Stunden führt" — das ist ein Problem Statement.

Template: Problem Statement für AI-Projekte

PROBLEM STATEMENT
=================

Unternehmen:     [Name, Branche, Größe]
Erstellt am:     [Datum]
Version:         [1.0]
Verantwortlich:  [Name, Rolle]

1. IST-ZUSTAND
   Beschreiben Sie den aktuellen Prozess so konkret wie möglich.
   - Wie wird die Aufgabe heute erledigt?
   - Wer ist beteiligt? (Rollen, Anzahl Personen)
   - Wie lange dauert der Prozess? (pro Vorgang, pro Tag, pro Monat)
   - Welche Tools werden heute eingesetzt?

2. PROBLEM (QUANTIFIZIERT)
   - Was genau funktioniert nicht oder nicht gut genug?
   - Wie groß ist das Problem? (Kosten, Zeit, Fehlerquote, Kundenzufriedenheit)
   - Seit wann besteht das Problem?
   - Was wurde bereits versucht, um es zu lösen?

3. ZIEL-ZUSTAND (MESSBAR)
   - Was soll nach dem Projekt anders sein?
   - Welche konkreten Kennzahlen sollen sich um wie viel verbessern?
   - Bis wann soll das Ziel erreicht sein?

4. GESCHÄFTSWERT
   - Welchen finanziellen Wert hat die Lösung? (EUR/Jahr)
   - Welche nicht-finanziellen Vorteile gibt es?
   - Was passiert, wenn wir das Problem NICHT lösen?

5. RAHMENBEDINGUNGEN
   - Budget-Rahmen: [EUR]
   - Zeitrahmen: [Monate]
   - Compliance-Anforderungen: [DSGVO, branchenspezifisch]
   - Bestehende Systemlandschaft: [ERP, CRM, etc.]

Drei echte Problem Statements aus der Praxis

Beispiel 1: Fertigungsunternehmen (Qualitätskontrolle)

Ist-Zustand: Zwei Qualitätsprüfer inspizieren täglich 1.200 Bauteile visuell. Die Prüfung dauert durchschnittlich 18 Sekunden pro Teil. Fehlerhafte Teile werden in 94 % der Fälle erkannt.

Problem: Bei einer Fehlerquote von 6 % gelangen ca. 72 fehlerhafte Teile pro Tag in die Weiterverarbeitung. Jedes fehlerhafte Teil verursacht Folgekosten von durchschnittlich 85 EUR. Jährliche Kosten durch nicht erkannte Fehler: ca. 1,5 Mio. EUR.

Ziel: Erkennungsrate ≥ 99 % bei gleichbleibender Durchlaufzeit. Reduktion der Folgekosten um mindestens 80 %.

Beispiel 2: Finanzdienstleister (Dokumentenverarbeitung)

Ist-Zustand: Ein Team von 8 Sachbearbeitern verarbeitet täglich 400 eingehende Dokumente (Verträge, Anträge, Korrespondenz). Jedes Dokument wird manuell gelesen, klassifiziert und den relevanten Datenfeldern zugeordnet. Durchschnittliche Bearbeitungszeit: 12 Minuten pro Dokument.

Problem: Die manuelle Verarbeitung bindet 8 Vollzeitkräfte (Personalkosten: ca. 480.000 EUR/Jahr). Die Bearbeitungszeit von Anträgen liegt bei durchschnittlich 3,5 Werktagen. Kundenzufriedenheit im NPS: 32.

Ziel: Automatische Klassifikation und Datenextraktion für 80 % der Standarddokumente. Reduktion der manuellen Bearbeitungszeit auf 3 Minuten pro Dokument. Antrags-Bearbeitungszeit unter 1 Werktag.

Beispiel 3: E-Commerce (Personalisierung)

Ist-Zustand: Alle Kunden sehen auf der Startseite dieselben Produktempfehlungen, die wöchentlich manuell vom Marketing-Team gepflegt werden. Conversion Rate auf der Startseite: 2,1 %. Durchschnittlicher Warenkorbwert: 67 EUR.

Problem: Kunden, die nicht im Standard-Segment liegen, finden relevante Produkte erst nach durchschnittlich 4,7 Klicks. Die Absprungrate auf der Startseite liegt bei 58 %.

Ziel: Individualisierte Produktempfehlungen basierend auf Kaufhistorie und Browsing-Verhalten. Conversion Rate ≥ 3,5 %. Reduktion der Absprungrate auf unter 40 %.

Die Daten-Bestandsaufnahme: Was haben Sie wirklich?

Nachdem das Problem definiert ist, folgt die ehrlichste Übung im gesamten Projekt: die Dateninventur. Hier trennt sich die Spreu vom Weizen — und hier werden die meisten Illusionen zerstört.

Erfolgs-KPIs: Woran messen Sie, ob das Projekt gelungen ist?

Definieren Sie exakt drei KPIs — nicht mehr. Jede zusätzliche Metrik verwässert den Fokus. Und achten Sie darauf, dass mindestens einer Ihrer KPIs ein Business-KPI ist, kein technischer KPI. Ein Modell mit 99 % Accuracy, das niemand nutzt, ist wertlos.

Praxis-Box: Das "Kill Criterion" Definieren Sie zu Beginn des Projekts ein explizites Abbruchkriterium. Zum Beispiel: "Wenn nach Phase 1 die Datenqualität unter Score 2 liegt und keine realistische Möglichkeit besteht, sie in 4 Wochen auf Score 3 zu heben, stoppen wir das Projekt." Das klingt pessimistisch, spart Ihnen aber potenziell Hunderttausende Euro. In unserer Praxis bei cierra haben wir drei Projekte in Phase 1 gestoppt — und unsere Kunden waren dankbar dafür.

✅ Checkliste Anforderungsanalyse:

• Problem Statement ausgefüllt und vom Sponsor abgenommen
• Problem geschäftlich (nicht technisch) formuliert
• Ist-Zustand quantifiziert (Kosten, Zeit, Fehlerquoten)
• Zielwerte messbar und realistisch definiert
• Dateninventur durchgeführt (alle relevanten Quellen identifiziert)
• Datenqualität initial bewertet (Score 1-5 pro Quelle)
• DSGVO-Relevanz geprüft, Datenschutzbeauftragten eingebunden
• Maximal 3 KPIs definiert (mindestens 1 Business-KPI)
• Kill Criterion definiert und dokumentiert
• Budget-Rahmen grob abgesteckt
• Stakeholder identifiziert und informiert