Proof of Concept: Ablauf, Kriterien, Grenzen
· DigifyNow
Ein Proof of Concept prüft genau eine technische Frage, zum Beispiel: Liest die KI unsere Lieferscheine zuverlässig aus? Oder: Liefert die Schnittstelle des ERP die Daten, die wir brauchen? Vorher legen Sie ein messbares Erfolgskriterium, eine feste Timebox von meist zwei bis vier Wochen und echte Testdaten fest. Am Ende steht eine Entscheidung, ob das Vorhaben weiterläuft, angepasst oder gestoppt wird. Ein fertiges Produkt kommt dabei nicht heraus. Der Code ist in der Regel Wegwerfcode.
Was ist ein Proof of Concept – und was ist er nicht?
Ein Proof of Concept (PoC) ist ein kleiner, zeitlich begrenzter Versuch. Er klärt, ob eine Idee technisch überhaupt funktioniert. Die Skala der Technology Readiness Levels (TRL) ordnet ihn ein. Die EU nutzt sie unter anderem in ihren Forschungsprogrammen, und dort heißt TRL 3 ausdrücklich „experimental proof of concept“. Das ist ein frühes Stadium: Die Kernfunktion ist nachgewiesen, aber noch nicht in der echten Betriebsumgebung. Ein Produkt im laufenden Einsatz steht erst auf TRL 9. Für Geschäftsführer heißt das: Mit einem PoC prüfen Sie, ob etwas technisch möglich ist. Ob Mitarbeiter es nutzen, ob es sich wirtschaftlich trägt oder ob es im Alltag stabil läuft, beantwortet er nicht. Bei DigifyNow steht deshalb am Anfang jedes PoC ein einziger Satz in der Form „Wir wollen wissen, ob …“. Lassen sich zwei solche Sätze nicht trennen, sind es zwei PoCs. Ein PoC hat keine Benutzerverwaltung, kein ausgefeiltes Design und keinen Betrieb. Wer das erwartet, will eigentlich einen Prototyp oder ein MVP.
| TRL | Bezeichnung (EU-Definition, sinngemäß) | Entspricht in der Praxis |
|---|---|---|
| 3 | Experimenteller Machbarkeitsnachweis | Proof of Concept |
| 4 | Technologie im Labor validiert | Klickbarer oder technischer Prototyp |
| 5–6 | Validiert bzw. demonstriert in relevanter Umgebung | Pilot mit echten Daten |
| 7 | Systemprototyp im Einsatzumfeld | MVP mit ersten Nutzern |
| 9 | System im Betrieb erprobt | Laufendes Produkt |
Was ist der Unterschied zwischen Proof of Concept, Prototyp und MVP?
Die drei Begriffe werden oft durcheinandergeworfen. Dabei beantworten sie unterschiedliche Fragen. Der Proof of Concept prüft die Machbarkeit: Funktioniert die Technik? Ein Prototyp prüft die Bedienung, also ob Nutzer verstehen, wie es geht. Er kann komplett ohne funktionierende Technik dahinter auskommen, etwa als klickbares Design-Modell. Ein MVP (Minimum Viable Product) ist dagegen echte, betriebsfähige Software mit dem kleinsten sinnvollen Funktionsumfang. Echte Nutzer arbeiten damit, und es braucht Hosting, Datensicherung und Wartung. Bei DigifyNow dauert ein MVP typischerweise 4–8 Wochen. Ein PoC ist deutlich kürzer, weil er alles weglässt, was nicht zur einen Prüffrage gehört. Wie Umfang und Dauer eines MVP zustande kommen, steht im Beitrag über MVP entwickeln lassen: Kosten und Dauer. Die Reihenfolge ist nicht fest. Ist die Technik bekannt, etwa ein Formular mit Datenbank, braucht es keinen PoC, und man fängt direkt mit dem Prototyp an. Hängt alles an einer unsicheren Schnittstelle oder einem KI-Modell, kommt der PoC zuerst.
Wann lohnt sich ein Proof of Concept – und wann nicht?
Ein PoC lohnt sich, wenn ein technisches Risiko das ganze Vorhaben kippen kann und sich günstig klären lässt, bevor das eigentliche Budget fließt. Typische Fälle sind: ein Altsystem ohne dokumentierte Schnittstelle, eine KI, die Freitext oder gescannte Belege verarbeiten soll, oder eine Echtzeit-Anbindung an Maschinen oder Kassensysteme. In unserer Projektpraxis lohnt sich ein PoC dagegen oft nicht, und dann raten wir auch ab:
- Die Technik ist Standard, zum Beispiel ein CRM-Backoffice mit Formularen, Listen und Rollen. Hier ist nur unsicher, ob der Ablauf passt, und das klärt ein Prototyp.
- Die eigentliche Frage ist fachlich oder organisatorisch: Wer pflegt die Daten, wer gibt frei? Dafür braucht es eine Prozessanalyse, keinen Code.
- Die Entscheidung steht ohnehin fest. Ein PoC, dessen Ergebnis niemand ernst nimmt, ist teure Beschäftigung.
- Es gibt keine echten Testdaten. Ein PoC mit ausgedachten Beispielen beweist fast nichts.
- Der Anbieter einer Schnittstelle sagt die Funktion verbindlich zu und dokumentiert sie. Dann reicht oft ein Blick in die API-Dokumentation.
Ob der Ablauf überhaupt klar genug ist, zeigt eine Prozessanalyse mit Vorlage und Beispiel meist schneller als jeder Testcode.
Wie läuft ein Proof of Concept bei DigifyNow ab?
DigifyNow baut einen PoC in fünf Schritten auf. Die Parameter werden vor dem ersten Code schriftlich festgelegt, damit das Ergebnis später nicht nach Gefühl beurteilt wird:
- Prüffrage formulieren: genau eine Frage, die mit Ja oder Nein beantwortet werden kann, zum Beispiel „Können wir Aufträge aus dem bestehenden ERP per Schnittstelle lesen?“
- Erfolgskriterium festlegen: eine messbare Schwelle, etwa „mindestens 45 von 50 echten Belegen ohne Nacharbeit korrekt erfasst“. Die Zahl legen Sie fest, nicht wir.
- Testdaten bereitstellen: echte, aber möglichst pseudonymisierte Daten in einer Menge, die die Bandbreite des Alltags abbildet, auch die unsauberen Fälle.
- Timebox setzen: meist zwei bis vier Wochen mit festem Enddatum. Ist die Zeit um, wird ausgewertet, auch wenn das Ergebnis unvollständig ist.
- Entscheidung dokumentieren: weiter, anpassen oder stoppen. Dazu gehört eine kurze Notiz, was gelernt wurde und welche Risiken offen bleiben.
Das Ergebnis ist kein Bildschirm zum Vorzeigen, sondern ein Befund. Oft ist es ein Skript, ein Testprotokoll und eine Seite Text. Wie es nach einem positiven Befund weitergeht, also Konzept, Sprints und Abnahme, steht in unserem Beitrag dazu, wie ein Softwareprojekt abläuft.
Wie sieht ein Proof of Concept für ein KI-Projekt aus?
Bei KI ist der PoC besonders wichtig, weil Sprachmodelle nicht deterministisch arbeiten. Dieselbe Eingabe kann unterschiedliche Ausgaben liefern. Ein einzelner gelungener Versuch in einer Demo beweist daher wenig. DigifyNow prüft KI-Vorhaben deshalb gegen ein festes Testset: eine Sammlung echter Fälle aus Ihrem Betrieb, zum Beispiel E-Mails, Angebote oder Lieferscheine, jeweils mit dem richtigen Ergebnis daneben. Jede Version des Prompts oder der Modellwahl läuft gegen dasselbe Set. So sieht man, ob eine Änderung etwas verbessert oder nur einen Fall repariert und zwei andere kaputt macht. Gemessen wird, was für den Ablauf zählt: Wie viele Fälle sind korrekt, wie viele brauchen Nacharbeit, wie viele sind falsch, ohne dass es auffällt? Die letzte Gruppe ist die gefährlichste. Sobald personenbezogene Daten an einen externen KI-Dienst gehen, verlangt Art. 28 DSGVO einen Vertrag zur Auftragsverarbeitung mit diesem Dienstleister. Ob er vorliegt und reicht, klären Sie mit Ihrem Datenschutzbeauftragten. Was nach einem erfolgreichen Test folgt, beschreibt unser Beitrag dazu, wie Sie einen KI-Assistenten im Unternehmen einführen.
Warum scheitern Proofs of Concept so oft?
Ein negatives Ergebnis ist kein Scheitern, sondern genau der Zweck: Sie wissen nach wenigen Wochen, was nicht geht, und nicht erst nach Monaten. Scheitern heißt, dass der PoC keine verwertbare Antwort liefert. Die Ursachen sind fast immer dieselben:
- Kein vorab festgelegtes Erfolgskriterium: Am Ende diskutiert man über Eindrücke statt über Zahlen.
- Schönwetter-Testdaten: Getestet wird nur mit sauberen Beispielen. Krumme Scans, handschriftliche Notizen oder Sonderfälle fehlen, und im Alltag bricht dann alles ein.
- Schleichender Umfang: Nebenbei kommen Login, Design und Export dazu, die Timebox reißt, und die Kernfrage bleibt offen.
- PoC wird zum Produkt: Der schnell geschriebene Testcode geht ohne Fehlerbehandlung, Tests und Absicherung in den Betrieb.
- Falsche Umgebung: Getestet wird gegen eine Testinstanz, deren Daten oder Rechte nicht der Produktion entsprechen.
Der vierte Punkt ist der teuerste. Code aus einem PoC ist darauf gebaut, eine Frage schnell zu beantworten, nicht darauf, jahrelang zu laufen. DigifyNow übernimmt aus einem PoC deshalb in der Regel die Erkenntnisse und einzelne geprüfte Bausteine, etwa die Logik einer Schnittstellenabfrage. Den Rest schreiben wir für das MVP sauber neu. Das sagen wir vorher an, damit niemand von einer fertigen Software ausgeht, nur weil etwas auf dem Bildschirm funktioniert hat.
Häufige Fragen
Was heißt Proof of Concept auf Deutsch?
Auf Deutsch heißt Proof of Concept Machbarkeitsnachweis. Gemeint ist ein kurzer, abgegrenzter Versuch, der eine einzelne technische Frage beantwortet. Auf der Skala der Technology Readiness Levels der EU entspricht das TRL 3, dem experimentellen Machbarkeitsnachweis. Ein betriebsfähiges Produkt steht dagegen auf TRL 9.
Wie lange dauert ein Proof of Concept?
Bei DigifyNow begrenzen wir einen PoC meist auf zwei bis vier Wochen, mit festem Enddatum. Ein MVP dauert typischerweise 4–8 Wochen. Wie lange ein konkreter PoC dauert, hängt von der Prüffrage und davon ab, wie schnell Testdaten und Zugänge zu Schnittstellen bereitstehen. Eine verbindliche Dauer lässt sich erst nach einer Einschätzung nennen.
Was ist der Unterschied zwischen PoC und MVP?
Ein PoC prüft, ob etwas technisch machbar ist, und ist meist nach der Auswertung erledigt. Ein MVP ist echte Software mit dem kleinsten sinnvollen Funktionsumfang, die von Nutzern im Alltag verwendet wird. Deshalb braucht es Hosting, Datensicherung und Wartung. Der PoC liefert eine Entscheidung, das MVP liefert ein nutzbares Werkzeug.
Kann man den Code aus einem Proof of Concept weiterverwenden?
Teilweise. Geprüfte Bausteine wie eine Schnittstellenabfrage oder ein Prompt mit Testset lassen sich übernehmen. Der Rest ist darauf gebaut, schnell eine Frage zu beantworten: Fehlerbehandlung, automatisierte Tests, Rechtekonzept und Protokollierung fehlen meist. Wer diesen Code ungeprüft in den Betrieb nimmt, baut auf einem Fundament, das dafür nie gedacht war.
Welche Testdaten braucht ein Proof of Concept?
Echte Daten aus dem Betrieb, die die normale Bandbreite abbilden, also auch schlechte Scans, unvollständige Angaben und Sonderfälle. Personenbezogene Daten sollten nach Möglichkeit pseudonymisiert werden. Art. 4 Nr. 5 DSGVO definiert Pseudonymisierung als Verarbeitung, bei der Daten ohne zusätzliche, getrennt aufbewahrte Informationen keiner Person mehr zugeordnet werden können.