Warum eine user-zentrische B2B-Anwendung weit mehr ist als ihr Frontend

Was KI-gestützte Entwicklung wirklich verändert — und welche Schichten sie unberührt lässt

Seit KI-gestützte Entwicklung und „Vibe Coding" den Softwarebau beschleunigen, hört man in Entscheider-Runden eine naheliegende Einschätzung: Wenn ein Modell die Oberfläche einer Vertriebs-Intelligenz-Software an einem Wochenende generiert, dann sei so eine Anwendung im Kern doch ein Frontend-Projekt — schnell gemacht, gut beherrschbar. Die Einschätzung stimmt für den sichtbaren Teil. Sie unterschätzt, woraus eine user-zentrische B2B-Anwendung tatsächlich besteht.

Was die neuen Werkzeuge verändern, ist real: Die Entwicklung der Oberfläche — über Jahre ein spürbarer Aufwandstreiber in solchen Projekten — ist deutlich schneller und günstiger geworden. Was früher Wochen an Frontend-Arbeit bedeutete, lässt sich heute in einem Bruchteil der Zeit erzeugen. Das senkt die Einstiegshürde für datengestützte Vertriebstools messbar.

Nur ist die Oberfläche nicht die Anwendung, sondern ihr Fenster. Sie schnell zu bauen ist etwas anderes, als zu wissen, welche Empfehlung ein Vertriebsteam im Alltag tatsächlich nutzt — statt sie nach drei Wochen zu ignorieren. Die KI hat den sichtbaren Aufwand reduziert; den, der über Adoption und Nutzen entscheidet, hat sie unberührt gelassen. Wer ein anspruchsvolles Design-In-Assistenztool baut, arbeitet an einem Stapel von Kompetenzschichten, von denen der Frontend-Code die dünnste und am leichtesten reproduzierbare ist. Darunter entsteht der Aufwand, der eine bloße Oberfläche von einer nutzbaren Anwendung unterscheidet.

Die Empfehlungslogik: von generisch zu kontextrelevant, priorisiert und aktionsorientiert

Im Kern eines solchen Tools steht eine Empfehlungslogik, die aus Daten vertrieblich relevante Vorschläge macht — Cross-Sell, Up-Sell, Alternativprodukte, BOM-Ergänzungen im Kontext einer konkreten Kundenopportunität. Das klingt nach einem gelösten Problem, ist es aber nicht, sobald man den Anspruch ernst nimmt: Der Unterschied entscheidet sich zwischen einer generischen und einer kontextspezifischen Empfehlung.

Generisch heißt: ein Vorschlag, der für viele Situationen plausibel klingt und deshalb in keiner wirklich trägt. Ein Vertriebsmitarbeiter braucht das Gegenteil — einen Vorschlag, der im Kontext genau dieser Kundenopportunität relevant ist: bezogen auf Zielapplikation, Kunden- und Branchensegment, Projektstadium, das registrierte Produktumfeld und die Historie vergleichbarer Vorgänge. Erst dieser Kontext macht aus einer technisch denkbaren Empfehlung eine, die der Vertriebler dem Kunden gegenüber vertreten kann.

Kontextrelevanz allein genügt jedoch nicht, wenn am Ende zwanzig zutreffende Vorschläge nebeneinanderstehen. Eine brauchbare Logik wertet die gesamte verfügbare Datenbasis aus — Transaktionshistorie, Stammdaten, Opportunity-Kontext, Referenzdesigns, Expertenwissen — und leitet daraus nicht nur ab, was passt, sondern in welcher Reihenfolge. Diese Priorisierung ist der eigentliche Hebel: Sie bringt die Empfehlungen nach oben, die im jeweiligen Moment den größten Beitrag zu Design-In und BOM-Abdeckung leisten, und macht damit gerade jene Chancen sichtbar, die außerhalb des primären Vertriebsfokus liegen und in manueller Durchsicht regelmäßig untergehen.

Der letzte Schritt entscheidet, ob aus einer guten Empfehlung eine Handlung wird: Sie muss aktionsorientiert sein. Ein richtiger, gut priorisierter Vorschlag, der im Nichts endet, verpufft im Alltag. Erst wenn eine Empfehlung unmittelbar anschlussfähig ist — mit Produktdetails zur Hand, als Aufgabe im Projektkontext, per Export mit dem Endkunden teilbar — wird sie Teil des Vertriebsprozesses statt einer weiteren Information, die der Nutzer erst selbst in Handlungen übersetzen müsste.

Genau hier zeigt sich der erste unterschätzte Aufwand: Eine Empfehlungslogik, die Kontextrelevanz, Priorisierung und Aktionsorientierung über die Gesamtheit der Datenpunkte leistet, ist das Ergebnis vieler Iterationen mit echten Nutzern — die über Generationen verfeinerte Abstimmung zwischen Datenauswertung und dem, worauf ein Vertriebsteam tatsächlich reagiert, nicht das Nebenprodukt eines guten Algorithmus.

