Wie organisiert man zuverlässigen Datenaustausch zwischen Anwendungen?

Ein Kunde ändert seine Rechnungsadresse im CRM. Der Vertrieb sieht die neue Anschrift, während die Buchhaltung weiterhin die alte verwendet. Gleichzeitig übernimmt das ERP eine Bestellung mit einer veralteten Kundennummer. Obwohl die Anwendungen miteinander verbunden sind, stimmen ihre Daten nicht überein.

Zuverlässiger Datenaustausch zwischen Anwendungen entsteht nicht allein durch funktionierende Schnittstellen. Entscheidend ist, welches System für welche Daten verantwortlich ist, wann Änderungen übertragen werden und wie Fehler erkannt und korrigiert werden. Erst mit klaren Datenflüssen, eindeutigen Datensatzkennungen und kontrollierten Synchronisationsprozessen lassen sich manuelle Doppelpflege und widersprüchliche Datenstände wirksam reduzieren.

Für Schweizer Unternehmen mit mehreren Fachanwendungen betrifft das nicht nur den Arbeitsaufwand. Unterschiedliche Kundenadressen, Zahlungsbedingungen oder Kreditlimiten können auch Rechnungsprozesse, Freigaben und Abschlusskontrollen erschweren. Eine belastbare Integration muss deshalb technische Zuverlässigkeit, fachliche Datenqualität und betriebliche Verantwortlichkeiten verbinden.

Warum entstehen unterschiedliche Datenstände zwischen verbundenen Anwendungen?

Unterschiedliche Datenstände entstehen vor allem dann, wenn mehrere Anwendungen dieselben Informationen unabhängig verändern, Aktualisierungen zeitversetzt eintreffen oder Mitarbeitende Daten parallel erfassen. Eine bestehende Schnittstelle verhindert solche Abweichungen nicht automatisch. Erst eine verbindliche Datenhoheit, nachvollziehbare Synchronisationsregeln und die Kontrolle fehlgeschlagener Übertragungen schaffen eine gemeinsame, verlässliche Datengrundlage.

Die erste Ursache ist eine ungeklärte Systemautorität. Wenn das CRM und das ERP beide Kundenadressen bearbeiten dürfen, ohne dass festgelegt ist, welches System massgebend ist, können konkurrierende Änderungen entstehen. Eine neuere Eingabe ist dabei nicht zwangsläufig fachlich richtiger.

Deshalb sollte für jeden Datentyp ein System of Record definiert werden. Beispielsweise kann das CRM die führende Quelle für Kontaktinformationen sein, das ERP für Artikelstammdaten und die Buchhaltungssoftware für gebuchte Rechnungen. Die konkrete Zuordnung richtet sich nach den Geschäftsprozessen und kann für verschiedene Felder desselben Objekts unterschiedlich ausfallen.

Die zweite Ursache ist ein asynchroner Austausch ohne nachvollziehbaren Synchronisationsstatus. Änderungen werden beispielsweise über eine Warteschlange übertragen, doch ein fehlgeschlagener Auftrag bleibt unbemerkt. Ohne Änderungskennung, Zeitstempel, Verarbeitungsstatus oder vergleichbare Kontrollinformationen lässt sich später schwer feststellen, welcher Stand tatsächlich übertragen wurde.

Die dritte Ursache ist die manuelle Doppelerfassung. Mitarbeitende übertragen Angaben per Excel oder erfassen Kundendaten erneut, weil eine Schnittstelle bestimmte Felder nicht unterstützt. Dadurch entstehen zusätzliche Datenbestände ausserhalb des definierten Integrationsprozesses.

Für Schweizer KMU können die Folgen konkret sein: Unterschiedliche Rechnungsadressen erzeugen Rückfragen bei der Prüfung von Belegen und MWST-relevanten Unterlagen. Abweichende Kreditlimiten zwischen ERP und CRM können wiederum unterschiedliche Entscheidungen bei der Auftragsfreigabe auslösen. Das bedeutet nicht automatisch einen steuerlichen Fehler, erhöht aber den Abstimmungs- und Kontrollaufwand.

