CRM und ERP an ein Sprachmodell anschließen · die Architektur in vier Schichten

Jedes ernsthafte KI-Vorhaben endet innerhalb weniger Wochen bei derselben Frage: Wie kommt das Modell an die Daten, mit denen wir tatsächlich arbeiten? Solange es sie nicht hat, beantwortet es allgemeine Fragen gut und die eigenen gar nicht. Es kennt den Auftragsbestand nicht, es sieht die Kontakthistorie nicht, und die Preisliste, die es zitiert, hat es sich ausgedacht.

Dieser Beitrag beschreibt den Weg dorthin: die drei Hürden, an denen Anbindungen üblicherweise scheitern, die Architektur, die sie umgeht, und die Zeiten, die wir für einzelne Systeme gemessen haben.

Drei Hürden, immer dieselben

• Jedes System spricht anders. Vertriebssystem, Warenwirtschaft, Postfach und Datenbank haben nichts gemeinsam außer dem Haus, in dem sie stehen. Ohne gemeinsames Protokoll wird jede Verbindung einzeln entwickelt, und der Aufwand fällt bei jeder weiteren Quelle erneut an.
• Die Daten verlassen das Haus. Werkzeuge, die als Dienst aus fremden Rechenzentren laufen, schicken Vertragsinhalte und Kundendaten dorthin. In regulierten Branchen ist das keine Abwägung, sondern ein Ausschlussgrund.
• Der Aufwand bindet die Entwicklung. Eine Sonderlösung je Quelle beschäftigt genau die Leute, die ohnehin ausgelastet sind, und macht jede Aktualisierung des Fachsystems zu einer Übung in Vorsicht.

Die dritte Hürde ist die teuerste, und sie zeigt sich erst spät. Bei einer Quelle ist eine Sonderlösung vernünftig. Bei drei Quellen ist sie eine Abteilung.

Ein Protokoll statt einer Schnittstelle je Quelle

Das Model Context Protocol ist ein offener Standard für genau diese Vermittlung. Statt jedes Fachsystem einzeln an jedes Modell zu binden, stellt ein MCP-Dienst die Quelle einmal standardisiert bereit. Was danach mit welchem Modell darauf zugreift, ist eine Frage der Konfiguration und nicht der Programmierung.

Das Protokoll kennt drei Bausteine, und mehr braucht es nicht.

• Resources sind die Daten: Dateien, Datensätze, Antworten anderer Schnittstellen. Jede Quelle wird zu einer einheitlich abfragbaren Ressource.
• Tools sind die Handlungen: einen Vorgang anlegen, eine Bestellung prüfen, eine Nachricht versenden. Ein Tool legt fest, welche Operation erlaubt ist und welche Parameter sie verlangt.
• Prompts sind die Bahnen: vorbereitete Abläufe, die ein Agent je nach Zusammenhang aufruft. Sie halten das Vorgehen wiederholbar, statt es dem Zufall der Formulierung zu überlassen.

Der entscheidende Satz steht in der Mitte: Ein Tool legt fest, welche Operation erlaubt ist. Ein Modell kann nichts tun, wofür kein Tool existiert. Diese Grenze ist keine Nebenwirkung, sondern der Grund, warum sich der Ansatz in regulierten Häusern überhaupt einsetzen lässt.

Vier Schichten, eine Architektur

Kein Geflecht aus Punkt-zu-Punkt-Verbindungen. Jede Schicht hat genau eine Aufgabe, und jede lässt sich einzeln austauschen.

• Datenquellen: Vertriebssystem, Warenwirtschaft, Zusammenarbeitsplattform und Dateiablage bleiben, wo sie sind. Nichts wird kopiert, und es entsteht keine zweite Datenhaltung, die auseinanderläuft.
• MCP-Dienste: je System ein Dienst. Er übersetzt Lesen und Schreiben in das Protokoll, setzt die Rechte des aufrufenden Kontos durch und schreibt zu jedem Aufruf einen Protokolleintrag.
• Steuerung: sie leitet eine Anfrage an das passende Modell und an den passenden Anschluss. Hier werden Berechtigungen und Datenklassifizierung durchgesetzt, und hier entscheidet sich, ob eine Anfrage das Haus überhaupt verlassen darf.
• Arbeitsumgebung und Teammates: der Fachbereich arbeitet in der Oberfläche oder mit einer der vorbereiteten Rollen. Wer von MCP nichts wissen will, muss es auch nicht.

