Warum lohnt sich Multi-System-Orchestrierung ab drei Kernsystemen?

Multi-System-Orchestrierung rechnet sich, sobald mehr als zwei oder drei Kernsysteme regelmäßig Daten austauschen müssen, etwa CRM, ERP und Ticketsystem. Unterhalb dieser Schwelle genügt oft ein einfacher Abgleich von Hand. Ab drei Systemen wächst die Zahl der möglichen Verbindungen schneller als der Nutzen einzelner Punkt-zu-Punkt-Lösungen, und der Pflegeaufwand übersteigt den Vorteil.

Im Vertrieb zeigt sich das Muster täglich: Eine Mitarbeiterin trägt einen neuen Auftrag ins CRM ein, wechselt dann ins ERP, um Verfügbarkeit und Preis zu prüfen, und öffnet parallel das Postfach, um dem Kunden eine Bestätigung zu schreiben. Jeder Wechsel kostet Zeit und birgt die Gefahr, dass Daten in einem System veraltet bleiben.

Im Service sieht es ähnlich aus: Ein Ticket im Ticketsystem verweist auf einen Auftrag, dessen Status nur im ERP sichtbar ist, während die Historie zum Kunden im CRM liegt. In der Buchhaltung wiederum landen Zahlungseingänge im ERP, während offene Posten und Mahnstufen an anderer Stelle geführt werden. Erst wenn solche Wege sich wiederholen und mehrere Abteilungen betreffen, trägt eine orchestrierende Schicht ihre Einrichtungskosten.

Für die technische Umsetzung solcher Abläufe eignen sich unter anderem etablierte Werkzeuge der Prozessautomatisierung, wie sie ANCUD IT im Bereich Business Process Management einsetzt, wenn feste Regeln allein nicht ausreichen.

Wie verbindet ein Agent CRM, ERP, Ticketsystem und E-Mail?

Ein Agent liest eine eingehende Kundenmail, erkennt darin die Kundennummer oder Auftragsreferenz und prüft im ERP den aktuellen Auftragsstatus. Fehlt eine Information, legt er im Ticketsystem einen Fall mit den passenden Angaben an und ergänzt im CRM eine Notiz zum Vorgang. Jeder dieser Schritte ist ein einzelner, nachvollziehbarer Übergabepunkt zwischen Systemen.

Am Beispiel wird der Ablauf konkret: Eine Kundin schreibt, ihre Lieferung sei verspätet. Der Agent liest die Mail, findet die Auftragsnummer im Text oder in vorherigen Nachrichten und ruft den Lieferstatus im ERP ab. Steht die Sendung tatsächlich noch aus, öffnet er im Ticketsystem, etwa Jira Service Management oder Zendesk, einen Vorgang mit Fristangabe und ordnet ihn der zuständigen Fachkraft zu. Parallel trägt er im CRM eine kurze Zusammenfassung ein, damit der nächste Kontakt mit dieser Kundin den vollständigen Verlauf zeigt.

Wichtig ist die Trennung der Rollen: Der Agent liest, sortiert und dokumentiert. Eine Antwort an die Kundin oder eine Änderung am Liefertermin gibt weiterhin ein Mensch frei, meist die zuständige Sachbearbeitung im Service. Jede Übergabe zwischen den Systemen wird protokolliert, sodass sich im Nachhinein prüfen lässt, welcher Schritt wann und mit welchem Ergebnis ausgeführt wurde.

Diese Vorgehensweise folgt dem Prinzip orchestrierter Agentensysteme, bei dem einzelne Komponenten klar abgegrenzte Aufgaben übernehmen, statt eine einzige Instanz mit allen Rechten auszustatten orchestrierte Agentensysteme. Für die IT-Leitung bedeutet das: Jeder Agent hat einen begrenzten Auftrag und eine begrenzte Berechtigung, keine pauschale Vollmacht über alle vier Systeme.

Warum beginnt Multi-System-Orchestrierung mit lesendem Zugriff?