Eine pragmatische Schnelldiagnose beginnt mit drei Geschäftsobjekten, etwa Kunden, Artikeln und Rechnungen. Für jeden Objekttyp wird eine definierte Stichprobe aus zwei Anwendungen verglichen. Die Abweichungsquote ergibt sich aus der Anzahl abweichender Datensätze geteilt durch die Anzahl geprüfter Datensätze. Zusätzlich sollten Ursache, betroffene Felder und Zeitpunkt der letzten Synchronisation dokumentiert werden.

Eine solche Bestandsaufnahme zeigt, ob lediglich einzelne Datensätze korrigiert werden müssen oder ob die Regeln des gesamten Datenflusses unzureichend sind. Auf dieser Grundlage lässt sich der Austausch zwischen CRM, ERP und Buchhaltung gezielt planen.

Wie plant man einen Datenfluss zwischen CRM, ERP und Buchhaltung?

Ein Datenfluss zwischen CRM, ERP und Buchhaltung wird geplant, indem zuerst die auszutauschenden Geschäftsobjekte festgelegt, anschliessend Übertragungsrichtung und Auslöser bestimmt und schliesslich die Felder eindeutig zugeordnet werden. Zusätzlich müssen Erstübernahme und laufende Synchronisation getrennt betrachtet werden. Das Ergebnis ist ein dokumentierter Ablauf, der technisch umgesetzt und anhand konkreter Testfälle abgenommen werden kann.

Die Planung beginnt nicht mit der Auswahl einer API, sondern mit den fachlichen Abläufen. Welche Informationen benötigt die Buchhaltung aus dem ERP? Wann soll ein neuer Kunde im CRM auch im ERP verfügbar sein? Welche Anwendung darf Zahlungsbedingungen ändern?

Eine einfache Flussplanung umfasst drei Schritte:

1. Geschäftsobjekte identifizieren: Kunden, Kontakte, Artikel, Bestellungen, Rechnungen und Zahlungen erfassen und ihre jeweiligen Datenverantwortlichen festlegen.
2. Richtung definieren: Bestimmen, ob Informationen ausschliesslich von einer Anwendung zur anderen übertragen werden oder ob Änderungen in beide Richtungen zulässig sind.
3. Trigger festlegen: Ereignisgesteuerte Übertragung, zeitgesteuerte Synchronisation oder kontrollierte manuelle Auslösung auswählen.

Danach folgt das Feldmapping. Für jedes Feld wird festgehalten, wie es im Quell- und Zielsystem heisst, welchen Datentyp es besitzt und ob eine Transformation erforderlich ist. Besonders wichtig sind Kundenkennungen, MWST-Nummern, Rechnungsadressen, Währungen und Zahlungsbedingungen.

Beispielsweise kann das CRM eine vollständige Adresse in einem Freitextfeld speichern, während das ERP separate Pflichtfelder für Strasse, Postleitzahl und Ort verlangt. Ohne dokumentierte Zuordnungs- und Validierungsregeln entstehen unvollständige Datensätze oder Übertragungsfehler.

Ebenso wichtig ist die Trennung zwischen Erstinitialisierung und laufendem Datenaustausch. Bei der erstmaligen Übernahme müssen vorhandene Kunden und ihre Kennungen abgeglichen werden. Andernfalls kann die anschliessende Synchronisation bereits existierende Datensätze erneut anlegen.

Im laufenden Betrieb werden dagegen nur neu entstandene oder geänderte Daten übertragen. Dafür müssen geeignete Änderungsmarker und Regeln zur Verarbeitung von Löschungen beziehungsweise Deaktivierungen vorgesehen werden.

Das Datenflussdiagramm sollte die Systeme, Objekte, Übertragungsrichtungen, Auslöser und Fehlerwege darstellen. Ergänzt durch ein Feldmapping und konkrete Testfälle bildet es ein überprüfbares Abnahmedokument. Bei späteren Systemwechseln bleibt nachvollziehbar, welche fachliche Funktion jede Verbindung erfüllt.

Sobald die Datenflüsse feststehen, lässt sich beurteilen, ob einzelne direkte Verbindungen genügen oder eine zentrale Integrationsplattform die wartungsärmere Architektur darstellt.

Direkte API oder Integrationsplattform: Was passt bei vielen Anwendungen besser?

