Um acht Uhr fragt ein Außendienstmitarbeiter seinen KI-Copiloten: „Welche Angebote sind noch offen, und welcher Kunde wartet auf eine Rückmeldung?“ Die Fakturierung läuft gleichzeitig in SAP, das CRM synchronisiert Kundendaten mit einem zwanzig Jahre alten Host-System, und ein separates Berichtssystem aktualisiert seine Daten zeitversetzt. Liefert der Copilot trotzdem eine Antwort, klingt sie vielleicht präzise. Ohne funktionierende System Interoperability bleibt sie jedoch ein Bauchgefühl.
Zwei Unternehmen können dasselbe Sprachmodell einsetzen und völlig unterschiedliche Ergebnisse erzielen. Im einen Unternehmen darf der Agent über definierte Schnittstellen aktuelle Aufträge lesen, Kundendaten abgleichen und nur freigegebene Aktionen auslösen. Im anderen sieht er veraltete Exporte, uneinheitliche Begriffe und unklare Berechtigungen. Das Modell ist nicht automatisch schlechter. Ihm fehlen verlässliche Verbindungen.
Der Wert entsteht deshalb immer stärker an der Schnittstelle zwischen Large Language Model, Tools und Legacy-Daten. Integrationsarchitektur wird zur Wettbewerbsfrage für AI Agents, weil erst die angeschlossenen Systeme aus einer sprachlich überzeugenden Antwort einen belastbaren Geschäftsvorgang machen.
Inhaltsverzeichnis
- Warum System Interoperability plötzlich über KI-Wert entscheidet
- Was System Interoperability im Unternehmen wirklich bedeutet
- Integrationsmuster im Vergleich API Connector und MCP
- Datenmodelle Authentifizierung und Autorisierung im Verbund
- Latenz Fehlerbehandlung und Idempotenz in der Praxis
- Governance Observability und Reifegrade für Integrationslandschaften
- Entscheidungsleitfaden und 90-Tage-Fahrplan für mehr System Interoperability
Warum System Interoperability plötzlich über KI-Wert entscheidet
Der Vertriebsmitarbeiter braucht keine allgemeine Zusammenfassung. Er braucht den aktuellen Status eines Angebots, den korrekten Debitor, die letzte Aktivität im CRM und eine klare Grenze zwischen Lesen und Buchen. Ein Agent, der diese Informationen aus drei Systemen zusammenführt, kann Arbeit abnehmen. Ein Agent, der nur auf Dokumente aus einem alten Export zugreift, erzeugt zusätzliche Prüfungen.
Der gleiche Agent, zwei vollkommen andere Ergebnisse
Im ersten Unternehmen besitzt jedes System eine klar beschriebene Rolle. SAP liefert Auftrags- und Rechnungsdaten, das CRM verwaltet Aktivitäten und Beziehungen, das Host-System stellt historische Kontoinformationen bereit. Ein Orchestrator ruft die passenden Funktionen auf, gleicht Identifier ab und schreibt die Antwort mit Quellen und Zeitstempeln zurück.
Im zweiten Unternehmen wurden über Jahre Einzellösungen ergänzt. Ein nächtlicher Export überschreibt Felder, ein Skript kennt eine lokale Kundennummer, und niemand kann sicher sagen, ob „offenes Angebot“ den Status im CRM oder den Buchungsstatus im ERP meint. Der Copilot kann daraus einen grammatikalisch perfekten Text formulieren, aber keine belastbare Entscheidung ableiten.
Praktische Regel: Ein AI Agent ist nur so verlässlich wie die Daten, Aktionen und Berechtigungen, die seine Systemverbindungen kontrollieren.
Österreich zeigt, dass Interoperabilität auch auf Verwaltungsebene mehrschichtig gedacht werden kann. Im Länderprofil zum European Interoperability Framework Monitoring Mechanism 2023 lag Österreich in den Scoreboards 2 und 3 in allen Dimensionen auf Stufe 3 oder 4. Für sieben Prinzipien der grenzüberschreitenden Interoperabilität wurde der Maximalwert 4 erreicht. Gleichzeitig nennt die Auswertung weiteres Verbesserungspotenzial, unter anderem bei Mehrsprachigkeit, administrativer Vereinfachung und einzelnen grenzüberschreitenden Prozessen.
Für Unternehmen ist der Schluss klar: KI-Qualität beginnt nicht beim Prompt, sondern bei konsistenten Datenwegen, eindeutigen Aktionen und kontrolliertem Zugriff. Wer einen Agent an einen alten Host, ein ERP und ein CRM anschliesst, baut keine Chatfunktion. Er baut eine neue operative Schnittstelle.
Was System Interoperability im Unternehmen wirklich bedeutet
System Interoperability bedeutet, dass unterschiedliche Systeme Informationen austauschen und in ihrem jeweiligen Kontext korrekt verwenden können. Eine erreichbare API allein reicht dafür nicht. Die beteiligten Anwendungen müssen dieselben Daten sinnvoll interpretieren, Prozesse abstimmen und rechtliche Regeln einhalten.
Das European Interoperability Framework ordnet diese Aufgabe in vier Ebenen ein. Diese Ebenen helfen, eine ERP-CRM-Landschaft nicht nur technisch, sondern als vollständiges Betriebsmodell zu prüfen.
Vier Ebenen, ein zusammenhängender Vorgang
| Ebene | Worum es geht | Beispiel im Unternehmen |
|---|---|---|
| Technisch | Protokolle, Schnittstellen und Datenformate | Ein REST-Aufruf gegen die Auftrags-API eines ERP-Systems |
| Semantisch | Gemeinsame Bedeutung von Daten | Buchhaltung und Controlling verwenden dasselbe Verständnis von „Umsatz“ und „Auftrag“ |
| Organisatorisch | Zuständigkeiten und Abläufe zwischen Einheiten | Vertrieb und IT definieren einen Eskalationsweg für fehlerhafte Kundensynchronisation |
| Rechtlich | Zulässigkeit, Nachvollziehbarkeit und Verantwortlichkeiten | Eine DSGVO-konforme Protokollierung dokumentiert Zugriff und Verarbeitung |
Die technische Ebene beantwortet die Frage: Kann System A System B erreichen? Ein JSON-Dokument kann übertragen werden, obwohl das Zielsystem ein anderes Format erwartet. Technische Kompatibilität ist deshalb notwendig, aber nicht ausreichend.
Die semantische Ebene prüft die Bedeutung. Ein CRM kann „Kunde“ als Organisation führen, während das ERP zusätzlich Debitor, Rechnungsempfänger und Lieferadresse unterscheidet. Ohne Mapping-Regeln entstehen scheinbar erfolgreiche Integrationen, die inhaltlich falsche Datensätze erzeugen.
Auf organisatorischer Ebene braucht jede Strecke einen Besitzer. Wer entscheidet bei einem widersprüchlichen Kundenstatus? Wer darf einen Auftrag erneut anstossen? Und wer prüft eine Änderung am Datenmodell?
Die rechtliche Ebene setzt Grenzen für Zugriff, Speicherung und Weitergabe. Dazu gehören Verarbeitungszweck, Rollen, Aufbewahrung und Auditierbarkeit. Die österreichische E-Government-Strategie beschreibt gemeinsame organisatorische, rechtliche und technische Standards von Bund, Ländern, Gemeinden und lokalen Gemeinschaften als Grundlage digitaler Basisdienste. Sie verweist ausserdem auf etablierte Standards wie XML, Webservices und SOAP sowie konsistente Schemata für Register-, Personen- und Organisationsdaten in der österreichischen E-Government-Strategie 2023.
Spiegeln Sie Ihre eigene Landschaft gegen diese vier Ebenen. Wenn eine davon ungeklärt bleibt, wird der AI Agent später genau an dieser Stelle unsicher.
Integrationsmuster im Vergleich API Connector und MCP
API, Connector und MCP beantworten dieselbe Grundfrage: Wie kommt ein System kontrolliert an ein anderes? Sie liegen aber auf unterschiedlichen Abstraktionsebenen und passen zu unterschiedlichen Integrationsproblemen.
API als direkte Systemsprache
Eine API ist der direkte Vertrag zwischen Anwendungen. Eine S/4HANA-OData-API kann Aufträge, Geschäftspartner oder Belege in definierten Ressourcen bereitstellen. Das Team kontrolliert Versionierung, Payload, Fehlercodes und Berechtigungen selbst.
Die Stärke liegt in der Präzision. Die Schwäche liegt im Aufwand, besonders bei alten Kernsystemen. Für jeden Sonderfall müssen Entwickler Authentifizierung, Mapping, Fehlerbehandlung und Betriebsüberwachung berücksichtigen. Eine API eignet sich, wenn ein System einen stabilen Vertrag anbietet und die Funktion langfristig als eigener Unternehmensbaustein gebraucht wird.
Connector als vorkonfigurierte Integrationslogik
Ein Connector bündelt wiederkehrende Aufgaben. Ein SAP-BTP-Connector kann den Zugang, bestimmte Protokolle und Teile der technischen Kommunikation vereinfachen. Ein iPaaS-Marktplatz bietet oft fertige Verbindungen zu verbreiteten Anwendungen.
Das spart Implementierungszeit, reduziert aber die Freiheit bei Sonderlogik. Ein Connector kann lokale Felder, alte Transaktionsmuster oder spezielle Buchungsregeln nur begrenzt abbilden. Ausserdem entsteht eine Abhängigkeit von Plattform, Release-Zyklus und Lizenzmodell. Ein Connector passt, wenn der Standardprozess genügt und die Verbindung schnell reproduzierbar sein soll. Eine Einordnung zu Plattformen und Automatisierungsarchitekturen bietet der Beitrag über Enterprise-Automation-Plattformen.
MCP als Agentenfähige Zugriffsschicht
MCP geht einen Schritt weiter. Ein MCP-Server beschreibt Ressourcen, Prompts und Aktionen so, dass ein AI Agent nicht nur Daten abfragt, sondern definierte Werkzeuge gezielt verwenden kann. Ein MCP-Server vor einem AS/400 kann beispielsweise eine Funktion „Kundenkonto prüfen“ bereitstellen, ohne dem Modell direkten Zugriff auf Tabellen oder undokumentierte Transaktionen zu geben.
Die Stärke ist die klare Tool-Grenze zwischen Modell und Legacy-System. Die Schwäche ist die zusätzliche Governance-Aufgabe. Jede Aktion braucht ein verständliches Schema, Sicherheitsprüfungen, Protokollierung und eine Regel für menschliche Freigabe.
| Muster | Stärke | Schwäche | Typischer Einsatzort |
|---|---|---|---|
| API | Präziser, versionierter Vertrag | Hoher Eigenaufwand bei Legacy-Systemen | S/4HANA-OData-API, interne Services |
| Connector | Schneller Zugang mit gebündelter Logik | Weniger Flexibilität und möglicher Lock-in | SAP BTP Connector, iPaaS-Marktplatz |
| MCP | Strukturierte Ressourcen und Aktionen für AI Agents | Erfordert strenge Tool- und Sicherheits-Governance | MCP-Server vor AS/400 oder anderen Legacy-Kernen |
Die Muster schliessen einander nicht aus. Ein MCP-Server kann intern eine API oder einen Connector aufrufen. Entscheidend ist, ob Sie nur Systeme verbinden oder einem Agenten eine kontrollierte Fähigkeit geben wollen.
Datenmodelle Authentifizierung und Autorisierung im Verbund
Eine produktive Integration scheitert häufig nicht am Netzwerk. Sie scheitert an einem falschen Kundenschlüssel, einem zu weit gefassten Token oder einer Aktion, die zwar technisch erlaubt, fachlich aber nicht freigegeben ist.
Erst die Bedeutung, dann die Übertragung
Beginnen Sie mit den Domänenobjekten. ERP, CRM und Drittsystem müssen nicht dasselbe interne Modell verwenden, aber sie brauchen eine belastbare Übersetzung. Definieren Sie gemeinsame Identifier, ein kanonisches Schema oder klare Mapping-Tabellen. Dokumentieren Sie, welches System für Name, Adresse, Zahlungsstatus und Vertragsbeziehung führend ist.
Versionierung schützt vor stillen Brüchen. Wenn das ERP ein Pflichtfeld ergänzt, darf ein alter CRM-Connector nicht unbemerkt falsche Standardwerte eintragen. Mapping-Fehler gehören in eine sichtbare Fehlerstrecke, nicht in ein Log, das niemand kontrolliert.
Nehmen wir eine Kette aus SAP IS-U, Salesforce und Power BI. SAP IS-U liefert Vertrags- und Verbrauchsinformationen, Salesforce verarbeitet Kundeninteraktionen, Power BI aggregiert freigegebene Daten. Eine gemeinsame Korrelations-ID verbindet den Vorgang, während Feldregeln verhindern, dass sensible Details ohne fachliche Berechtigung im Analysemodell landen.
Authentifizierung ist nicht Autorisierung
Authentifizierung beantwortet: Wer oder was ruft auf? Autorisierung beantwortet: Was darf dieser Aufrufer tun? In Integrationsprojekten werden beide Schichten oft vermischt, obwohl sie getrennt entworfen werden müssen.
| Verfahren | Einsatzort | Stärke | Typisches Risiko |
|---|---|---|---|
| OAuth2 | APIs und Delegation | Granulare Tokens und Scopes | Zu lange gültige oder zu weit reichende Tokens |
| SAML | Unternehmensweite Identität | Bewährte Anmeldung über Identity Provider | Komplexe Fehlersuche bei Weiterleitungen und Claims |
| mTLS | Maschinenkommunikation | Gegenseitige Zertifikatsprüfung | Zertifikatswechsel wird übersehen |
| Service-Account | Hintergrundprozesse | Klare technische Identität | Gemeinsame Konten erschweren Verantwortlichkeit |
Rollen und Scopes begrenzen Funktionen. RBAC ordnet Rechte Rollen zu, ABAC kann zusätzlich Attribute wie Mandant, Region, Datensensitivität oder Prozessstatus prüfen. Ein Agent darf dann vielleicht einen Salesforce-Kontakt lesen, aber keine SAP-IS-U-Vertragsdaten exportieren oder eine Buchung auslösen.
Die Audit-Spur muss Identität, Tenant, Aktion, verwendete Daten, Entscheidung und Ergebnis nachvollziehbar verbinden. Für weiterführende Kontrollfragen zur Sicherheitsorganisation eignet sich ein Security-Governance-Framework. Entscheidend bleibt, dass Berechtigungen im Toolvertrag sichtbar sind und nicht nur in einer undurchsichtigen Middleware-Konfiguration.
Latenz Fehlerbehandlung und Idempotenz in der Praxis
Eine Integration kann fachlich richtig modelliert und trotzdem unbrauchbar sein. Wenn ein ERP-Aufruf zu lange blockiert, ein Webhook verloren geht oder ein Retry eine Rechnung ein zweites Mal bucht, wird aus einem kleinen Übertragungsfehler ein operatives Problem.
Latenz nach Prozess statt nach Wunsch planen
Batch-Verarbeitung eignet sich für grosse, nicht zeitkritische Datenmengen. Change Data Capture kann Änderungen nahezu in Echtzeit weitergeben, ohne jedes System permanent vollständig abzufragen. Synchrone API-Aufrufe passen dagegen zu kurzen Entscheidungen, bei denen der Nutzer unmittelbar eine Antwort braucht.
Ein Agent sollte nicht auf eine sofortige Antwort bestehen, wenn das Legacy-System nur sequenzielle Verarbeitung erlaubt. Für einen Statuscheck kann ein Timeout sinnvoll sein. Für eine komplexe Bestellung ist eine asynchrone Aufgabe mit Rückmeldung oft stabiler.
Fehler sind Teil des Designs
Retries helfen bei transienten Netzwerkfehlern, aber nicht bei ungültigen Stammdaten. Exponentielles Backoff verhindert, dass ein überlastetes ERP durch weitere Wiederholungen zusätzlich belastet wird. Ein Circuit-Breaker stoppt Aufrufe, wenn ein Zielsystem erkennbar nicht verfügbar ist.
Typische Fehlerbilder verlangen unterschiedliche Gegenmassnahmen:
- Doppelte Rechnung: Ein Idempotency-Key stellt sicher, dass derselbe Geschäftsvorgang nicht erneut verbucht wird.
- Halb abgeschlossene Bestellung: Eine kompensierende Transaktion nimmt bereits ausgeführte Schritte kontrolliert zurück.
- Verlorener Webhook: Eine Dead-Letter-Queue hält die Nachricht zur Prüfung und Wiederverarbeitung fest.
- Stammdaten-Drift: Abgleichläufe erkennen widersprüchliche Werte und weisen sie einem verantwortlichen Team zu.
Idempotenz bedeutet nicht, dass ein Aufruf niemals wiederholt wird. Sie bedeutet, dass die Wiederholung keinen unerwünschten zweiten Geschäftsvorgang erzeugt.
Eine Korrelations-ID muss vom Eingang im CRM über den Orchestrator bis zum ERP und zur manuellen Nachbearbeitung erhalten bleiben. Ohne diese Spur sieht das Betriebsteam nur einzelne technische Ereignisse, aber nicht den vollständigen Geschäftsfall.
Governance Observability und Reifegrade für Integrationslandschaften
Viele Organisationen kennen ihre kritischsten Integrationen erst dann, wenn ein Auftrag ausbleibt. Observability macht dagegen sichtbar, was eine Datenstrecke tut, wie sie sich verhält und wo ein Vorgang stecken bleibt. Governance sorgt dafür, dass diese Transparenz in verbindliche Entscheidungen übersetzt wird.
Vier Stufen vom Skript zur kontrollierten Agentenarchitektur
Stufe eins, Ad-hoc-Skripte: Einzelne Teams verbinden Systeme mit Skripten, Tabellen oder manuellen Exporten. Dokumentation, Versionierung und Verantwortlichkeit fehlen häufig. Das Verfahren kann für einen kurzfristigen Test genügen, aber nicht als dauerhafte Grundlage für Agenten dienen.
Stufe zwei, zentralisierte Integration: Eine gemeinsame Middleware bündelt Verbindungen. Das schafft einen Betriebsort, doch Monitoring bleibt oft manuell und fachliche Abhängigkeiten sind noch nicht vollständig dokumentiert.
Stufe drei, Governed Integration: APIs besitzen Verträge, Änderungen laufen durch definierte Prozesse, automatisierte Tests prüfen Payloads und Metriken zeigen Fehler, Durchsatz und Verzögerungen. Security Controls und Kostenkontrolle gehören zum Standard.
Stufe vier, Observable Integration: Teams sehen Datenflüsse, Agentenaktionen und Ausnahmen nahezu unmittelbar. Alarme orientieren sich an vereinbarten Servicezielen, und die Organisation verbessert die Architektur kontinuierlich statt nur Störungen zu reparieren.
Was in der Praxis verbindlich sein sollte
Ein Integrationskatalog listet Systeme, Besitzer, Datenobjekte, Abhängigkeiten und Kritikalität. Ein goldenes API-Vertragsmuster definiert Namensgebung, Versionierung, Fehlerformat und Authentifizierung. SLOs pro Datenstrecke machen aus „schnell“ eine prüfbare Erwartung.
FinOps für Datenvolumen verhindert, dass unnötige Abfragen und Modellkontext die Betriebskosten unkontrolliert erhöhen. Ein revisionssicherer Audit-Trail zeigt, welcher Agent welche Aktion mit welcher Identität ausgelöst hat. Praktische Muster für die Verwaltung solcher Nachweise beschreibt Audit-Log-Management.
Neue AI-Agent-Connectoren brauchen ein verbindliches Onboarding. Prüfen Sie Toolbeschreibung, Datenumfang, Schreibrechte, Freigabepunkte, Testdaten und Notfallabschaltung. Ein MCP-Server ohne diesen Prozess wird schnell zur Schatten-IT, selbst wenn seine technische Implementierung sauber aussieht.
<iframe width="100%" style="aspect-ratio: 16 / 9;" src="https://www.youtube.com/embed/zHVi8NNtUvk" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>Die österreichische Verwaltung liefert dafür einen relevanten Rahmen. Im E-Government-Benchmark 2024 für Österreich wurde Österreich mit 82 von 100 Punkten bewertet, gegenüber 76 Punkten im EU27-Durchschnitt. Der österreichische Wert lag damit 16 Punkte über der vorherigen Messperiode. Besonders stark war die Nutzerfreundlichkeit mit 96 Punkten, während grenzüberschreitende Dienste in der EU von 66 auf 72 Punkte stiegen. Solche Werte ersetzen keine Unternehmens-Governance, zeigen aber, dass digitale Anschlussfähigkeit in messbaren Prozessketten sichtbar wird.
Entscheidungsleitfaden und 90-Tage-Fahrplan für mehr System Interoperability
Die Technologiewahl wird einfacher, wenn Sie nicht mit dem Tool beginnen, sondern mit dem Vorgang. Prüfen Sie Datenfrequenz, Schemaänderungen, Sicherheitsniveau und Wiederverwendbarkeit der Funktion.
Drei Wenn-dann-Regeln für die Musterwahl
- Wenn ein System einen stabilen Vertrag anbietet, Daten direkt verarbeitet werden müssen und die Funktion langfristig individuell kontrolliert werden soll, dann wählen Sie eine REST- oder GraphQL-API.
- Wenn der Prozess einem etablierten Standard folgt, der Connector die benötigten Felder und Aktionen abdeckt und schnelle Wiederverwendung wichtiger ist als Sonderlogik, dann nutzen Sie einen iPaaS-Connector.
- Wenn ein AI Agent Ressourcen lesen, Werkzeuge auswählen und Aktionen in einem Legacy-System kontrolliert ausführen soll, dann setzen Sie eine MCP-Schicht vor die vorhandenen APIs, Connectoren oder Transaktionsdienste.
Bei sensiblen Finanz- und Personendaten zählen enge Scopes, menschliche Freigaben und eine vollständige Audit-Spur stärker als maximale Automatisierungsbreite. Bei häufigen Schemaänderungen braucht das Team Vertrags- und Regressionstests, bevor ein Agent produktive Daten nutzt.
Ein umsetzbarer Plan in vier Sprints
Sprint eins, Discovery und Inventarisierung: Erfassen Sie ERP, CRM, Buchhaltung, Host-Systeme, Datenbesitzer, Schnittstellen und kritische Prozesse. Das Deliverable ist ein priorisierter Integrationskatalog. Typische Stolperfalle: Teams dokumentieren Anwendungen, aber nicht die fachlichen Übergaben.
Sprint zwei, Pilot mit einem nicht kritischen Use Case: Wählen Sie eine lesende Agentenfunktion, etwa die Zusammenfassung offener Angebote aus CRM und ERP. Definieren Sie Toolvertrag, Mapping, Berechtigungen, Korrelations-ID und Fehlerweg. Vermeiden Sie im Pilot eine direkte Buchungsaktion.
Sprint drei, Ausweitung auf zwei weitere Systeme: Ergänzen Sie Authentifizierungs- und Observability-Standards, testen Sie Timeouts, Wiederholungen und fehlerhafte Stammdaten. Die häufigste Gefahr ist ein funktionierender Happy Path ohne kontrollierte Ausnahmebehandlung.
Sprint vier, Governance-Rollout: Veröffentlichen Sie Onboarding-Regeln für neue Connectoren und MCP-Server, dokumentieren Sie den Quick Win und legen Sie Besitzer, SLOs, Auditierung und Abschaltprozesse fest. Damit wird aus einem Pilot eine wiederholbare Integrationspraxis.
Der FFG-Erhebung zu Interoperabilität und Standards zufolge sehen österreichische Unternehmen Defizite bei Software-, Hardware- und Datenstandards sowie bei organisatorischen und administrativen Abläufen. Bei öffentlichen Organisationen wurden mobile Lösungen und Workflow-Lösungen jeweils mit 43 % sowie Content- und Dokumentenmanagement mit 41 % als grosse Defizitfelder genannt, wie die österreichbezogene FFG-Auswertung berichtet. Das bestätigt eine praktische Erfahrung aus ERP- und CRM-Projekten: Der Engpass liegt selten nur im Modell. Er liegt in fehlenden Verträgen, unklarer Verantwortung und nicht kontrollierten Übergängen.
Specialty Tokens verbindet als vorwärts eingesetzte AI-Engineering-Firma ERP-, CRM-, Buchhaltungs- und Legacy-Systeme mit LLMs, kundenspezifischen Connectoren und einer verwalteten MCP-Schicht über Supercenter. Besprechen Sie Ihre Integrationslandschaft, Ihre kritischste Datenstrecke und einen konkreten Agenten-Use-Case mit Specialty Tokens.