App an ERP & Altsysteme anbinden

TL;DR: Die wenigsten Business-Apps stehen allein. Sie müssen an das reden, was schon da ist: ERP, Warenwirtschaft, Buchhaltung, ein gewachsenes Altsystem. Genau hier wird es anspruchsvoll - nicht in der App, sondern in der Anbindung. Wer die Schnittstellen-Frage früh und sauber klärt, baut eine App, die sich nahtlos einfügt. Wer sie unterschätzt, baut eine Insel. Hier hilft, dass ich nicht nur Apps baue, sondern auch Software-Architektur und Altsysteme verstehe.

---

Für Entscheider: Worum es geht

Eine schöne App, die die Daten doppelt erfasst, weil sie nicht mit dem ERP spricht, ist kein Fortschritt - sie ist eine zweite Insel. Der eigentliche Wert einer Business-App entsteht erst, wenn sie sich in Ihre bestehende Systemlandschaft einfügt: Aufträge aus dem ERP holen, Erfassungen zurückschreiben, Stammdaten synchron halten.

Das Problem: Diese bestehenden Systeme sind oft alt, eigen oder zugeknöpft. Manche haben moderne Schnittstellen, manche nur eine Datenbank, an die man nicht so einfach heran darf. Die Anbindung ist deshalb häufig der schwierigere - und unterschätzte - Teil des Projekts.

Warum die Anbindung oft das eigentliche Projekt ist

„Wir brauchen nur eine kleine App, die Aufträge anzeigt." Klingt einfach. Aber wo kommen die Aufträge her? Aus dem ERP. Wie kommt man da heran? Gibt es eine Schnittstelle? Ist sie dokumentiert? Darf man sie nutzen? Was passiert, wenn die App etwas zurückschreibt - ist das System dafür gebaut?

Genau an diesen Fragen entscheidet sich der Projekterfolg. Die App-Oberfläche ist in Wochen gebaut. Die zuverlässige, sichere, wartbare Anbindung an ein gewachsenes System kann der größere Brocken sein. Das ist keine schlechte Nachricht - man muss es nur wissen und einplanen, statt es zu übersehen.

Der Sonderfall SAP: „Darf man" kann sehr teuer werden

Ein Beispiel, das zeigt, warum die Frage „darf man die Schnittstelle nutzen?" mehr ist als eine Formalität: SAP. Wer pragmatisch direkt auf eine SAP-Datenbank zugreift, um Daten in die App zu holen, begeht oft einen Lizenzverstoß. SAP verlangt für den Zugriff durch Drittsysteme regelmäßig zusätzliche Lizenzen (Stichwort „indirect access" bzw. „digital access") - ein Thema, an dem schon große Unternehmen massive Nachforderungen kassiert haben: Im Fall Diageo ging es um rund 54 Millionen Pfund, bei AB InBev forderte SAP sogar etwa 600 Millionen Dollar. Das sind keine abstrakten Drohungen, sondern dokumentierte Fälle.

Der scheinbar günstigste, direkteste Weg ist hier also der teuerste. Und Vorsicht vor einem verbreiteten Trugschluss: Eine Zwischenschicht (Weg 2) entkoppelt die Systeme und schützt das Altsystem technisch - aber sie ist kein Freibrief gegen SAPs Indirect-Access-Lizenzierung. Lizenzrechtlich zählt, dass ein Drittsystem die SAP-Daten nutzt, nicht über welchen technischen Umweg. Bei SAP gehört die Lizenzfrage also geklärt, egal welcher technische Weg gewählt wird.

Der konstruktive Ausweg passt genau zu meiner Beratungshaltung: vorher klären. Manche Unternehmen ergänzen ihre Verträge gezielt um Klauseln, die bestimmten Dritt-Lesezugriff ausdrücklich erlauben, und vermeiden so künftigen Streit. Hätten Diageo oder AB InBev ihre Integrationspläne vorab offen mit SAP besprochen, wäre die teure Nachforderung vermeidbar gewesen. Bei SAP umfasst die Machbarkeitsprüfung deshalb explizit das Gespräch mit SAP bzw. die schriftliche Klärung der Lizenz - bevor eine Zeile Code entsteht. Das ist der Unterschied zwischen jemandem, der nur weiß, wie man andockt, und jemandem, der auch weiß, ob man darf. Letzteres erspart Ihnen im Zweifel eine sehr unangenehme Rechnung.

Die Wege der Anbindung

Je nachdem, was Ihr bestehendes System anbietet, gibt es verschiedene Wege - von elegant bis pragmatisch.

1. Moderne API (der Idealfall)

Das Zielsystem bietet eine dokumentierte Schnittstelle (REST, oft mit klarer Authentifizierung). Dann ist die Anbindung sauber: Die App - oder besser eine Zwischenschicht - spricht direkt mit dem System. Viele moderne ERP- und Warenwirtschaftssysteme bieten so etwas.

2. Middleware / Zwischenschicht (der Regelfall)

Statt die App direkt ans ERP zu hängen, baue ich oft eine schlanke Zwischenschicht: ein kleines Backend, das zwischen App und Altsystem vermittelt. Vorteile: Die App bleibt einfach, die Logik der Anbindung ist an einem Ort gebündelt, und das empfindliche Altsystem ist von der App entkoppelt. Ändert sich eine Seite, muss man nicht alles anfassen. Das ist meist der robusteste Weg.

3. Datei- oder Datenbank-Austausch (der pragmatische Weg)

