Schnittstellenentwicklung in ERP-, EDI- und Systemintegrationsprojekten gelingt sauber, wenn Sie fünf Phasen strikt durchlaufen: Quellsystem verstehen, Datenflüsse klären, Verantwortlichkeiten festziehen, Testfälle aufbauen und die Abnahme vorbereiten. Wer Monitoring und Fehlerhandling schon während der Entwicklung mitdenkt, erreicht den Go-live ohne wochenlange Nachbesserung. Im Mittelstand scheitert genau das aber oft.
Für Entscheider heißt das konkret: Die technischen Weichen für Betrieb und spätere Änderungen stellen Sie in den ersten Projektwochen. Wer Quellsystem, Datenverantwortung und Testkonzept früh klärt, spart sich später die Feuerwehreinsätze, die richtig Zeit und Nerven kosten.
Stand der Quellenprüfung: 22. September 2026
Drei Reibungspunkte entscheiden dabei über Erfolg oder Verzug: fehlende Dokumentation, unklare Zuständigkeiten und zu knapp kalkulierte Tests. Ein paar Zahlen aus der Praxis machen das Risiko greifbar.
Die Schnittstellenentwicklung startet direkt am Quellsystem: Sie prüfen, welche Daten es liefert, in welchem Format, mit welcher Aktualität und welchen Sonderfällen. Erst danach lässt sich seriös planen, was eine neue Schnittstelle technisch überhaupt leisten muss.
In vielen Mittelstandsprojekten ist genau das der erste Bruch im Zeitplan. Alte ERP- oder Warenwirtschaftssysteme laufen seit Jahren stabil, aber niemand im Haus kann mehr erklären, warum ein bestimmtes Feld befüllt wird oder welche Ausnahme ein Custom-Report abfängt. Fehlt die Dokumentation, wird das Quellsystem zur Blackbox. Dann müssen Sie die Fachlogik erst aus echten Datenständen zusammenpuzzeln, bevor die Entwicklung losgeht. Genau für diese Situation hilft ein strukturiertes Reverse Engineering von Blackbox-Schnittstellen, das die verborgene Logik aus Beispieldaten und Feldverwendung wieder sichtbar macht.
Praktisch bedeutet das: Sie ziehen reale Exportdateien oder Datenbankauszüge und vergleichen sie mit dem, was die Fachabteilung erzählt. Abweichungen dokumentieren Sie sofort. Wer diesen Schritt überspringt, baut die Schnittstelle gegen eine Annahme über das System und bezahlt das später in der Testphase mit Nacharbeit.
Bevor Sie eine einzige Mapping-Regel schreiben, legen Sie fest, welches System für welches Datenfeld die führende Quelle ist und wer bei Änderungen entscheidet. Ohne diese Klärung entstehen Schnittstellen, die technisch laufen, aber im Betrieb niemand konsequent pflegt.
Für Datenflüsse hat sich eine einfache Regel bewährt: Jedes Feld hat genau eine führende Quelle, jede Transformation wird dokumentiert, und jede Ausnahme bekommt einen eigenen Namen im Regelwerk. Erprobte Templates und Best Practices in der Datenintegration verkürzen diesen Schritt erheblich, weil Sie auf wiederholbaren Mustern aufsetzen können.
Bei Partneranbindungen über EDI kommt meist ein Standardformat zum Einsatz. In Deutschland dominiert dabei EANCOM als UN/EDIFACT-Subset von GS1. In der Automobilindustrie ergänzt der VDA-Standard mit eigenen, vierstellig codierten Nachrichtentypen wie VDA 4905 dieses Bild. Welcher Standard gilt, klären Sie vor dem Mapping.
Verantwortlichkeiten lassen sich am saubersten über eine RACI-Matrix regeln: Wer ist verantwortlich (Responsible), wer trägt die Rechenschaftspflicht (Accountable), wer wird konsultiert, wer nur informiert? Entscheidend ist, dass pro Aufgabe nur eine Person accountable ist. Doppelte Zuordnung ist der klassische Fehler, der im späteren Betrieb zu Verantwortungsdiffusion führt: Fällt ein Fehler auf, schiebt jede Seite die Verantwortung der anderen zu.
Testfälle, die vor dem Go-live wirklich etwas finden, orientieren sich am V-Modell: Komponententest, Integrationstest, Systemtest und Abnahmetest greifen ineinander. Jede Stufe deckt andere Fehlerarten auf, und genau das nutzen Sie, indem Sie Testfälle stufengerecht planen.
Das ISTQB-Standardglossar, auf Deutsch vom German Testing Board herausgegeben, unterscheidet diese Teststufen bewusst, weil sich verschiedene Fehlerarten auf unterschiedlichen Ebenen zeigen: Ein falsches Feldmapping fällt im Komponententest auf, ein Timing-Problem zwischen zwei Systemen oft erst im Integrationstest.
Faustregel aus der Testpraxis: Integrationstest und Systemtest finden unterschiedliche Fehler. Der eine zeigt Probleme im Zusammenspiel zweier Systeme, der andere Lücken im gesamten Geschäftsprozess. Wer diese beiden Stufen bei der Schnittstellenentwicklung zusammenlegt, verschiebt einen Teil der Fehler in den produktiven Betrieb.
Für die Praxis heißt das: Bauen Sie Testfälle entlang echter Geschäftsvorfälle auf. Ein Testfall zu einer Gutschrift mit Teillieferung und abweichender Steuerart deckt mehr auf als zehn Testfälle, die jeweils nur ein einzelnes Feld isoliert prüfen.
Die Abnahme ist die letzte Prüfstufe vor dem Go-live, und sie findet bewusst in einer produktionsnahen Umgebung statt. Der Systemtest läuft noch in der Testumgebung des Entwicklers, die Abnahme simuliert dagegen Installation, Konfiguration und reale Partneranbindungen so genau wie möglich. So finden Sie Probleme, die im isolierten Systemtest gar nicht auftauchen.
Setzen Sie für die Abnahme feste Kriterien: definierte Geschäftsvorfälle, die durchlaufen müssen, akzeptierte Fehlerklassen und eine klare Freigabe-Verantwortung laut Ihrer RACI-Matrix. Wer die Abnahme erst eine Woche vor dem geplanten Termin plant, gerät fast automatisch unter den Zeitdruck, der schon viele ERP-Projekte belastet hat. Besonders kritisch wird das bei Schnittstellen im Rahmen eines ERP-Systemwechsels, weil dort mehrere Migrationen gleichzeitig laufen und ein verschobener Cutover ganze Lieferketten stoppt.
Planen Sie deshalb einen Puffer zwischen letztem Testlauf und Go-live-Termin ein, in dem Nachbesserungen noch ohne Produktionsdruck möglich sind. Dieser Puffer entscheidet oft darüber, ob der Go-live kontrolliert verläuft oder in einer Nachtschicht am Wochenende endet.
Vier Reibungspunkte tauchen in nahezu jedem Mittelstandsprojekt zuverlässig auf.
Fehlende Dokumentation ist dabei kein Randproblem. Nach unserer Projekterfahrung scheitern Ablösungen von Altsystemen häufig am fehlenden Wissenstransfer: Implizites Fachwissen wurde nie aufgeschrieben, und mit dem Mitarbeiter, der es im Kopf hatte, verschwindet es aus dem Projekt. Wer Knowledge-Transfer fest ins Projektbudget einplant, umgeht diese Falle.
Wie teuer ungepflegte Legacy-Strukturen werden, zeigt sich im Alltag vieler IT-Teams: Ein wachsender Teil der Entwicklungszeit fließt in Wartung, Workarounds und das Verstehen alter Logik statt in neue Funktionen. Das gilt für den 50-Personen-Betrieb genauso wie für den Konzern. Wer Altlasten ignoriert, zahlt strukturell mehr.
Zeitdruck verschärft alle drei anderen Punkte gleichzeitig. Der CHAOS Report der Standish Group beziffert den Anteil gescheiterter oder mangelhaft abgeschlossener Technologieprojekte weltweit seit Jahren auf rund zwei Drittel, ein US-zentrierter, aber viel zitierter Risikowert. Für den DACH-Mittelstand liefert die Trovarit-Studie den passenderen Anker: Schnittstellen zählen dort traditionell zu den Schwachstellen von ERP-Systemen, wurden zuletzt aber besser bewertet als zwei Jahre zuvor, ein Hinweis darauf, dass strukturiertes Vorgehen wirkt.
Auch die Kostenseite gehört zum Zeitdruck-Thema: Stundensätze für professionelle Softwareentwicklung in Deutschland liegen meist zwischen 80 und 150 Euro, je nach Erfahrungsgrad und Region, und Schnittstellenprojekte bewegen sich in diesem Rahmen. Wird die Testphase zusammengestrichen, um Budget zu sparen, verschiebt sich genau dieser Aufwand in den teureren Produktivbetrieb.
Monitoring und Fehlerhandling gehören in die Entwicklungsphase selbst, weil sich Architekturentscheidungen dafür kaum nachträglich reparieren lassen. Wer erst nach dem Go-live über Alarmierung nachdenkt, baut sie gegen eine bereits laufende Schnittstelle, was regelmäßig zu Kompromissen führt.
Drei Muster haben sich in robusten Schnittstellenarchitekturen durchgesetzt: zentrales Monitoring mit Alerting, das Abweichungen sofort meldet, Retry-Mechanismen mit Idempotenz, die eine Nachricht nicht doppelt verarbeiten, selbst wenn sie mehrfach ankommt, und Dead-Letter-Queues, die fehlgeschlagene Nachrichten aufbewahren statt sie zu verwerfen. So geht im Fehlerfall keine Bestellung, keine Rechnung und keine Lagerbuchung verloren.
Ebenso wichtig ist die organisatorische Seite: Wer bekommt welchen Fehler gemeldet, und wer muss ihn lösen? Mit einem Fehlerhandling nach dem Verursacherprinzip landet ein fehlerhafter Datensatz automatisch bei der Stelle, die ihn verursacht hat. Das verkürzt Reaktionszeiten und verhindert das Ping-Pong zwischen Abteilungen, das viele Schnittstellenbetriebe lähmt.
Wir begleiten solche Projekte nicht nur technisch, sondern schließen auch Lücken bei Dokumentation, Tests und späterem Betrieb, wenn genau diese Punkte im Projektalltag untergehen.
Die RACI-Matrix, die Sie in den ersten Projektwochen aufstellen, taucht am Ende noch einmal auf: als Grundlage für Ihr Fehlerhandling im Betrieb. Wer schon beim Datenfluss-Mapping festlegt, welche Abteilung für welches Feld verantwortlich ist, muss das später nicht neu erfinden, wenn eine Schnittstelle im Live-Betrieb einen Fehler meldet. Wie Sie in der ersten Woche die Organisation aufstellen, entscheidet später über die Betriebsstabilität. Das übersehen viele Projekte, weil Entwicklung und Betrieb getrennt geplant werden.
Genauso hängt die Testphase direkter am Go-live-Termin, als die meisten Projektpläne zugeben. Wird sie verkürzt, verschiebt sich der eigentliche Aufwand in die ersten Betriebswochen, dann mit echten Kunden- und Lieferantendaten statt Testdatensätzen. Das kostet mehr Nerven und in der Regel auch mehr Geld als der ursprünglich eingesparte Testtag.
Der konkrete nächste Schritt: Prüfen Sie vor dem nächsten Sprint-Planning, ob für Ihre aktuelle Schnittstelle bereits eine RACI-Zuordnung, ein stufenweises Testkonzept und ein dokumentiertes Fehlerhandling existieren. Fehlt eines der drei, ist das der Punkt, an dem Sie ansetzen, bevor Sie einen Go-live-Termin überhaupt festlegen.
Wie lange dauert die Schnittstellenentwicklung in einem typischen ERP-Projekt?
Eine komplette ERP-Einführung im Mittelstand dauert laut aktuellen Branchendaten zehn bis dreizehn Monate, wobei die Schnittstellenentwicklung parallel zu Datenmigration und Anpassung läuft. Mehr als die Hälfte dieser Projekte verfehlt dabei Zeit- oder Budgetziele, weshalb ein realistischer Zeitplan für Schnittstellen von Anfang an eingeplant werden sollte.
Was tun, wenn zu einer Altsystem-Schnittstelle keine Dokumentation existiert?
Fehlt Dokumentation, rekonstruieren Sie die Fachlogik aus echten Datenständen: Exportdateien, Datenbankauszüge und konkrete Beispielfälle zeigen, wie ein Feld tatsächlich befüllt wird. Diese Reverse-Engineering-Arbeit gehört fest in den Projektplan, weil sie sonst später im Testzeitraum unkontrolliert Zeit kostet.
Wer ist bei der Abnahme einer neuen Schnittstelle verantwortlich?
Das übernimmt die Person, die laut RACI-Matrix als Accountable für die Schnittstelle benannt wurde, meist der fachliche Prozessverantwortliche auf Kundenseite. Diese Rolle prüft definierte Geschäftsvorfälle in der produktionsnahen Testumgebung und gibt die Freigabe zum Go-live.
Wie viele Testfälle braucht eine Schnittstelle vor dem Go-live wirklich?
Es gibt keine feste Zahl, entscheidend ist die Abdeckung realer Geschäftsvorfälle statt einzelner Felder. Eine Schnittstelle mit Sonderfällen wie Teillieferungen, Gutschriften oder abweichenden Steuersätzen braucht für jeden dieser Fälle einen eigenen Testfall über Komponenten-, Integrations- und Systemtest hinweg.
Was kostet die Entwicklung einer Schnittstelle in Deutschland typischerweise?
Stundensätze für professionelle Softwareentwicklung liegen in Deutschland meist zwischen 80 und 150 Euro, abhängig von Erfahrung und Region. Der Gesamtaufwand hängt stärker von der Komplexität des Quellsystems und der Anzahl der Testfälle ab als vom reinen Stundensatz, weshalb Pauschalpreise ohne Systemkenntnis wenig aussagekräftig sind.
Quellen:
