Proof of Concept (PoC).

Prototyp, Proof of Concept und MVP werden häufig synonym verwendet, beantworten aber verschiedene Fragen. Der Prototyp fragt: Verstehen Nutzer den Ablauf? Das MVP fragt: Verwenden sie ihn freiwillig weiter? Der PoC fragt ausschliesslich: Geht das technisch, in dieser Umgebung, mit diesen Daten? Deshalb interessiert beim PoC weder Design noch Bedienbarkeit noch Sauberkeit des Codes. Ein Kommandozeilenskript, das die kritische Stelle einmal durchläuft, reicht vollkommen. Wird der PoC hübsch gemacht, ist er kein PoC mehr, sondern der teure Beginn einer Umsetzung ohne Entscheidung.

Ein brauchbarer PoC hat drei Dinge schriftlich, bevor die erste Zeile entsteht: die zu prüfende Annahme in einem Satz, das Abbruchkriterium und ein hartes Zeitbudget. Typisch sind wenige Tage bis zwei Wochen. Das Abbruchkriterium ist der wichtigste Teil, weil ein PoC ohne definiertes Scheitern erfahrungsgemäss nie scheitert — man findet immer noch eine Stellschraube. Sinnvoll ist ausserdem, das Ergebnis unabhängig vom Ausgang zu dokumentieren: Auch ein «geht nicht» ist ein wertvolles Resultat, wenn es nachvollziehbar begründet ist und eine Investition verhindert.

Ein konkreter Fall: Ein Betrieb möchte eingehende Lieferantenrechnungen automatisch auslesen und in die Buchhaltung übergeben. Die riskante Annahme ist nicht die Oberfläche, sondern die Erkennungsqualität bei den tatsächlich eintreffenden PDF-Formaten und die Frage, ob die Buchhaltungssoftware eine belastbare Schnittstelle bietet. Der PoC nimmt hundert echte Rechnungen aus dem letzten Quartal, lässt sie durch die geplante Verarbeitung laufen und misst, wie viele Felder korrekt herauskommen. Das Ergebnis entscheidet über das Projekt — vor der Diskussion über Funktionsumfang, Rollen und Design.

Das häufigste Fehlerbild ist der PoC, der in Produktion geht. Weil er «ja schon läuft», wird er statt neu geschrieben nur ergänzt: ohne Tests, ohne Fehlerbehandlung, mit fest verdrahteten Zugangsdaten und Annahmen, die nur für den Testdatensatz gelten. Das ist der klassische Ursprung technischer Schuld, die über Jahre Zinsen kostet. Sauber ist der umgekehrte Weg: PoC prüfen, Erkenntnis festhalten, Code verwerfen und die tragfähige Lösung mit dem gewonnenen Wissen neu aufsetzen. Wer das nicht will, muss den PoC von Anfang an anders und teurer bauen.