KI Proof of Concept: In 6 Wochen von der Idee zur Entscheidung
Ein KI-Projekt zu starten ist einfach. Die schwierige Frage ist: Wird es funktionieren? Wird es sich rentieren? Wie wissen wir, ob wir 200.000 EUR in ein Full-Scale Deployment investieren sollten?
Die Antwort heißt Proof of Concept (PoC). Ein PoC ist ein Mini-Projekt, das in 4–8 Wochen zeigt: Ja, KI kann Ihr spezielles Problem lösen, und hier sind die wirtschaftlichen Zahlen.
Dieser Artikel führt Sie durch einen bewährten 6-Wochen-PoC-Prozess, zeigt häufige Fallstricke und erklärt, wie Sie am Ende eine klare Go/No-Go-Entscheidung treffen.
Warum ein Proof of Concept unverzichtbar ist
Viele Unternehmen springen direkt in Full-Scale KI-Projekte. Das ist riskant:
Szenario 1: Zu viel Ambition Plan: Wir implementieren KI Qualitätskontrolle für 50 Produktionslinien. Budget: 500.000 EUR, Timeline: 6 Monate.
Realität: Nach 3 Monaten stellt sich heraus, dass Ihre Kamerasysteme zu alt sind, die Lichtverhältnisse sind ungeeignet, Trainingsdaten sind unzureichend. Projekt wird 12 Monate, 1 Mio EUR, und funktioniert nicht richtig.
Szenario 2: Zu viel Hoffnung Plan: Predictive Maintenance wird unsere Wartungskosten um 50 % senken.
Realität: Euer Maschinenpark ist zu heterogen. Ein Modell funktioniert für Maschine A, versagt für Maschine B. Die reale Einsparung ist 15 %, nicht 50 %.
Ein PoC senkt dieses Risiko. Für 30.000–50.000 EUR und 6 Wochen Zeit findet Ihr heraus, ob die Idee funktioniert und was Sie realistisch erwarten können.
Die 6-Wochen-PoC Roadmap
flowchart TD
A["Woche 1-2:<br/>Scope & Datenvorbereitung"] --> B["Woche 3-4:<br/>Modellentwicklung & Training"]
B --> C["Woche 5-6:<br/>Validierung & Business Case"]
C --> D{"Go/No-Go<br/>Entscheidung"}
D -->|Go| E["Full-Scale Projekt planen"]
D -->|No-Go| F["Insights nutzen, anders anpassen"]
D -->|Bedingt| G["PoC Phase 2 mit Fokus<br/>auf offene Fragen"]
style A fill:#2E75B6
style B fill:#2E75B6
style C fill:#2E75B6
style E fill:#70AD47
style F fill:#C5504E
style G fill:#FFC000
Woche 1–2: Scope-Definition und Datenvorbereitung
Das Fundament eines erfolgreichen PoC ist Klarheit. Ambivalenz ist Ihr Feind.
Aufgaben:
Nutzen definieren (Very Specific)
- Nicht: „Wir wollen Machine Learning einsetzen"
- Sondern: „Wir wollen vorhersagen, welche Lager-SKU in den nächsten 30 Tagen abreißen werden, damit wir Nachbestellungen rechtzeitig platzieren"
Success Criteria aufschreiben
- Genauigkeit: Modell sollte mit 85+ % Genauigkeit vorhersagen
- Business Impact: Lagerumschlag sollte um mindestens 10 % steigen
- Umsetzbarkeit: Vorhersage muss wöchentlich verfügbar sein, nicht täglich
Datenquelle identifizieren und prüfen
- Wo ist die Daten? (ERP, Data Warehouse, Logs?)
- Welche Zeitspanne haben Sie? (Mindestens 3–6 Monate für Demand Forecasting)
- Qualität prüfen: Sind die Daten vollständig oder fehlen 30 % der Records?
Ein Sample-Dataset extrahieren
- Laden Sie die Roh-Daten herunter (CSV, JSON, Database Export)
- Kontrollierte Größe für schnelle Iteration (nicht 10 GB auf einmal, lieber 100 MB zuerst)
- Anonymisieren Sie, wenn nötig (DSGVO!)
Meilenstein Ende Woche 2: Sie haben ein 20-seitiges Scope-Dokument mit klar definierten Erfolgskriterien und einen bereinigten Datensatz.
Häufiger Fehler: Scope zu breit. „Wir wollen KI überall einsetzen" ist keine Scope. Fokussieren Sie auf einen einen kleinen, wertvollen Problem.
[[INTERNAL LINK: KI für Unternehmen]] zeigt 10 konkrete Use Cases mit gut definierten Scopes.
Woche 3–4: Modellentwicklung und Training
Jetzt baut das Data Science Team (intern oder Partner) das erste Modell.
Aufgaben:
Feature Engineering
- Rohe Daten → aussagekräftige Features
- Beispiel: Aus „Umsatz Tag X, Y, Z" erstelle „Durchschnittsumsatz letzte 7 Tage", „Trend", „Saisonalität", „Wochentag-Effekt"
Modellauswahl
- Mehrere Algorithmen testen (Regression, Gradient Boosting, LSTM, etc.)
- Welcher performt am besten auf Test-Daten?
Training und Validierung
- Daten teilen: 70 % Training, 30 % Test
- Overfitting-Check: Funktioniert Modell auf unsichtbare Daten oder hat es nur Training-Daten auswendig gelernt?
- Cross-Validation: Test auf unterschiedliche Zeitperioden (letzte Woche, letzter Monat, etc.)
Erste Ergebnisse
- Modell-Genauigkeit: 82 %? 91 %? Ist das gut genug für die Success Criteria?
- Fehleranalyse: Wo versagt das Modell? Bei neuen Produkten? Saisonalen Spitzen?
Meilenstein Ende Woche 4: Trainiertes Modell mit dokumentierter Genauigkeit und Fehleranalyse.
Häufiger Fehler: Synthetische Daten zum Training verwenden. Synthetische Daten sind „zu sauber", Modell funktioniert im Labor, nicht in der echten Welt.
Woche 5–6: Validierung, Fallstudien und Business Case
Jetzt wird es praktisch.
Aufgaben:
Backtest auf realen Szenarien
- Nicht nur: Modell-Genauigkeit war 85 %
- Sondern: Wenn wir dieses Modell vor 3 Monaten eingesetzt hätten, hätten wir X EUR gespart
Beispiel Demand Forecasting:
- Modell sagt: „Produkt A wird 100 Stück in Woche 31 verkaufen"
- Realität war: 102 Stück
- Fehler: 2 %, akzeptabel
- Einsparung: 5.000 EUR Lagerhaltung + 10.000 EUR Kapitalfreisetzung
Edge Cases testen
- Wie funktioniert das Modell bei Anomalien? (Pandemic? Naturkatastrophe? Viral TikTok?)
- Wenn Sie einen Black Swan erwartet, sollte die Lösung robust sein
Go-Live Simulation
- Nehmen Sie an, Modell läuft ab morgen in Production
- Wer sieht die Vorhersagen? Wie werden Sie aktioniert?
- Können Sie die Architektur in 4 Wochen bereitstellen?
Business Case kalkulieren
- PoC-Ergebnisse: Einsparungen, Umsatzsteigerung, Zeitersparnisse
- Hochrechnung auf Full Scale: 1 Produktlinie vs. 50 Produktlinien
- Investitionskosten für Full Scale
- ROI-Berechnung und Payback-Zeit
- Szenarioanalyse: Best Case, Base Case, Worst Case
Entscheidungsdokument erstellen
- 1 Seite Executive Summary
- Technisch machbar? (Ja, aber mit folgenden Herausforderungen)
- Wirtschaftlich sinnvoll? (Ja, 18 Monate Payback bei Best Case Szenario)
- Risiken und Mitigationen
Meilenstein Ende Woche 6: Go/No-Go Entscheidungsdokument mit klaren Zahlen.
Häufiger Fehler: Business Case mit zu hohen Hoffnungen. PoC zeigte 82 % Genauigkeit, aber Business Case rechnet mit 95 %. Nutzen Sie konservative Zahlen.
Go/No-Go Entscheidung: Framework
Nach Woche 6 treffen Sie eine Entscheidung. Nicht zwingend Ja oder Nein – es gibt auch „Bedingt":
GO ✓
Entscheidung: Geld für Full-Scale Projekt freigeben
Kriterien:
- Modell-Performance erfüllt Success Criteria (z. B. 85 % Genauigkeit)
- Business Case ist positiv (ROI > 100 %, Payback < 12 Monate)
- Technische Machbarkeit ist klar (keine großen Unbekannten)
- Team hat Capacity für nächste Phase
Nächste Schritte: Full-Scale Projekt mit klarem Budget, Timeline und Success Metrics planen.
NO-GO ✗
Entscheidung: Projekt auf Eis legen oder Pivot
Wann passt das:
- Modell-Performance war viel schlechter als erwartet (< 60 % Genauigkeit)
- Datenlage ist hoffnungslos (Daten sind zu rausch, zu spärlich, zu alt)
- Business Impact ist marginal (Einsparungen sind < 50.000 EUR/Jahr)
- Technische Barrieren sind zu hoch (Legacy Systeme, Datensilos, keine IoT Sensoren)
Nächste Schritte: Gelernte Erkenntnisse dokumentieren, anderes Use Case identifizieren. Nicht verloren Zeit – PoC hat 30.000 EUR gekostet, nicht 500.000 EUR.
CONDITIONAL ⚠️
Entscheidung: PoC Phase 2 mit reduziertem Scope
Wann passt das:
- Modell-Performance ist OK, aber nicht großartig (72 % Genauigkeit, braucht 80 %)
- Business Case ist marginal, aber könnte mit Scope-Änderung besser sein
- Technische Fragen sind offengelassen (Dataverfügbarkeit unklar, etc.)
Beispiel: Demand Forecasting PoC zeigte 75 % Genauigkeit für alle 500 SKU. In PoC Phase 2 konzentrieren Sie sich auf die Top-50 SKU (die 80 % des Umsatzes ausmachen). Modell braucht weniger Trainingsdaten, Genauigkeit steigt auf 88 %, Business Case wird besser.
Nächste Schritte: Klar definierte Phase-2-Frage, gleiche Timeline (6 Wochen), gleicher Budget (30.000 EUR).
Häufige Fallstricke in PoCs
Fallstrick 1: Zu viel Daten, Zu lange Timeline
PoC hat 6 Wochen. Wenn Data Preparation 4 Wochen dauert, bleibt 2 Wochen für Modellentwicklung. Das ist knapp.
Lösung: Reduzieren Sie Daten-Scope. Statt „alle Transaktion seit 2020" nehmen Sie „letzte 6 Monate Top 100 Produkte". Fokus auf Geschwindigkeit.
Fallstrick 2: Scope-Creep
„Lass mich auch Vorhersagen zu X, Y, Z machen. Ist ja nur eine Feature mehr."
6 Wochen sind weg. Modell ist halb-fertig.
Lösung: Strenge Scope. Schreiben Sie am Anfang auf: Was ist IN-SCOPE, was ist OUT-OF-SCOPE. OUT-OF-SCOPE-Anfragen dokumentieren Sie für Phase 2.
Fallstrick 3: Synthetische oder Test-Daten
Ihr Team sagt: „Echte Produktionsdaten sind schwer zu kriegen. Nutzen wir Test-Daten."
Modell trainiert auf sauberen Test-Daten, versagt auf echten, messigen Produktionsdaten.
Lösung: Echte Daten nicht verhandelbar. Wenn nötig: Anonymisieren, DSGVO-konform subsetzen, aber verwenden Sie echte Daten.
Fallstrick 4: Falsche KPI überwachen
Modell hat 90 % Genauigkeit (schön!), aber: In 20 % der Fälle sagt es False Negatives (missversteht kritische Probleme). Das ist schlecht.
Lösung: Definieren Sie explizit: Precision vs. Recall. Genauigkeit ist nicht alles.
Fallstrick 5: Keine Fehleranalyse
Modell erreicht 80 % Genauigkeit, alles looks gut, Sie gehen zu Full Scale. Später merken Sie: 80 % auf neue Produkte, 60 % auf alte. Modell war nicht generalizable.
Lösung: Detaillierte Fehleranalyse am Ende des PoC. Wo versagt das Modell? Segmentieren Sie nach Produkttyp, Zeit, Kundensegment, etc. Verstehen Sie die Blindspots.
PoC Budget und Timeline Realistisch
Typische Kostenstruktur eines 6-Wochen PoC:
| Item | Kosten |
|---|---|
| Data Science Team (6 Wochen, 1 Person) | 15.000–25.000 EUR |
| Data Engineer / Analytics (Datenvorbereitung) | 5.000–10.000 EUR |
| Cloud / Computing Resources | 2.000–5.000 EUR |
| Dokumentation & Reporting | 3.000–5.000 EUR |
| Total | 25.000–45.000 EUR |
Abhängig von: Komplexität der Daten, Verfügbarkeit von Expertise, ob intern oder extern.
Timeline: Nicht negotiable sind die 6 Wochen. Schneller ist möglich (4–5 Wochen), wenn Daten bereits sauber sind. Länger (8–12 Wochen) bedeutet, dass der PoC zu ambitious ist – Scope reduzieren.
Was nach einem erfolgreichen PoC kommt
Entscheidung: GO. Jetzt planen Sie Full-Scale Projekt.
Typischer Full-Scale Ablauf:
| Phase | Dauer | Budget | Output |
|---|---|---|---|
| Phase 1: Design & Architecture | 2–4 Wochen | 10.000–20.000 EUR | Technical Design Dokument |
| Phase 2: Development | 8–16 Wochen | 50.000–200.000 EUR | Production-ready System |
| Phase 3: Integration & Testing | 4–8 Wochen | 20.000–50.000 EUR | System läuft im Pilot |
| Phase 4: Rollout | 2–4 Wochen | 10.000–20.000 EUR | System läuft in Production |
| Phase 5: Monitoring & Improvement | Ongoing | 5.000–15.000 EUR/Monat | Continuous Improvement |
Total für Full Scale: 100.000–400.000 EUR über 6–9 Monate (abhängig von Komplexität).
Mit guten PoC-Ergebnissen können Sie stakeholders sagen: „Wir haben bewiesen, dass dies funktioniert. Jetzt brauchen wir EUR X für die Skalierung. ROI ist Z Monate, dann sparen wir Y EUR/Jahr."
Checkliste: PoC erfolgreich durchgeführt?
Am Ende des PoC sollten Sie diese Fragen mit JA beantworten können:
- Scope ist klar dokumentiert, nicht verschwommen
- Success Criteria sind explizit und messbar (nicht „das Modell sollte gut sein", sondern „85 % Genauigkeit")
- Trainingsdaten sind echte Produktionsdaten, nicht synthetisch
- Modell wurde auf Test-Daten validiert (nicht nur Training-Daten)
- Fehleranalyse wurde durchgeführt (wo versagt das Modell, warum?)
- Business Case ist konservativ kalkuliert (nicht optimistisch)
- Go/No-Go Entscheidungsdokument ist geschrieben
- Team hat Learnings dokumentiert für Full Scale
- Stakeholder haben verstanden, was funktioniert und was nicht
Wenn Sie alle abhaken, war der PoC erfolgreich – unabhängig vom Ergebnis (GO oder NO-GO).
Die häufigsten Fehler, die PoCs zum Scheitern bringen
Scope zu breit: „Wir wollen KI überall nutzen." Resultat: PoC scheitert, weil Fokus fehlt. Lösung: Ein Problem, ein Use Case, maximal 2.
Keine Geschwindigkeit: Datenbeschaffung dauert 8 Wochen, Modellentwicklung 4 Wochen, PoC ist um. Lösung: Pre-defined Timeline, 6 Wochen nicht verhandelbar.
Falsche Erwartungen: Stakeholder erwartet, dass PoC bereits Production-ready ist. Ist nicht, ist nur Proof. Lösung: Am Anfang klar kommunizieren: PoC ist zum Validieren, nicht zum Deployen.
Keine Executive Sponsor: PoC wird von einem Data Analyst gemacht, Manager wissen nicht, was läuft. Resultat: Go-Live ist blockiert, weil Budget freigegeben werden muss. Lösung: C-Level Sponsor von Anfang an, klare Escalations.
Zu wenig Budget: PoC hat 15.000 EUR, Data Scientist kostet 3.000 EUR/Woche. Nach 5 Wochen ist Budget weg, Modell halb-fertig. Lösung: Realistischer Budget, 25.000–45.000 EUR ist normal.
FAQ
Ist ein PoC immer notwendig, oder kann ich direkt in ein Full-Scale Projekt gehen?
Für komplexe Probleme (Predictive Maintenance, Demand Forecasting) sehr empfohlen. Für einfachere (Chatbots, Dokumentenverarbeitung) können Sie schneller gehen. Aber ein 6-Wochen PoC spart Ihnen am Ende 200.000 EUR Investition, die schiefgeht.
Was ist der Unterschied zwischen PoC und MVP?
- PoC (Proof of Concept): Zeigt, dass es technisch funktioniert. Nicht Production-ready. 6 Wochen, 30.000 EUR.
- MVP (Minimum Viable Product): Minimal funktionierende Version, die echte Nutzer können nutzen. Production-ready, aber minimalistisch. 16–24 Wochen, 100.000+ EUR.
Sie starten mit PoC, dann MVP, dann Full Scale.
Wie viele PoCs sollte ein Unternehmen parallel laufen?
Max 2–3. Jeder PoC braucht gute Data Scientists und Management-Aufmerksamkeit. Mit 5+ parallel laufen, fehlt die Fokus.
Was ist, wenn der PoC scheitert?
Das ist OK. Ein gescheiterter PoC ist nicht verloren. Sie haben 30.000 EUR ausgegeben und gelernt, dass dieser Weg nicht funktioniert. Besser als 500.000 EUR in ein Projekt zu stecken, das nicht klappt.
Können wir PoC Costs sparen, indem wir intern machen?
Ja, wenn Sie gute Data Scientists haben. Aber: Interne Kapazität ist knapp. Ein externer Partner (Agentur, Beratung) kann schneller, fokussierter, und ohne Ablenkung durch andere Projekte arbeiten.
Wie finde ich einen Partner für meinen PoC?
[[CTA: Kostenloses Beratungsgespräch vereinbaren → /de/kontakt]]