Direkte API-Verbindungen eignen sich besonders für wenige, stabile Integrationen mit klar definierten Datenflüssen. Eine Integrationsplattform wird interessanter, wenn zahlreiche Anwendungen miteinander kommunizieren, Schnittstellen häufig geändert werden oder Monitoring und Fehlerbehandlung zentral erfolgen sollen. Entscheidend sind die Zahl der tatsächlichen Verbindungen, die internen Entwicklungsressourcen und der langfristige Wartungsaufwand, nicht allein die Anschaffungskosten.

Bei einer Direktintegration kommuniziert eine Anwendung unmittelbar mit der API einer anderen. Das kann technisch übersichtlich sein, solange wenige Systeme beteiligt sind und die Zuständigkeiten klar bleiben.

Wenn jedoch mehrere Anwendungen paarweise verbunden werden, wächst die Zahl möglicher Schnittstellen deutlich. Bei vollständig bidirektionaler Paarvernetzung von n Systemen ergeben sich rechnerisch n × (n − 1) / 2 Systempaare. Das ist keine Prognose für ein konkretes Unternehmen, sondern beschreibt lediglich die mögliche Komplexität einer vollständig verbundenen Architektur.

Eine Integrationsplattform bündelt die Kommunikation über zentrale Konnektoren und Datenflüsse. Dadurch lassen sich Fehlerüberwachung und Transformationen vereinheitlichen. Gleichzeitig entstehen Lizenzkosten, zusätzliche Betriebsanforderungen und Abhängigkeiten vom Plattformanbieter.

Die folgende Entscheidungsmatrix bietet eine Orientierung. Sie ersetzt keine Bewertung der tatsächlich benötigten Datenflüsse und verfügbaren Schnittstellen.

Eine brauchbare Entscheidungsregel lautet: Sobald jede neue Anwendung mehrere individuelle Schnittstellenänderungen auslöst und die interne IT deren Betrieb nicht mehr zuverlässig gewährleisten kann, sollte eine zentrale Integrationsarchitektur wirtschaftlich geprüft werden. Eine feste Systemanzahl als universellen Schwellenwert gibt es nicht.

Bei Integrationsplattformen verdient das Vendor-Lock-in besondere Aufmerksamkeit. Wenn geschäftskritische Regeln ausschliesslich in proprietären Plattformabläufen gespeichert werden, kann ein späterer Anbieterwechsel aufwendig werden. Schnittstellenverträge, Datenmodelle und Transformationen sollten deshalb nachvollziehbar dokumentiert werden. Fachliche Geschäftsregeln bleiben soweit sinnvoll im zuständigen Quell- oder Zielsystem.

Für Schweizer Unternehmen ist zudem die konkrete Integrationsfähigkeit ihrer ERP-Landschaft wichtig. Bei Abacus sind REST-Webservices dokumentiert. Die technische Dokumentation der Abacus REST-API beschreibt unter anderem Service-Benutzer und OAuth-basierte Authentifizierung. Welche Funktionen verfügbar sind, muss für die eingesetzte Installation geprüft werden.

Auch bei treiba, Odoo und branchenspezifischen ERP-Lösungen sollte vor der Architekturentscheidung geklärt werden, welche Standardkonnektoren, dokumentierten APIs oder herstellereigenen Integrationsmodule für die jeweilige Produktversion tatsächlich zur Verfügung stehen. Eine pauschale Verfügbarkeit lässt sich daraus nicht ableiten.

Unabhängig vom gewählten Integrationsweg müssen Datensätze eindeutig erkannt und Änderungen kontrolliert verarbeitet werden. Andernfalls werden technische Verbindungen zwar vereinfacht, Dubletten und unbeabsichtigte Überschreibungen bleiben jedoch bestehen.

Welche Integrationsfehler führen zu doppelten oder überschriebenen Datensätzen?

Doppelte oder überschriebene Datensätze entstehen häufig durch ungeeignete Zuordnungsschlüssel, unkontrollierte Wiederholungsversuche und fehlende Konfliktregeln bei bidirektionaler Synchronisation. Hinzu kommen fehlerhafte Feldformate und nicht erkannte Übertragungsabbrüche. Verhindern lassen sich diese Probleme durch stabile Kennungen, idempotente Verarbeitung, dokumentierte Schreibberechtigungen und realistische Integrationstests vor der Inbetriebnahme.