Multi-System-Orchestrierung beginnt mit lesendem Zugriff, weil sich so Zusammenhänge zwischen Systemen prüfen lassen, ohne Daten in CRM, ERP oder Ticketsystem zu verändern. Schreibende Aktionen folgen erst, wenn die Lesephase gezeigt hat, dass Zuordnungen korrekt und Datenmapping zuverlässig funktionieren. Das reduziert das Risiko fehlerhafter Einträge von Anfang an.

Schon in der Lesephase entsteht Nutzen: Der Agent kann Auftragsstatus im ERP mit offenen Tickets abgleichen, widersprüchliche Einträge zwischen CRM und Buchhaltung aufdecken oder E-Mail-Anfragen automatisch der richtigen Kundennummer zuordnen. Solche Abweichungen fallen der Fachabteilung sonst oft erst bei einer Reklamation auf.

Erst wenn diese Zuordnungen zuverlässig sind, kommen schreibende Aktionen hinzu, und auch dann schrittweise: zunächst mit Bestätigung durch eine Mitarbeiterin, später für klar abgegrenzte Routinefälle automatisiert. Der Agent legt beispielsweise einen Ticket-Entwurf an, den ein Mensch freigibt, bevor er verbindlich im System landet.

Dieses gestufte Vorgehen unterscheidet eine seriöse Einführung von Versprechen, ein System schreibe von Beginn an eigenständig in die Unternehmenslandschaft. Wer stattdessen zuerst prüft, wie sauber die Systeme heute schon zusammenpassen, spart sich spätere Korrekturen und schafft die Grundlage für spätere Automatisierung, etwa im Bereich IT Service Management.

Welche Systeme lassen sich orchestrieren?

Orchestrieren lassen sich grundsätzlich alle Systeme mit einer erreichbaren Schnittstelle, etwa SAP, Microsoft Dynamics, Salesforce, HubSpot, DATEV, Jira Service Management, Zendesk sowie Exchange und Outlook für E-Mail. Wie leicht ein System ansprechbar ist, hängt davon ab, ob es REST-Schnittstellen, ältere SOAP-Dienste oder Webhooks für ereignisgesteuerte Meldungen bereitstellt.

Moderne Cloud-Systeme wie Salesforce oder HubSpot bieten meist gut dokumentierte REST-Schnittstellen und Webhooks, die Ereignisse in Echtzeit melden. Ältere ERP-Installationen, etwa gewachsene SAP-Landschaften, arbeiten dagegen häufig noch mit SOAP-Diensten oder proprietären Modulen, die einen höheren Aufwand bei der Anbindung bedeuten. In solchen Fällen prüft ANCUD IT zunächst, welche Module bereits eine offene Schnittstelle besitzen, bevor zusätzliche Wege wie ein Datenbankzugriff in Betracht gezogen werden.

Buchhaltungssysteme wie DATEV verlangen wegen der GoBD besondere Sorgfalt bei jedem automatisierten Zugriff auf Belege oder Buchungen. Auch hier gilt der Grundsatz, zunächst lesend zu prüfen, was sich zuverlässig abbilden lässt.

Wann genügt ein Automatisierungswerkzeug und wann braucht es Multi-System-Orchestrierung?

Ein klassisches Automatisierungswerkzeug wie n8n, Make oder Zapier genügt, wenn ein fester Ablauf immer gleich abläuft und keine Interpretation nötig ist, etwa das Kopieren eines Formularfelds in ein CRM. Multi-System-Orchestrierung wird nötig, sobald Entscheidungen unter Unsicherheit anstehen, Texte unstrukturiert sind oder Ausnahmefälle regelmäßig vorkommen.

Der Unterschied liegt im Umgang mit Unklarheit. Ein Automatisierungswerkzeug folgt einer festen Regel: Wenn Feld A einen bestimmten Wert enthält, dann trage Wert B in System C ein. Sobald eine Kundenmail frei formuliert ist, mehrere mögliche Anliegen enthält oder eine Auftragsnummer fehlt, stößt eine solche Regel an ihre Grenzen. Genau hier setzt ein orchestrierender Agent an, der Text einordnet, Rückschlüsse zieht und je nach Kontext einen anderen Weg durch die Systeme wählt.

iPaaS-Plattformen decken oft einen Mittelweg ab: Sie verbinden viele Systeme technisch sauber, treffen aber ebenfalls keine inhaltlichen Entscheidungen. Wo eine Fachkraft heute noch selbst einschätzen muss, ob ein Vorgang dringend, ungewöhnlich oder unvollständig ist, kann ein Agent diese Einschätzung unterstützen, ersetzt sie aber nicht vollständig.

Für den Einstieg lohnt sich deshalb eine ehrliche Bestandsaufnahme: Wo reichen feste Regeln bereits aus, und wo entstehen die eigentlichen Kosten durch Ausnahmefälle, die Mitarbeitende von Hand klären müssen? Nur für den zweiten Bereich lohnt sich der zusätzliche Aufwand einer Orchestrierungsschicht mit Entscheidungslogik.

Wie unterscheidet sich Multi-System-Orchestrierung von klassischer Schnittstellenprogrammierung?

Klassische Schnittstellenprogrammierung verbindet Systeme meist punktuell, also jedes System direkt mit jedem anderen. Multi-System-Orchestrierung führt stattdessen einen zentralen Ablauf, über den alle Systeme angesprochen werden. Das verringert die Zahl der Einzelverbindungen und macht Änderungen und Fehlerbehandlung an einer Stelle statt in mehreren Programmen möglich.

Bei Punkt-zu-Punkt-Verbindungen wächst der Wartungsaufwand mit jeder neuen Verbindung überproportional: Ändert sich ein Feld im ERP, müssen alle direkt angebundenen Systeme angepasst werden. Bei einer zentral gesteuerten Orchestrierung genügt eine Anpassung an einer Stelle, dem Orchestrator, der die Übersetzung zwischen den Systemen übernimmt.

Auch die Fehlerbehandlung profitiert: Schlägt ein Schritt fehl, etwa weil ein Ticketsystem kurzzeitig nicht erreichbar ist, kann der Ablauf zentral erneut versucht oder angehalten werden, statt dass jedes einzelne Programm eigene Rückfallregeln braucht. Das schafft eine Stelle, an der sich Protokolle und Freigaben nachvollziehen lassen, statt sie über verstreute Skripte zu suchen.

Welche Rechte und Freigaben braucht ein Orchestrierungs-Agent?

Ein Orchestrierungs-Agent braucht für jedes System und jede Aktion ein eigenes, begrenztes Recht, niemals einen pauschalen Vollzugriff. Er arbeitet über technische Benutzerkonten mit klar definierten Lese- und Schreibrechten, beschränkt auf einzelne Objekte und Felder. Diese Struktur wird bei einer sauberen Multi-System-Orchestrierung von Anfang an so angelegt und im Betrieb regelmäßig überprüft.

In der Praxis heißt das: Der Agent darf im CRM die Kontaktdaten eines Vorgangs lesen, aber keine Umsatzzahlen im ERP verändern, solange dafür kein Auftrag vorliegt. Im Ticketsystem darf er einen Status setzen, aber keine Tickets löschen. Jede Aktion ist einem konkreten Konto zugeordnet, jedes Konto einem konkreten Zweck. Das reduziert die Angriffsfläche und macht nachvollziehbar, welches System welchen Zugriff tatsächlich benötigt.

Der Einstieg erfolgt deshalb fast immer über lesenden Zugriff. Schreibende Aktionen kommen schrittweise dazu, zunächst mit Bestätigung durch eine zuständige Person, erst später ohne Rückfrage für klar abgegrenzte, risikoarme Fälle. Diese Reihenfolge ist kein Zeichen von Zurückhaltung, sondern die Grundlage dafür, dass Fehler früh auffallen und nicht in mehreren Systemen gleichzeitig entstehen. Wer Prozesse ohnehin mit Werkzeugen wie Prozessmodellierung mit Camunda modelliert, kann Freigabeschritte dort direkt sichtbar machen.

Vollzugriff über alle Systeme mag technisch bequem wirken, verschiebt das Risiko aber vollständig auf den Betrieb. ANCUD IT legt Berechtigungen deshalb pro Feld und pro Aktion fest, dokumentiert sie und passt sie an, wenn sich Prozesse ändern.

Was passiert, wenn eine Schnittstelle ausfällt?

Fällt eine Schnittstelle aus, greift eine Retry-Logik mit begrenzter Wiederholungszahl, der Vorgang landet in einer Warteschlange und wird als idempotente Operation markiert, damit er beim erneuten Versuch nicht doppelt ausgeführt wird. Bleibt der Ausfall bestehen, wird der Vorgang als offen gekennzeichnet und eine zuständige Person benachrichtigt.

Idempotenz bedeutet hier konkret: Legt der Agent einen Datensatz im ERP an und brict die Verbindung danach ab, erkennt er beim nächsten Versuch anhand einer eindeutigen Kennung, dass der Schritt bereits erfolgt ist, und schreibt ihn nicht ein zweites Mal. Ohne diese Absicherung entstünden doppelte Buchungen oder doppelte Tickets, sobald ein System nur kurz nicht erreichbar ist.

Ein Teilabbruch wird nicht verschwiegen. Wenn ein mehrstufiger Vorgang im CRM bereits angelegt, im ERP aber noch nicht gebucht ist, zeigt das Protokoll genau diesen Zwischenstand. Die zuständige Fachabteilung sieht, welcher Schritt fehlt, und kann entscheiden, ob nachgetragen oder storniert wird. Diese Sichtbarkeit ist Teil jeder seriösen Multi-System-Orchestrierung, nicht ein nachträglich ergänztes Feature.

Die Benachrichtigung läuft über den Kanal, den das Unternehmen ohnehin nutzt, etwa eine Meldung im Ticketsystem oder eine E-Mail an eine definierte Rolle. Wichtig ist, dass niemand raten muss, welcher Vorgang gerade in der Schwebe hängt.

Wie behandelt Multi-System-Orchestrierung fehlgeschlagene Änderungen in mehreren Systemen?

Eine echte Transaktion über mehrere Systeme hinweg gibt es technisch nicht, deshalb arbeitet Multi-System-Orchestrierung mit Kompensationsschritten. Schlägt eine Änderung im zweiten von drei Systemen fehl, wird nicht rückwärts gerollt wie in einer Datenbank, sondern gezielt gegengebucht oder korrigiert. Die Reihenfolge der Schreibvorgänge ist dabei so gewählt, dass der riskanteste Schritt zuletzt erfolgt.

Das Grundproblem verteilter Systeme ist seit Jahren bekannt: Sobald mehrere unabhängige Anwendungen beteiligt sind, lässt sich ein einmal geschriebener Zustand nicht einfach zurücknehmen, sondern nur durch einen weiteren, entgegengesetzten Schreibvorgang korrigieren Erfahrungen aus dem produktiven Betrieb von Multi-Agenten-Systemen. Legt der Agent zum Beispiel zuerst einen Kontakt im CRM an und scheitert danach die Buchung im ERP, wird der Kontakteintrag markiert und bei Bedarf automatisch zurückgesetzt, statt unbemerkt stehen zu bleiben.

Für Fälle, in denen eine automatische Kompensation nicht sinnvoll oder nicht möglich ist, sieht die Orchestrierung einen manuellen Korrekturlauf vor. Eine zuständige Person erhält eine vollständige Liste der betroffenen Datensätze samt Protokoll, wer wann was versucht hat, und entscheidet über die Korrektur. Diese Protokollierung ist keine Kür, sondern die Voraussetzung dafür, dass ein Fehler im ERP nicht Wochen später ohne erkennbare Ursache aufteucht.