Data Intelligence: die unglamouröse Arbeit, die über alles entscheidet

Unter der Empfehlungslogik liegt die Schicht, die in Eigenentwicklungen am regelmäßigsten unterschätzt wird: die Aufbereitung der Daten selbst. Empfehlungsqualität ist immer nur so gut wie die Datenbasis, auf der sie beruht — und reale Vertriebsdaten sind selten sauber.

Sie kommen aus heterogenen Quellen, in unterschiedlichen Formaten, mit inkonsistenten Bezeichnungen, Lücken und Widersprüchen. Bevor daraus eine brauchbare Empfehlung entsteht, müssen diese Quellen bereinigt, angereichert und auf eine konsistente Produkt- und Applikations-Taxonomie abgebildet, Konflikte aufgelöst und dünne Historien ergänzt werden — eine über mehrere Projektgenerationen verfeinerte Methode, die den Löwenanteil des Aufwands ausmacht, lange bevor die erste Empfehlung auf einem Bildschirm erscheint. Übersehen wird diese Schicht, weil sie unsichtbar ist: Man sieht das Frontend und die Empfehlung, nicht die Wochen an Taxonomie-Mapping und Konsistenzprüfung, ohne die beide wertlos wären.

Das Frontend: schneller gebaut, aber nicht trivial entschieden

Gerade weil die Oberfläche früher so aufwändig war, ist die KI-getriebene Beschleunigung hier ein echter Gewinn — und genau deshalb lohnt der Blick, was sie abnimmt und was nicht. Sie beschleunigt das Bauen des Frontends; sie trifft nicht die Entscheidungen, die ein gutes Frontend ausmachen.

Denn dessen Wert lag nie allein in den Pixeln oder in der Bauzeit. Er liegt in den hunderten geschäfts- und nutzergetriebenen Entscheidungen, die in ihm kodiert sind: Welche Anwendungsfälle werden sichtbar gemacht und welche bewusst weggelassen? Wie bleibt der Inhalt relevant und ablenkungsfrei, statt den Nutzer mit Optionen zu erschlagen? Wie arbeiten Innendienst, Außendienst und Applikationsingenieur im selben Werkzeug zusammen? Diese Fragen kosteten auch früher nicht primär Entwicklungszeit — sie kosteten Erkenntnis. Und dieser Teil ist durch KI nicht billiger geworden.

Eine KI kann ein Frontend generieren, heute schneller als je zuvor. Sie kann einem nicht sagen, welches Frontend ein Vertriebsteam zum Handeln bringt. Das Interface ist die Verkörperung von Produktentscheidungen aus echtem Nutzerkontakt — die Bauzeit dafür ist gesunken, der Erkenntnisaufwand dahinter nicht.

Adoption: das häufigste Scheitern hat nichts mit Software zu tun

Über Erfolg oder Misserfolg entscheidet am Ende die Schicht, die am wenigsten mit Technik zu tun hat. Das häufigste Scheitern interner Werkzeuge ist nicht, dass sie nicht gebaut werden können — sondern dass sie gebaut und dann nicht genutzt werden.

Der Kontext dafür ist strukturell, nicht motivational. Wenn ein erheblicher Teil der Arbeitszeit im B2B-Vertrieb auf administrative Tätigkeiten entfällt — verschiedene Untersuchungen verorten den Anteil nicht-verkaufender Tätigkeiten bei rund zwei Dritteln — dann ist ein neues Tool zunächst zusätzliche Komplexität in einem ohnehin überladenen Alltag. Es setzt sich nur durch, wenn es spürbar mehr Zeit zurückgibt, als es kostet, und wenn die Einführung aktiv begleitet wird.

Adoption ist deshalb eine eigene Kompetenz: Nutzer-Onboarding, Training, laufende Betreuung, regelmäßige Feedback-Zyklen, das kontinuierliche Nachschärfen dessen, was das Tool zeigt. Diese Arbeit lässt sich nicht in Code gießen. Sie kommt aus der Erfahrung, schon einmal ein solches Werkzeug in einer echten Organisation zum Laufen gebracht zu haben — und beobachtet zu haben, woran andere gescheitert sind.

KI hilft auch unterhalb des Frontends — aber nur mit Verständnis

KI liefert einen signifikanten Beitrag auch über das Frontend hinaus: bei Datenbereinigung, Taxonomie-Mapping, Backend-Komponenten, der Empfehlungslogik selbst. Der Unterschied liegt nicht darin, ob sie hilft, sondern wie man diese Hilfe nutzen kann.

