ERP-Schnittstelle programmieren lassen — Kosten, Ablauf, Risiken

Am Anfang steht selten der Wunsch nach einer Schnittstelle. Am Anfang steht ein konkretes Problem:

• Bestellungen aus dem Webshop werden manuell ins ERP übertragen
• CRM und ERP laufen auseinander, weil niemand die Daten synchron hält
• E-Mail- oder PDF-Bestellungen landen im Postfach und werden abgetippt
• ein altes System tauscht Daten per CSV-Datei — und niemand traut sich, das anzufassen
• Marktplätze oder Partner brauchen Bestands- und Auftragsdaten, die nur im ERP liegen

Irgendwann fällt dann der Satz: „Wir brauchen eine Schnittstelle zum ERP."

Aber was damit genau gemeint ist, unterscheidet sich massiv. Die einen denken an einen Standard-Connector. Die anderen an Individualentwicklung. Wieder andere an Middleware. Und am Ende stehen Angebote nebeneinander, die denselben Begriff verwenden — aber komplett unterschiedliche Projekte meinen.

Dieser Artikel hilft Ihnen, das Thema sauber zu bewerten:

• wann eine individuelle ERP-Schnittstelle wirklich sinnvoll ist
• welche Faktoren den Preis tatsächlich treiben
• wann Standard-Connectoren reichen
• wann Middleware sinnvoller ist als eine direkte Anbindung
• und woran Sie Anbieter erkennen, die Ihnen ein vermeintlich günstiges Projekt später teuer machen

Wenn Sie speziell den Auftragseingang automatisieren möchten, lohnt sich zuerst ein Blick auf den Überblicksartikel Auftragseingang automatisieren im Mittelstand. Geht es konkret um E-Mail-Bestellungen, zeigt der Artikel E-Mail-Bestellungen automatisch ins ERP übernehmen, wie der Weg von der Mailbox ins ERP funktioniert.

Wann eine individuelle ERP-Schnittstelle sinnvoll ist

Nicht jede Anbindung muss individuell entwickelt werden. Und nicht jedes Standardprodukt spart Ihnen am Ende wirklich Aufwand.

Die entscheidende Frage lautet nicht:

„Gibt es dafür schon irgendein Plugin?"

Sondern:

„Wie müssen Daten in unserem konkreten Prozess fließen, geprüft werden und bei Fehlern behandelt werden?"

Ein Standard-Connector reicht oft, wenn …

• nur zwei klar definierte Systeme verbunden werden
• der Anwendungsfall verbreitet und wenig speziell ist
• das Datenmodell weitgehend auf beiden Seiten zusammenpasst
• keine komplexe Freigabe-, Prüf- oder Ausnahme-Logik nötig ist
• Sie mit den Grenzen des Connectors leben können

Typische Beispiele: Webshop-Bestellungen ins ERP übertragen, Lagerbestände in den Shop zurückspielen, Adressdaten zwischen CRM und ERP synchronisieren, Buchungsdaten in ein Standardsystem exportieren.

Eine individuelle Schnittstelle ist sinnvoll, wenn …

• kundenspezifische Felder, Regeln oder Mappings nötig sind
• mehrere Eingangskanäle auf dieselbe ERP-Logik laufen sollen
• das ERP alt, schlecht dokumentiert oder nur begrenzt integrationsfähig ist
• Geschäftslogik zwischen Quelle und Ziel liegt
• Fehler sauber behandelt, protokolliert und nachverfolgbar sein müssen
• das Projekt später erweiterbar bleiben soll

Typische Fälle: Kundenartikel müssen auf interne Artikelnummern gemappt werden. Bestellungen dürfen nur bei bestimmten Plausibilitätsprüfungen automatisch angelegt werden. Ein System liefert API-Events, das andere kann Daten nur per Datei-Import annehmen. Oder ein Prozess muss mit Freigaben, Dublettenprüfung oder Rückmeldungen arbeiten.

Dann reden Sie nicht mehr über „eine kleine Verbindung". Dann reden Sie über Systemarchitektur.

Welche Faktoren den Preis wirklich treiben

Viele Angebote für ERP-Schnittstellen sind schwer vergleichbar, weil der eigentliche Aufwand selten in einem einzigen Wort steckt.

Nicht „API" macht ein Projekt teuer. Nicht „Middleware" macht es automatisch groß.

Teuer wird es dort, wo aus einem simplen Datentransfer ein belastbarer Prozess werden muss.

1. Wie unterschiedlich die Datenmodelle sind

Wenn Quelle und Ziel ähnliche Felder, Bezeichnungen und Logiken verwenden, ist der Aufwand deutlich geringer.

Teurer wird es, wenn zum Beispiel:

• Kunden eigene Artikelnummern verwenden
• Variantenlogiken unterschiedlich aufgebaut sind
• Mengeneinheiten übersetzt werden müssen
• Adressen oder Konditionen unterschiedlich modelliert sind
• Freitext sauber in strukturierte ERP-Felder überführt werden soll

2. Ob die Schnittstelle nur schreibt — oder bidirektional arbeitet

Eine unidirektionale Übergabe ist meist deutlich einfacher als eine echte Synchronisation.

Komplexer wird es, wenn:

• Status zurückgespielt werden müssen
• Daten in beide Richtungen geändert werden können
• Dubletten verhindert werden müssen
• Konflikte zwischen Systemen auflösbar bleiben sollen

3. Wie viel Geschäftslogik zwischen Quelle und ERP liegt

Eine gute Schnittstelle schiebt nicht einfach blind Daten weiter. Sie entscheidet, was unter welchen Bedingungen ins ERP darf.

Aufwand entsteht hier zum Beispiel durch:

• Validierung gegen Stammdaten
• Preis- und Mengenkontrollen
• Freigabelogiken
• Terminprüfungen
• Sonderregeln für bestimmte Kunden oder Belegarten

4. Wie integrationsfähig Ihr ERP wirklich ist

Die entscheidende Frage ist nicht, ob ein ERP „modern" klingt. Sondern wie es technisch angebunden werden kann.

Je nach System kann die Anbindung laufen über:

• REST- oder SOAP-APIs
• Datenbank-Views oder Austausch-Tabellen
• CSV-, XML- oder TXT-Importe
• Dateiaustausch via FTP/SFTP
• individuelle Adapter auf bestehende Logiken

Fehlende oder schwache Standardschnittstellen bedeuten nicht automatisch Projektstopp. Sie erhöhen aber oft den Analyse-, Test- und Wartungsaufwand.

5. Wie professionell Fehlerbehandlung und Betrieb gelöst werden sollen

Viele Angebote rechnen nur den Happy Path — also den Fall, in dem alles sauber ankommt.

In der Praxis braucht ein belastbares Projekt aber auch Antworten auf diese Fragen:

• Was passiert bei unvollständigen Daten?
• Wie werden Dubletten erkannt?
• Wie werden Fehler sichtbar?
• Wer wird benachrichtigt?
• Gibt es Wiederholversuche?
• Sind Vorgänge protokolliert?
• Kann man später nachvollziehen, warum etwas nicht gebucht wurde?

Wer hier spart, spart selten dauerhaft.

Was eine ERP-Schnittstelle ungefähr kostet

Eine saubere Kostenschätzung hängt immer vom konkreten Scope ab. Trotzdem wollen Entscheider eine belastbare Orientierung — zu Recht.

Deshalb hier keine Fantasiezahl, sondern eine grobe Einordnung nach Projekttyp:

• Standardnahe Anbindung (2 Systeme, klarer Scope, geringe Geschäftslogik, eher unidirektional): eher niedriger bis mittlerer vierstelliger Bereich
• Individuelle 2-System-Schnittstelle (Mapping, Validierung, Rückmeldungen, Testfälle, sauberer Go-Live): oft im niedrigen bis mittleren fünfstelligen Bereich
• Komplexes Integrationsprojekt (mehrere Systeme, Middleware, Legacy-Anteile, Freigaben, Monitoring, hohe Ausnahmequote): häufig deutlich fünfstellig

Wichtig ist dabei:

Nicht der erste Preis entscheidet. Der spätere Änderungs- und Wartungsaufwand entscheidet mit.

Ein vermeintlich günstiges Projekt kann schnell teuer werden, wenn:

• das Mapping schlecht dokumentiert ist
• Fehlerfälle nicht abgefangen werden
• Änderungen nur mit manueller Nacharbeit möglich sind
• niemand Monitoring oder Betrieb mitgedacht hat

Die bessere Frage lautet deshalb nicht nur:

„Was kostet die Umsetzung?"

Sondern auch:

„Wie teuer wird jede Änderung, jeder Fehler und jede Erweiterung danach?"

Direkter Adapter, Standard-Connector oder Middleware?

Diese Entscheidung ist oft wichtiger als die Tool-Frage.

Standard-Connector

Sinnvoll, wenn:

• der Use Case häufig vorkommt
• beide Systeme gut unterstützt werden
• der Prozess nah am Standard bleibt

Vorteile: schnellerer Start, oft geringere Einstiegskosten, weniger Individualcode.

Nachteile: begrenzte Flexibilität, Sonderlogik wird schnell unbequem, Abhängigkeit von den Möglichkeiten des Connectors.

Direkte individuelle Schnittstelle

Sinnvoll, wenn:

• genau zwei Systeme verbunden werden
• die Logik spezifisch ist
• Sie einen schlanken, kontrollierten Datenfluss wollen

Vorteile: exakt auf Ihren Prozess zugeschnitten, keine unnötige Plattform dazwischen, oft sauber und effizient bei klar abgegrenztem Scope.

Nachteile: Erweiterungen auf weitere Systeme können später teurer werden, Monitoring und Betrieb müssen bewusst mitgebaut werden.

Middleware

Sinnvoll, wenn:

• drei oder mehr Systeme beteiligt sind
• mehrere Datenflüsse zentral gesteuert werden sollen
• Transformation, Monitoring und Fehlerbehandlung an einer Stelle sitzen sollen
• weitere Integrationen absehbar sind

Vorteile: zentrale Steuerung, saubere Entkopplung zwischen Systemen, besser skalierbar bei wachsender Systemlandschaft, Monitoring und Wiederverwendbarkeit meist einfacher.

Nachteile: zusätzliche Plattform und Betriebslogik, lohnt sich nicht für jeden kleinen Punkt-zu-Punkt-Fall, schlechte Middleware-Setups erzeugen nur eine neue Komplexitätsschicht.

Die pragmatische Regel

• 2 Systeme + klarer Prozess: direkte Anbindung oft sinnvoll
• Standardfall + gute Herstellerunterstützung: Connector zuerst prüfen
• Mehrere Systeme + künftige Erweiterungen: Middleware ernsthaft bewerten

Nicht alles braucht Middleware. Aber ab einer bestimmten Systemlandschaft ist sie oft günstiger als viele einzeln wachsende Sonderlösungen.

Typischer Projektablauf von Analyse bis Go-Live

Wenn ein Anbieter sofort mit „Wir bauen das schnell" einsteigt, ohne Ihre Datenflüsse zu verstehen, ist Vorsicht angebracht.

Ein solides Schnittstellenprojekt läuft meist so:

Woran billige Schnittstellenprojekte später teuer werden

Der häufigste Fehler ist nicht schlechte Entwicklung, sondern ein zu klein gedachter Scope.

Eine einfache Praxisregel:

Lassen Sie sich nicht nur die Schnittstelle zeigen. Lassen Sie sich den Fehlerfall zeigen.

Welche Fragen Sie Anbietern vorab stellen sollten

Bevor Sie Angebote vergleichen, sollten Sie diese acht Fragen stellen:

1. Welches System ist in diesem Prozess führend? Wer das nicht klar beantworten kann, landet schnell in ungewollten Synchronisationskonflikten.
2. Wie gehen Sie mit Mapping und Datenqualitätsproblemen um? Die eigentliche Arbeit steckt oft nicht in der Verbindung, sondern im sauberen Übersetzen und Prüfen von Daten.
3. Was passiert bei Fehlern oder unvollständigen Datensätzen? Landen diese in einer Prüfstrecke? Gibt es Benachrichtigungen? Wird etwas automatisch wiederholt?
4. Wie verhindern Sie Dubletten und Mehrfachverarbeitung? Gerade bei Imports, Events und Wiederholungen ist das ein Kernpunkt.
5. Wie werden Änderungen an Feldern, Formaten oder Prozessen später umgesetzt? Eine gute Lösung ist nicht nur initial baubar, sondern auch später noch bezahlbar änderbar.
6. Was ist Standard — und was ist individuell? Das trennt echte Standardisierung von versteckter Individualentwicklung im Standardgewand.
7. Wie sehen Logging, Monitoring und Dokumentation aus? Lassen Sie sich nicht nur den Happy Path zeigen — lassen Sie sich zeigen, wie Fehler sichtbar werden.
8. Welche laufenden Kosten oder Betriebsaufgaben kommen danach dazu? Hosting, Middleware-Lizenzen, Support, Zertifikate, API-Änderungen, Wartung und Weiterentwicklung gehören zur Gesamtrechnung.

Fazit

Eine ERP-Schnittstelle ist selten „nur ein kleines Integrationsprojekt". Wer das Thema sauber angehen will, braucht Klarheit über drei Dinge:

• Was genau soll fließen? Welche Daten, welche Richtung, welche Ausnahmen?
• Wie integrationsfähig ist Ihr ERP wirklich? Nicht auf dem Papier, sondern in der Praxis.
• Wer betreibt das Ganze danach? Wartung, Monitoring und Änderungsfähigkeit gehören ins Angebot, nicht in die Fußnote.

Der günstigste Einstieg ist selten der, der auf dem Angebot am billigsten aussieht. Sondern der, bei dem jede Änderung, jeder Fehler und jede Erweiterung danach bezahlbar bleibt.

FAQ zu ERP-Schnittstellen und Kosten