Die Reihenfolge der Schritte wird deshalb bewusst geplant: Änderungen mit geringer Tragweite zuerst, finanzwirksame oder rechtlich bindende Buchungen zuletzt und erst nach Bestätigung der vorherigen Schritte.

Wie werden Datenfelder zwischen den Systemen abgeglichen?

Datenfelder werden über ein festes Mapping abgeglichen, das für jedes Feld ein führendes System bestimmt. Der Kundenname etwa stammt verbindlich aus dem CRM, die Steuernummer aus dem ERP. Widersprechen sich die Systeme, gilt die Regel, nicht die zuletzt geschriebene Version. Ohne dieses Mapping entstehen Dubletten und widersprüchliche Datenstände, die die Multi-System-Orchestrierung selbst nicht auflösen kann.

Dubletten sind das häufigste praktische Problem bei der Zusammenführung von CRM, ERP und Ticketsystem, weil Kontakte oder Firmen in jedem System eigenständig angelegt wurden. Der Agent kann Kandidaten für einen Abgleich vorschlagen, eine endgültige Zusammenführung von Datensätzen sollte aber eine Person aus der Fachabteilung bestätigen, insbesondere wenn Rechnungs- oder Vertragsdaten betroffen sind.

Ein tragfähiges Mapping setzt eine saubere Stammdatenqualität voraus. Sind Adressfelder, Kundennummern oder Statuswerte schon heute uneinheitlich gepflegt, verschärft eine Orchestrierung dieses Problem eher, statt es zu lösen. Deshalb steht am Anfang jedes Projekts eine Bestandsaufnahme, welche Felder wo geführt werden und wo sich Formate unterscheiden. Wer diesen Schritt überspringt, verlagert Datenprobleme nur von einer manuellen Eingabe in eine automatisierte.

Diese Vorarbeit ist aufwendiger als der eigentliche technische Anschluss der Systeme, entscheidet aber darüber, ob der spätere Betrieb stabil läuft oder ständig Rückfragen erzeugt.

Wie bleibt Multi-System-Orchestrierung DSGVO-konform?

Multi-System-Orchestrierung bleibt DSGVO-konform, wenn der Datenfluss zwischen den Systemen zweckgebunden bleibt, jeder Zugriff protokolliert wird und nur die tatsächlich benötigten Felder übertragen werden. Werden externe Dienste eingebunden, ist ein Auftragsverarbeitungsvertrag Voraussetzung. Bei Buchhaltungs- oder ERP-Daten gelten zusätzlich die Aufbewahrungs- und Nachvollziehbarkeitspflichten der GoBD.

Zweckbindung bedeutet konkret, dass ein Agent, der Ticketdaten mit dem CRM abgleicht, keine Personaldaten aus einem HR-System mitliest, nur weil eine Schnittstelle technisch offen ist. Jeder Zugriff wird auf den Zweck begrenzt, für den er eingerichtet wurde. Datenminimierung heißt, dass nur die Felder übertragen werden, die der jeweilige Prozessschritt benötigt, nicht der gesamte Datensatz.

Ein Auftragsverarbeitungsvertrag wird immer dann relevant, wenn Systeme oder Modelle außerhalb der eigenen IT-Infrastruktur eingebunden sind, etwa cloudbasierte CRM- oder Ticketsysteme. Die Protokollierung jedes Zugriffs und jeder Änderung ist dabei nicht nur eine Sicherheitsmaßnahme, sondern auch die Grundlage für Auskunftsersuchen nach Artikel 15 DSGVO. Ähnliche Anforderungen gelten für weitere KI-Integrationen in Unternehmenssysteme, wie eine Analyse zur Einbindung von KI in ERP-, CRM- und DMS-Umgebungen beschreibt KI-Integration in ERP-, CRM- und DMS-Systeme.

