Schnittstellen: warum die Anbindung ans ERP teuer wird

Was eine Schnittstelle eigentlich ist

Fast jede Software, die du in einem Betrieb baust, muss mit anderen Systemen reden. Eine App für die Auftragserfassung braucht die Kundenstammdaten aus dem ERP. Ein Kundenportal muss wissen, welche Rechnungen offen sind. Ein Lagertool meldet Bestände zurück an die Warenwirtschaft. Der Punkt, an dem zwei Systeme Daten austauschen, heisst Schnittstelle, im Fachjargon API (Application Programming Interface).

Im Kern ist eine Schnittstelle eine Vereinbarung. System A legt fest, in welcher Form es Daten anbietet oder annimmt, und System B hält sich daran. Dazu gehören das Transportformat (etwa JSON über HTTPS), die Struktur der Daten und die Regeln, wann welcher Aufruf erlaubt ist. Solange beide Seiten dieselbe Vereinbarung verstehen, läuft der Austausch. Sobald eine Seite etwas anders meint als die andere, entstehen Fehler. Und dort beginnt die Arbeit, die ein Projekt verteuert.

Entscheidend ist der Unterschied zwischen der Fachlogik deiner Software und der Anbindung an Fremdsysteme. Die Fachlogik gestaltest du selbst, du bestimmst die Regeln. Bei der Schnittstelle bestimmst du nichts. Du passt dich an das an, was das andere System vorgibt, und das ist selten so ordentlich, wie du es gern hättest.

Das fremde Datenmodell: der erste Kostentreiber

Ein ERP wie SAP, Abacus oder Microsoft Dynamics ist über Jahre gewachsen. Sein Datenmodell bildet die ganze Firma ab: Kunden, Artikel, Aufträge, Buchungen, Lager, alles hängt zusammen. Gebaut wurde es für den Zweck des ERP, nicht für deine App. Wer andocken will, lernt seine Sprache, nicht umgekehrt.

Das klingt harmlos. Ist es nicht. Ein scheinbar simples Feld wie die Kundennummer kann im ERP an drei Stellen unterschiedlich gepflegt sein. Ein Artikel hat vielleicht eine technische ID, eine Artikelnummer und eine EAN, und welche du brauchst, hängt am Anwendungsfall. Adressen liegen oft verteilt in mehreren Tabellen, weil Liefer-, Rechnungs- und Stammadresse getrennt geführt werden. Bevor du eine einzige Zeile produktiven Code schreibst, musst du dieses Modell durchdringen. Das kostet Zeit.

Dann kommt das Mapping, die Abbildung zwischen zwei Welten. Deine App hat ein schlankes Datenmodell, zugeschnitten auf ihren Zweck. Das ERP hat sein breites, generisches. Für jedes Feld, das über die Schnittstelle läuft, definierst du, woher es kommt, wie es umgerechnet wird, wohin es geht. Datumsformate, Währungen, Mehrwertsteuersätze, Einheiten: alles muss übersetzt werden. Diese Arbeit ist stupide, aber unverzichtbar, und sie wächst mit jedem Feld, das du anbindest.

Dokumentation und Zugang sind oft das Nadelöhr

In der Theorie hat jedes moderne ERP eine dokumentierte API. In der Praxis ist die Doku oft unvollständig, veraltet oder beschreibt eine Funktion, die in deiner Installation gar nicht aktiviert ist. ERP-Systeme werden beim Kunden angepasst, mit eigenen Feldern, eigenen Workflows, eigenen Modulen. Die Standard-Doku beschreibt den Standard, nicht deine Installation.

Deshalb beginnt fast jede ERP-Anbindung mit Ausprobieren. Du brauchst einen Testzugang, am besten auf einem echten Abbild der Daten, und musst herausfinden, was die Schnittstelle wirklich liefert. Hier verstecken sich die Verzögerungen: Der Zugang muss erst beim ERP-Dienstleister beantragt werden. Das Testsystem ist nicht aktuell. Die nötige API-Lizenz steht gar nicht im Vertrag des Kunden. Solche organisatorischen Hürden kosten regelmässig mehr Zeit als das Programmieren selbst. Wer ein Projekt schon einmal an einem fehlenden Testzugang hängen sah, kennt diese Form von Ärger. Ähnliche Reibungsverluste sind ein Grund, warum SaaS-Projekte scheitern, wenn man sie unterschätzt.

Die Sonderfälle, die niemand auf dem Schirm hat

