KI-Projekte, welche mit der Technologiefrage starten statt mit den Prozessen, in denen heute Wert
verloren geht, bleiben meist im Pilot stecken.
Der richtige Einstieg ist umgekehrt: zuerst die Pain Points in den Kernprozessen identifizieren,
daraus Use Cases ableiten, priorisieren und erst danach Technologie wählen.
Es bedeutet, dass KI kein eigenständiges System ist, sondern eine Schicht, die auf den Daten und Prozessen operiert, die bereits existieren. KI verbessert die Architektur darunter nicht, sondern verstärkt sie. In beide Richtungen.
KI-Funktionalität, die direkt auf dem Datenmodell und in den Workflows eines operativen Systems eingebettet ist, etwa Lead-Scoring, Cross-Selling-Vorhersagen oder Service-Automatisierung innerhalb der Customer Plattform. Im Gegensatz zur Produktivitäts-KI (eigenständige Assistenten ohne Zugriff auf die Geschäftsprozesse) ist prozessintegrierte KI immer nur so leistungsfähig wie die Datenbasis, auf der sie aufsetzt.
Liegt eine saubere, zentralisierte Datenbasis vor, multipliziert KI die Wertschöpfung: Sie automatisiert Workflows, liefert verlässliche Vorhersagen, personalisiert Kundeninteraktionen über die gesamte Customer Journey. Liegt Datenchaos vor, entsteht kein intelligenter Mehrwert, sondern eine beschleunigte Verstärkung bestehender Probleme. KI ist nur so gut wie die Daten, Prozesse und Wissensquellen, auf die sie zugreift. Sind diese unvollständig, veraltet, widersprüchlich oder schlecht strukturiert, liefert KI falsche Empfehlungen, unzuverlässige Antworten oder automatisiert sogar fehlerhafte Entscheidungen.
Für die Geschäftsleitung heisst das: KI ist kein Ersatz für saubere Datenführung. Sie macht Datenqualität sichtbar und erhöht den Druck, diese zu beheben. Ohne solide Datenbasis entstehen Risiken in Effizienz, Entscheidungsqualität, Compliance und Vertrauen der Mitarbeitenden.
Geschäftsleitungen müssen drei Kategorien klar trennen: Produktivitäts-KI, prozessintegrierte KI und KI-Agenten. Sie unterscheiden sich grundlegend in dem, was sie tun, was sie kosten und, am wichtigsten, welche Voraussetzungen sie an Ihre Datenarchitektur stellen.
Die Voraussetzungen an Ihre Architektur steigen mit jeder Stufe: Produktivitäts-KI verlangt nichts. Prozessintegrierte KI verlangt eine saubere, zentralisierte Datenbasis. KI-Agenten verlangen darüber hinaus klar definierte Prozesse, sauber geregelte Zugriffsrechte, definierte Eskalationspfade und eine Governance, die festlegt, wo der Agent eigenständig handeln darf und wo der Mensch zwingend einbezogen wird. Wer agentische KI auf einen unaufgeräumten Stack setzt, vervielfacht die Risiken der prozessintegrierten KI, jetzt mit Handlungsvollmacht.
Der häufigste strategische Fehler auf Geschäftsleitungsebene: Man führt Produktivitäts-KI ein, sieht einen echten Nutzen und schliesst daraus, man sei «mit KI unterwegs». Man verwechselt das schnelle, einfache Werkzeug mit dem langsamen, anspruchsvollen Hebel. Wer KI als Wachstumstreiber will, meint prozessintegrierte KI oder Agenten. Und beide beginnen nicht mit einem KI-Tool, sondern mit der Datenarchitektur.
KI-fähig wird eine Architektur, wenn kundenrelevante Daten zentral, konsistent und über die gesamte Customer Journey zugänglich sind und wenn das CRM die Quelle der Wahrheit ist und nicht das Backup für den Excel-Friedhof.
Der Unterbau ist derselbe, den jedes moderne Unternehmen ohnehin braucht: ein ERP als finanziell-operative Wahrheit und eine Customer Plattform als kundenseitige Wahrheit, sauber über offene Schnittstellen verbunden. Drittsysteme ergänzen situativ. Wer diesen Kern nicht hat, hat keine KI-Frage. Er hat eine Architektur-Frage, die er zuerst lösen muss.
Hier liegt die unterschätzte Stärke einer modernen Customer Plattform wie HubSpot: Smart CRM, Marketing Hub, Sales Hub und Service Hub teilen sich ein gemeinsames Datenmodell, und Breeze AI als KI-Schicht operiert direkt darauf. Was in einem fragmentierten Stack ein massives Daten-Engineering-Projekt wäre, ist hier Standard-Funktionalität. Nicht, weil HubSpot eine bessere KI hätte, sondern weil die Architektur darunter stimmt.
KI-Projekte scheitern typischerweise an drei wiederkehrenden Mustern: dem KI-Projekt ohne Use Case, der KI auf dem Datensilo und der KI, die niemandem gehört.
Das Projekt startet mit «Wir müssen etwas mit KI machen» statt mit einem konkreten, messbaren Geschäftsfall, einem Business Case mit klar benanntem Problem, klarer Chance oder klarem Potenzial. Es gibt kein Zielbild, keine Kennzahl, an der sich Erfolg festmachen liesse. Entsprechend lässt sich am Ende auch nicht sagen, ob das Projekt funktioniert hat. KI ohne Geschäftsfall ist eine Lösung, die noch ihre Frage sucht. Solche Projekte versanden, sobald die anfängliche Begeisterung nachlässt.
Das Unternehmen setzt eine KI-Funktion auf eine fragmentierte Datenlandschaft und erwartet belastbare Ergebnisse. Die KI greift auf eine Teilwahrheit zu, weil die andere Hälfte der Daten in einem System liegt, das sie nicht sieht. Die Vorschläge sind plausibel formuliert und inhaltlich falsch. Nach den ersten schlechten Empfehlungen verlieren Sales und Service das Vertrauen und benutzen die KI nicht mehr. Das Tool läuft weiter, die Lizenz wird bezahlt, der Nutzen ist null.
Niemand verantwortet durchgängig, welche KI-Funktionen eingesetzt werden, auf welchen Daten sie operieren und wer ihre Qualität überwacht. KI-Initiativen entstehen verstreut in einzelnen Abteilungen, ohne gemeinsame Datengrundlage und ohne gemeinsame Governance. Das Resultat ist dasselbe wie bei Tool-Anarchie: Vielfalt ohne Architektur. Ohne klare Verantwortung wird KI nicht zum Hebel, sondern zum nächsten unkoordinierten Wildwuchs.