Bei ERP- und Buchhaltungsdaten kommt die GoBD hinzu: Buchungsrelevante Belege und ihre Änderungen müssen nachvollziehbar und unveränderbar dokumentiert sein. Ist ein Betriebsrat vorhanden, ist er bei automatisierten Verarbeitungen, die Leistungs- oder Verhaltenskontrolle ermöglichen könnten, frühzeitig einzubeziehen, bevor ein Agent produktiv geschaltet wird. Wer diese Einordnung mit vorhandenen Werkzeugen zur digitalen Zusammenarbeit verknüpfen will, findet Anknüpfungspunkte bei digitale Kollaboration.

Fällt Multi-System-Orchestrierung unter den EU AI Act?

Ob Multi-System-Orchestrierung unter den EU AI Act fällt, hängt vom konkreten Einsatz ab. Setzt ein Agent Entscheidungen mit rechtlicher oder finanzieller Wirkung um oder überwacht er Beschäftigte, greifen die Anforderungen an Hochrisiko-Systeme. Für viele Orchestrierungsfälle mit klarer menschlicher Freigabe gelten dagegen vor allem die allgemeinen Transparenzpflichten nach Artikel 50 der Verordnung (EU) 2024/1689.

Die zentralen Pflichten der Verordnung werden ab dem 2. August 2026 aktiv durchgesetzt. Ab diesem Datum beginnt für Anbieter und Betreiber von Hochrisiko-KI-Systemen sowie für Unternehmen mit Transparenzpflichten die Phase der scharfen Kontrolle Anwendbarkeit und Bußgeldrahmen der KI-Verordnung. Wer bis dahin einen Orchestrierungs-Agenten produktiv einsetzt, sollte die eigene Einstufung kennen und dokumentieren können, welche Entscheidungen automatisiert und welche von Menschen getroffen werden.

Artikel 50 verlangt, dass Nutzerinnen und Nutzer erkennen können, wenn sie mit einem KI-System interagieren oder automatisiert erzeugte Inhalte erhalten. Für einen Orchestrierungs-Agenten heißt das: Eine automatisch erstellte Antwort im Ticketsystem oder eine automatisiert vorgeschlagene Buchung im ERP muss als solche erkennbar bleiben, und eine Person muss die Möglichkeit behalten, einzugreifen, bevor eine Wirkung nach außen entsteht.

Verstöße gegen Hochrisiko-Pflichten können mit Bußgeldern bis zu 15 Millionen Euro oder drei Prozent des weltweiten Jahresumsatzes geahndet werden, für verbotene Praktiken nach Artikel 5 sogar bis zu 35 Millionen Euro Anwendbarkeit und Bußgeldrahmen der KI-Verordnung. In Deutschland regelt das KI-Marktüberwachungs- und -Durchführungsgesetz (KI-MIG) die Zuständigkeiten, und ISO/IEC 42001 bietet einen Rahmen, um ein KI-Managementsystem strukturiert nachzuweisen. ANCUD IT ordnet diese Anforderungen im Rahmen der technischen Bestandsaufnahme für jeden konkreten Anwendungsfall ein, statt pauschal Konformität zu versprechen.

Wer haftet, wenn der Agent einen falschen Eintrag in ERP oder CRM anlegt?

Verantwortlich bleibt immer das Unternehmen, das den Agenten betreibt, nicht ANCUD IT als Dienstleister und nicht die eingesetzte Software. Die Multi-System-Orchestrierung wird deshalb so aufgebaut, dass jede schreibende Aktion einer Aktionsklasse zugeordnet ist, für die vorab festgelegt wurde, wer sie prüfen und freigeben muss, bevor sie in ERP oder CRM wirksam wird.

Aktionen ohne finanzielle oder rechtliche Wirkung, etwa das Anlegen eines Notizfelds oder das Aktualisieren eines Bearbeitungsstatus, kann der Agent nach Testphase eigenständig ausführen. Sobald eine Aktion Zahlungsläufe, Preise, Kreditlimits oder Vertragsdaten berührt, greift ein Vier-Augen-Prinzip: Der Agent schlägt die Änderung vor, eine zuständige Person in Buchhaltung oder Vertrieb bestätigt sie im gewohnten System. Diese Trennung ist keine Formalie, sondern der Kern der Haftungsklärung.

