Hören Sie auf zu testen: Warum Ihr PoC keine Ergebnisse liefert

Willkommen bei IT for Business. Ich bin Mirko Peters.

Seien wir ehrlich: Die meisten PoCs verbrennen monatelang Zeit in Meetings, Vendor-Demos und internen Workshops, nur um am Ende vor einem Berg aus Slides zu stehen, statt eine echte Entscheidung zu haben. Bleiben Sie kurz dran, denn das könnte Ihnen einen sehr teuren Fehler ersparen. Die Wahrheit ist nämlich, dass die meisten PoCs scheitern, noch bevor der erste technische Test überhaupt beginnt.

Gerade im Mittelstand ist das ein echtes Problem, weil das Budget schmilzt und Ihr Team von den eigentlichen Aufgaben im Betrieb abgezogen wird. Am Ende lernt das Unternehmen fast nichts, was man wirklich nutzen kann. Ein PoC ist kein Sandkasten zum Spielen, sondern ein Werkzeug für harte Management-Entscheidungen. Schauen wir uns also an, wo die meisten Teams falsch abbiegen, lange bevor überhaupt über Software gesprochen wird.

Teil 1: Starten Sie mit dem Use Case, nicht mit der Technologie

Der erste Punkt klingt simpel, und trotzdem fahren hier viele Projekte direkt gegen die Wand: Ein PoC beginnt mit einem geschäftlichen Problem und nicht mit einer glänzenden neuen Funktion.

Sie erkennen einen Fehlstart meistens sofort an Sätzen wie „Wir brauchen jetzt auch KI“ oder „Wir sollten diese Plattform mal testen, weil der Anbieter uns da was Spannendes gezeigt hat“. Das klingt zwar nach Tatendrang, ist aber viel zu vage für ein seriöses Projekt. Wenn die Technologie der Startpunkt ist, ufert die Diskussion sofort aus, und in jedem Meeting kommt ein neues Feature oder eine weitere Abteilung dazu. Mit jeder neuen Option wird der PoC schwächer statt stärker, weil am Ende niemand mehr genau sagen kann, welches konkrete Problem wir hier eigentlich lösen wollen.

Diesen Punkt unterschätzen viele Unternehmen massiv, denn ein vager Anwendungsfall schafft keine Freiheit, sondern führt zu einem schleichenden Kontrollverlust. Wenn dieser Prozess erst einmal läuft, fühlt sich niemand mehr für das Ergebnis verantwortlich. Der Anbieter zeigt immer neue Demos, die internen Teams diskutieren endlos weiter, und die Geschäftsführung wartet vergeblich auf Klarheit. Nach ein paar Wochen wird der PoC so zu einer höflichen Form der Prokrastination, für die man auch noch ein Budget reserviert hat.

Lassen Sie uns das kurz zerlegen und zwei verschiedene Startpunkte vergleichen.

Der erste Ansatz lautet: „Wir wollen KI im Support nutzen.“

Der zweite Ansatz ist: „Wir wollen die manuelle Vorsortierung in einem bestimmten Support-Workflow reduzieren, weil First-Level-Anfragen aktuell von Hand sortiert werden, der Backlog wächst und erfahrene Mitarbeiter mit dieser stumpfen Klassifizierung ihre Zeit verschwenden.“

Das sind nicht einfach nur unterschiedliche Formulierungen für dieselbe Sache, sondern es sind zwei völlig verschiedene Projekte.

Der erste Satz lädt zu einer endlosen Entdeckungsreise ein, bei der man sich schnell in Fragen nach Modellen, Tools, Anbietern und Dokumenten verliert. In so einem Raum wird es sehr schnell sehr laut, ohne dass etwas passiert. Der zweite Satz gibt Ihnen dagegen eine echte Handhabe, weil er sich auf einen Workflow und einen operativen Schmerzpunkt konzentriert. Das ist etwas, das man wirklich testen kann, da es eng genug für eine Bewertung und konkret genug für eine klare Verantwortung ist.

Wenn Sie einen PoC wollen, der zu einer echten Entscheidung führt, müssen Sie den Anwendungsfall ordentlich modellieren. Dafür brauchen Sie kein fünfzigseitiges Konzept, sondern nur genug Klarheit, damit jeder im Raum dasselbe versteht.

Beginnen Sie beim betroffenen Prozess und klären Sie, um welchen Teil des Geschäfts es genau geht. Wir reden hier nicht über „den Kundenservice“ im Allgemeinen, sondern über einen ganz spezifischen Ablauf innerhalb dieser Abteilung. Definieren Sie dann den aktuellen Schmerzpunkt und fragen Sie sich, wo es heute hakt. Ist der Prozess zu langsam, zu fehleranfällig oder hängt er zu stark von einzelnen Personen ab, sodass er sich kaum noch wirtschaftlich skalieren lässt?