Ein zentraler Fehler ist die falsche Auswahl des Match-Kriteriums. Wenn das CRM einen Kunden anhand der E-Mail-Adresse identifiziert, das ERP jedoch über eine Kundennummer, kann eine Adressänderung zu einer neuen Zuordnung führen. Gemeinsam genutzte, unveränderliche externe IDs sind für eine eindeutige technische Verknüpfung häufig besser geeignet als veränderliche Geschäftsfelder.

Dabei müssen zwei Probleme unterschieden werden: Die Dublettenerkennung bei bestehenden Kundenstammdaten prüft, ob mehrere Datensätze dasselbe Geschäftsobjekt darstellen. Die technische Nachrichtendeduplizierung stellt hingegen sicher, dass ein bereits übermittelter Vorgang bei erneuter Zustellung nicht unbeabsichtigt erneut ausgeführt wird.

Letzteres ist besonders bei Timeouts relevant. Eine Anwendung sendet beispielsweise eine Bestellung, erhält aber keine Bestätigung. Sie wiederholt die Anfrage, obwohl die erste Verarbeitung bereits erfolgreich war. Ohne geeignete Absicherung können daraus zwei Bestellungen entstehen.

Die Microsoft-Dokumentation zum Idempotent Consumer-Muster beschreibt hierfür die Verwendung stabiler Deduplizierungsschlüssel und einer Verarbeitung, die bei wiederholten Nachrichten keine zusätzlichen unerwünschten Auswirkungen erzeugt. Wo die technische Grundlage es erlaubt, sollten Geschäftsänderung und Verarbeitungsmarker atomar gespeichert werden.

Weitere Fehlerquellen sind fehlende Prioritätsregeln bei gleichzeitigen Änderungen. Wenn CRM und ERP dieselbe Lieferadresse bearbeiten, benötigt die Integration eine eindeutige Regel, welches System schreiben darf oder wie konkurrierende Versionen aufgelöst werden. Eine Änderungshistorie unterstützt die spätere Fehleranalyse.

Ebenso können unterschiedliche Datumsformate, Dezimaltrennzeichen, Zeichensätze und Pflichtfelder zu stillen Datenveränderungen oder abgelehnten Übertragungen führen. Fehlende Retry-Regeln und nicht überwachte Fehlerwarteschlangen verstärken das Problem.

Vor dem Produktivstart sollten solche Fehler bewusst ausgelöst werden. Entscheidend ist nicht nur, ob eine reguläre Übertragung funktioniert, sondern auch, ob das System nach Unterbrüchen kontrolliert fortfahren kann.

Ein bestandener Testlauf ist allerdings keine dauerhafte Garantie. Wiederkehrende Fehler, steigende Korrekturaufwände oder veränderte Geschäftsanforderungen können darauf hinweisen, dass die bestehende Datenflussarchitektur grundsätzlich überarbeitet werden muss.

Wann muss ein bestehender Datenaustausch technisch neu geplant werden?

Ein bestehender Datenaustausch sollte neu geplant werden, wenn wiederkehrende Datenfehler trotz Korrekturen bestehen bleiben, Schnittstellen nicht mehr unterstützt werden oder Geschäftsprozesse wesentlich verändert wurden. Einzelne Mapping-Fehler lassen sich meist gezielt beheben. Stimmen jedoch Datenhoheit, Übertragungsrichtungen, Auslöser oder Betriebsverantwortlichkeiten nicht mehr mit dem tatsächlichen Ablauf überein, reicht eine punktuelle Reparatur häufig nicht aus.

Eine Neuplanung wird oft zu spät erwogen, weil jede einzelne Störung zunächst lösbar erscheint. Das eigentliche Problem liegt dann nicht im aktuellen Fehler, sondern in einer Architektur, deren Grundannahmen überholt sind.

Messbare Warnsignale sind beispielsweise ein zunehmender manueller Aufwand für Datenkorrekturen, wiederkehrende Dubletten oder eine wachsende Zahl erfolgloser Übertragungsversuche. Auch nicht mehr unterstützte Schnittstellenversionen, beispielsweise ältere SOAP-Schnittstellen eines Herstellers, können eine technische Umstellung notwendig machen.