Jede Aktion, jeder Vorschlag und jede Freigabe wird in einem Protokoll festgehalten, das im Streitfall nachweist, wer wann welche Entscheidung getroffen hat. Das ist auch mit Blick auf Sorgfaltspflichten aus der europäischen KI-Verordnung relevant, deren zentrale Bestimmungen ab August 2026 durchgesetzt werden zentrale Bestimmungen der KI-Verordnung. ANCUD IT liefert die technische Grundlage und berät zur Aufteilung der Aktionsklassen, trägt aber keine Entscheidung an Stelle des Unternehmens. Wie Freigaben und Protokolle im Servicebetrieb organisiert werden, zeigt der Bereich IT Service Management.

Muss ich meine bestehende Software für Multi-System-Orchestrierung ersetzen?

Nein. Die Multi-System-Orchestrierung setzt auf vorhandene Systeme auf und ersetzt weder SAP noch Microsoft Dynamics, Salesforce, HubSpot oder DATEV. Der Orchestrator spricht diese Systeme über bestehende oder nachgerüstete Schnittstellen an und übernimmt keine ihrer Fachfunktionen, sondern verbindet nur die Datenflüsse zwischen ihnen.

Schwierig wird es bei Altsystemen, die keine moderne API bieten und nur über Exporte, Batch-Dateien oder Bildschirmmasken ansprechbar sind. Solche ERP-Module sind technisch schwer von außen erreichbar, das wird auf vielen Anbieterseiten verschwiegen. In diesen Fällen kommt Robotic Process Automation als Notlösung infrage: ein Roboter bedient die Maske wie ein Mensch, oder ein Dateiexport wird zeitgesteuert eingelesen.

Diese Notlösungen haben klare Nachteile: Sie reagieren empfindlich auf Änderungen an der Oberfläche, liefern keine Echtzeitdaten und erschweren Fehlerdiagnosen, weil keine strukturierte Rückmeldung des Systems erfolgt. Deshalb wird zu Beginn geprüft, welche Systeme sich direkt integrieren lassen und wo eine Übergangslösung mit begrenztem Funktionsumfang die realistischere Option ist, statt eine funktionierende Landschaft zu ersetzen.

Wie wird der Betrieb der Multi-System-Orchestrierung überwacht?

Der Betrieb wird über ein laufendes Monitoring und ein durchgängiges Audit-Log überwacht, das jede Aktion des Agenten protokolliert. Vor dem Piloten werden Ausgangswerte wie Bearbeitungszeit, Fehlerquote oder Anzahl manueller Eingaben erfasst, damit sich der tatsächliche Effekt der Multi-System-Orchestrierung nach der Einführung belegen lässt, statt ihn zu vermuten.

Auffälligkeiten wie ausbleibende Antworten einer Schnittstelle, gehäufte Ablehnungen bei Freigaben oder ungewöhnliche Datenmuster lösen eine Alarmierung an eine benannte Person im IT-Betrieb aus. Diese Person entscheidet, ob eine Aktionsklasse vorübergehend eingeschränkt oder der Agent pausiert wird, bis die Ursache geklärt ist.

Die Regeln, nach denen der Agent Aktionen einordnet und Freigaben anfordert, werden in festen Abständen überprüft und angepasst, weil sich Prozesse, Zuständigkeiten und Systeme im Unternehmen verändern. Diese wiederkehrende Prüfung ist Teil des laufenden Betriebs, nicht ein einmaliger Abschlussschritt bei der Einführung, und wird häufig in bestehende Strukturen für Incident- und Change-Management eingebunden.

Wie lange dauert die Einführung von Multi-System-Orchestrierung?

Eine pauschale Wochenangabe wäre unseriös, da die Dauer von der Anzahl der Systeme, ihrer technischen Ansprechbarkeit und der Zahl geplanter schreibender Aktionen abhängt. Realistisch ist ein Ablauf in klar abgegrenzten Phasen, die jeweils erst nach erfolgreicher Prüfung in die nächste übergehen.