Manche Altsysteme bieten keine API, aber einen Export/Import (Dateien, CSV) oder einen kontrollierten Datenbankzugriff. Nicht schön, aber oft tragfähig - wenn man Sicherheit und Datenkonsistenz im Griff behält. Wichtig: Direkte Datenbankzugriffe sind meist nur dann sinnvoll, wenn sie vom Hersteller ausdrücklich vorgesehen oder technisch sauber abgesichert sind - sonst handelt man sich Instabilität oder rechtliche Probleme ein. Bei manchen Systemen wie SAP ist der direkte DB-Zugriff unter Umgehung der Anwendungsschicht ohnehin technisch nicht supportet und kann den Support-Anspruch kosten - es ist dort also nicht nur eine Geld-, sondern auch eine Stabilitätsfrage (dazu gleich mehr beim Stichwort SAP).

Die Knackpunkte, die jedes Anbindungsprojekt hat

• Datenkonsistenz: Was passiert, wenn die App offline erfasst und das ERP sich derweil ändert? Konfliktauflösung muss durchdacht sein.
• Sicherheit: Eine App, die ans ERP darf, ist ein potenzielles Einfallstor. Authentifizierung, Rechte, Verschlüsselung sind Pflicht - hier zahlt sich Security-Erfahrung aus.
• Performance: Das Altsystem darf von der App nicht in die Knie gezwungen werden. Die Zwischenschicht puffert und schützt.
• Fehlerfälle: Was, wenn das ERP nicht antwortet? Die App muss damit umgehen, ohne Daten zu verlieren.
• Berechtigungen: Wer darf was sehen und schreiben? Das muss sauber abgebildet werden.
• Wartbarkeit: Systeme ändern sich. Die Anbindung muss so gebaut sein, dass ein Update nicht alles bricht.

Hier zahlt sich Architektur-Erfahrung aus

Eine App-Entwicklerin, die nur Oberflächen baut, stößt bei der ERP-Anbindung schnell an Grenzen. Hier geht es um Schnittstellen, Datenmodelle, Sicherheit und den Umgang mit gewachsenen Systemen - also um Software-Architektur.

Das ist der Punkt, an dem meine 25+ Jahre über die reine App-Entwicklung hinaus zählen: Ich verstehe nicht nur die App-Seite, sondern auch die System-Seite. Wie ein Altsystem tickt, wo es empfindlich ist, wie man eine Brücke baut, die beide Seiten schützt. Genau diese Doppelkompetenz - App und Architektur - macht die Anbindung sicher. Diese Erfahrung stammt nicht nur aus der App-Entwicklung, sondern auch aus meiner Arbeit als Softwarearchitektin.

Typische Einsatzszenarien

Aufträge mobil bearbeiten

Der Außendienst oder das Service-Team holt Aufträge aus dem ERP, bearbeitet sie vor Ort und schreibt das Ergebnis zurück. Die Zwischenschicht sorgt dafür, dass beide Seiten konsistent bleiben - auch wenn vor Ort offline gearbeitet wurde.

Lager & Warenwirtschaft

Bestände in der App sehen und Bewegungen erfassen, synchron mit der Warenwirtschaft. Hier ist Datenkonsistenz besonders heikel - niemand will Geisterbestände durch doppelte Erfassung.

Zeit & Spesen Richtung Buchhaltung

Erfasste Zeiten oder Belege fließen strukturiert Richtung Buchhaltung/DATEV. Statt manueller Übertragung landen die Daten im richtigen Format am richtigen Ort.

Aufwand & Vorgehen

Der Aufwand hängt fast vollständig vom Zielsystem ab - nicht von der App:

• System mit guter API: Anbindung gut kalkulierbar.
• Altsystem ohne API: Erst muss der Zugangsweg gefunden und abgesichert werden - das ist der Hauptaufwand.
• Bidirektional + offline: Hin- und Zurückschreiben mit Konfliktauflösung ist die Königsdisziplin.

Mein dringender erster Schritt: eine Machbarkeitsprüfung der Schnittstelle. Bevor wir die App planen, klären wir, wie genau der Zugang zum Zielsystem aussieht und ob er trägt. Das ist der Punkt, an dem Projekte kippen - also schauen wir dort zuerst hin. Ein schlanker Proof of Concept, der einmal echte Daten aus Ihrem System holt und zurückschreibt, schafft Klarheit, bevor Budget fließt. Ich arbeite zu Festpreisen; nach dieser Klärung wissen Sie, woran Sie sind.

Checkliste: ERP-/Altsystem-Anbindung starten

• ☐ Welches Zielsystem genau (ERP, Warenwirtschaft, DATEV, Eigenbau)?
• ☐ Gibt es eine dokumentierte Schnittstelle - und darf man sie nutzen?
• ☐ Nur lesen oder auch zurückschreiben?
• ☐ Muss offline erfasst und später synchronisiert werden?
• ☐ Sicherheits- und Rechte-Anforderungen geklärt?
• ☐ Wer wartet/kennt das Zielsystem (Ansprechpartner)?
• ☐ Machbarkeitsprüfung der Schnittstelle vor App-Planung?

Fazit: Die Brücke entscheidet

Eine Business-App ist nur so wertvoll wie ihre Anbindung an das, was schon läuft. Die App-Oberfläche ist selten das Risiko - die saubere, sichere, wartbare Brücke zum ERP oder Altsystem ist es. Wer diese Frage zuerst stellt, statt zuletzt, baut eine App, die sich einfügt, statt eine Insel zu werden.

Mein Rat: Klären Sie die Schnittstelle, bevor Sie die App planen. Setzen Sie auf eine Zwischenschicht, die beide Seiten entkoppelt. Und holen Sie sich jemanden, der App und Architektur versteht - denn genau an dieser Naht entscheidet sich der Erfolg.