An der Oberfläche lässt sich ein generiertes Ergebnis durch Hinsehen beurteilen — man erkennt, ob ein Element sitzt. In den darunterliegenden Schichten geht das nicht. Ob eine Taxonomie-Zuordnung fachlich stimmt, eine Konfliktauflösung die vertrieblich sinnvolle war, eine Empfehlung im Opportunity-Kontext trägt oder nur plausibel aussieht, lässt sich nicht ansehen. Es setzt ein tiefgehendes Verständnis der Datenstrukturen und ihrer Zusammenhänge voraus — ohne das ist eine belastbare Umsetzung nicht möglich, und einfaches Kopieren KI-generierter Ergebnisse produziert schwer erkennbare Fehler.

Damit ist auch die naheliegende Rückfrage beantwortet, ob KI die Datenintelligenz künftig ganz übernimmt. Ein Teil davon wird automatisierbar — Schema-Abgleich, Dublettenerkennung, Zuordnungsvorschläge werden besser. Aber „richtig" ist hier kein technischer, sondern ein fachlicher Maßstab, der außerhalb der Daten liegt: im realen Verhalten von Applikationen, Kunden und Vertrieb. Ein Modell erzeugt eine plausibel aussehende Antwort; ob sie stimmt, kann nur beurteilen, wer den fachlichen Sollzustand kennt. Auch ein bereits vorliegendes Vorhersagemodell ist nur eine Grundlage — es hebt die Decke des Möglichen, ersetzt aber die darüberliegenden Schichten nicht.

Daraus folgt keine Zurückhaltung, sondern das Gegenteil: Es gilt, die Möglichkeiten von KI und LLMs in der Datenintelligenz proaktiv zu nutzen — überall dort, wo es geschäftlich und technisch sinnvoll ist. Der Hebel ist beträchtlich, von der Beschleunigung mühsamer Aufbereitung bis zur Anreicherung dünner Datenbestände. Entscheidend ist nur, dass der Einsatz von jemandem gesteuert wird, der die Datenstrukturen und ihre Zusammenhänge durchdringt. So verschiebt KI die Arbeit vom Erzeugen zum Beurteilen — und macht das fachliche Urteil nicht überflüssig, sondern zum eigentlichen Werthebel.

Was am Ende zählt

Die Enterprise-taugliche Basis, die das alles trägt, kommt noch obendrauf: ein skalierbares, mandantenfähiges Backend mit Datenisolation und rollenbasiertem Zugriff, Hosting nach Unternehmensrichtlinie, Sicherheit, Compliance, Backup — und die Fähigkeit, ohne initiale Integrationen zu starten und dennoch später per API sauber ins ERP- und CRM-Umfeld anzudocken. Auch das ist Aufwand, der in keiner Frontend-Demo sichtbar wird.

Rechnet man diese Schichten zusammen, wird deutlich, wie wenig eine user-zentrische B2B-Anwendung mit ihrem Frontend allein zu tun hat. Der Code ist reproduzierbar, die Oberfläche heute so schnell wie nie. Was nicht schneller geworden ist, ist das angesammelte Urteilsvermögen darüber, was man bauen muss: welche Empfehlungen Nutzer akzeptieren, wie man Vertriebsdaten empfehlungsreif macht, welche Anwendungsfälle wirklich zählen, und wie man ein Team dazu bringt, das Werkzeug zu benutzen. Das ist die eigentliche Konsequenz der KI-Beschleunigung: Sie senkt einen real teuren Aufwand — und macht den Blick auf die Schichten frei, die sie nicht abnimmt. Eine Anwendung, die von der ersten Version an im Vertrieb ankommt, entsteht nicht an der Oberfläche, sondern in dem, was darunter über Jahre zusammenwächst.

Über dieses eine Tool hinaus

Was hier am Beispiel eines Design-In-Assistenztools sichtbar wird, ist kein Sonderfall der Elektronikbranche, sondern das Grundmuster von Geschäftsanwendungen in der KI-Ära. Je günstiger das Erzeugen von Software wird, desto deutlicher verlagert sich der Engpass auf das, was Software nie allein war: das Verständnis des Geschäfts, in das sie eingreift, der Prozesse, die sie verändern soll, und der Systemlandschaft, in der sie bestehen muss. Eine Geschäftsherausforderung wirklich zu lösen, setzt das Zusammenspiel dieser drei Wissensarten voraus — und keine davon fällt als Nebenprodukt guten Codes ab.

Hinzu kommt, dass Nutzeranforderungen kein fixer Zielpunkt sind, den man einmal trifft. Sie verschieben sich mit Markt, Portfolio und den Menschen, die das Werkzeug bedienen. Eine tragfähige Lösung ist deshalb weniger ein fertiges Produkt als eine fortlaufende Auseinandersetzung mit sich wandelnden Anforderungen — ein Prozess, der nicht endet, wenn die erste Version ausgeliefert ist. Die KI beschleunigt das Bauen. Die kontinuierliche Arbeit am Verstehen beschleunigt sie nicht — und genau dort entscheidet sich, ob eine Geschäftsanwendung über ihre erste Version hinaus relevant bleibt.