POCs, die Erfolg vorhersagen: und POCs, die allen die Zeit rauben

Ein Proof of Concept sollte genau eine Frage beantworten: Löst dieses Produkt unser konkretes Problem in unserer konkreten Umgebung? In der Praxis beantworten die meisten B2B-POCs eine andere Frage: Kann der Sales Engineer des Vendors eine gute Demo mit unserem Logo darauf abliefern?

Die Kluft zwischen einem nützlichen und einem inszenierten POC ist enorm. Käufer, die den Unterschied nicht erkennen, treffen teure Entscheidungen auf Basis wertloser Daten. Sechs Monate nach Vertragsabschluss merken sie, dass die Integrationskomplexität, über die in der Evaluation alle hinweggegangen sind, nun ein sechswöchiges IT-Projekt ist, für das niemand Budget eingeplant hat.

Das ist keine Frage der Vendor-Ethik. Vendors bauen POCs, um zu gewinnen, nicht um Fehlerbilder aufzudecken. Die Verantwortung, eine Evaluation zu designen, die echte Signale liefert, liegt beim Käufer. Die Forschung der Harvard Business Review zu B2B-Kaufentscheidungen hält seit Langem fest, dass Käufer, die Bewertungskriterien vorab festlegen, langfristig bessere Ergebnisse erzielen als jene, die sich auf Vendor-geführte Demonstrationen verlassen.

Fünf Anzeichen, dass Ihr POC Theater ist

Bevor Sie einen besseren Prozess designen, sollten Sie erkennen, wie ein inszenierter POC aussieht. Diese Muster sind so verbreitet, dass die meisten Käufer in jeder größeren Evaluation mindestens zwei oder drei davon antreffen.

Vom Vendor kontrollierte Daten. Der POC läuft ausschließlich auf den Beispieldaten des Vendors oder auf einer bereinigten Version Ihrer Daten, die der Vendor aufbereitet hat. Ihre tatsächlichen Daten mit Sonderfällen, historischen Inkonsistenzen und nicht standardisierten Feldnamen kommen nie mit dem System in Berührung. Die Demo sieht sauber aus, weil die Daten für die Demo kuratiert wurden.

Keine schriftlichen Erfolgskriterien. Vor dem POC sind sich alle einig, dass Sie "Benutzerfreundlichkeit" und "Integrationsfähigkeit" evaluieren. Niemand schreibt auf, was das heißt. Nach sechs Wochen fragt der Vendor, wie es lief, und der Champion sagt "ganz gut", doch Procurement und IT hatten völlig andere Erwartungen, die nie zur Sprache kamen.

Der Vendor führt alle Sessions durch. Ein nützlicher POC bedeutet, dass Ihr Team das Produkt tatsächlich nutzt. Ein inszenierter POC bedeutet, dass der Sales Engineer des Vendors Ihrem Team jeden Dienstag das Produkt vorführt. Haben Ihre Anwender die Arbeit nicht selbst erledigt, haben Sie nicht die Usability evaluiert. Sie haben die Präsentationsfähigkeit des Vendors evaluiert.

Scope-Erweiterung ohne Anpassung des Zeitplans. Der POC beginnt als Evaluation einer CRM-Migration. In Woche drei hat der Vendor vorgeschlagen, auch sein Marketing-Automation-Modul zu evaluieren, weil es "schon eingerichtet ist und Ihnen den vollen Plattformwert zeigt". Der Scope hat sich verdoppelt. Der Zeitplan nicht. Die Tiefe der Evaluation im ursprünglichen Scope hat sich halbiert.

Keine Diskussion darüber, wie Scheitern aussieht. Ein gut designter POC definiert vorab, bei welchem Ergebnis Sie nicht kaufen würden. Wenn alle so agieren, als wäre der Kauf das einzig mögliche Ergebnis, führen Sie keine Evaluation durch. Sie führen einen choreografierten Abschluss durch.

Was ein nützlicher POC vorab definieren muss

Der wichtigste Prädiktor für die Qualität eines POC ist, ob der Käufer vor dem ersten Vendor-Kick-off einen POC-Design-Brief verfasst hat. Die meisten tun das nicht. Das muss dieser Brief enthalten.

Schriftliche Erfolgskriterien. Nicht "wir wollen sehen, ob es einfach zu bedienen ist". Schriftliche Kriterien lauten etwa: "User-Onboarding: 80 % der Pilotanwender schließen ihren ersten zentralen Workflow innerhalb von 5 Werktagen ohne Support ab." Oder: "CRM-Integration: Alle Änderungen der Dealphasen im Quell-CRM erscheinen innerhalb von 15 Minuten in dieser Plattform, validiert über einen Beobachtungszeitraum von 10 Tagen." Diese Kriterien sind falsifizierbar. Sie sind bestanden oder nicht. Sie müssen nicht darüber diskutieren, ob sie bestanden wurden.

