Proof of Concept Software: Machbarkeit vorab belegen

Ein Proof of Concept für Software beantwortet eine einzige Frage, bevor Budget freigegeben wird. Funktioniert die geplante Lösung mit den eigenen Systemen und Daten. Ob am Ende eine Entscheidung steht oder nur eine Diskussion, hängt davon ab, was vor dem Start festgelegt wurde. Dieser Leitfaden zeigt, was ein Software-Machbarkeitsnachweis klärt und was nicht.
Zwei Männer in Bürokleidung betrachten eine große Balkenwaage, in deren einer Schale ein einzelnes kleines gelbgrünes Gewicht liegt, während am anderen Ende ein hoher Stapel schwerer Holzkisten hängt. Sinnbild für einen Proof of Concept in der Software, bei dem eine kleine Vorprüfung über eine große Investition entscheidet.
© KI-generiert (TenMedia)

Proof of Concept für Software: was er leistet

Laut Erhebung des Statistischen Bundesamtes sagen 45 Prozent der Unternehmen ohne KI-Einsatz, dass die Technik nicht zum vorhandenen Bestand passt, 44 Prozent nennen Verfügbarkeit oder Qualität ihrer Daten. Beide Hürden zeigen sich erst am eigenen System.

Ein Proof of Concept ist ein zeitlich begrenzter Versuch. Er prüft unter realen Bedingungen, ob eine technische Annahme trägt, bevor ein Vorhaben beauftragt wird. Gebaut wird nur der Teil, der die kritische Unsicherheit betrifft. Am Ende steht ein belegtes Ja oder Nein, kein fertiges Produkt.

Was der Software-Machbarkeitsnachweis prüft

PoC ist die Abkürzung für Proof of Concept, auf Deutsch Machbarkeitsnachweis. Wo dieser Schritt im Leben einer Anwendung sitzt, ordnet der Leitfaden zum IT Lifecycle Management ein. Was ein Proof of Concept in der Softwareentwicklung leistet, hängt am Zuschnitt. Ein Software-Machbarkeitsnachweis richtet sich auf genau eine Unsicherheit. Prüft er mehrere gleichzeitig, liefert er zu jeder nur ein Vielleicht.

Fünf Fragen tragen einen PoC für Software:

Proof of Concept, Prototyp oder MVP

Die drei Begriffe stehen für drei verschiedene Fragen. Ein Proof of Concept klärt, ob etwas technisch geht. Ein Prototyp zeigt, wie sich eine Lösung bedienen lässt. Ein Minimalprodukt oder MVP klärt, ob jemand sie tatsächlich nutzt, und ist deshalb schon Software mit echten Anwendern. Die Reihenfolge ist nicht beliebig, weil jede Stufe die vorherige voraussetzt. Wer Machbarkeit und Marktnachfrage in einem Schritt belegen will, belegt am Ende keines von beidem. Die Proof-of-Concept-Phase dauert in der Praxis zwei bis sechs Wochen, ein bedienbarer Prototyp deutlich länger.

Warum die Begriffe in Angeboten durcheinandergehen

In Angeboten steht häufig Proof of Concept, gemeint ist aber ein bedienbarer Klickpfad. Der Unterschied kostet Geld, weil eine Oberfläche den größten Teil des Aufwands bindet und zur technischen Frage nichts beiträgt. Ein Machbarkeitsnachweis darf hässlich sein. Vor das Preisgespräch gehört deshalb ein Satz im Angebot, der benennt, welches der drei Ergebnisse geliefert wird und was ausdrücklich nicht dazugehört. Fehlt diese Zeile, klärt sich die Frage erst bei der Abnahme, also im teuersten Moment.

Welche Annahmen klärt nur ein Proof of Concept?

