ERP-Schnittstellen anbinden: Was im Projekt wirklich zählt

Welche Daten wandern typischerweise zwischen ERP und Fachanwendung?

Fast jedes Anbindungsprojekt beginnt mit derselben Illusion: „Wir brauchen nur die Artikel.“ Nach der ersten Sitzung mit dem Vertrieb steht eine Liste mit sechs Datenbereichen, die alle voneinander abhängen. Es lohnt sich, diese Liste früh zu erstellen und zu priorisieren.

• Stammdaten zu Kunden und Lieferanten, meist inklusive abweichender Liefer- und Rechnungsanschriften.
• Artikel mit Bezeichnungen, Einheiten, Klassifizierungen, Nachfolgeartikeln und Auslaufkennzeichen.
• Preise und Konditionen, häufig kundenindividuell, staffelabhängig und zeitlich befristet.
• Bestände und Verfügbarkeiten, oft je Lagerort und mit Unterscheidung zwischen frei und reserviert.
• Aufträge und Auftragspositionen inklusive Statusrückmeldungen aus der Fertigung oder dem Versand.
• Belege und Buchungen: Lieferscheine, Rechnungen, Gutschriften, Zahlungsavise.

Die Komplexität steckt selten in der Übertragung, sondern in der fachlichen Übersetzung. Ein Großhändler führt Preise als Konditionssätze mit Gültigkeitszeiträumen; der Onlineshop erwartet einen Preis pro Kunde und Artikel zum Zeitpunkt des Klicks. Diese Umrechnung ist Fachlogik, kein Datentransport, und sie braucht eine Person aus dem Vertrieb, nicht aus der IT.

Preise und Konditionen sind erfahrungsgemäß der teuerste Bereich. Kalkulieren Sie hier großzügiger als bei Artikelstammdaten, deren Übertragung meist geradlinig verläuft.

Welches Übertragungsverfahren passt zu welchem ERP?

Die Wahl trifft in der Regel nicht Ihr Projekt, sondern das ERP-System. Was der Hersteller anbietet, bestimmt den Weg — der Rest ist die Frage, wie viel Sie an Aufwand ergänzen wollen.

• REST-Schnittstellen sind komfortabel, gut dokumentiert und bei neueren Systemen der Normalfall; achten Sie auf Mengenbegrenzungen bei großen Abzügen.
• SOAP begegnet Ihnen bei älteren, oft sehr stabilen Systemen; der Aufwand liegt im Umgang mit den Beschreibungsdateien und in mühsamer Fehlersuche.
• Dateiaustausch per CSV oder XML über einen gesicherten Ablageort wirkt altmodisch, ist aber robust, gut nachvollziehbar und für nächtliche Massendaten häufig die beste Wahl.
• Direkter Datenbankzugriff ist der schnellste Weg und der gefährlichste: Er umgeht die Prüflogik des ERP und bricht beim nächsten Versionswechsel.
• Eine Middleware lohnt sich ab etwa drei bis vier angebundenen Systemen, weil sie Übersetzung, Protokollierung und Wiederholung an einer Stelle bündelt.

Vom direkten Datenbankzugriff raten wir in nahezu allen Fällen ab. Schreibend ist er ein Risiko für die Datenkonsistenz, und selbst lesend verliert er beim ersten Release-Wechsel des Herstellers seine Grundlage. Wo er unvermeidbar ist, sollte er auf klar benannte Sichten beschränkt und im Projekt schriftlich als Risiko vermerkt werden.

Wer besitzt die Wahrheit — wie legen Sie das führende System fest?

Für jedes einzelne Feld muss geklärt sein, welches System es ändern darf. Ohne diese Festlegung entstehen Ringschlüsse: Die Fachanwendung überschreibt die Kundenadresse, das ERP schreibt sie in der nächsten Nacht zurück, am Morgen ruft der Vertrieb an.

