Proof of Concept (PoC), auf Deutsch Machbarkeitsnachweis, ist ein bewusst klein gehaltener Test, der zeigt, ob eine Idee, Technik oder Architektur unter realen Bedingungen funktionieren kann. Ein PoC beantwortet genau eine Frage: „Geht das überhaupt, und zwar so, wie wir es brauchen?“ Er ist kein Produkt, kein Prototyp für Nutzer und keine erste Ausbaustufe, sondern ein Erkenntnisinstrument.
In der Softwareentwicklung und bei Systemauswahlen im E-Commerce ist der PoC das wichtigste Mittel, um teure Fehlentscheidungen früh zu vermeiden. Wer eine neue Plattform, ein Framework oder eine Integration bewertet, kann Datenblättern, Demos und Referenzen glauben oder selbst prüfen, ob die kritischen Punkte im eigenen Umfeld tragen. Der PoC ist die zweite Option.
Was ein Proof of Concept ist und was nicht
Der Begriff wird oft schlampig verwendet. Ein PoC ist kein fertiges Teilprodukt. Er darf hässlich, unvollständig und nicht wartbar sein, solange er die Ausgangsfrage sauber beantwortet. Er wird typischerweise nach der Bewertung verworfen oder als Wissensgrundlage archiviert, nicht als Fundament für die Produktion weiterverwendet.
| Begriff | Leitfrage | Adressat | Qualitätsanspruch | Danach |
|---|---|---|---|---|
| Proof of Concept | Ist es technisch und fachlich machbar? | Projektteam, Entscheider | Gering, Wegwerfcode erlaubt | Entscheidung: weiter oder stoppen |
| Prototyp | Wie könnte es aussehen und sich anfühlen? | Nutzer, Stakeholder | Mittel, Fokus auf Bedienung | Feedback, Überarbeitung |
| Pilot | Funktioniert es im echten Betrieb mit echten Nutzern? | Ausgewählte Anwender | Hoch, produktionsnah | Rollout oder Korrektur |
| MVP | Lohnt sich das Produkt für den Markt? | Echte Kunden | Produktionsreif, aber klein im Umfang | Ausbau nach Marktrückmeldung |
Die Abgrenzung ist wichtig, weil die Begriffe unterschiedliche Erwartungen wecken. Wird ein PoC als MVP behandelt, gerät hastig geschriebener Testcode in die Produktion. Wird ein MVP als PoC verkauft, unterschätzen Beteiligte den Aufwand für Qualität, Sicherheit und Betrieb.
Woher der Begriff stammt
Der Ausdruck „proof of concept“ ist älter als die Softwarebranche und wird auch in der Wissenschaft, der Medizin und der Produktentwicklung verwendet. Gemeint ist überall dasselbe: der Nachweis, dass ein Prinzip prinzipiell funktioniert, bevor Zeit und Geld in die vollständige Umsetzung fließen. In der IT-Sicherheit hat der Begriff eine eigene Bedeutung. Dort bezeichnet ein PoC häufig Beispielcode, der eine Schwachstelle ausnutzt und damit belegt, dass sie real und ausnutzbar ist. Bekannte Sicherheitslücken wie Heartbleed (CVE-2014-0160) wurden durch öffentlich verfügbare PoC-Exploits für Verteidiger wie Angreifer greifbar.
Aufbau eines guten PoC
Ein PoC ohne klare Frage wird zum Bastelprojekt. Die folgenden Schritte haben sich für technische Bewertungen bewährt.
- Hypothese formulieren. Nicht „Wir testen Framework X“, sondern „Framework X kann unsere Preislogik mit kundenspezifischen Staffeln abbilden und dabei 200 Anfragen pro Sekunde bedienen.“ Eine überprüfbare Aussage ist die Voraussetzung für ein klares Ergebnis.
- Erfolgskriterien vorab festlegen. Was gilt als bestanden, was als gescheitert? Messbare Kriterien verhindern, dass das Ergebnis nachträglich schöngeredet wird.
- Umfang begrenzen. Nur die Risiken testen, nicht das Gesamtsystem. Die größten Unbekannten kommen zuerst, Standardfunktionen bleiben außen vor.
- Zeitrahmen setzen. Ein PoC ohne Frist läuft aus dem Ruder. Für technische Evaluierungen sind einige Wochen üblich, für kleinere Fragestellungen genügen Tage.
- Realistische Bedingungen schaffen. Echte Datenmengen, echte Schnittstellen, echte Randfälle. Ein PoC mit Spielzeugdaten beweist wenig.
- Ergebnis dokumentieren und entscheiden. Am Ende steht eine klare Empfehlung mit Begründung: weiter, anpassen oder stoppen. Auch ein gescheiterter PoC ist ein Erfolg, wenn er eine teure Fehlentscheidung verhindert.
Typische Fragen, die ein PoC im E-Commerce klärt
- Lässt sich unsere Preis- und Rabattlogik in der Zielplattform ohne Sonderlösungen abbilden?
- Wie robust ist die Anbindung an ERP und PIM bei realen Datenmengen und Fehlerfällen?
- Hält die Architektur den erwarteten Spitzenlasten stand, etwa in Aktionszeiträumen?
- Wie hoch ist der Aufwand für die Migration von Produkt- und Kundendaten?
- Können die Teams die neue Technik tatsächlich betreiben und erweitern?
Ein Beispiel: Plattformwahl im Mittelstand
Ein häufiger Anwendungsfall ist die Entscheidung für ein Commerce-Framework. Bei einem modularen, code-lastigen System wie MedusaJS liegt der Wert eines PoC darin, dass sich viele Eigenschaften erst im eigenen Kontext zeigen. Ein solcher PoC läuft üblicherweise über vier bis acht Wochen und hat einen festen Umfang: eine Standard-Storefront, ein Payment-Provider, eine ERP-Anbindung und ein klar definierter Anwendungsfall. Das Ziel ist nicht der fertige Shop, sondern eine belastbare Antwort darauf, ob das Framework unter den tatsächlichen Anforderungen wie versprochen funktioniert. Die Einordnung findest du im Beitrag zu MedusaJS.
Dabei zeigen sich häufig Punkte, die in Datenblättern fehlen: Lizenzgrenzen für Funktionen wie Rechteverwaltung oder Firmenanmeldung, der Aufwand für individuelle Preislogik, die Reife der Integrationen oder die Häufigkeit von Breaking Changes zwischen Releases. Ein PoC, der diese Punkte bewusst als Testfälle enthält, liefert Entscheidern mehr Substanz als jede Präsentation.
Ergebnisse auswerten und dokumentieren
Der Wert eines PoC entsteht erst durch die Auswertung. Sinnvoll ist ein kurzer Ergebnisbericht mit festem Aufbau: Ausgangsfrage, Vorgehen, Messwerte, beobachtete Probleme, Bewertung gegen die vorab festgelegten Kriterien und eine Empfehlung. Wichtig ist die Trennung von Beobachtung und Interpretation. „Der Import von 40.000 Artikeln dauerte 35 Minuten“ ist eine Beobachtung. „Das ist für unseren Nachtlauf ausreichend“ ist eine Bewertung, die sich an einem vorher definierten Fenster messen lassen muss.
Ebenso gehören offene Risiken in den Bericht. Kein PoC deckt alles ab. Was nicht getestet wurde, sollte ausdrücklich als ungetestet benannt werden, damit Entscheider den Restrisiko-Rahmen kennen. Bewährt hat sich eine einfache Ampellogik pro Hypothese: bestätigt, teilweise bestätigt, widerlegt. Bei teilweise bestätigten Hypothesen steht dabei, was für die Bestätigung noch fehlt und mit welchem Aufwand sich das prüfen lässt.
Kosten und Nutzen abwägen
Ein PoC kostet Zeit und Geld, und auch das gehört in die Rechnung. Als Orientierung hilft der Vergleich mit dem Risiko, das er abdeckt. Betragen die Kosten der Plattformentscheidung einen sechsstelligen Betrag über mehrere Jahre, ist ein PoC im niedrigen fünfstelligen Bereich eine geringe Versicherungsprämie. Bei kleinen, leicht umkehrbaren Entscheidungen lohnt der Aufwand dagegen selten. Die Faustregel: Je teurer und schwerer umkehrbar die Entscheidung, desto eher lohnt sich ein PoC.
Wichtig ist außerdem, wer die Kosten trägt. Bei externen Dienstleistern sollte der PoC als eigenständiges, klar beschriebenes Paket beauftragt werden, mit festem Umfang und festem Ende. Das schützt beide Seiten davor, dass aus einem Test unbemerkt ein Projekt wird.
Häufige Fehler
Der PoC wird zum Produkt. Der klassische Fehler: Der Test läuft gut, der Termindruck ist hoch, und der Code geht in die Produktion. Später zeigt sich, dass Architektur, Tests und Sicherheit nie vorgesehen waren. Die Regel lautet: Was als PoC entstanden ist, wird neu gebaut oder zumindest gründlich überarbeitet.
Kein definiertes Ende. Ohne Erfolgskriterien und Frist ist jeder PoC ein Dauerprojekt. Er verbraucht Ressourcen, ohne zu einer Entscheidung zu führen.
Falsche Fragen. Getestet wird, was leicht ist, nicht was riskant ist. Ein PoC, der nur den Happy Path zeigt, bestätigt lediglich, was ohnehin klar war.
Voreingenommenheit. Wird der PoC von Fürsprechern einer Lösung durchgeführt, fällt das Ergebnis oft freundlicher aus als die Realität. Kritische Fragen sollten von jemandem gestellt werden, der die Entscheidung nicht schon getroffen hat.
Überspringen des PoC. Der umgekehrte Fehler ist verbreitet. Wer direkt mit einem MVP beginnt, baut Architekturentscheidungen ein, die später nur schwer zu revidieren sind. Ein kurzer, fokussierter PoC ist in aller Regel günstiger als die Korrektur einer falschen Plattformwahl.
Wann ein PoC nicht die richtige Antwort ist
Nicht jede Unsicherheit verlangt einen Machbarkeitsnachweis. Ist die Technik ausgereift und in ähnlichen Umgebungen vielfach erprobt, genügt oft eine Referenzprüfung mit Gesprächen bei bestehenden Anwendern. Geht es vor allem um Bedienbarkeit, ist ein klickbarer Prototyp aussagekräftiger. Und wenn die eigentliche Frage lautet, ob Kunden das Angebot annehmen, hilft nur ein Test am Markt, etwa mit einem MVP. Der PoC ist das richtige Werkzeug, wenn ein konkretes technisches oder organisatorisches Risiko besteht, das sich mit begrenztem Aufwand isolieren und messen lässt. Fehlt dieses Risiko, ist er Beschäftigungstherapie mit Projektnamen.
PoC, Discovery und Ausschreibung
In größeren Vorhaben steht der PoC nicht allein. Er ist Teil einer Abfolge aus Anforderungsklärung, Evaluierung, Entscheidung und Umsetzung. In der Vorphase klärt eine Discovery-Phase, was das System leisten muss. Der PoC prüft danach die riskantesten Annahmen. In öffentlichen Ausschreibungen oder Auswahlverfahren mit mehreren Bietern wird der PoC gelegentlich als Bewertungsstufe genutzt: Die Anbieter bauen einen definierten Ausschnitt, und die Ergebnisse werden anhand gleicher Kriterien verglichen. Das erhöht die Vergleichbarkeit, verursacht aber Aufwand auf beiden Seiten und sollte angemessen vergütet werden.
Bei KI-Vorhaben ist der PoC besonders verbreitet, weil die Ergebnisqualität schwer vorherzusagen ist. Ob ein Sprachmodell Produkttexte in der geforderten Qualität liefert oder Kundenanfragen zuverlässig klassifiziert, lässt sich am besten mit echten Daten testen. Auch hier gilt die Regel, dass ein erfolgreicher PoC noch kein produktionsreifes System bedeutet. Die Lücke zwischen Demo und Betrieb, mit Monitoring, Datenschutz und Fehlerbehandlung, wird regelmäßig unterschätzt.
Ausblick
Generative Werkzeuge verkürzen den Weg zu einem lauffähigen Versuchsaufbau erheblich. Was früher Wochen dauerte, entsteht heute teilweise in Tagen. Das verändert nicht die Logik des PoC, verschärft aber ein Risiko: Wenn ein Ergebnis schnell und ansehnlich entsteht, wächst die Versuchung, es für mehr zu halten, als es ist. Die Disziplin, vorab Hypothese und Erfolgskriterien festzulegen und das Ergebnis nüchtern zu bewerten, wird dadurch wichtiger, nicht unwichtiger.
Für Entscheider bleibt die Regel stabil: Ein PoC ist eine Investition in Information. Er sollte klein sein, eine klare Frage beantworten und am Ende eine Entscheidung ermöglichen, egal in welche Richtung.
Häufige Fragen zum Proof of Concept
Was ist ein Proof of Concept?
Ein Machbarkeitsnachweis, der mit begrenztem Aufwand zeigt, ob eine Idee oder Technik unter realen Bedingungen funktioniert.
Was ist der Unterschied zwischen PoC und MVP?
Ein PoC beantwortet die Frage nach der technischen Machbarkeit und ist meist nur intern sichtbar. Ein MVP ist ein produktionsreifes Minimalprodukt, das mit echten Kunden getestet wird.
Wie lange sollte ein PoC dauern?
So kurz wie möglich. Für technische Plattformbewertungen sind vier bis acht Wochen üblich, für einzelne Fragestellungen reichen oft Tage.
Wer sollte einen PoC durchführen?
Ein Team mit ausreichender technischer Tiefe, das nicht allein von einem bestimmten Ergebnis profitiert. Häufig wird er gemeinsam von internen Fachleuten und externen Partnern erarbeitet.
Wird der PoC-Code später weiterverwendet?
In der Regel nicht. Erkenntnisse und Architekturentscheidungen fließen in die Umsetzung ein, der Code selbst wird neu geschrieben oder gründlich überarbeitet.
Weiterführende Quellen
Einen allgemeinen Überblick bietet der Wikipedia-Artikel zum Machbarkeitsnachweis. Die genannte Sicherheitslücke ist im National Vulnerability Database-Eintrag zu CVE-2014-0160 dokumentiert.