Diese Seite bietet einen Überblick über den Integrationsansatz. Detaillierte Seiten für die beiden Integrationskategorien, die bereits über eigene Dokumentationen verfügen – Back-Office- und ERP-Systeme sowie CRM-Daten – sind am Ende dieser Seite verlinkt. Die Anbindung des Blueprints an Ihre spezifischen Systeme ist Bestandteil eines kostenpflichtigen Beratungsmandats. Unter Beratungsprozess erfahren Sie, wie diese Arbeit kalkuliert wird.
Das Adaptermuster
Jede Integration im Blueprint folgt derselben Struktur: eine stabile Schnittstelle auf der Agentenseite und ein austauschbarer Adapter auf der Systemseite.Integrationskategorien
Der Blueprint gruppiert externe Systeme in Kategorien, jede mit einem eigenen Schnittstellenvertrag. Die für die meisten Abteilungsagenten-Deployments relevanten Kategorien sind:Back-Office- und ERP-Systeme
Systeme, die Lagerbestände, Auftragsunterlagen, Finanzdaten und andere operative Back-Office-Informationen enthalten. Die Schnittstelle stellt einen generischen Satz von Operationen bereit – Bestand prüfen, Auftrag erstellen, Status aktualisieren, Dokument generieren –, die Agenten aufrufen, ohne zu wissen, welches spezifische System hinter dem Adapter steckt.
CRM-Daten
Kundenbezogene Daten – Kontakte, Fälle, Abschlusshistorie, Kommunikationsprotokolle – als separat zugangskontrollierte Domäne. Jedem Abteilungsagenten wird ein autorisierter Scope zugewiesen, der festlegt, welche CRM-Datensätze er lesen und schreiben darf. Jeder Zugriff erfolgt über die CRM-Schnittstelle; kein Agent greift direkt auf den CRM-Datenspeicher zu.
Eingehende Kanäle
Die Eingabequellen, die ein Agent überwacht – ein gemeinsamer Posteingang, ein Formularendpunkt, ein Ereignisstrom oder ein zeitgesteuerter Auslöser. Diese werden als Teil der Eingabequellen jedes Agenten konfiguriert und sind keine separaten Adapter, folgen jedoch demselben Prinzip: Der Agent empfängt ein normalisiertes Eingabeereignis, unabhängig davon, von welchem Kanal es stammt.
Ausgehende Nachrichtendienste
Die Kanäle, über die der Agent seine Ausgaben bereitstellt – ausgehende E-Mails von einem verbundenen Mailkonto, Nachrichten an einen internen Kanal oder Benachrichtigungen an ein zuständiges Team. Wie eingehende Kanäle werden auch diese pro Agent als ausgehende Schnittstellen konfiguriert.
Planungssysteme
Ein verbundenes Planungstool, das von Agenten genutzt wird, die Termine anbieten, buchen oder stornieren müssen. Der Agent ruft die Planungsschnittstelle auf, um Verfügbarkeit zu prüfen und eine Buchung zu registrieren; der Adapter übernimmt die Kommunikation mit dem Kalender- oder Planungssystem Ihrer Organisation.
Benutzerdefinierte Systeme
Jedes System mit einer strukturierten API, das sich keiner der oben genannten Kategorien zuordnen lässt. Benutzerdefinierte Schnittstellenverträge werden im Rahmen des Beratungsmandats konzipiert und folgen demselben Adaptermuster wie alle anderen Integrationskategorien.
Anbindung eines Systems
Die Anbindung eines Systems an den Blueprint umfasst zwei Aspekte: die Definition des Schnittstellenvertrags für diese Kategorie (sofern noch keiner vorhanden ist) und die Entwicklung eines Adapters, der diesen Vertrag für Ihr spezifisches System erfüllt. Die erforderlichen Zugangsdaten, Authentifizierungsmethoden und Berechtigungen hängen vollständig davon ab, welchen Zugang Ihre Organisation für dieses System gewährt. Die Anbindung eines Systems erfordert den Zugang, den Ihre Organisation kontrolliert – sei es ein API-Schlüssel, ein Dienstkonto, ein Verbindungsstring oder eine andere Form des autorisierten Systemzugangs. Der Blueprint schreibt kein spezifisches Authentifizierungsverfahren vor, und es werden keine Zugangsdaten an Dritte weitergegeben, die über das hinausgehen, was das Zielsystem selbst erfordert. Der Adapter übernimmt die gesamte Authentifizierung und das Sitzungsmanagement intern. Der Agent sieht keine Zugangsdaten – er ruft ausschließlich Schnittstellenoperationen auf und empfängt strukturierte Antworten.Der stufenweise Build-Ansatz
Der Blueprint folgt dem evolutionären Grundsatz für Integrationen: Zunächst wird der Agenten-Workflow entwickelt und validiert; erst wenn der Workflow belegt ist und die Integration tatsächlich benötigt wird, erfolgt die Anbindung an das Produktivsystem. In frühen Build- und Testphasen werden Adapter durch eine lokale Referenzimplementierung unterstützt – einen kontrollierten Datenspeicher, der auf jede Schnittstellenoperation antwortet. Dadurch kann der vollständige Agenten-Workflow entwickelt und end-to-end getestet werden, ohne vom Zugang zu Produktivsystemen abhängig zu sein. Sobald der Workflow validiert ist und die Organisation bereit ist, wird die Referenzimplementierung durch einen Produktions-Adapter für das tatsächliche Zielsystem ersetzt. Der Agentencode ändert sich dabei nicht. Dieser Ansatz wird auf der Seite ERP & Legacy-Systeme im Detail beschrieben, die die stufenweise Vorgehensweise für die Back-Office-Integration dokumentiert. Dieselbe Vorgehensweise gilt für jede Integrationskategorie.Weiterführende Dokumentation
ERP & Legacy-Systeme
Das Adaptermuster angewendet auf Back-Office- und Bestandsdaten – einschließlich des Schnittstellenoperationssatzes, der stufenweisen Build-Vorgehensweise und der Aufgaben, die der Adapter für den Agenten übernimmt.
CRM-Integration
Wie CRM-Daten als abgegrenzte Domäne modelliert werden, wie die Zugangskontrolle auf Schnittstellenebene durchgesetzt wird und was der generische CRM-Operationssatz umfasst.