Führen Sie deshalb eine Feldtabelle. Sie enthält je Feld das führende System, die Richtung der Übertragung und das Verhalten bei Konflikten. Diese Tabelle ist unspektakulär, spart aber im Betrieb mehr Zeit als jede Optimierung der Übertragungstechnik.

Bewährt hat sich eine grobe Aufteilung: Das ERP führt kaufmännische Stammdaten, Preise und Buchungen. Die Fachanwendung führt das, was nur sie kennt — etwa Konfigurationen aus einem Produktkonfigurator im Maschinenbau oder Zusatzinformationen aus dem Kundenportal. Doppelte Pflege wird vermieden, nicht organisiert.

Zwei Systeme, die dasselbe Feld ändern dürfen, erzeugen keinen Abgleich, sondern einen Wettlauf. Den gewinnt immer das, das zuletzt geschrieben hat.

Echtzeit, Nacht-Batch oder Ereignis: wie oft muss abgeglichen werden?

Frequenz ist eine Kostenfrage, keine Geschmacksfrage. Fragen Sie den Fachbereich nicht, wie aktuell die Daten sein sollen — die Antwort lautet immer „sofort“. Fragen Sie stattdessen, welcher Schaden entsteht, wenn ein Wert vier Stunden alt ist.

Bestände in einem Onlineshop brauchen häufig Aktualität im Minutenbereich, weil Überverkäufe direkt Geld kosten. Artikelbezeichnungen und Klassifizierungen vertragen einen nächtlichen Lauf ohne jeden Nachteil. Aufträge sollten ereignisgesteuert übertragen werden: Sobald eine Bestellung abgeschlossen ist, geht sie los.

Eine bewährte Mischung besteht aus drei Ebenen: ein nächtlicher Vollabgleich als Sicherheitsnetz, ein regelmäßiger Abzug der Änderungen im Minuten- oder Stundentakt und ereignisgesteuerte Übertragung für die wenigen zeitkritischen Vorgänge. Der nächtliche Vollabgleich fängt genau die Fälle auf, in denen ein Ereignis verloren ging.

Was passiert, wenn eine Übertragung fehlschlägt?

Schnittstellen fallen aus. Das ERP ist im Wartungsfenster, das Netz stockt, ein Datensatz enthält ein Zeichen, das der Gegenseite nicht schmeckt. Ein Projekt, das den Fehlerfall erst nach dem Produktivstart behandelt, verbringt die ersten Monate mit Telefonaten statt mit Fachthemen.

Zentral ist Idempotenz: Dieselbe Nachricht darf mehrfach ankommen, ohne doppelte Wirkung zu entfalten. Praktisch heißt das, jede Übertragung trägt eine eindeutige Kennung, und die Gegenseite erkennt eine bereits verarbeitete Kennung wieder. Ohne diese Eigenschaft erzeugt jeder Wiederholversuch das Risiko einer zweiten Buchung.

• Wiederholen Sie mit wachsenden Abständen statt im Sekundentakt — sonst überlasten Sie das gerade erholende ERP.
• Legen Sie nicht zustellbare Nachrichten in einen gesonderten Bereich, statt sie zu verwerfen oder endlos zu wiederholen.
• Unterscheiden Sie fachliche Fehler, etwa eine unbekannte Kundennummer, von technischen Störungen; nur letztere sind wiederholbar.
• Richten Sie eine Benachrichtigung ein, die eine benannte Person erreicht — nicht ein Postfach, das niemand liest.

Ergänzen Sie eine einfache Übersicht für den Fachbereich: Was wurde heute übertragen, was hängt, was ist fehlgeschlagen. Diese Ansicht kostet zwei bis drei Personentage und ersetzt später viele Rückfragen an den Dienstleister.

Warum ist ein Testsystem des ERP-Herstellers unverzichtbar?

Gegen ein Produktivsystem zu entwickeln, ist keine Option — schon ein versehentlich angelegter Testauftrag löst reale Vorgänge in Fertigung oder Buchhaltung aus. Sie brauchen eine eigene Umgebung mit realistischem Datenbestand, und Sie brauchen sie ab dem ersten Projekttag.