Ein anstehender ERP- oder CRM-Wechsel ist ebenfalls ein geeigneter Anlass, die Integration vollständig zu überprüfen. Die bisherige Feldstruktur, die verfügbare API und die Zuständigkeit für Geschäftsdaten können sich erheblich verändern.

Für die Bewertung des bestehenden Austauschs empfiehlt sich ein einfaches Reifegrad-Schema mit vier Kriterien:

Ein praktisches Warnsignal ist die Entstehung von Schatten-IT. Sobald Abteilungen regelmässig Daten per Excel zwischen Systemen verschieben oder dieselben Informationen parallel erfassen, ist der bestehende Integrationsweg möglicherweise nicht mehr ausreichend.

Bei der Entscheidung zwischen Reparatur und Neuplanung sollte zuerst untersucht werden, ob der Fehler auf ein isoliertes Feldmapping, eine einzelne Schnittstellenfunktion oder einen grundsätzlichen Architekturkonflikt zurückgeht. Nur im letzten Fall ist eine umfassendere Neugestaltung technisch naheliegend.

Ergibt sich daraus ein Integrationsprojekt mit externen Dienstleistern, müssen die fachlichen und technischen Verantwortlichkeiten schon vor der Umsetzung verbindlich geregelt werden.

Wie plant man eine externe Systemanbindung ohne unklare Verantwortlichkeiten?

Eine externe Systemanbindung benötigt eindeutige Zuständigkeiten für fachliche Anforderungen, technische Umsetzung, Freigaben und laufenden Betrieb. Ein RACI-Modell macht sichtbar, wer Aufgaben ausführt, Entscheidungen verantwortet, konsultiert wird und informiert werden muss. Ergänzend sollten Abnahmekriterien, Reaktionszeiten, Fehlerbehandlung und die Wartung bei Schnittstellenänderungen vertraglich vereinbart werden.

Ein typischer Konflikt entsteht, wenn ein externer Integrationspartner eine funktionierende Schnittstelle liefert, nach der Inbetriebnahme jedoch unklar bleibt, wer bei fehlerhaften Geschäftsdaten reagieren muss. Technische Erreichbarkeit und fachliche Korrektheit sind unterschiedliche Verantwortungsbereiche.

Die IT kann beispielsweise bestätigen, dass eine Nachricht erfolgreich übertragen wurde. Ob die übernommene Zahlungsbedingung fachlich korrekt ist, muss dagegen eine zuständige Fachperson beurteilen können.

Das RACI-Modell unterscheidet vier Rollen: Responsible bezeichnet die ausführende Stelle, Accountable die letztverantwortliche Stelle, Consulted einzubeziehende Fachpersonen und Informed die zu informierenden Beteiligten.

Die folgende Zuordnung ist ein beispielhaftes Organisationsmodell, das an die tatsächliche Unternehmensstruktur angepasst werden muss.

Für jedes Aufgabenpaket sollten ausserdem die zu konsultierenden und zu informierenden Rollen festgelegt werden. Wichtig ist, dass bei fachlichen Konflikten eine entscheidungsbefugte Person benannt ist.

Vertraglich relevant sind nachvollziehbare Abnahmekriterien, vereinbarte Reaktionszeiten bei Ausfällen, die Behandlung möglicher Datenverluste sowie Verantwortlichkeiten bei API- und ERP-Versionswechseln. Auch Dokumentation, Zugriffsübergabe und Beendigung der Zusammenarbeit gehören zur Betriebsplanung.

Bei Standardkonnektoren kann der Anbieter die Pflege des Konnektors übernehmen. Das bedeutet jedoch nicht, dass er automatisch für sämtliche kundenspezifischen Feldzuordnungen, Prozessregeln oder Integrationen verantwortlich ist. Bei Individualentwicklungen muss die Anpassungspflicht besonders klar vereinbart werden.

Schliesslich ist das Betriebsmodell festzulegen. Bei einem reaktiven Ansatz wird nach erkannten Störungen eingegriffen. Ein proaktiver Ansatz überwacht definierte Zustände und löst bei Abweichungen Benachrichtigungen aus. Beide Modelle benötigen eine eindeutige Ansprechstelle; proaktives Monitoring verkürzt jedoch typischerweise die Zeit bis zur Erkennung von Problemen.