Echte Daten statt Demo-Daten. Ihre tatsächlichen Daten sind Ihr bester Stresstest. Braucht der Vendor vor dem POC Zeit, um Ihre Datenstruktur zu verstehen, ist das in Ordnung, aber der POC selbst sollte auf repräsentativen Stichproben Ihrer echten Daten laufen, einschließlich der unordentlichsten Teile. Jede Integrationsfrage, die dabei auftaucht, wäre nach Vertragsabschluss ohnehin aufgetaucht. Besser, man findet sie in Woche zwei als in Woche zehn nach dem Go-live. Der Leitfaden zu Datenbereinigung und Deduplizierung ist eine nützliche Übung vor dem POC: Saubere Daten zeigen echte Integrationsprobleme schneller, als unordentliche Daten sie verbergen.

Definition des Integrationsumfangs. Listen Sie vor Beginn des POC jedes System auf, mit dem dieses Tool verbunden werden muss. Nicht "vielleicht irgendwann". Listen Sie nur die Integrationen auf, die für den Basis-Use-Case nötig sind. Definieren Sie für jede Integration, wer sie verantwortet (IT, Vendor oder gemeinsam) und wie das Abnahmekriterium lautet. So kommt die versteckte Integrationskomplexität ans Licht, die später Deals (und Implementierungen) zu Fall bringt.

Ein Entscheidungszeitplan. Der POC hat ein Enddatum, und an diesem Datum tritt das Buying Committee wieder zusammen, um auf Basis der POC-Ergebnisse zu entscheiden. Kein "Debrief-Call" zur Planung nächster Schritte. Ein Entscheidungsmeeting. Wird das Meeting verschoben, wird der POC entsprechend verlängert, doch die Erwartung, dass auf die Evaluation eine Entscheidung folgt, steht von Anfang an fest.

Rollen und Verantwortlichkeiten. Wer auf Ihrer Seite verantwortet den POC? Wer ist der primäre Ansprechpartner des Vendors? Wer in Ihrem Team ist dafür zuständig, die Pilot-Workflows durchzuführen? Das ist wichtig, denn POCs scheitern operativ, wenn auf Käuferseite niemand klare Verantwortung trägt und die Evaluation nebenbei läuft, während das eigentliche Tagesgeschäft weitergeht.

Das Vendor-Anreizproblem

Das sagen die meisten Kaufleitfäden nicht direkt: Ihr Vendor will, dass der POC erfolgreich ist. Das ist nicht unehrlich. Es ist rational. Doch seine Definition von "Erfolg" und Ihre müssen nicht übereinstimmen.

Ein Vendor definiert den POC-Erfolg als abgeschlossenen Deal. Sie definieren den POC-Erfolg als zutreffende Antwort auf die Frage "Funktioniert das für uns?". Das sind unterschiedliche Ziele, und sie erzeugen unterschiedliches Verhalten.

Vendors werden:

• Sie zu Funktionen lenken, die gut funktionieren, und von Use Cases wegführen, die Grenzen sichtbar machen
• Blocker im POC schnell beheben, die nach Vertragsabschluss Wochen dauern würden
• Während der Evaluation dedizierte Support-Ressourcen bereitstellen, die normalen Kunden nicht zur Verfügung stehen
• Integrationskomplexität optimistisch darstellen, weil der Sales Engineer überzeugt ist, dass sie lösbar ist (das Implementierungsteam wird es anders erleben)

Besonders sichtbar ist das bei CRM-POCs. Ein Vergleich wie Rework vs. HubSpot CRM kann die strukturellen Funktionsunterschiede aufzeigen, die Vendors in Demos gern herunterspielen.

Nichts davon ist gelogen. Es ist die natürliche Folge davon, dass ein Vendor seine besten Ressourcen und erfahrensten Leute in eine Evaluation mit hohem Einsatz schickt. Nach Vertragsabschluss sind Sie ein normaler Kunde.

Daraus folgt: Sie sollten den POC aktiv auf die Probe stellen und nicht den Weg des geringsten Widerstands akzeptieren. Nutzen Sie Ihre unordentlichsten Daten. Fragen Sie nach den Use Cases, bei denen Sie am wenigsten sicher sind, dass sie funktionieren. Bitten Sie um ein Gespräch mit einer Kundenreferenz, die vor einer ähnlichen Integrationsherausforderung stand. Suchen Sie diese selbstständig über eine Community oder Ihr Netzwerk, nicht über das Customer-Success-Team des Vendors.

