Ein ERP, das seine Aufgabe erfüllt, wird nicht zum Ablösekandidaten, weil es alt ist. Es wird zum Thema, wenn niemand mehr Daten hinein- oder herausbekommt, ohne sie von einem Bildschirm auf den nächsten zu übertragen. Die Prozessautomatisierung setzt an den Übergängen an, nicht in den Systemen. Fehlt dort ein brauchbarer Zugang, steht eine eigene Entscheidung im Raum — mit eigener Kostenrechnung.
Das ist nicht die Investitionsfrage, ob ein System insgesamt neu gebaut, abgelöst oder weiterbetrieben werden soll. Die gehört in einen eigenen Beitrag. Hier geht es nur um den Fall, in dem der Kern noch trägt und trotzdem blockiert: Es gibt keinen Weg, der sich vertraglich und technisch als Schnittstelle behandeln lässt.
Was „keine Schnittstelle“ wirklich heißt
„Keine Schnittstelle“ ist selten wörtlich wahr. Fast jedes System gibt irgendetwas heraus: einen CSV-Export, eine undokumentierte URL, einen Datenbankbenutzer, den irgendwann jemand eingerichtet hat, oder eine Oberfläche, über die sich klicken lässt. Der Unterschied liegt nicht darin, ob ein Kanal existiert, sondern ob er ein veröffentlichter Vertrag ist.
Martin Fowler unterscheidet genau das: öffentlich ist noch nicht veröffentlicht. Published Interface meint eine Schnittstelle außerhalb der eigenen Codebasis — und damit eine, die sich nicht mehr ungefragt ändern lässt. Eine undokumentierte URL, die heute funktioniert, ist in diesem Sinn keine Schnittstelle. Sie ist ein Zufall, der sich als Abhängigkeit tarnt.
Die OpenAPI Specification macht denselben Anspruch maschinenlesbar: Menschen und Programme verstehen die Fähigkeiten eines Dienstes ohne Quelltext, Zusatzdokumentation oder Mitschnitt. Wo diese Beschreibung fehlt, raten beide Seiten. Raten ist der teuerste Betriebszustand einer Integration.
Praktisch liegen die meisten Bestände auf einer Skala, nicht in zwei Körben:
- Veröffentlichter Vertrag. Dokumentierte Operationen, benannte Fehler, zugesagte Stabilität. Das ist der Normalfall, in dem Automatisierung billig bleibt.
- Stabiler Export. Datei, Zeitfenster, Format und Löschregel sind vereinbart. Für nächtliche Abgleiche oft ausreichend — und oft unterschätzt.
- Undokumentierter Kanal. Eine URL, ein SDK, ein Datenbankzugriff, den der Hersteller nicht als Produkt führt. Er trägt, bis das nächste Update ihn bricht.
- Nur die Oberfläche. Daten sind sichtbar, aber nicht adressierbar. Jeder automatisierte Klick ist eine Wette auf das nächste Release der Maske.
- Kein legaler Weg. Vertrag, Lizenz oder Technik verbieten den Zugriff. Hier endet die Baufrage, bevor sie gestellt ist.
Die Frage ist also nicht: „Gibt es eine API?“ Die Frage ist: Auf welcher Stufe liegt der Zugang — und hält diese Stufe die Last, die Sie darauf legen wollen?
Die vier Zugangswege und was sie tatsächlich kosten
Hohpe und Woolf verdichten Integration auf vier Wege: Dateiübertragung, gemeinsame Datenbank, entfernter Aufruf und Nachrichten. Jeder löst dasselbe Problem — verschiedene Anwendungen, langsame Netze, unvermeidliche Änderung —, aber mit einem anderen Preisprofil.
Was sich vor der Beauftragung benennen lässt, sind die Kostentreiber, nicht ein Marktpreis. Geratene Tagessätze gehören nicht in diese Rechnung. Die Größen, die den Aufwand bewegen, stehen auf der Prozessautomatisierungsseite:
- Zustand der Daten. Eine Schnittstelle, die unvollständige oder widersprüchliche Stammdaten ausliefert, beschleunigt den Fehler. Die Bereinigung ist Projektarbeit, nicht Vorarbeit.
- Qualität des Zugangs. Ein dokumentierter Vertrag kostet einen Bruchteil eines Wegs über Exportdateien oder über die Oberfläche.
- Zahl der Operationen und Ausnahmen. Der Regelfall ist billig. Jede abzubildende Ausnahme ist ein eigener kleiner Prozess.
- Betriebsanforderung. Ein nächtlicher Dateiaustausch ist etwas anderes als ein Aufruf, der während der Geschäftszeit durchlaufen muss.
- Änderungstakt der Gegenstelle. Ein Published Interface ändert sich langsam. Eine Oberfläche ändert sich, wann immer jemand eine Maske umbaut.
Die gemeinsame Datenbank wirkt billig, weil nichts übertragen wird. Sie koppelt die Systeme an dasselbe Schema; jede Änderung trifft alle gleichzeitig — der Lawineneffekt, den Hohpe als Grundrisiko beschreibt. Ein Datenbankbenutzer ist deshalb kein Ersatz für eine Schnittstelle, sondern eine Abkürzung, die die nächste Migration teurer macht.
Wann der Bau der richtige Weg ist
Eine Schnittstelle zu bauen heißt: vor dem bestehenden System eine Schicht zu errichten, die den fremden Vertrag in den eigenen übersetzt. Fowler nennt das Gateway — die eigene Anwendung spricht ihre Sprache, die Übersetzung sitzt an der Grenze, nicht verteilt im Code.
Der Bau ist der richtige Weg, wenn die folgenden Punkte zusammenkommen — nicht wenn drei von fünf „ungefähr“ passen.
Das System trägt seine Kernaufgabe. Was immer es tun soll, tut es zuverlässig. Die Störung sitzt am Übergang, nicht im Kern.
Der benötigte Zugang ist klein und beschreibbar. Sie können vorher aufschreiben, welche Daten in welche Richtung laufen, was ein Erfolg ist und was im Fehlerfall passiert. Lässt sich das nicht aufschreiben, fehlt die Regel, nicht die Technik.
Es existiert ein Zugang, der sich vertraglich halten lässt. Ein Herstellerexport, ein vereinbarter Dateiaustausch, eine geduldete API, ein lesender Zugriff, den der Vertrag nicht verbietet. Ohne diesen Kern bauen Sie keine Schnittstelle, sondern eine Umgehung.
Die Gegenstelle hat eine absehbare Lebensdauer. Der Hersteller existiert, der Wartungsvertrag läuft, ein End-of-Life ist nicht angekündigt. Eine Schicht vor einem sterbenden System ist der erste Schritt einer Ablösung — nur ohne den Mut, sie so zu nennen.
Der manuelle Jahresaufwand rechtfertigt den Bau, nicht die Ablösung. Häufigkeit mal Bearbeitungszeit mal interner Stundensatz, zuzüglich der Fehlerkosten der heutigen Übertragung. Diese Zahl liegt in Ihrem Haus, nicht auf einem Marktplatz.
Trifft das zu, ist der Bau die kleinere Entscheidung. Er lässt das System in seiner Aufgabe und beseitigt den Übergang, an dem niemand verdient.
Wann die fehlende Schnittstelle zur Ablösefrage wird
Die Schnittstelle ist der Anlass, nicht automatisch der Befund. Ablösung wird aus dieser Frage nur dann die richtige Antwort, wenn der Zugangsweg selbst nicht tragfähig ist — nicht, weil jemand „endlich modernisieren“ möchte.
Es gibt keinen legalen oder technischen Kern. Kein Export, kein Vertrag, kein lesender Weg, den der Hersteller anerkennt. Screen-Scraping und versteckte Datenbankzugriffe sind dann das gesamte Design. Sie fallen beim nächsten Update aus und sind bis dahin eine Angriffsfläche ohne Inventar.
Die Oberfläche ist der einzige Kanal und ändert sich häufig. Eine Automatisierung, die auf Pixel wettet, hat keinen Vertrag. Sie hat eine Annahme. Annahmen gehören nicht in den Betrieb kritischer Vorgänge.
Das System erfüllt seine Kernaufgabe nicht mehr. Dann ist die fehlende Schnittstelle nur das sichtbarste Symptom. Die Investitionsfrage — neu bauen, ablösen oder weiterbetreiben — gehört nicht hierher; sie hat andere Kriterien.
Jede gebaute Schicht wäre dauerhaft gegen das Produkt gearbeitet. Der Hersteller liefert keine API und plant keine. Die Modelle widersprechen sich in den Begriffen, nicht nur in den Feldnamen. Sie würden nicht übersetzen, sondern umdefinieren — bei jedem Release neu.
Die Datenlage ist schlechter als ihr Ruf. Wo dieselben Stammdaten in Freitext, Paralleltabellen und Kopien liegen, beschleunigt eine Schnittstelle den Fehler. Zuerst gehört geklärt, welches System für welche Information zuständig ist. Erst danach ist der Zugang ein Bauauftrag.
Ein häufiger Fehlschluss ist, die Ablösung sei „sowieso fällig“ und die Schnittstelle deshalb Zeitverschwendung. Wer den Übergang nicht beherrscht, kann auch nicht kontrolliert ablösen. Ein fehlender Zugang bereitet eine Ablösung nicht vor. Er blockiert sie.
Die Kostenrechnung, ohne geratene Marktpreise
Belastbare Euro-Beträge für den Bau gibt es erst, wenn Zugangsweg, Datenlage und Ausnahmen bekannt sind. Alles davor ist geraten. Was sich vorher aufstellen lässt, ist eine Gegenüberstellung aus Größen, die Sie selbst kennen.
Seite A — der heutige Übergang. Vorgänge mal Minuten mal interner Satz, zuzüglich der Fehler der Übertragung: doppelte Anlagen, falsche Bestände, versäumte Fristen. Das ist der Jahresaufwand, gegen den jede Maßnahme gerechnet wird.
Seite B — der gebaute Zugang. Aufwandsklasse statt Marktpreis: Operationenzahl, Stil (Datei, Aufruf, Nachricht), Ausnahmen, Betriebsanforderung. Dazu der laufende Preis: Überwachung, Anpassung bei Updates, Schlüssel. Eine Schnittstelle ohne Betrieb ist eine verschobene Störung.
Seite C — die Ablösung nur wegen des Zugangs. Migration, Parallelbetrieb, Schulung, Datenbereinigung, Lizenzwechsel. Diese Seite ist fast immer die größere. Sie wird trotzdem die richtige, wenn Seite B keinen vertraglichen Kern hat oder das System seine Kernaufgabe nicht mehr trägt. Sie wird die falsche, wenn jemand sie wählt, weil Seite B unbequem aussieht.
Ein Vergleich ohne Seite A ist keine Rechnung. Er ist eine Präferenz.
Was sich bei 01PC beziffern lässt, ist nicht der Bau der Schnittstelle, sondern die vorgelagerte Klärung. Das System-Audit prüft unter anderem die Dimension Integrationen: wer wen aufruft, mit welchem Vertrag, was im Fehlerfall passiert — einschließlich der Verbindungen, die in keiner Dokumentation stehen. Festpreis 6.500 € netto, vier Wochen, fünf benannte Dokumente, keine Folgeverpflichtung. Kommt die Frage aus einem Automatisierungsvorhaben, nimmt die Prozessaufnahme (3.900 € netto) den Ablauf so auf, wie er wirklich läuft.
Die Einstiegspreise für automatisierte Strecken — erste Strecke ab 7.500 €, jede weitere ab 3.500 € — gelten dort, wo ein Zugang existiert, der sich als Vertrag behandeln lässt. Sie sind kein Preis für „eine API bauen“. Wer sie so liest, rechnet mit der falschen Zeile.
Was „bauen“ konkret bedeutet — und was nicht
Bauen heißt hier nicht, im Altsystem eine API nachzurüsten, wenn der Hersteller das nicht vorsieht. Es heißt, an der Grenze eine Schicht zu betreiben, die den fremden Bestand übersetzt: welche Felder gemeint sind, welche Fehler wiederholbar sind, wer im Zweifel die Wahrheit besitzt. Die Arbeit sitzt an der Übersetzung, nicht im Kern. Sie gehört so dokumentiert, dass ein Dritter den Vertrag lesen kann — OpenAPI ist dafür das geläufige Format, weil es den Unterschied zwischen Zugang und Vertrag sichtbar macht.
Drei Wege sind kein Bau, auch wenn sie so angeboten werden:
- Klicks auf die Oberfläche. Kein Published Interface, sondern eine Annahme über Pixel. Die Annahme veraltet ohne Ankündigung.
- Ein schreibender Datenbankzugriff. Er umgeht jede Regel, die das System intern erzwingt, und hinterlässt Zustände, die die Fachlogik nie vorgesehen hat.
- Eine Schicht ohne Inventar und ohne Überwachung. Die OWASP API Security Top 10 listen genau das: undokumentierte Endpunkte, veraltete Versionen, fehlende Autorisierung, ungeprüfter Konsum fremder APIs. Eine gebaute Schnittstelle ist eine neue Angriffsfläche. Wer das nicht einpreist, hat die billigere Variante der Ablösung gewählt — ohne den Nutzen.
Der richtige Bau ist schmal: wenige Operationen, ein benannter Fehlerweg, ein Wiederanlauf, der denselben Vorgang nicht doppelt anlegt, und eine Zuständigkeit für den Fall, den die Schicht nicht kennt. Alles andere ist ein zweites System, das niemand beauftragt hat.
Zuerst der Befund, dann die Entscheidung
Ob eine Schnittstelle fehlt, ist eine Feststellung. Ob man sie bauen oder das System deshalb ablösen sollte, ist eine Entscheidung. Beides zu vermischen — „kein API, also neues ERP“ — ist die teuerste Abkürzung in dieser Landschaft.
Das System-Audit ist der passende erste Auftrag: fester Preis, feste Dauer, Dokumente, die ein anderer Dienstleister weiterverwenden kann. Es sagt, auf welcher Stufe der Zugang liegt, welche Verbindungen undokumentiert schon existieren und welche Seite der Rechnung die kleinere ist. Was danach passiert, entscheiden Sie.
Quellen