Der Vorteil der Trennung zeigt sich beim Wechsel. Ein neues Modell berührt nur die Steuerung. Ein neues Fachsystem berührt nur einen Dienst. In einer Punkt-zu-Punkt-Landschaft berührt beides alles.

Was ein Aufruf hinterlässt

Eine Antwort ohne Herkunft ist in einem geprüften Haus wertlos. Jeder Aufruf hinterlässt deshalb einen Eintrag, der später ohne Rückfrage lesbar ist: wer hat wann über welches Tool welche Daten berührt, mit welchem Ergebnis.

{
  "zeitpunkt": "2026-08-09T09:14:52Z",
  "konto": "[email protected]",
  "rolle": "vertrieb",
  "dienst": "mcp-hubspot",
  "tool": "deal.read",
  "parameter": { "dealId": "41207" },
  "datenklasse": "intern",
  "ergebnis": "ok",
  "dauerMs": 214
}

Zwei Dinge fehlen in diesem Eintrag mit Absicht: der Inhalt des Datensatzes und der Wortlaut der Anfrage. Ein Protokoll, das den Inhalt mitschreibt, ist selbst ein Datenschutzproblem. Nachvollziehbar sein muss der Zugriff, nicht sein Gegenstand.

Wie lange das dauert

Die folgenden Werte stammen aus abgeschlossenen Einführungen zwischen dem vierten Quartal 2025 und dem zweiten Quartal 2026. Sie beschreiben die Einrichtung des Anschlusses, nicht die Einführung eines Anwendungsfalls. Aufwendige Sonderfelder oder Brücken zu Altsystemen liegen darüber.

• HubSpot und Odoo: 2 bis 4 Stunden. Anmeldung und Testumgebung stehen innerhalb von Stunden.
• Nextcloud: 1 bis 2 Stunden. Ein Anwendungskennwort genügt.
• Microsoft 365 und SharePoint: etwa ein halber Tag. Es entscheidet der Geltungsbereich, der für die Sites vergeben wird.
• Salesforce und Dynamics 365: ein halber bis ein Tag, sofern Profile und Rechte gepflegt sind. Sind sie es nicht, ist das die eigentliche Aufgabe.
• SAP S/4HANA: 2 bis 5 Tage. Der OData-Dienst und das Berechtigungswesen geben den Ausschlag, nicht das Protokoll.

Die vollständige Tabelle mit Kategorie, Anmeldeverfahren und Umfang je System steht im Leitfaden zur CRM- und ERP-Integration.

Die Rechte sind die eigentliche Arbeit

Die technische Anbindung ist selten das Problem. Das Problem ist die Frage, die sie stellt: Wer darf was sehen? In den meisten Häusern ist diese Frage im Fachsystem seit Jahren unsauber beantwortet, und sie fällt erst auf, wenn ein Agent mit den Rechten eines Kontos arbeitet und dabei sichtbar macht, wie weit diese Rechte reichen.

Der Grundsatz lautet deshalb: ein Teammate bekommt genau die Rechte, die ein Mensch in derselben Rolle hätte, nicht mehr. Ein Dienstkonto mit Vollzugriff ist bequem, sobald es steht, und es ist der Punkt, an dem eine Prüfung die Einführung anhält.

Vier Fragen vor dem ersten Anschluss

• Welcher Ablauf soll besser werden, und woran wird das erkennbar? Ohne Antwort darauf ist jeder Anschluss ein Selbstzweck.
• Welches System führt? Wenn zwei Quellen einander widersprechen, muss vorher feststehen, welche recht behält.
• Wer verantwortet die Rechte? Nicht die Technik, sondern der Fachbereich, dem die Daten gehören.
• Was passiert bei einem Fehler? Ein Agent, der schreibt, braucht einen Weg zurück, und der gehört vor die erste Schreiboperation.

Womit man anfängt

Mit einem lesenden Zugriff auf ein System, das ohnehin sauber gepflegt ist, und mit einem Ablauf, dessen Nutzen niemand bezweifelt. Schreiboperationen kommen später, wenn die Protokollierung im Betrieb steht und jemand sie regelmäßig ansieht.

Welche Systeme heute fertig angebunden sind, steht auf der Seite zu den MCP-Konnektoren. Wer einen eigenen Dienst für ein System bauen will, das dort nicht steht, findet den Weg im Beitrag Einen eigenen MCP-Server bauen.