Die drei häufigsten POC-Fehler

Drei Fehlerbilder schwächen immer wieder das Signal, das ein POC liefern soll.

Scope Creep ohne Anpassung des Zeitplans. Das wurde bei der Theater-Diagnose erwähnt, verdient aber eine Vertiefung. Scope Creep im POC ist fast immer gut gemeint. Der Vendor sieht die Chance, mehr Mehrwert zu zeigen. Ihr Champion will eine Fähigkeit evaluieren, die er anfangs nicht eingeplant hatte. Jemand im Committee fragt: "Können wir auch sehen, wie es X handhabt?" Jede einzelne Anfrage wirkt vernünftig. Aber in Summe entsteht eine Evaluation, die alles oberflächlich abdeckt statt den ursprünglichen Use Case in der Tiefe.

Lösung: Jede Scope-Erweiterung nach Unterzeichnung des POC-Design-Briefs erfordert eine schriftliche Ergänzung, die den Zeitplan entsprechend verlängert. Keine kostenlosen Erweiterungen.

Abdriften der Erfolgskriterien. Ein POC beginnt mit klaren Kriterien. Drei Wochen später hat der Vendor das Integrationskriterium nicht erfüllt. Es folgt ein Gespräch. Das Kriterium wird als "aspirativ" oder "Phase zwei" umgedeutet. Am Ende des POC sind die ursprünglichen Kriterien durch eine weichere Erzählung über "vielversprechende Signale" und eine "Implementierungs-Roadmap" ersetzt.

Lösung: Die ursprünglichen Erfolgskriterien sind mit Unterzeichnung des POC-Briefs fixiert. Das Buying Committee kann sie formal ändern, doch der Vendor kann sie nicht einseitig in informellen Gesprächen mit dem Champion neu verhandeln.

Weggang des Champions während der Evaluation. Die Person, die den POC designt hat, verlässt das Unternehmen, wird auf ein Projekt mit höherer Priorität gezogen oder in eine Rolle befördert, in der sie diese Entscheidung nicht mehr verantwortet. Der POC läuft ohne sein institutionelles Wissen weiter. Der neue Evaluation Owner hat den Brief nicht geschrieben, versteht die ursprünglichen Erfolgskriterien nicht und ist anfällig für Umdeutungen durch den Vendor.

Lösung: Ein POC hat zwei interne Verantwortliche, nicht einen. Der Backup-Owner wird zu Beginn über Kriterien und Vorgehen informiert. Verlässt der primäre Owner das Unternehmen, beginnt die Evaluation nicht bei null.

Die Vorlage für das POC-Design-Brief

Nutzen Sie diese einseitige Struktur, bevor ein Vendor-POC beginnt.

1. Beschreibung des Geschäftsproblems. Ein Absatz: Welches konkrete operative oder umsatzbezogene Problem wollen wir lösen? Nicht "wir wollen besseres Reporting". Etwas Konkretes, zum Beispiel: "Unser Vertriebsteam verbringt 6 Stunden pro Woche damit, Pipeline-Daten manuell zwischen CRM und Forecasting-Tool abzugleichen, und die Folge ist ein Forecast-Fehler von durchschnittlich 22 %."

2. Erfolgskriterien (schriftlich). Drei bis fünf Kriterien, jedes falsifizierbar. Für jedes: was wir messen, wie wir es messen und welcher Schwellenwert als Erfolg gilt.

3. Integrationsanforderungen. Jede Systemverbindung, die für den Basis-Use-Case nötig ist. Verantwortlicher und Abnahmekriterium für jede.

4. Pilot-Scope. Welches Team, wie viele Anwender, welche Workflows. Was sie während des POC in ihrer normalen Arbeit mit echten Daten tun.

5. Zeitplan. Startdatum, Enddatum, zentrale Check-in-Meilensteine. Der Termin des Entscheidungsmeetings steht vor Beginn des POC fest.

6. Abbruchklausel. Ein Absatz: Bei welchem Ergebnis würden wir nicht fortfahren? Das ist der nützlichste Abschnitt und der, den die meisten Käufer überspringen. Ihn zu schreiben, zwingt zur Klarheit darüber, was Ihnen tatsächlich Sorgen bereitet.

7. Rollen. Primärer und Backup-Evaluation-Owner. Primärer Vendor-Ansprechpartner. IT-Integrationsverantwortlicher. Liste der Entscheider für den finalen Review.

