Wenn Daten nicht fließen: Integrations-Kürzel wie API, iPaaS und EDI richtig einordnen

Softwareauswahlen scheitern selten an fehlenden Funktionen. Sie scheitern daran, dass die Systeme am Ende nicht miteinander sprechen: Das ERP kennt die Lagerbestände, das Shopsystem nicht; das DMS archiviert Belege, aber die Buchhaltungssoftware muss sie mühsam erneut erfassen. Genau hier spielt sich der eigentliche Kampf um die Digitalisierung ab – auf der Ebene der Integration. Wer die gängigen Kürzel dieses Feldes beherrscht, verhandelt mit Anbietern auf Augenhöhe.

API: Der Grundbaustein der Kopplung

Eine API (Application Programming Interface) ist eine definierte Schnittstelle, über die zwei Programme Daten und Funktionen austauschen. Moderne Cloud-Systeme stellen ihre APIs in der Regel als REST- oder Webservice-Schnittstellen bereit, dokumentiert und versioniert. Entscheidend ist nicht das Vorhandensein einer API, sondern ihre Qualität: Welche Datenobjekte stehen zur Verfügung? Gibt es Limits für die Anzahl der Zugriffe? Wird die Schnittstelle langfristig gepflegt und versioniert? Ein Anbieter, der seine API nur widerwillig dokumentiert, kündigt häufig eine geschlossene Systemstrategie an.

ESB, iPaaS und Co.: Die Integrationsplattform

Sobald mehr als zwei oder drei Systeme gekoppelt werden müssen, stößt die punktuelle Punkt-zu-Punkt-Programmierung an Grenzen: Bei zehn Systemen wären theoretisch 45 Einzelverbindungen zu pflegen.

Der ESB (Enterprise Service Bus) war die klassische Antwort aus der Großunternehmen-Welt: eine zentrale Software, über die alle Nachrichten laufen, transformiert und weitergeleitet werden. ESBs sind mächtig, aber komplex und teuer.

Der iPaaS (Integration Platform as a Service) ist die Cloud-Variante für den Mittelstand: Plattformen wie Zapier, Make, Celigo oder Microsoft- und SAP-Integrationsdienste bieten vorgefertigte Konnektoren für hunderte Standardanwendungen. Prozesse lassen sich weitgehend grafisch konfigurieren. Der Vorteil: geringe Einstiegshürden und Wartung ohne eigene Middleware-Abteilung. Der Haken: Sensible Geschäftsdaten laufen über Cloud-Dienste – für datenschutzrelevante Kopplungen sollte geprüft werden, wo die Plattform verarbeitet und ob eine Auftragsverarbeitung nach Art. 28 DSGVO vereinbart ist.

EDI: Der Standard für den Warenverkehr

EDI (Electronic Data Interchange) bezeichnet den standardisierten, weitgehend automatisierten Datenaustausch mit Geschäftspartnern – etwa Bestellungen als ORDERS, Lieferavise als DESADV und Rechnungen als INVOIC im EDIFACT- oder X12-Format. Im Handel und in der Automobilzulieferindustrie ist EDI faktisch Pflicht: Wer als Lieferant keine EDI-Anbindung bietet, wird gar nicht erst in das Sortiment aufgenommen. Für den Anschluss an die Warenwirtschaft sorgen spezialisierte Anbieter und Dienstleister, die Formate konvertieren und den Transport über sogenannte Wertnetze abwickeln. Seit der E-Rechnungspflicht für B2B-Transaktionen in Deutschland gewinnt strukturiertes Format-XChange wie ZUGFeRD/XRechnung zusätzlich an Bedeutung – technisch verwandt, rechtlich getrieben.

Typische Stolperfallen bei der Systemkopplung

• Datenmodell-Konflikte: Felder heißen überall anders – die Kundenummer im ERP ist nicht die Kunden-ID im CRM. Ohne klare Zuordnungstabelle entsteht Datenmüll.
• Fehlende Synchronisationsregeln: Welches System ist führend, wenn sich eine Adresse ändert? Ohne definierte Datenhoheit entstehen Dubletten und widersprüchliche Datensätze.
• Versionswechsel beim Anbieter: Ein Cloud-Update kann Schnittstellen brechen. Vertraglich sollte eine Vorlaufzeit für API-Änderungen vereinbart sein.
• Stillschweigende Zusatzkosten: Integrationsarbeit wird im Angebot oft unter "Individuelle Anpassungen" verbucht – hier lohnt ein genauer Blick auf das Kleingedruckte.
• Nachweisbarkeit: Bei gekoppelten Systemen muss auch der Datenfluss dokumentiert und nachvollziehbar sein – ein Aspekt, der bei Betriebsprüfungen und im Rahmen der DSGVO-Relevanz relevant wird.

Die richtigen Fragen im Anbietergespräch

1. Welche Standardkonnektoren bieten Sie zu den Systemen an, die wir bereits einsetzen?
2. Ist die API vollständig dokumentiert und gibt es eine Testumgebung?
3. Wie werden Schema- und Versionsänderungen der Schnittstelle kommuniziert?
4. Können Integrationsflüsse überwacht und Fehlermeldungen protokolliert werden?
5. Wer trägt bei einer Kopplung über Dritt-Plattformen die Verantwortung für die Datenverarbeitung?

Fazit

Integration ist kein technisches Detail, sondern eine strategische Entscheidung. Wer von Beginn an klärt, welche Systeme wie zusammenarbeiten sollen, welche Datenhoheit gilt und welche Schnittstellen vertraglich zugesichert sind, vermeidet die teuerste Fehlerklasse der Digitalisierung: die Insel-Landschaft, die nachträglich mühsam und kostspielig zusammengefügt werden muss.