Am Anfang steht die Bestandsaufnahme: Welche Systeme sind im Einsatz, welche Schnittstellen existieren bereits, wo liegen Altsysteme mit eingeschränktem Zugriff. Darauf folgt ein Lesepilot, in dem der Agent Daten aus CRM, ERP, Ticketsystem und E-Mail zusammenführt, ohne etwas zu verändern. Erst wenn dieser Pilot stabil läuft und die Datenqualität ausreicht, werden erste schreibende Aktionen mit geringer Wirkung freigeschaltet.

Was die Dauer tatsächlich treibt, ist selten die Technik allein: Uneinheitliche Stammdaten, unklare Zuständigkeiten für Freigaben und fehlende Dokumentation bestehender Schnittstellen verlängern jede Phase deutlich. Ein Unternehmen mit sauberen Stammdaten und modernen APIs kommt schneller voran als eines mit gewachsenen Altsystemen und unklaren Verantwortlichkeiten, unabhängig davon, wie viele Systeme letztlich orchestriert werden sollen.

Was kostet Multi-System-Orchestrierung?

Ein pauschaler Preis lässt sich seriös nicht nennen, da die Kosten von mehreren Faktoren abhängen, die sich erst durch eine technische Bestandsaufnahme klären lassen. Entscheidend sind unter anderem die Anzahl der beteiligten Systeme, die Qualität der Schnittstellen und der Umfang geplanter schreibender Aktionen.

Statt Preise zu erfinden, listet die folgende Übersicht die Faktoren auf, die den Aufwand einer Multi-System-Orchestrierung tatsächlich bestimmen. Sie bildet die Grundlage für ein individuelles Angebot nach der Bestandsaufnahme.

Zusätzlich zum einmaligen Einführungsaufwand fällt laufender Betriebsaufwand für Monitoring, Regelpflege und gegebenenfalls Lizenzkosten für Middleware oder Orchestrator-Werkzeuge an. Wer bereits Automatisierungswerkzeuge wie n8n oder Make einsetzt, kann diese teilweise weiterverwenden, was die Kosten senkt. Der erste Schritt ist deshalb immer eine technische Bestandsaufnahme, aus der sich Aufwand und Umfang der weiteren Phasen ableiten lassen, statt mit einem unverbindlichen Pauschalangebot zu starten.

Wie starten Sie mit Multi-System-Orchestrierung bei ANCUD IT?

Der Einstieg erfolgt bewusst klein: ein einzelner Vorgang, zwei Systeme, ausschließlich lesender Zugriff. Zum Beispiel liest der Agent offene Tickets aus dem Ticketsystem und gleicht sie mit Kundendaten im CRM ab, ohne dort etwas zu verändern. So lässt sich der Nutzen der Multi-System-Orchestrierung an einem konkreten Fall prüfen, bevor weitere Systeme oder schreibende Aktionen dazukommen.

ANCUD IT bringt die technische Umsetzung, die Erfahrung im Umgang mit unterschiedlichen Schnittstellenarten und die Beratung zu Aktionsklassen und Freigaberegeln mit. Das Unternehmen stellt Zugänge zu den betroffenen Systemen, benennt Ansprechpersonen für die Fachbereiche und legt fest, welche Kennzahlen vor dem Piloten erfasst werden sollen.

Der nächste Schritt ist ein Gespräch zur technischen Bestandsaufnahme, in dem Systeme, Schnittstellen und ein geeigneter erster Vorgang gemeinsam ausgewählt werden. Wer bereits mit Low-Code-Plattformen wie Mendix arbeitet, kann prüfen, ob sich Teile davon einbinden lassen, was der Vergleich unter Low-Code-Vergleich genauer einordnet. Einen Überblick über verwandte Automatisierungsthemen bietet außerdem der Blog von ANCUD IT.