Danach legen Sie die erwartete Verbesserung fest, also was genau besser wird, wenn die Lösung funktioniert. Geht es um weniger manuellen Aufwand, schnellere Durchlaufzeiten oder eine höhere Qualität bei der Datenerfassung? Und dann kommt der Punkt, an dem viele Teams plötzlich sehr leise werden: Benennen Sie den Business Owner. Wer verantwortet dieses Problem heute im Tagesgeschäft? Es geht nicht darum, wer die Technik mag oder wer beim Termin mit dem Verkäufer dabei war. Die Frage ist, wer in der Fachabteilung den Schmerz spürt, wenn sich absolut nichts ändert.

Ohne diesen Owner haben Sie keinen echten Anwendungsfall, sondern nur ein unverbindliches Interesse, und das ist nicht dasselbe.

In den meisten mittelständischen Unternehmen mangelt es nicht an Ideen, sondern an Fokus. Sobald ein Thema Aufmerksamkeit bekommt, hat jede Abteilung plötzlich einen passenden Vorschlag, der erst einmal plausibel klingt. So bleiben Teams oft dabei hängen, Use Cases zu sammeln, statt endlich einen auszuwählen. Sie brauchen also einen Filter, um diszipliniert zu entscheiden. Schauen Sie auf das Verhältnis von Aufwand und Nutzen, prüfen Sie die strategische Relevanz und fragen Sie, welcher Fall ein echtes Problem löst, ohne das halbe Unternehmen lahmzulegen.

Ein PoC ist nicht dazu da, die Neugier in zehn verschiedene Richtungen zu befriedigen. Er soll die Unsicherheit rund um eine einzige, wichtige Entscheidung reduzieren.

Klartext: Wählen Sie einen eng gefassten Anwendungsfall, der weh genug tut, um echte Aufmerksamkeit zu verdienen. Wenn das Problem zu klein ist, interessiert sich niemand für das Ergebnis, und wenn es zu breit ist, werden Sie niemals fertig. Sie brauchen die goldene Mitte aus sichtbarem Schmerz, begrenztem Umfang und einem klaren Verantwortlichen. Das ist das Setup, das einem PoC eine faire Chance gibt.

Wenn der Anwendungsfall dann endlich steht, zeigt sich meistens sofort die nächste Schwachstelle, weil viele Teams immer noch nicht definiert haben, wie Erfolg eigentlich aussieht.

Teil 2: Definieren Sie Erfolg, bevor Sie irgendetwas testen

Im zweiten Teil kippen viele PoCs in teures Theater, und zwar immer dann, wenn Erfolgskriterien, Hypothesen und harte Grenzen fehlen.

Einfach gesagt: Ein PoC ohne Zielmetriken ist nur eine Reihe von Workshops mit Cloud-Kosten im Hintergrund. Man trifft sich, diskutiert, der Anbieter zeigt Fortschritte, und intern fallen dem Team ständig noch neue Blickwinkel ein. Das Problem dabei ist, dass niemand die eine Frage beantworten kann, auf die es ankommt: Hat die Lösung gut genug funktioniert, um den nächsten Schritt zu rechtfertigen? Das klingt banal, aber genau an dieser Stelle driften viele Projekte in einen Nebel ab, der Sie bares Geld kostet.

Das Problem ist meist nicht, dass niemand Erfolg definieren will. Das Problem ist, dass alle stillschweigend davon ausgehen, schon dasselbe zu meinen. Die IT schaut auf technische Machbarkeit, der Fachbereich auf die erhoffte Entlastung, und das Management auf Budget und Zeit. Der Anbieter schaut oft vor allem darauf, was sich in kurzer Zeit attraktiv demonstrieren lässt. All das kann im selben Raum passieren, und trotzdem gehen am Ende alle mit einem anderen Verständnis hinaus.

Genau da wird es für Sie teuer. Wenn niemand sauber festgelegt hat, was „funktioniert“ überhaupt bedeutet, kann am Ende auch niemand eine klare Go- oder No-Go-Entscheidung treffen. Dann ist das Ergebnis kein Ergebnis, sondern eine Sammlung weicher Aussagen wie „sieht vielversprechend aus, wir sollten noch mehr testen“ oder „technisch interessant, aber noch nicht vollständig“. Irgendwann hören Sie dann diesen klassischen Satz aus dem Management, man solle das Thema weiter erkunden, und genau an diesem Punkt fehlt die klare Sprache, weil von Anfang an die klaren Kriterien gefehlt haben.

Bevor Sie also irgendetwas testen, schreiben Sie die Hypothese in einfacher Business-Sprache auf. Sie müssen wissen, was sich verbessern soll, wie stark sich etwas verbessern soll und welcher Teil des Prozesses genau betroffen ist.

Schreiben Sie bitte nicht: „Die neue Lösung soll das Serviceteam besser unterstützen.“

„Besser“ ist keine Hypothese.

