Eine Demo ist so konzipiert, dass sie funktioniert. Sie läuft mit vorbereiteten Daten, einem Benutzer mit allen Berechtigungen, folgt dem optimalen Ablauf des Produkts und ohne die Ausnahmen, die im realen Betrieb auftreten. Das ist nicht irreführend: So funktioniert eine Demo. Der Fehler liegt darin, sie als Beweis dafür zu betrachten, dass das System am Montagmorgen in Ihrem Unternehmen einwandfrei funktioniert.
Die Diskrepanz zwischen diesen beiden Faktoren erklärt einen wesentlichen Teil der dokumentierten Projektabbrüche. S&P Global Market Intelligence schätzte im März 2025, dass 421 % der Unternehmen den Großteil ihrer KI-Initiativen aufgegeben hatten, verglichen mit 171 % im Vorjahr. Dabei verwarfen sie durchschnittlich 46 % ihrer Proof-of-Concept-Projekte.
Dimension | In der Demo | Montag in der Produktion |
|---|---|---|
Daten | Ausgewählt und vollständig | Unvollständig, doppelt, widersprüchlich |
Genehmigungen | Benutzer mit vollem Zugriff | Unterschiedliche Rollen, eingeschränkte Sichtbarkeit |
Volumen | Einige Fälle | Tausende, mit Spitzenzeiten und Staus |
Ausnahmen | Keiner | Zwischen 15% und 30% Volumen |
Integration | Kopieren und Einfügen zwischen Bildschirmen | Echte Verbindung mit ERP, CRM und Identität |
Kosten | Irrelevant | Stückkosten, die die Rentabilität bestimmen |
Keine der sechs Spalten auf der rechten Seite lässt sich aus der linken ableiten. Daher liefert eine exzellente Demo keine Informationen über das Projektrisiko, sondern Informationen über die Qualität der Benutzeroberfläche und das bestmögliche Szenario.
Die Lösung besteht nicht darin, Demos zu misstrauen, sondern darin, den Entwickler zu wechseln. Hier sind fünf konkrete Forderungen, die Sie an jeden seriösen Anbieter stellen können:
Erlauben Sie ihnen, Ihre Daten zu verwenden, auch wenn es nicht viel ist. Hundert echte Datensätze, mit ihren Duplikaten und leeren Feldern, lehren mehr als zehntausend synthetische.
Fügen Sie einen von Ihnen ausgewählten seltenen Fall hinzu. Kein gewöhnlicher, seltener Fall: Ihr Fall, mit Ihrer ungeschriebenen Regel. Diese Anfrage unterscheidet jemanden, der ein System entwickelt hat, von jemandem, der eine Präsentation erstellt hat.
Lass es von jemandem aus deinem Team durchführen. Nicht die Werbung. Der Unterschied zwischen dem Zuschauen bei der Benutzung eines Werkzeugs durch einen Experten und der eigenen Benutzung ist oft beträchtlich.
Zeigen Sie, was passiert, wenn es fehlschlägt. Fordern Sie es auf, einen Fehler zu verursachen. Wie es diesen kommuniziert, was es protokolliert und wie es sich davon erholt, sagt mehr über das Produkt aus als jede Funktionalität.
Das ergibt die Kosten pro Fall für Ihr Volumen. Hochgerechnet, einschließlich Wiederholungsversuchen. Wenn Sie es nicht berechnen können, können Sie es auch nicht einplanen.
Ein Lieferant, der alle fünf Bedingungen akzeptiert, wird seine Zusagen voraussichtlich einhalten. Verschiebt er drei davon auf eine «spätere Analysephase», deutet dies darauf hin, wo Kostenüberschreitungen auftreten werden.
Vor der Unterzeichnung empfiehlt es sich, eine bestimmte mentale Übung durchzuführen: Montagmorgen beschreiben.
Ein bestimmter Mitarbeiter mit den ihm zugewiesenen Berechtigungen öffnet das System und bearbeitet den ersten Fall des Tages. Dieser Fall enthält fehlerhaft eingegebene Informationen, der Kunde hat ein offenes Support-Ticket, und es wurde telefonisch eine Vereinbarung getroffen, die in keinem System erfasst ist.
Die zu beantwortenden Fragen:
Kann das Projekt nicht alle fünf Fragen beantworten, ist es nicht produktionsreif, egal wie gut die Demo ist. Das ist dieselbe Diagnose, die wir bereits gestellt haben... das Fegefeuer des Piloten [interner Link], angewendet vor dem Kauf statt danach.
Ein Pilotprojekt ist besser als eine Demo, aber es teilt einen Teil des Problems: Es wird mit freiwilligen Nutzern, unter besonderer Aufsicht des Teams und an einer geeigneten Teilmenge durchgeführt.
Die drei Elemente, die einen Pilotenbericht zu verlässlichen Informationen machen:
Echte Nutzer, keine Enthusiasten. Diejenigen, die es benutzen müssen, nicht diejenigen, die sich angemeldet haben.
Aufeinanderfolgende, nicht ausgewählte Fälle. Alle Fälle einer Woche, inklusive der unschönen.
Ohne außergewöhnliche Unterstützung. Wenn während des Pilotenflugs ein Ingenieur anwesend ist, der auf jeden einzelnen Vorfall achtet, misst der Pilot das System plus den Ingenieur.
Ein so konzipiertes Pilotprogramm kann schlechtere Ergebnisse liefern als ein eher selbstzufriedenes. Diese schlechteren Ergebnisse sind die realen, und sie vor der Ausweitung zu kennen, ist weitaus wertvoller als ein optimistischer Bericht.
Die praktische Schlussfolgerung ist einfach und spart eine Menge Geld: Das Kaufkriterium sollte nicht sein, wie gut die Demo funktioniert, sondern wie gut der Anbieter erklärt, wo sein Produkt Schwächen aufweist..
Ein Anbieter, der seine Einschränkungen, nicht unterstützten Anwendungsfälle und den Umgang mit beschädigten Daten präzise beschreibt, beweist damit, dass er das System in realen Umgebungen eingesetzt hat. Ein Anbieter, der behauptet, alles funktioniere einwandfrei, hat noch nicht einmal den Montagmorgen erreicht.
Da die Demo mit ausgewählten und vollständigen Daten, einem Benutzer mit vollen Berechtigungen, geringem Datenvolumen, ohne Ausnahmen und ohne tatsächliche Integration in bestehende Systeme arbeitet, sind diese Bedingungen im Produktivbetrieb nicht erfüllt und lassen sich auch nicht aus der Demo ableiten.
Fünf Dinge: dass es Ihre eigenen Daten verwendet, auch wenn es nur wenige sind; dass es einen von Ihnen ausgewählten seltenen Fall beinhaltet; dass es von jemandem aus Ihrem Team und nicht vom Vertriebsteam betrieben wird; dass es anzeigt, was passiert, wenn es fehlschlägt; und dass es die Kosten pro Fall auf der Grundlage Ihres tatsächlichen Volumens, einschließlich Wiederholungsversuchen, berechnet.
Eine Evaluierungsübung besteht darin, das erste reale Szenario an einem Montagmorgen zu beschreiben: Ein bestimmter Mitarbeiter mit seinem Berechtigungsprofil bearbeitet einen Fall mit fehlerhaften Daten, ein Kunde hat ein offenes Problem, und es wurde eine mündlich vereinbarte Bedingung festgelegt. Kann die Situation nicht beschrieben werden, ist das System noch nicht einsatzbereit.
Nur wenn es gut konzipiert ist. Es muss mit echten Nutzern, nicht mit enthusiastischen Freiwilligen, an aufeinanderfolgenden, nicht ausgewählten Anwendungsfällen und ohne besondere Unterstützung des technischen Teams durchgeführt werden. Andernfalls misst es das System und die günstigen Rahmenbedingungen.
S&P Global Market Intelligence berichtete im März 2025, dass Unternehmen durchschnittlich 461 TP3T ihrer Proof-of-Concept-Projekte verwerfen und dass 421 TP3T ihre KI-Initiativen größtenteils aufgegeben haben, verglichen mit 171 TP3T im Vorjahr.
Es kommt nicht darauf an, wie gut die Demo funktioniert, sondern darauf, wie präzise der Anbieter die Grenzen seines Produkts erläutert: welche Anwendungsfälle es nicht unterstützt, wie es sich bei unvollständigen Daten verhält und was im Fehlerfall passiert. Diese Fähigkeit zeugt von praktischer Produktionserfahrung.
Werden Sie die Lieferanten bewerten? Wir können die Kriterien definieren, den Test mit Ihren Daten konzipieren und die Angebote anhand unabhängiger technischer Kriterien bewerten, ohne uns selbst als Kandidaten zu präsentieren. Lass uns reden →