Genau hier entsteht die häufigste Verzögerung. Testumgebungen sind bei vielen ERP-Anbietern kostenpflichtig, müssen beantragt werden und haben Vorlaufzeiten von mehreren Wochen. Setzen Sie diesen Punkt in der Projektplanung an die erste Stelle, noch vor der Konzeptphase.

Klären Sie zugleich, wer die Testumgebung mit brauchbaren Daten füllt und wie oft sie vom Produktivstand aufgefrischt wird. Eine Testumgebung mit zwölf Artikeln beweist wenig über das Verhalten bei achtzigtausend.

Welche Lizenz- und Freigabefragen bremsen Projekte?

Der Zugriff auf ERP-Schnittstellen ist selten frei. Manche Hersteller lizenzieren nach angebundenen Systemen, andere nach technischen Benutzern oder nach übertragenem Volumen. Ein Zugang, der im Test kostenlos ist, kann im Produktivbetrieb einen jährlichen Posten bedeuten.

Dazu kommen Freigabefragen bei betreuten Installationen: Wenn ein Systemhaus Ihr ERP wartet, braucht die Anbindung häufig dessen Zustimmung, und Änderungen an Konfiguration oder Erweiterungen laufen über dessen Ticketsystem. Rechnen Sie diese Abstimmung als eigene Aufgabe mit Wartezeiten ein, nicht als Nebentätigkeit.

Der dritte Punkt ist der Versionswechsel. Ein ERP-Upgrade während der Projektlaufzeit kann Feldstrukturen, Endpunkte und Verhalten verändern. Fragen Sie zu Projektbeginn nach dem Releaseplan des Herstellers und halten Sie im Vertrag fest, wer den Anpassungsaufwand trägt, wenn das Zielsystem sich unter dem laufenden Projekt bewegt.

Wie schätzen Sie den Aufwand realistisch?

Als Orientierung aus unseren Projekten: Ein einzelner, gut dokumentierter Datenbereich in eine Richtung liegt bei 10 bis 20 Personentagen, inklusive Konzept, Umsetzung, Fehlerbehandlung und Abnahme. Ein Bereich mit fachlicher Übersetzung oder Abgleich in beide Richtungen liegt bei 25 bis 40 Personentagen.

Zu diesen Entwicklungstagen kommen drei Posten, die gern untergehen: die Datenbereinigung im ERP vor dem ersten Abgleich, die Testbegleitung durch den Fachbereich und der erhöhte Betreuungsaufwand in den ersten vier bis sechs Wochen nach dem Start. Zusammen machen sie leicht ein Drittel des Gesamtaufwands aus.

Ein wirksamer Weg, die Schätzung zu härten: Verlangen Sie vor dem Angebot eine Beispieldatei oder einen echten Beispielaufruf je Datenbereich. Wer die tatsächlichen Feldnamen und Wertebereiche gesehen hat, schätzt anders als jemand, der nur die Handbuchseite kennt.

Sinnvoll ist zudem, das Vorhaben in Stufen zu schneiden. Beginnen Sie mit einer Richtung und einem Datenbereich, bringen Sie diesen produktiv und lernen Sie am echten Datenbestand, bevor der zweite folgt. Ein Maschinenbauer, der zuerst nur Artikelstammdaten in sein Ersatzteilportal übernimmt, entdeckt in vier Wochen mehr über die Datenqualität seines ERP als in jeder Konzeptsitzung.

Diese Reihenfolge hat einen zweiten Vorteil: Der Fachbereich sieht früh ein Ergebnis und liefert dadurch präzisere Anforderungen für die späteren Stufen. Projekte, die alle sechs Datenbereiche gleichzeitig starten, gehen fast immer gemeinsam in Verzug, weil ein einziger offener Punkt im Preisfindungsmodell den gesamten Abnahmetermin blockiert.