Eine brauchbare Hypothese klingt eher so: In diesem einen klar abgegrenzten Eingangsprozess soll die Lösung den manuellen Sortieraufwand um zwanzig Prozent senken und dabei die Klassifizierungsqualität über fünfundneunzig Prozent halten, ohne zusätzliche Übergaben im Team zu erzeugen. Das kann man prüfen. Es kann immer noch scheitern, aber dann scheitert es wenigstens ehrlich, und Sie können sauber entscheiden.

Danach trennen Sie Ihre Kriterien in Muss-, Soll- und Kann-Kriterien. Das klingt erst einmal nach Verwaltung, ist es aber nicht, weil es Ihre spätere Entscheidung schützt.

Muss heißt: Wenn dieser Punkt verfehlt wird, gibt es keinen belastbaren Grund, weiterzumachen. Diese Kriterien hängen direkt an Ihrem Entscheidungsrisiko. Kann die Lösung die nötige Datenqualität verarbeiten, bleibt sie innerhalb einer akzeptablen Reaktionszeit und funktioniert sie mit der ausgewählten Quelle ohne riskante Workarounds? Sie müssen auch klären, ob die Nutzer das Ergebnis überhaupt so weit akzeptieren, dass sie es im Alltag einsetzen würden.

Soll heißt: Der Punkt ist nützlich und verbessert den Fall, aber sein Fehlen wäre in der PoC-Phase für sich genommen noch nicht tödlich.

Kann heißt: Schön, wenn es da ist, vielleicht später relevant, aber nicht Teil dieser ersten Entscheidung.

Wenn Sie diese Trennung weglassen, kommt jeder Wunsch mit demselben Gewicht in den Raum. Dann wird ein fehlendes Nice-to-have plötzlich wie ein schwerer Mangel behandelt, und ein echter Mangel wird weichgespült, nur weil die Demo auf dem Bildschirm gut aussah.

Sie müssen Erfolg außerdem über drei Ebenen definieren und nicht nur über eine.

Die erste Ebene ist der technische Fit. Funktioniert das Werkzeug unter den gesetzten Bedingungen, verarbeitet es die richtigen Eingaben und erreicht es eine Mindestqualität?

Die zweite Ebene ist die Prozesswirkung. Verbessert es den Ablauf tatsächlich oder fügt es nur noch einen weiteren Bildschirm hinzu, durch den Ihre Mitarbeiter klicken müssen? Ein PoC kann technisch gut aussehen und den realen Prozess trotzdem verschlechtern.

Die dritte Ebene ist der Business Value. Ist der erwartete Nutzen groß genug, um den Folgeaufwand, die laufenden Kosten und die operative Veränderung zu rechtfertigen?

Machen wir es konkret. Technische Kriterien können eine Reaktionszeit unter zwei Sekunden und eine Mindestschwelle bei der Datenqualität sein. Prozesskriterien können eine hohe Nutzerakzeptanz und weniger manuelle Korrekturen sein. Business-Kriterien sollten eine sichtbare Reduktion des manuellen Aufwands in genau diesem einen definierten Workflow sein. Es geht hier nicht um vage Chancen, sondern um messbare Veränderung.

Dann kommen die harten Grenzen, die Teams oft meiden, weil sie sich eingeschränkt anfühlen. Genau das sollen sie auch.

Setzen Sie eine klare Timebox und einen klaren Budgetrahmen. Begrenzen Sie den PoC auf ein Team, eine Hauptdatenquelle und nur die Schnittstellen, die Sie wirklich brauchen, um den Kernpunkt zu prüfen. Erst dadurch bekommt der PoC eine Form. Ohne diese Grenzen wächst er in jede Richtung und saugt jede offene Frage aus Ihrer Organisation mit auf.

Was heißt das konkret für Sie? Definieren Sie die Exit-Kriterien, bevor der Anbieter das erste Angebot schreibt. Wenn Sie damit bis nach dem Vertriebsgespräch warten, rahmen Sie den PoC nicht mehr, sondern reagieren nur noch auf ihn.

Und jetzt wird es interessant, denn selbst ein sauber gesetztes Ziel fällt in sich zusammen, wenn der Testaufbau falsch ist.

Teil 3: Begrenzen Sie den Scope konsequent, sonst wird aus dem PoC versehentlich ein Pilot

Der dritte Teil betrifft den Scope, die Daten, die Testumgebung und Ihre architektonischen Leitplanken.

Genau hier verlieren viele an sich vernünftige Projekte die nötige Disziplin. Auf dem Papier wirkt das Ziel noch fokussiert, in der Praxis wächst der Aufbau aber in alle Richtungen. Noch ein System kommt dazu, weil es nützlich sein könnte, ein zweiter Datensatz wird ergänzt, weil jemand einen besseren Vergleich will, und eine größere Nutzergruppe wird eingeladen, weil irgendwer meint, man müsse größer denken. So beantwortet der PoC plötzlich nicht mehr eine Frage, sondern schleppt schon die Last einer halben Implementierung mit sich herum.