Der Hauptteil der Kosten steckt nicht im Normalfall. Den hast du in wenigen Tagen: Kunde anlegen, Auftrag übertragen, Bestand abfragen. Teuer werden die Sonderfälle, und in jedem gewachsenen Betrieb gibt es davon erstaunlich viele.

Was passiert, wenn ein Auftrag übertragen wird, der Kunde im ERP aber gesperrt ist? Wenn ein Artikel zwischenzeitlich gelöscht wurde? Wie behandelst du Teillieferungen, Rabattstaffeln, Gutschriften, Stornos? Was machst du mit einem Datensatz, dem ein Pflichtfeld fehlt, das deine App erwartet? Jeder dieser Fälle braucht eine bewusste Entscheidung und meist Code, der ihn abfängt.

Dazu kommt die Fehlerbehandlung. Deine App schickt einen Auftrag ans ERP, die Verbindung bricht mitten in der Übertragung ab. Ist der Auftrag angekommen oder nicht? Weisst du es nicht und sendest einfach erneut, hast du womöglich den doppelten Auftrag. Verlässliche Integrationen brauchen genau dagegen Mechanismen: eindeutige Vorgangsnummern, Wiederholungslogik, ein Protokoll über das, was schon verarbeitet wurde. Der Nutzer sieht davon nie etwas. Trotzdem entscheidet es darüber, ob die Integration läuft oder jeden Montag jemanden zum Aufräumen zwingt.

Genau deshalb lassen sich Integrationen so schwer schätzen. Zu Beginn kennst du die Sonderfälle schlicht nicht alle. Sie tauchen auf, sobald echte Daten durch die Schnittstelle fliessen, und echte Daten aus einem jahrelang gepflegten ERP sind unordentlicher als jede Spezifikation. Das ist kein Planungsfehler, sondern die Natur der Sache. Realistisch schätzen heisst hier: einen Puffer für das Unbekannte einplanen, statt den glatten Normalfall hochzurechnen. Dasselbe Prinzip gilt bei der Frage, was ein MVP kostet.

Wartung: warum die Schnittstelle nie fertig ist

Viele rechnen eine Integration als einmalige Ausgabe und sind dann überrascht, dass sie laufend Geld kostet. Das liegt in ihrer Natur: Eine Schnittstelle verbindet zwei Systeme, die sich beide unabhängig voneinander weiterentwickeln.

Das ERP bekommt ein Update, und ein Feld heisst plötzlich anders. Der Dienstleister stellt auf eine neue API-Version um und kündigt die alte. Im Betrieb verschieben sich Prozesse, und ein Sonderfall, den es vorher nicht gab, wird Alltag. Jede dieser Änderungen kann die Schnittstelle stören, und keiner merkt es sofort, weil sie im Hintergrund läuft. Oft fällt der Fehler erst auf, wenn Daten fehlen oder falsch sind. Dann ist die Ursachensuche aufwendig.

Deshalb gehört zu jeder ernsthaften Integration ein Monitoring: eine Überwachung, die meldet, wenn die Schnittstelle nicht mehr antwortet oder ungewöhnlich viele Fehler produziert. Wer Software baut, aber nicht betreibt, gibt diese Verantwortung am Tag der Übergabe ab. Wir bei Wertstifter halten es anders, weil wir unsere eigenen Produkte Wortfreunde und Reazon selbst betreiben. Eine Schnittstelle, die im Reazon-Umfeld Daten zwischen Systemen bewegt, taugt erst dann, wenn sie sich auch nach dem zehnten ERP-Update von selbst meldet, statt still zu versagen. Dieser Betriebsblick verändert, wie man eine Anbindung von Anfang an baut.

Was die Kosten konkret treibt

Sortiert man die Treiber, zeigen sich ein paar klare Muster. Am offensichtlichsten ist die Anzahl der Objekte und Felder. Eine Schnittstelle, die nur Kunden synchronisiert, ist ein Bruchteil des Aufwands einer, die Kunden, Artikel, Aufträge, Lieferungen und Rechnungen abdeckt. Jedes weitere Objekt bringt eigenes Mapping und eigene Sonderfälle mit.

Die Richtung des Datenflusses wiegt schwer. Daten nur lesen ist deutlich einfacher als schreiben. Schreibst du ins ERP zurück, trägst du Verantwortung für dessen Datenqualität, und Fehler haben echte Folgen, etwa eine falsche Buchung. Am teuersten ist die beidseitige Synchronisation, bei der beide Systeme dieselben Daten ändern dürfen. Dann musst du Konflikte auflösen: Wer gewinnt, wenn beide Seiten denselben Datensatz gleichzeitig anfassen?