Ein PoC lohnt sich bei Annahmen, deren Antwort nirgends steht. Was in einer Produktdokumentation, einer Norm oder einem Vertrag nachlesbar ist, wird gelesen und nicht erprobt. Diese Trennung erledigt etwa die Hälfte der Fälle ohne Aufwand, und zwar in einer Stunde am Tisch, bevor ein Anbieter überhaupt ein Angebot schreibt. Der Rest gehört in die Rechnung der Lebenszykluskosten, weil ein Versuch die Investition vorbereitet und nicht ersetzt. Die Vorprüfung kostet einen Bruchteil der Umsetzung, verschiebt den Start aber um Wochen.

Vier Anlässe, die den Aufwand tragen

Vier Fälle kehren in Projekten regelmäßig wieder. Sie haben eines gemeinsam. Die Antwort hängt an den eigenen Daten und Systemen, nicht am Produkt eines Anbieters. Ein Versuch mit fremden Beispieldaten beantwortet sie deshalb nicht.

Diese vier Anlässe rechtfertigen den Aufwand:

Wie sich Datenqualität dauerhaft steuern lässt, behandelt der Text zum Data Lifecycle Management.

Wann ein Software-Machbarkeitsnachweis nichts bringt

Drei Situationen sprechen gegen einen PoC. Die Frage ist fachlich und nicht technisch. Die Antwort steht in der Dokumentation. Oder die Entscheidung ist längst gefallen und der Versuch soll sie nur noch bestätigen. Im letzten Fall entstehen Kosten ohne Erkenntnis. Bei Schnittstellen hilft oft eine saubere Versionsplanung weiter, wie der Text zum API Lifecycle Management zeigt. Häufig übersehen wird ein vierter Fall. Steht die Machbarkeit außer Frage und geht es um die Akzeptanz im Fachbereich, gehört dorthin ein bedienbarer Prototyp.

Proof of Concept für Software beauftragen

Ein PoC-Projekt braucht drei Festlegungen. Was geprüft wird, woran der Erfolg gemessen wird, und was mit dem Ergebnis passiert. Alle drei gehören in das Angebot und nicht in eine Mail nebenbei. Fehlt die zweite, endet der Versuch in einer Diskussion über Auslegungen statt in einer Entscheidung. Ein PoC-Projekt ohne Abbruchkriterium läuft praktisch nie negativ aus, weil sich für jedes Teilergebnis eine wohlwollende Lesart findet. Wie aus einem technisch unsicheren Vorhaben eine tragfähige Anwendung wird, zeigt die Prozessplattform für das Pre-Employment-Screening bei SIGNUM Consulting.

Welche Erfolgskriterien gehören vor den Start?

Erfolgskriterien sind messbar oder sie sind keine. Stabile Anbindung taugt nicht als Maßstab, 10.000 Datensätze in unter zwei Minuten ohne Verlust taugt. Der Maßstab wird vor der ersten Codezeile festgelegt, weil er hinterher zur Auslegungsfrage wird. Wird er nachträglich gesetzt, verhandeln beide Seiten am Ende über das Ergebnis.

Sechs Punkte gehören schriftlich fest, bevor jemand einen Proof of Concept erstellt:

❗ Die eine Annahme, die geprüft wird, im Wortlaut
❗ Messbare Schwellen für Erfolg und für Abbruch
❗ Laufzeit und Budget als feste Obergrenze
❗ Welche Daten in welcher Umgebung verwendet werden
❗ Wer das Ergebnis abnimmt und wann
❗ Welche Rechte an Code und Dokumentation übergehen

Wer darf den PoC-Code später weiterverwenden?

Ohne ausdrückliche Regelung im Vertrag liegen die Rechte am Ergebnis nicht automatisch beim Auftraggeber. Für die Erkenntnis ist das gleichgültig, für die technische Weiterverwendung nicht. Ein Machbarkeitsnachweis braucht deshalb eine eigene Klausel, die Code, Konfiguration und Dokumentation einschließt, gleich wie der Versuch ausgeht. Sonst wird ein negatives Ergebnis später ein zweites Mal bezahlt. Der Erkenntniswert überlebt den Code um Jahre, sofern jemand ihn festhält.

Echtdaten im Versuch rechtlich absichern