Ein PoC soll unter kontrollierten Bedingungen genau eine Kernfrage beantworten. Er ist nicht dafür da, jede spätere Architekturfrage gleich mitzulösen, sondern nur die eine Frage, von der abhängt, ob das Konzept den nächsten Schritt verdient.

Das ist deshalb wichtig, weil das Ergebnis unscharf wird, sobald zu viele Systeme oder zu viele Nutzer hineingezogen werden. Wenn das Resultat schwach ausfällt, weiß am Ende niemand mehr, warum es gescheitert ist. Lag es am Konzept, an den Daten oder an der Integration? Aus so einem Aufbau bekommen Sie keine belastbaren Belege, sondern nur Rauschen.

Die erste Disziplin ist daher simpel und wird trotzdem oft übersprungen: Schreiben Sie auf, was im Scope ist, und genauso wichtig, was ausdrücklich nicht im Scope ist.

Die meisten Teams sind ganz ordentlich darin, aufzuzählen, was sie einschließen wollen. Deutlich weniger Teams sind bereit, sauber festzuhalten, was sie bewusst nicht anfassen. Genau dort schleicht sich Scope Drift ein. Wenn „später“ nirgends steht, landet „später“ schon im nächsten Workshop als neue Aufgabe auf dem Tisch und frisst Ihre Zeit.

Zum Beispiel kann „im Scope“ ein klar definierter Workflow, ein Quellsystem und eine ausgewählte Nutzergruppe sein. „Außerhalb des Scope“ kann ein Rollout über mehrere Abteilungen, eine Vollautomatisierung oder die Integration in nachgelagerte Systeme sein. Sobald das sauber dokumentiert ist, wird die Diskussion meist deutlich ruhiger, weil der PoC nicht mehr wie ein verstecktes Lieferprojekt behandelt wird.

Die nächste Leitplanke ist die Integration, und die sollten Sie auf ein Minimum begrenzen.

An dieser Stelle werden Anbieter und interne Teams gerne zu ehrgeizig. Dann sagt jemand, das Ergebnis werde realistischer, wenn man nur noch dieses eine weitere System mit anschließt. Das klingt vernünftig, ist aber oft genau der Fehler, der das Projekt kippt. Wenn Sie drei neue Schnittstellen brauchen, nur um das Grundkonzept zu prüfen, dann testen Sie nicht das Konzept. Sie testen, ob Ihre Organisation ein überhastetes Integrationsprogramm überlebt.

Architektur schlägt Tools. Testen Sie erst das Konzept, bevor Sie die ganze Verrohrung drumherum bauen. Sonst landen Sie beim üblichen Problem: ein technisches Konstrukt, das nie als tragfähige Zielarchitektur gedacht war, aber irgendwie trotzdem dazu wird. Und sechs Monate später betreut Ihr Team provisorische Verbindungen, die eigentlich nur zwei Wochen leben sollten.

Auch bei den Daten brauchen Sie dieselbe Disziplin. Nutzen Sie realistische Daten, aber halten Sie sie kontrolliert.

Wenn die Daten zu künstlich sind, sagt das Ergebnis Ihnen kaum etwas. Wenn sie zu breit oder zu sensibel sind, wird der PoC erst einmal zu einem Governance-Problem, bevor er überhaupt etwas lernt. Sie brauchen also einen Mittelweg. Nutzen Sie Daten, die den realen Prozess abbilden, prüfen Sie die Qualität frühzeitig und klären Sie die Zugriffsrechte sauber. Im Mittelstand ist DSGVO keine Randnotiz. Wenn der Umgang mit den Daten unklar ist, kann ein PoC aus Gründen stehen bleiben, die mit der Technik gar nichts zu tun haben.

Für die Testumgebung gilt dieselbe Logik. Sie sollte nah genug an der Realität sein, damit das Ergebnis etwas bedeutet, aber getrennt genug, damit kein Produktionsrisiko in den Raum kommt. Ein separates Setup ist meistens der sauberste Weg. Nicht weil es besonders elegant wäre, sondern weil produktive Systeme wenig verzeihen. Sobald ein PoC ohne echte Kontrolle in den laufenden Betrieb greift, wird jede Abkürzung sehr schnell teuer.

Nehmen Sie ein einfaches Beispiel: ein Workflow, ein Quellsystem und eine Nutzergruppe. Keine unternehmensweite Rollout-Logik und kein Versuch, jeden Sonderfall der Firma gleich mitzulösen. Für einen PoC reicht das. Es wirkt vielleicht klein, aber genau das ist der Punkt.

Was heißt das konkret für Sie? Wenn der PoC plötzlich fünf Schnittstellen braucht, validieren Sie nicht mehr. Sie implementieren bereits, nur ohne die Ehrlichkeit, die Budgetklarheit und die Governance, die eine echte Umsetzung verlangen würde.

Und selbst wenn der Scope sauber geschnitten ist, driftet das Ganze wieder, sobald die falschen Leute zu spät auftauchen oder gar nicht auftauchen.

Teil 4: Holen Sie die richtigen Stakeholder in den Raum, und halten Sie sie dort