Die Qualität der Gegenstelle entscheidet mit. Eine moderne, gut dokumentierte API mit stabilem Testsystem spart Wochen. Eine alte Schnittstelle, die nur über Dateiexporte oder eine direkte Datenbankverbindung erreichbar ist, kostet ein Vielfaches und bleibt fragil. Diesen Faktor beeinflusst du nicht, aber du solltest ihn früh prüfen. Er bestimmt die Bandbreite des Aufwands mehr als fast alles andere.

Zuletzt treibt die geforderte Verlässlichkeit die Kosten. Wo ein gelegentlicher Fehler verschmerzbar ist, baust du schneller als dort, wo die Buchhaltung auf der Schnittstelle fusst und sie jederzeit korrekt sein muss. Je höher der Anspruch an Konsistenz und Ausfallsicherheit, desto mehr Logik für Wiederholung, Prüfung und Überwachung steckt drin.

Wann sich eine ERP-Anbindung nicht lohnt

Nicht jede Integration ist ihr Geld wert. Wenn nur eine Handvoll Datensätze pro Woche den Besitzer wechseln, ist ein manueller Export oft die nüchternere Wahl. Jemand zieht einmal am Tag eine CSV-Datei und spielt sie ein. Das ist unschön, aber eine automatische Schnittstelle, die gebaut, getestet und über Jahre betrieben werden will, kostet hier mehr, als sie spart.

Genauso solltest du innehalten, wenn das ERP kurz vor einem Wechsel oder einer grossen Migration steht. Eine Schnittstelle gegen ein System zu bauen, das in einem Jahr verschwindet, ist verbranntes Budget. Und wenn die Gegenstelle nur über eine direkte Datenbankverbindung erreichbar ist, ohne saubere API, wird die Anbindung so fragil, dass sich der Aufwand selten rechnet. Dann lohnt es sich, zuerst beim ERP-Anbieter eine echte Schnittstelle zu fordern, statt um seine Datenbank herumzubauen.

Die Faustregel: Eine Schnittstelle lohnt sich, wenn das Datenvolumen hoch, der Vorgang häufig und die Korrektheit wichtig ist. Trifft nichts davon zu, ist der manuelle Weg ehrenwerter als sein Ruf.

Wie du die Kosten in den Griff bekommst

Die meisten Treiber lassen sich entschärfen, wenn du früh die richtigen Entscheidungen triffst. Der stärkste Hebel ist Reduktion auf das Nötige. Frag bei jedem Objekt und jedem Feld, ob du es wirklich brauchst. Oft will jemand alle Daten synchronisieren, obwohl der konkrete Anwendungsfall mit einem Drittel auskommt. Jedes Feld, das du nicht anbindest, kostet auch nichts in Mapping, Tests und Wartung.

Der zweite Hebel: früh mit echten Daten testen. Hol dir so schnell wie möglich Zugang zu einem realistischen Abbild des ERP und lass echte Daten durch die Schnittstelle laufen. Die teuren Sonderfälle zeigen sich nur dort, und je früher du sie kennst, desto günstiger sind sie. Ein Prototyp in Woche zwei ist mehr wert als eine perfekte Spezifikation, die an der Realität zerschellt. Welche Wege sich dafür eignen, ordnet der Vergleich der besten Wege, ein MVP zu bauen ein.

Der dritte Hebel ist eine klare Trennung zwischen App und Anbindung. Ist die Schnittstelle als eigene, abgegrenzte Schicht gebaut, kannst du sie anpassen, wenn das ERP sich ändert, ohne deine ganze App anzufassen. Diese Trennung kostet anfangs etwas mehr Struktur und zahlt sich bei jedem ERP-Update aus. Sie ist auch der Grund, warum eine sauber gebaute Anbindung über Jahre günstiger im Betrieb bleibt als eine schnell zusammengesteckte.

Wer eine Individualsoftware für KMU plant, behandelt die ERP-Anbindung am besten nicht als Nebensache am Schluss, sondern von Beginn an als eigenen Arbeitsbereich mit eigenem Budget und eigenem Puffer. Eine Schnittstelle ist kein Schalter, den man am Ende umlegt. Sie ist ein laufendes Stück Infrastruktur, das gebaut, getestet und betrieben werden will. Wer das von Anfang an einplant, zahlt am Ende weniger, weil die bösen Überraschungen ausbleiben, und behält eine Anbindung, die auch in drei Jahren noch verlässlich ihre Arbeit tut.