Was kostet ein Blockchain Proof of Concept?

Die Kosten eines Blockchain Proof of Concept hängen weniger vom Wort „Blockchain“ ab als vom Scope: Daten, Schnittstellen, Rollen, Compliance, UX, Integration und Entscheidungsziel bestimmen den Aufwand.

Die wichtigsten Kostentreiber

Ein einfacher technischer Demonstrator kann relativ schlank sein. Ein belastbarer Proof of Concept für ein Unternehmen ist aber mehr als eine Demo. Er braucht fachliche Anforderungen, echte Beispielprozesse, klare Akzeptanzkriterien und eine Architektur, die nicht sofort wieder verworfen werden muss.

Typische Kostentreiber sind Schnittstellen zu bestehenden Systemen, Datenschutz- und Security-Anforderungen, Identitäts- und Rollenmodelle, externe Partner, regulatorische Abstimmung, Testdaten, UX-Prototypen und die Frage, ob der PoC später in Richtung Pilot weiterentwickelt werden soll.

Drei sinnvolle Größenordnungen

Praktisch lassen sich drei Größenordnungen unterscheiden:

• Use-Case-Check: wenige Termine, Bewertung von Nutzen, Risiken, Alternativen und nächstem Schritt.
• Fachlicher PoC-Scope: Anforderungen, Prozessmodell, Rollen, Datenobjekte, Architektur-Skizze und Backlog.
• Technischer PoC: klickbarer oder lauffähiger Prototyp mit ausgewählten Integrationen und Testdaten.

Viele Organisationen springen zu früh in Stufe drei. Oft ist Stufe eins oder zwei der bessere erste Schritt, weil dort teure Missverständnisse sichtbar werden.

Warum der erste PoC nicht zu groß werden sollte

Ein PoC soll Unsicherheit reduzieren, nicht schon das Zielsystem bauen. Wenn zu viele Use Cases, Stakeholder und Integrationen gleichzeitig enthalten sind, wird das Ergebnis langsam, teuer und schwer interpretierbar.

Besser ist ein enger Schnitt: ein Nachweis, ein Prozess, eine Zielgruppe, wenige Erfolgskriterien. Danach kann entschieden werden, ob der Ansatz verworfen, angepasst oder in einen Pilot überführt wird.

So lassen sich Kosten senken

• Vor dem PoC eine klare Entscheidungsfrage formulieren.
• Nur den kritischsten Prozessabschnitt modellieren.
• Testdaten statt produktiver Daten verwenden.
• Integrationen zunächst simulieren, wenn sie nicht entscheidungsrelevant sind.
• Regulatorische und Datenschutzfragen früh als Annahmen dokumentieren.
• Den PoC mit einem kurzen Review abschließen: weiter, ändern oder stoppen.

Ein kostenloses Erstgespräch reicht oft, um zu erkennen, ob zuerst Beratung, Workshop oder technischer PoC sinnvoll ist.

Warum Budgets oft falsch eingeschätzt werden

Viele Kostenschätzungen unterschätzen den fachlichen Anteil eines Blockchain Proof of Concept. Die eigentliche Arbeit liegt selten nur im Schreiben von Code. Sie liegt in der Klärung von Prozess, Datenmodell, Rollen, Prüflogik, Datenschutz, Schnittstellen und Erfolgskriterien. Wenn diese Fragen nicht vorbereitet sind, wird der technische Aufwand schnell zum Suchprozess.

Auch kleine PoCs können teuer werden, wenn zu viele offene Grundsatzfragen gleichzeitig gelöst werden sollen. Umgekehrt kann ein gut vorbereiteter PoC sehr schlank bleiben, wenn Ziel, Umfang und Entscheidungskriterium klar sind. Budgetdisziplin entsteht also nicht durch Sparen an Analyse, sondern durch einen sauberen Schnitt des Problems.

Interne Aufwände nicht vergessen

Bei PoC-Kosten wird häufig nur der externe Entwicklungs- oder Beratungsaufwand betrachtet. Für die tatsächliche Entscheidung sind aber auch interne Aufwände relevant: Fachbereichszeit, IT-Abstimmung, Datenschutzprüfung, Security-Review, Datenbereitstellung, Testkoordination, Managementtermine und Abstimmung mit Partnern.

Diese internen Aufwände müssen nicht abschrecken, sollten aber sichtbar sein. Wenn ein Projekt nur deshalb günstig wirkt, weil interne Arbeit nicht gezählt wird, entsteht ein falsches Bild. Gerade bei Banken, Versicherungen, öffentlichem Sektor und Industrie ist die interne Koordination oft ein größerer Faktor als die reine Prototyp-Entwicklung.

Kosten immer an der Entscheidung messen

Die wichtigste Budgetfrage lautet nicht: „Was kostet ein PoC?“ Sondern: „Welche Entscheidung wird dadurch besser?“ Ein PoC ist sinnvoll, wenn er eine relevante Unsicherheit reduziert: technische Machbarkeit, Integrationsrisiko, Akzeptanz, regulatorische Annahme, Partnerfähigkeit oder Business-Nutzen.

• Wenn die Entscheidung noch unklar ist, zuerst einen Use-Case-Check durchführen.
• Wenn Rollen und Daten unklar sind, zuerst Requirements und Prozessmodell schärfen.
• Wenn die technische Hypothese kritisch ist, einen engen technischen Prototyp bauen.
• Wenn Akzeptanz unsicher ist, früh mit Klickdummy, Demo oder Testgruppe arbeiten.

So wird der PoC nicht zum Selbstzweck, sondern zu einem kontrollierten Schritt in Richtung einer belastbaren Roadmap.

Typische Szenarien und ihre Kostenlogik

Ein PoC für einen digitalen Nachweis hat eine andere Kostenlogik als ein Smart-Contract-Prototyp oder ein Tokenisierungs-Experiment. Bei digitalen Nachweisen stehen Rollen, Datenmodell, Wallet- oder Verifier-Prozess und Widerruf im Vordergrund. Bei Smart Contracts sind Geschäftslogik, Testfälle, Security und Fehlerfälle wichtiger. Bei Tokenisierung kommen zusätzlich Asset-Definition, regulatorische Annahmen und Integrationsfragen dazu.

Deshalb ist eine pauschale Zahl selten hilfreich. Besser ist eine Scope-Klärung: Was muss tatsächlich gebaut werden, was kann simuliert werden, welche Entscheidung soll entstehen und welche Arbeit ist nur „nice to have“? Diese Trennung senkt Kosten, ohne den Erkenntniswert zu zerstören.

Der Abschluss ist Teil des PoC

Viele PoCs enden mit einer Demo, aber ohne klare Entscheidung. Das ist verschenktes Budget. Ein guter PoC enthält am Ende ein Review: Welche Hypothesen wurden bestätigt, welche nicht? Welche Annahmen bleiben offen? Was müsste für einen Pilot geändert werden? Welche Kosten entstehen realistisch in Betrieb und Rollout?

Gerade dieser Abschluss macht die Investition wertvoll. Er trennt technische Begeisterung von belastbarer Projektentscheidung und hilft, Folgeaufwände realistisch einzuschätzen.