Der vierte Punkt betrifft die Abstimmung der Stakeholder, die Rollenverteilung und den Rhythmus Ihrer Kommunikation.

Das klingt im Vergleich zu Themen wie Scope, Daten oder Architektur oft nach einem weichen Faktor, weshalb es in der Praxis gerne beiseitegeschoben wird. Seien wir ehrlich: Das ist ein teurer Fehler. Die meisten PoCs scheitern nicht, weil die Technik kapituliert, sondern weil fünf verschiedene Abteilungen im Stillen fünf unterschiedliche Erwartungen an das Projekt haben. Der Anbieter will zeigen, dass es technisch machbar ist, während die IT nur die Integrationsrisiken im Blick hat. Der Fachbereich hofft auf eine Entlastung im Tagesgeschäft, die Security will später kein Chaos aufräumen müssen und das Management braucht am Ende eine Entscheidung, die sie vor dem Vorstand rechtfertigen können. Wenn Sie diese Ziele nicht explizit auf den Tisch legen, wird der PoC zu einer Ansammlung von höflichen Missverständnissen.

Das wiegt schwerer, als die meisten Teams wahrhaben wollen. Ein Stakeholder, der erst nach vier Wochen dazustößt, kann die Arbeit eines ganzen Monats in nur einem Meeting zerlegen. Wenn der entscheidende Owner fehlt, bleiben wichtige Erkenntnisse einfach in der Luft hängen, ohne dass jemals ein Urteil gefällt wird. Und die üblichen Status-Updates nach dem Motto „Gute Fortschritte, nächste Schritte, offene Punkte“ helfen hier kein Stück weiter, weil sie zwar Aktivität suggerieren, aber niemandem sagen, ob seine spezifischen Bedenken eigentlich ausgeräumt wurden.

Identifizieren Sie deshalb frühzeitig die echten Stakeholder-Gruppen und nicht nur die Leute, die aus Höflichkeit auf der Liste stehen. Den Anfang macht der Business Owner, also die Person, die das operative Problem jeden Tag auf dem Schreibtisch hat. Dann kommt die IT dazu, denn früher oder später erbt die IT sowieso alle Konsequenzen Ihrer Entscheidung. Nehmen Sie die operativen Mitarbeiter mit rein, die den Prozess tatsächlich bedienen müssen, und vergessen Sie Security und Compliance nicht, denn diese Abteilungen verschwinden nicht einfach, nur weil sie keine Einladung zum Workshop bekommen haben. Holen Sie die künftigen Nutzer ab, statt nur mit deren Managern zu sprechen, und binden Sie den Budgetverantwortlichen ein, denn ein PoC ohne klaren Weg zur Finanzierung ist am Ende oft nur eine sehr gut dokumentierte Zeitverschwendung.

Sobald diese Gruppen feststehen, müssen Sie die Rollen präzise verteilen. Ich meine nicht vage, sondern wirklich konkret.

Wer entscheidet am Ende, ob das Projekt weitergeht oder gestoppt wird? Wer liefert die Daten und stellt sicher, dass sie pünktlich ankommen? Wer testet das Ergebnis im echten Workflow und wer gibt die Risikobereiche offiziell frei? Und ganz wichtig: Wer hat die Autorität, den nächsten Schritt zu blockieren, falls ein kritisches Problem ungelöst bleibt?

Wenn diese Rollen im Ungefähren bleiben, füllen die Beteiligten die Lücken selbst aus, und dann landen Sie beim üblichen Muster: Jeder fühlt sich irgendwie beteiligt, aber niemand übernimmt die Verantwortung. Da versteckt sich das Risiko, denn die Verantwortlichkeit kehrt spätestens dann zurück, wenn die Budgetfrage auf dem Tisch liegt und jemand unterschreiben muss.

Es gibt noch einen Punkt, den viele unterschätzen: Die Endnutzer müssen früh dabei sein. Nicht erst nach dem Setup oder der ersten Demo, sondern von Anfang an.

Die Annahmen des Managements und die Realität im täglichen Prozess sind selten deckungsgleich. Ein Workflow, der in einer Präsentation elegant aussieht, kann sich in der Praxis als völlig sperrig erweisen. Ein Screen, der für die Führungsebene simpel wirkt, bedeutet für die Leute, die damit arbeiten sollen, vielleicht drei zusätzliche Klicks, neue Ausnahmen und massiven Frust. Wenn Sie diesen Realitätscheck auslassen, sieht der PoC auf dem Papier zwar sauber aus, scheitert aber in der Sekunde, in der er das erste Mal echte Arbeit berührt.

Auch Ihre Kommunikation braucht eine klare Struktur. Eine Nachricht für alle klingt zwar effizient, führt aber meistens dazu, dass niemand die Informationen bekommt, die er wirklich braucht.