Verantwortlichkeiten allein reichen nicht aus, wenn unklar bleibt, welche Informationen externe Systeme überhaupt verarbeiten dürfen. Deshalb gehört die Bewertung von Datenschutz und Zugriffsrisiken zur Integrationsplanung.

Wie klassifiziert man Unternehmensdaten nach Schutzbedarf und Zugriffsrisiko?

Unternehmensdaten lassen sich anhand ihrer Vertraulichkeit, geschäftlichen Bedeutung und möglichen Auswirkungen eines unberechtigten Zugriffs klassifizieren. Für die praktische Integrationsplanung eignet sich ein dreistufiges Modell mit öffentlichen, internen und vertraulichen Daten. Zusätzlich muss bewertet werden, wie viele Systeme auf diese Informationen zugreifen, wohin sie übertragen werden und welche Berechtigungen die Schnittstelle besitzt.

Eine einfache Klassifizierung schafft zunächst Transparenz. Sie ersetzt keine datenschutzrechtliche Prüfung, hilft jedoch dabei, technische Schutzmassnahmen angemessen auszuwählen.

Diese drei Stufen sind ein vorgeschlagenes Organisationsmodell und keine durch das schweizerische Datenschutzgesetz allgemein vorgeschriebene Klassifizierung.

Das revidierte Bundesgesetz über den Datenschutz (DSG) gilt seit dem 1. September 2023. Bei Integrationen mit personenbezogenen Informationen müssen Unternehmen unter anderem prüfen, ob die Datenbearbeitung datenschutzkonform erfolgt und ob eine Bekanntgabe ins Ausland stattfindet.

Für grenzüberschreitende Übermittlungen erläutern die Informationen des EDÖB zur Bekanntgabe von Personendaten ins Ausland die Voraussetzungen nach dem schweizerischen Datenschutzrecht. Massgebend sind insbesondere das Datenschutzniveau des Empfängerstaates und, sofern erforderlich, geeignete Garantien oder gesetzlich vorgesehene Ausnahmen.

Ein Staat ohne anerkannt angemessenes Datenschutzniveau führt also nicht automatisch zu einem generellen Übermittlungsverbot. Gleichzeitig macht die technische Möglichkeit einer Verbindung eine Datenübermittlung noch nicht rechtmässig. Die konkrete Beurteilung hängt von den beteiligten Akteuren, Daten, Empfängerstaaten und Schutzmassnahmen ab.

Neben dem Schutzbedarf ist das Zugriffsrisiko entscheidend. Vertrauliche Daten, die ausschliesslich in einem stark beschränkten System verarbeitet werden, besitzen eine andere Risikosituation als Daten, die zahlreiche externe Dienste über verschiedene Schnittstellen abrufen können.

Für jeden Datenfluss sollte daher dokumentiert werden, welche Felder übertragen werden, welche Anwendung sie benötigt, welche Berechtigungen gelten und ob eine Verarbeitung im Ausland vorgesehen ist. Eine Schnittstelle sollte nur jene Daten bereitstellen, die für den jeweiligen Geschäftszweck erforderlich sind.

Abhängig vom Risiko können Verschlüsselung bei der Übertragung, restriktive Servicekonten, Zugriffskontrollen, revisionsfähige Protokolle und begrenzte Aufbewahrungsfristen erforderlich sein. Besonders wichtig ist, dass Protokolle nicht unbeabsichtigt zusätzliche vertrauliche Informationen offenlegen.

Mit dieser Einordnung lässt sich vor der technischen Anbindung festlegen, welche Informationen verfügbar sein sollen und welche Sicherheitsvoraussetzungen die beteiligten Systeme erfüllen müssen.

Wie bindet man externe Systeme an ERP, CRM oder andere Unternehmenssoftware an?

Externe Systeme werden über direkte APIs, Integrationsplattformen oder vorhandene Standardkonnektoren an ERP-, CRM- und andere Geschäftsanwendungen angebunden. Vor der Umsetzung müssen die verfügbaren Schnittstellen, Authentifizierungsverfahren, Zugriffsbeschränkungen und technischen Betriebsbedingungen geprüft werden. Anschliessend folgen dokumentierte Datenflüsse, Feldmapping, eine Testumgebung, ein begrenzter Pilotlauf und die kontrollierte Übergabe in den Regelbetrieb.