Sobald ein externer Dienstleister personenbezogene Echtdaten verarbeitet, liegt eine Auftragsverarbeitung nach Artikel 28 DSGVO vor und es braucht einen entsprechenden Vertrag. Anonymisierte oder erfundene Daten ersparen diesen Aufwand, verfälschen bei Fragen zur Datenqualität aber genau das Ergebnis, um das es geht. Welche Daten in den Versuch gehen, ist eine inhaltliche Frage, keine formale. Gangbar ist häufig ein kleiner Echtdatenauszug mit fester Frist und terminierter Löschung.

Vom Proof of Concept in der Softwareentwicklung ins Projekt

Der Übergang ist die Stelle, an der Wissen verloren geht. Ein Proof of Concept in der Softwareentwicklung zeigt Aufwände, Risiken und Grenzen, und genau das gehört in die Schätzung für das Folgeprojekt. Ohne Übergabe an das Projektteam bleibt vom Versuch nur das Ergebnis übrig, nicht der Weg dorthin. Nach der Proof-of-Concept-Phase entsteht der Aufbau dann als Individualsoftware auf gesicherter Grundlage. Praktisch heißt das, das Ergebnis als kurzen Bericht mit Zahlen und offenen Punkten abzulegen.

Was bleibt und was Wegwerfcode ist

Code aus einem Proof of Concept entsteht bewusst ohne Fehlerbehandlung, Tests und Sicherheitsniveau. Wird er als Fundament weiterverwendet, sammelt das Projekt vom ersten Tag an technische Schulden. Der Wert liegt in den Erkenntnissen, nicht in den Dateien. Für die Abnahme heißt das, den Bericht einzufordern und nicht den Quellcode.

Vier Ergebnisse gehen sinnvoll in das Projekt über:

Hinweis: Dieser Beitrag dient der allgemeinen Information und stellt keine Rechtsberatung dar. Für verbindliche Auskünfte zu regulatorischen Anforderungen empfehlen wir die Konsultation einer spezialisierten Rechtsberatung.

FAQs

Wie lange sollte ein Proof of Concept dauern? keyboard_arrow_down keyboard_arrow_up
Zwei bis sechs Wochen tragen die meisten Fälle. Wichtiger als die Dauer ist die vorab gesetzte Obergrenze. Läuft ein Proof of Concept in der Softwareentwicklung länger, wächst der Umfang meist unbemerkt mit und die Aussage verwässert. Ein Beispiel dafür ist die nachträglich eingebaute Oberfläche.
Was passiert, wenn der Proof of Concept die Annahme widerlegt? keyboard_arrow_down keyboard_arrow_up
Ein widerlegter Proof of Concept ist der günstigste Ausgang, weil er eine Fehlinvestition verhindert, bevor sie entsteht. Praktisch folgen drei Wege. Die Annahme wird angepasst und der Nachweis mit verändertem Zuschnitt wiederholt, die Anforderung wird gestrichen, oder das Vorhaben wechselt die technische Grundlage. Voraussetzung ist, dass das Abbruchkriterium vorher schriftlich feststand. Ohne diesen Maßstab wird ein negatives Ergebnis regelmäßig als Teilerfolg gedeutet und das Vorhaben startet trotzdem. Für die Aufwandsschätzung bleibt das Ergebnis verwertbar, weil die Grenzen jetzt belegt sind. Darin liegt die Bedeutung des Nachweises in der Softwareentwicklung.
Wie unterstützt TenMedia bei einem Proof of Concept für Individualsoftware? keyboard_arrow_down keyboard_arrow_up
TenMedia legt den Nachweis auf Wunsch als abgegrenzten Vorlauf zur Individualsoftware an, mit festgelegtem Prüfziel, messbaren Abbruchkriterien und Übertragung der Nutzungsrechte. Angebunden werden vorhandene Fachsysteme und Schnittstellen. Genau darum geht es bei einem Proof of Concept für Software, um eine Entscheidung auf Belegen statt auf Annahmen.