Das Management will Klarheit für die Entscheidung und wissen, ob die Unsicherheit sinkt. Die IT braucht technische Risikoklarheit bezüglich Schnittstellen und dem späteren Betrieb, während die Nutzer wissen wollen, ob das Tool ihnen hilft oder nur mehr manuelle Nacharbeit verursacht. Wenn Sie denselben Bericht an alle drei Gruppen schicken, wird er am Ende niemanden zufriedenstellen.

Ein klassisches Beispiel aus der Praxis sieht so aus: In Woche vier taucht plötzlich ein Stakeholder aus der Security oder dem Betrieb auf, weil er merkt, dass er betroffen sein könnte. Er schaut sich den Testaufbau an und fragt, ob das Ganze überhaupt repräsentativ ist. Das macht er nicht aus Bosheit, sondern weil er die frühe Phase verpasst hat und jetzt Annahmen sieht, die er am ersten Tag sofort hinterfragt hätte. In diesem Moment ist das Team frustriert, der Anbieter fühlt sich kontrolliert und das Vertrauen beginnt zu bröckeln.

Was das für Sie bedeutet, ist simpel: Wenn ein wichtiger Stakeholder die Reise nicht mitmacht, dürfen Sie sich nicht wundern, wenn er das Ergebnis am Ende ablehnt. Eine Ablehnung kurz vor dem Ziel ist oft nur die Quittung für eine vernachlässigte Einbindung zu Beginn des Projekts.

Wenn Sie jetzt einen fokussierten Use Case, harte Kriterien, einen sauberen Scope und die richtigen Leute an Bord haben, kann der eigentliche PoC endlich starten.

Teil 5: Führen Sie den PoC als Entscheidungsprozess, nicht als technisches Experiment

Der fünfte Teil umfasst die Durchführung, die Review-Phasen und das finale Go oder No-Go.

Sobald der PoC läuft, müssen Sie die Disziplin aufrechterhalten, denn hier verfallen viele Teams wieder in alte Muster. Der Live-Test sorgt für Begeisterung, es entstehen neue Möglichkeiten und ständig kommen neue Ideen auf den Tisch. Aber halten wir fest: Das Ziel eines PoCs ist nicht der Beweis, dass ein Tool irgendetwas Interessantes kann. Es geht darum, die Unsicherheit rund um eine geschäftliche Entscheidung zu reduzieren, und das ist ein völlig anderer Maßstab.

Ein Werkzeug kann technisch beeindruckend sein und trotzdem die falsche Investition für Ihr Unternehmen darstellen. Es kann eine starke Demo liefern und für Optimismus im Raum sorgen, während der tatsächliche Weg zur Wertschöpfung steinig, teuer oder operativ kaum umsetzbar bleibt. Genau deshalb kann ein technisch erfolgreicher PoC am Ende ein klares No-Go sein. Wenn der Nutzen zu gering, die Abhängigkeiten zu groß oder das Betriebsmodell zu chaotisch sind, dann hat der Test seinen Job gemacht, indem er genau das frühzeitig aufgedeckt hat.

Führen Sie den PoC deshalb in kurzen Review-Schleifen durch und messen Sie ihn an den Kriterien, die Sie vorher festgelegt haben. Lassen Sie sich nicht von jeder neuen Idee ablenken, die im letzten Meeting aufkam. Wenn jedes Review zu einer neuen Brainstorming-Runde wird, verliert das Projekt sofort seine Form. Die Frage in jeder Runde muss lauten: Sind wir der Antwort auf unsere Kernfrage einen Schritt nähergekommen?

Testen Sie dabei nicht nur den Idealfall, sondern schauen Sie sich gezielt die schwierigen Pfade an, denn dort sitzen die echten operativen Risiken. Was passiert bei schlechten Datenqualitäten? Wie reagiert das System, wenn Felder fehlen, Berechtigungen unvollständig sind oder ein Prozess auftaucht, der nicht der Norm entspricht? Ein PoC, der nur unter perfekten Bedingungen funktioniert, sagt Ihnen absolut nichts über die spätere Realität in Ihrem Unternehmen.

Ihre Dokumentation muss diese Realität widerspiegeln, und zwar nicht in der Marketingsprache des Anbieters oder in technischer Selbstbeweihräucherung. Nutzen Sie Business-Sprache.

Schreiben Sie auf, was funktioniert hat, was gescheitert ist und welche Fragen noch offen sind. Listen Sie auf, was der nächste Schritt kosten würde – und zwar an Aufwand, Architekturarbeit, Prozessänderungen und Folgerisiken. Nur so kann das Management auf Basis von harten Konsequenzen entscheiden und nicht nach Bauchgefühl.

Beenden Sie den PoC dann mit einem sauberen Abschluss. Das Ergebnis sollte ein Go, ein No-Go oder ein Go mit klaren Bedingungen sein. Letzteres ist völlig legitim, solange die offenen Punkte bekannt, begrenzt und beherrschbar sind. Was auf keinen Fall passieren darf, ist ein vager Satz wie „Wir sollten das Thema weiter verfolgen“. Das bedeutet meistens nur, dass das Team sich vor einer echten Entscheidung gedrückt hat, weil der PoC nie darauf ausgelegt war, eine solche Entscheidung zu erzwingen.

Es hilft auch, wenn Sie zwischen einem PoC und einem Piloten sauber trennen. Ein PoC beweist die Machbarkeit unter kontrollierten Bedingungen, während ein Pilot den Betrieb unter echten Bedingungen testet. Wenn Sie erwarten, dass der PoC bereits alle Fragen des Piloten beantwortet, wird der Aufbau von Anfang an überladen. Sie überfordern entweder den Test oder verwechseln Teilbeweise mit einer echten Produktionsreife.

Klartext: Wenn das Ergebnis Ihres PoCs weder eine Finanzierungsentscheidung noch eine Rollout-Entscheidung oder einen Projektabbruch beeinflusst, dann war das Design des PoCs schlecht. Er mag zwar interessant gewesen sein, aber er war für das Unternehmen schlichtweg nicht nützlich.

Das führt uns zu dem Teil, den viele Teams überspringen: Wie all diese Punkte als ein zusammenhängendes System funktionieren, statt nur eine Liste aus fünf separaten Projekttipps zu sein.

Verknüpfung: Wie die Teile als ein System zusammenarbeiten

Lassen Sie uns diese Einzelteile jetzt zusammenfügen, denn erst in der Kombination wird der eigentliche Punkt klar.

Der Use Case sorgt für den nötigen Fokus, während die Kriterien das Urteilsvermögen schärfen. Der Scope macht das Ganze überhaupt erst testbar, die Stakeholder sichern die Akzeptanz und die Ausführung liefert am Ende die Beweise. All das führt zu einer Entscheidung, die echte Bewegung in die Sache bringt. Wenn auch nur eines dieser Glieder schwach ist, bricht das gesamte System früher oder später in sich zusammen.

Das ist genau der Punkt, den viele Unternehmen übersehen. Die meisten PoCs scheitern nämlich nicht in der eigentlichen Testphase, sondern sie scheitern schon bei der Rahmung. Die Testphase macht diese grundlegenden Schwächen dann lediglich für alle sichtbar.

Wenn der Use Case nicht klar definiert ist, bleiben zwangsläufig auch die Metriken vage. Sind die Metriken erst einmal schwammig, fängt der Scope fast immer an zu wuchern, weil niemand mehr sicher sagen kann, was eigentlich irrelevant ist. Sobald der Umfang wächst, kommen mehr Systeme, mehr Daten und vor allem mehr Meinungen mit an den Tisch. Dann folgen die Konflikte zwischen den Stakeholdern fast automatisch, weil die verschiedenen Abteilungen plötzlich ganz unterschiedliche Risiken und Erwartungen sehen. In diesem Moment glaubt das Team meistens an ein technisches Problem, aber in Wahrheit liegt ein massiver Designfehler im PoC selbst vor.

Am Ende zahlt das Unternehmen dann doppelt. Zuerst bezahlen Sie für den eigentlichen PoC und danach zahlen Sie noch einmal drauf, um die Unklarheiten zu beseitigen, die man schon vor dem Start hätte klären müssen.

Seien wir ehrlich: Ein PoC ist kein Innovationstheater und auch keine reine Beruhigungsmaßnahme für das Management. Er ist eine kontrollierte Risikoreduzierung vor einer großen Investitionsentscheidung. Genau deshalb ist Disziplin an dieser Stelle auch viel wichtiger als bloßer Enthusiasmus.

Was sollten Sie also konkret anders machen, wenn das nächste Mal ein Anbieter oder ein motiviertes Team mit der Idee um die Ecke kommt, man könne das ja „einfach mal kurz testen“?

Konkrete Maßnahmen + Schluss

Schauen wir uns an, wie Sie das in der Praxis umsetzen.

Erstens: Verlangen Sie ein einseitiges PoC-Briefing, bevor überhaupt der erste technische Workshop stattfindet. Wirklich nur eine Seite. Kein Foliensatz, der mit jedem Termin dicker wird, und auch keine zehn Seiten voll mit Marketing-Floskeln der Anbieter. Dieses Dokument benennt klipp und klar das Problem, den Verantwortlichen, die Hypothese, die Metriken und den Scope.

Diese eine Seite leistet oft mehr Arbeit als drei Kick-off-Meetings zusammen. Sie zwingt die Organisation nämlich dazu, schriftlich festzuhalten, welches Problem gelöst werden soll und wer für das Ergebnis am Ende den Kopf hinhält. Wenn Ihr Team das nicht präzise aufschreiben kann, dann ist es schlichtweg zu früh, um mit dem Testen zu beginnen. Sie befinden sich dann noch in der Phase der Ideensammlung, was völlig in Ordnung ist, aber dann sollten Sie es auch so nennen.