Die drei wichtigsten Integrationswege unterscheiden sich vor allem hinsichtlich Entwicklungsaufwand, Flexibilität und Wartung.

• Direkte API: Zwei Anwendungen kommunizieren über eine dokumentierte Schnittstelle. Dieser Weg bietet gezielte Kontrolle, erfordert jedoch eigene Implementierung, Fehlerbehandlung und Wartung.
• Middleware oder Integrationsplattform: Eine zentrale technische Komponente verbindet verschiedene Anwendungen. Sie kann Konvertierung, Weiterleitung und Überwachung vereinheitlichen, verursacht aber zusätzliche Betriebs- und gegebenenfalls Lizenzkosten.
• Standardkonnektor: Ein vorhandenes Integrationsmodul verbindet unterstützte Systeme. Die Umsetzung kann einfacher ausfallen, solange die verfügbaren Funktionen die fachlichen Anforderungen tatsächlich abdecken.

Vor dem Start muss geprüft werden, ob die Zielsoftware eine dokumentierte API bereitstellt. Dabei sind nicht nur verfügbare Endpunkte relevant, sondern auch unterstützte Geschäftsobjekte, Lese- und Schreibrechte, Authentifizierung und zulässige Abrufhäufigkeiten.

Je nach Anbieter kommen API-Keys, OAuth-Verfahren oder zertifikatsbasierte Mechanismen zum Einsatz. Zugangsdaten müssen geschützt gespeichert und Berechtigungen auf den erforderlichen Funktionsumfang begrenzt werden.

Ratenlimits, Zeitüberschreitungen und die Unterstützung konkreter API-Versionen beeinflussen die technische Gestaltung. Wo ein Anbieter keine langfristige Versionsunterstützung garantiert, sollte ein Verfahren zur Beobachtung und Prüfung von Schnittstellenänderungen vereinbart werden.

Bei Abacus beispielsweise beschreibt die Herstellerdokumentation REST-Webservices mit Service-Benutzern und OAuth. Zusätzlich veröffentlicht Abacus versionsbezogene AbaConnect-Schnittstellendokumentationen. Daraus lässt sich die dokumentierte Schnittstellenlandschaft prüfen; ob ein bestimmter Endpunkt in der konkreten Kundenumgebung nutzbar ist, muss separat abgeklärt werden.

Ein pragmatischer Umsetzungsablauf in fünf Schritten verbindet die fachliche Planung mit einer kontrollierten Einführung:

1. Datenfluss und führende Datenquellen festlegen, einschliesslich Objekten, Richtung und Synchronisationsauslösern.
2. Feldmapping, Datensatzkennungen, Konfliktregeln und technische Schnittstellenanforderungen dokumentieren.
3. Eine geeignete Testumgebung aufbauen und reguläre Übertragungen sowie Fehlerfälle prüfen.
4. Einen Pilotlauf mit begrenztem, kontrolliertem Datenbestand durchführen und die Ergebnisse fachlich abnehmen lassen.
5. Monitoring, Benachrichtigungen, Wiederanlaufverfahren und Verantwortlichkeiten einrichten und die Schnittstelle in den Regelbetrieb übergeben.

Die technische Anbindung sollte auch bei der Beschaffung neuer Geschäftsanwendungen berücksichtigt werden. Ein System, das ausschliesslich manuelle Dateiimporte oder eingeschränkte Exporte anbietet, kann bei späteren Automatisierungsvorhaben zusätzlichen Entwicklungs- und Betriebsaufwand verursachen.

Bereits in der Softwareevaluation sollten deshalb die verfügbaren Schnittstellen, Datenobjekte, Authentifizierungsverfahren, Dokumentationsqualität und Updatebedingungen bewertet werden. Die Integrationsfähigkeit ist ein langfristiges Auswahlkriterium und kein Detail, das erst nach der Einführung geklärt werden sollte.

Der nächste praktische Schritt ist eine Bestandsaufnahme der eingesetzten Anwendungen, ihrer verfügbaren APIs und der wichtigsten manuellen Datenübertragungen. Daraus kann ein abgegrenzter Pilotprozess ausgewählt werden, an dem sich Datenqualität, Fehlerbehandlung und Betriebsaufwand realistisch überprüfen lassen.