Fünf Erfolgskriterien, die jeder Software-POC haben sollte

Unabhängig von der Kategorie sollten diese fünf Kriterien in irgendeiner Form in jedem Enterprise-Software-POC vorkommen:

Abschlussquote des Kern-Workflows. Können Anwender den primären vorgesehenen Workflow innerhalb der Pilotphase selbstständig und ohne Vendor-Support abschließen? Legen Sie einen Schwellenwert fest: 80 % Abschluss bis Tag 10 ist ein vernünftiger Ausgangspunkt.

Integrationslatenz und Zuverlässigkeit. Für jede erforderliche Integration: Die Daten synchronisieren innerhalb des definierten Zeitfensters (z. B. 15 Minuten) mit einer definierten Zuverlässigkeit (z. B. über 99 % im POC-Zeitraum). Testen Sie das aktiv und fragen Sie nicht den Vendor.

Umgang mit Sonderfällen. Identifizieren Sie drei bis fünf Use Cases, die in Ihrer Umgebung nicht standardisierte Situationen abbilden. Spielen Sie sie im POC explizit durch. Wenn das Tool Ihre Sonderfälle nicht abdeckt, merken Sie es nach Vertragsabschluss, es sei denn, Sie testen sie jetzt.

Qualität der Support-Antworten. Stellen Sie während des POC eine echte Support-Anfrage, keine leichte. Wie lange dauert es, bis eine substanzielle Antwort kommt? Wer antwortet? Ist die Antwort fachlich korrekt? Die Support-Qualität nach Vertragsabschluss ist oft die am meisten unterschätzte Dimension eines Enterprise-Softwarekaufs, und sie ist eines der klarsten Signale in jedem CRM-Implementierungs-Rollout.

Validierung der Datenportabilität. Exportieren Sie vor Ende des POC Ihre Daten aus dem System. Bestätigen Sie, dass Sie alles exportieren können, was Sie eingegeben haben, und zwar in einem Format, das Sie tatsächlich nutzen können. Fragen zum Vendor-Lock-in lassen sich mit einem leeren Vertrag leichter bewerten als mit einer vollen Datenbank. Der TrustRadius-Report zum B2B Buying Disconnect stellt immer wieder fest, dass Datenportabilität und Integrationsqualität zu den wichtigsten Faktoren zählen, die Käufer vor der Entscheidung gern gründlicher geprüft hätten.

Wie ein guter POC aussieht

Die POCs, die verlässliche Kaufsignale liefern, haben einige Gemeinsamkeiten. Sie sind kurz: vier bis sechs Wochen, nicht offen. Sie laufen auf echten Daten und echten Workflows. Die Erfolgskriterien wurden geschrieben, bevor der Sales Engineer des Vendors am ersten Call teilnahm. Der Evaluation Owner hat die Befugnis, Nein zu sagen, und jeder im Buying Committee weiß das. Das RevOps-Reifegradmodell beschreibt, wie diese organisatorische Bereitschaft in verschiedenen Stufen aussieht: Eine RevOps-Funktion ab Level 3 führt in der Regel deutlich strukturiertere POCs durch als Teams in früheren Stufen.

Sie sind außerdem vom Käufer geführt, nicht vom Vendor. Der Vendor unterstützt. Der Käufer steuert. Das ist ein bedeutsamer operativer Unterschied, und die meisten Käufer müssen ihn bewusst etablieren, denn Vendors füllen das Vakuum, wenn man sie lässt. Forresters Forschung zum Technologieeinkauf untermauert das: Strukturierte, vom Käufer kontrollierte Evaluationen erzielen 12 Monate nach der Implementierung deutlich höhere Zufriedenheitswerte als Vendor-geführte.

Ein POC, der echte Probleme vor Vertragsabschluss aufdeckt, ist ein Geschenk. Die meisten Käufer sehen das im Moment nicht so. Sie sehen eine problematische Evaluation, die einen Deal verkompliziert, den sie abschließen wollten. Doch die Alternative ist immer teurer: Einen Vertrag zu unterschreiben und diese Probleme während der Implementierung zu entdecken, stört mehr, als sie in der Evaluation aufzudecken.

Weiterführende Inhalte

• Das neue B2B-Buying-Committee: Wer wirklich im Raum ist, die Stakeholder, die Ihre POC-Ergebnisse freigeben müssen
• Die wahren Kosten von Software-Sprawl in Mid-Market-Unternehmen, was passiert, wenn POC-Abkürzungen zu Integrationsschulden im großen Maßstab führen