Das verändert übrigens auch die Qualität der Gespräche mit Ihren Dienstleistern. Sobald dieses Briefing existiert, wird die Diskussion sehr schnell sehr sachlich. Sie fragen dann nicht mehr allgemein, was die Lösung alles theoretisch kann, sondern Sie fragen ganz gezielt, ob die Lösung diese eine definierte Frage unter Ihren spezifischen Bedingungen beantworten kann. Das ist ein völlig anderes Niveau der Unterhaltung und meistens auch ein deutlich ehrlicheres.

Zweitens: Definieren Sie die Must-Kriterien und die Abbruchbedingungen schriftlich. Dazu gehören der Budgetrahmen und ein festes Zeitfenster. Legen Sie genau fest, an welchem Punkt der PoC endet, selbst wenn die Beteiligten gerade noch voller Begeisterung sind.

Das klingt vielleicht etwas starr, aber das ist auch gut so.

Ein PoC ohne klare Abbruchbedingungen neigt dazu, allein durch Optimismus am Leben zu bleiben. Es findet sich immer jemand, der noch ein Meeting, einen weiteren Testfall oder eine zusätzliche Schnittstelle braucht. Weil niemand aufgeschrieben hat, wo der Test eigentlich aufhört, treibt das Projekt einfach weiter, ohne jemals einer echten Entscheidung näher zu kommen. Schriftliche Stopp-Bedingungen schützen Ihr Team vor diesem Drift und bewahren das Unternehmen davor, Geld in ein Projekt zu stecken, das niemand mehr zu stoppen wagt.

Die Must-Kriterien sind aus dem gleichen Grund so wichtig. Wenn ein PoC die Bedingungen verfehlt, die später über das Risiko entscheiden, dann rettet ihn auch keine noch so schöne Abschlusspräsentation mehr. Er ist dann im Entscheidungstest durchgefallen, was überhaupt kein Problem ist, denn genau dafür machen wir den PoC ja so früh.

Drittens: Halten Sie den ersten PoC so klein, dass ein No-Go finanziell und politisch jederzeit möglich bleibt.

Dieser letzte Punkt ist entscheidend. Günstig bezieht sich hier nicht nur auf das Geld, sondern auch auf das interne Ego und die Sichtbarkeit der Sponsoren. Wenn der erste PoC zu groß aufgezogen wird, entsteht oft ein stiller Druck, das Projekt fortzusetzen, weil schon zu viel Aufmerksamkeit hineingeflossen ist. Sobald das passiert, wird die Entscheidung verzerrt, und man fragt nicht mehr nach dem Nutzen, sondern nur noch nach der Rechtfertigung für das, was man bereits angefangen hat.

Ein kleinerer PoC hält die Organisation ehrlich. Wenn es funktioniert, haben Sie ein sauberes Fundament für den nächsten Schritt. Wenn es nicht funktioniert, kann das Unternehmen die Reißleine ziehen, ohne dass daraus ein politisches Drama wird. Ein frühes Nein ist fast immer billiger als ein schwaches Ja, das sich dann mühsam in die Implementierung schleppt.

Bevor Sie also den nächsten PoC freigeben, nutzen Sie zwei kurze Checks.

Erstens: Testet dieser PoC wirklich eine Entscheidung oder versteckt er in Wahrheit fünf ungelöste Architekturfragen? Wenn er eigentlich einen Use Case validieren soll, aber nebenbei noch die Data Governance, die Schnittstellenstrategie und das Sicherheitsdesign lösen muss, dann ist er überladen. Trennen Sie diese Probleme voneinander, denn ein PoC kann fehlende Architekturentscheidungen an anderer Stelle nicht kompensieren.

Zweitens: Wer wird das Ergebnis später wahrscheinlich ablehnen, weil er jetzt noch nicht eingebunden ist? Stellen Sie diese Frage frühzeitig, solange man es noch leicht korrigieren kann. Es gibt fast immer eine Gruppe, die erst eingeladen wird, wenn das Ergebnis schon auf dem Tisch liegt. Dann wird plötzlich der Aufbau oder die Übertragbarkeit infrage gestellt, und meistens haben diese Leute sogar recht. Holen Sie sie also vorher ab.

Klartext: Gute PoCs beweisen keinen Ehrgeiz. Sie legen die Realität so früh offen, dass Sie noch darauf reagieren können.

Das war IT for Business.

Wenn Sie eine Sache aus dieser Folge mitnehmen, dann diese: Gute IT entscheidet sich nicht im Tool selbst. Sie entscheidet sich in der Architektur und in den Weichenstellungen, die Sie vor dem Tool vornehmen.

Wenn Ihnen diese Folge gefallen hat, abonnieren Sie den Podcast, damit Sie die nächsten Analysen zu praktischen IT-Entscheidungen nicht verpassen.

Und wenn Sie gerade vor einem neuen Projekt oder einer Modernisierung stehen: Sprechen Sie mit Ihrem Team, bevor Sie irgendetwas unterschreiben. Stellen Sie die harten Fragen jetzt und nicht erst später im laufenden Betrieb.

Bis zum nächsten Mal.