B2B-Bestellwege vor einem ERP-Wechsel getrennt bewerten

Ich würde einen schwierigen Bestellweg für Geschäftskunden (B2B) zunächst getrennt vom Austausch der betrieblichen Verwaltungssoftware (ERP) bewerten. Eine bessere Suche, eine wiederverwendbare Artikelliste oder eine verständliche Statusanzeige können in einer Kundenanwendung entstehen. Ob dieser Weg trägt, entscheidet sich an der vorhandenen Anbindung und den benötigten Geschäftsregeln.

Die Grenze pro Funktion ziehen

Ein fiktiver technischer Großhändler möchte Kunden die Nachbestellung erleichtern. Das bestehende ERP bleibt für Kundenpreise und Auftragserstellung zuständig. Die folgende Aufteilung ist ein vorgeschlagener Entwurf.

Damit wird sichtbar, welche Arbeit tatsächlich die Oberfläche betrifft. Eine bessere Artikelsuche benötigt nicht automatisch ein neues Auftragswesen. Sie hilft aber wenig, wenn die gewählten Artikel anschließend falsch an das bestehende System übergeben werden.

Übersetzung löst keine fehlende Fähigkeit

Microsoft beschreibt eine Übersetzungsschicht zwischen unterschiedlich modellierten Systemen. Eine solche Grenze kann sinnvoll sein, wenn Kundenanwendung und ERP andere Datenformen verwenden. Im Beispiel soll sie die vereinbarte Zuordnung tragen, statt zwei unabhängig gepflegte Preislogiken entstehen zu lassen.

Beantwortet das ERP eine Auftragserstellung nicht rechtzeitig, muss die Anwendung den unsicheren Ausgang behandeln können. Eine Wiederholung darf nicht ungeprüft einen zusätzlichen Auftrag erzeugen. Zur Planung gehören deshalb ein wiedererkennbarer Vorgang und eine verlässliche Klärung des Ergebnisses. Eine optische Erfolgsmeldung schafft diesen Nachweis nicht.

Wann die getrennte Erneuerung an ihre Grenze kommt

Kann das bestehende System benötigte Kundenpreise nicht liefern, Aufträge nicht kontrolliert anlegen oder Berechtigungen nicht passend unterstützen, reicht eine neue Oberfläche allein nicht. Dann sind Anpassungen, ein anderer Integrationsweg oder auch die Ablösung des ERP zu prüfen. Die kleinere Anfangsmaßnahme ist kein Selbstzweck.

Umgekehrt braucht nicht jedes Projekt einen eigenen zusätzlichen Vermittlungsdienst. Reicht eine vorhandene, betreute Schnittstelle für die benötigte Zuordnung, sollte zusätzliche Infrastruktur ihren Aufwand begründen.

Für den Großhändler wäre ein begrenzter Probelauf aussagekräftig: einen Artikel im richtigen Kundenkontext finden, den bestätigten Preis anzeigen, einen Testauftrag übergeben und dessen Ergebnis wieder zuordnen. Scheitert dabei die Oberfläche, liegt dort die Aufgabe. Fehlt eine benötigte Fähigkeit im Kernsystem, muss die Entscheidung diese Grenze berücksichtigen. So wird der Umfang eines ERP-Wechsels aus einem belegten Problem abgeleitet.

Quellen

• Microsoft Azure Architecture Center: Anti-Corruption Layer pattern