> Fallstudie I

Linkname=ERPMicroService

Best Practice
Eigene Module sicher planen und realisieren

„Viele Entwicklungen beginnen, ohne dass man seine Wünsche wenigstens in großen Teilen beschrieben und sich Standardlösungen angesehen hat. So wird die Komplexität unterschätzt.“

In vielen Ansätzen zum Requirements Engineering und Solution Architecture werden Geschäftsvorfälle in Domains und Attributen beschrieben. Der Schwerpunkt liegt in der Regel auf der statischen Betrachtung der Objekte und deren Relationen untereinander. Also wie man z.B. im Geschäftsvorfall „Kundenauftrag“ die Bestellung selbst in Kopf und Linien einteilt, oder wie man verschiedene Referenzen zum Artikel, Kunden oder Adressstamm implementiert.

Und so beginnt auch die Entwicklung der heutigen „Microservices“: Nicht selten hat alleine der Artikelstamm einer ERP-Standardlösung über 200 Felder, von denen oft nur 10 gebraucht werden, und 2 weitere als individuelle Anpassung kaum zu finden sind. Aber mit dem individuellen Microservice werden alle 12 Felder wie gewünscht angezeigt, und die Lösung erscheint zunächst als die genau passende und kostengünstige Alternative.

Prozessierung der Geschäftsvorfälle

Aber es sind bereits im Allgemeinen die zeitabhängigen Daten aus der Prozessierung der Geschäftsvorfälle (z.B. Gültigkeitszeiträume, Folgebuchungen, Abweichungen, Abgrenzungen), die selbst die klassischen ERP-Systeme an ihre Grenzen bringen, also z.B.:

• Von 10 bestellten Artikeln werden 8 Artikel versendet, 2 zurückgesendet, 5 berechnet, 3 als Sicherheit voraus bezahlt, 1 noch gar nicht genehmigt und 2 versehentlich geliefert, die gar nicht bestellt wurden … und der Kunde ist zwischenzeitlich umgezogen (Historisierung).

• Unterschiedliche Preisabweichungen müssen separat ausgewiesen werden, wie Großkundenrabatt, Rohstoffaufschlag, Änderungen im Währungskurs, oder weil eine ausländische USt-Sonderregelung besteht.

• Spezielle Konten im Finanzkontenplan müssen gebucht werden, damit ein Geschäftsvorfall erst einer späteren Periode zugerechnet wird, zu mehreren Kostenstellen gehört, einem bestimmten Bestand zugerechnet wird oder auf zusätzliche Art qualifiziert wird usw.

Artikel- und Branchenbesonderheiten

Hinzu kommen artikel- und branchenspezifische Anforderungen:

• Es müssen immer mehr Folgeaktionen ausgelöst werden, z.B. Mitteilungsworkflows, Nachbestellungen, Logistikoptimierungen, Zollvorbereitungen.

• Es werden z.B. immer neue Vertragsformen angeboten. Sie beinhalten immer differenzierte Abhängigkeiten und machen eine immer komplexere Preisberechnung erforderlich.

Die Herausforderung der Agilität

In den agilen Projekten erlebe ich häufig, wie obige Anforderungen zunächst zurückgestellt werden, weil man zu Beginn nur mit dem „Substanziellen“, also mit Artikel / Kunde / Bestellpositionen, anfangen möchte.

Das Problem spitzt sich in den modularisierten Microservices um so mehr zu, als dass immer komplexere Abstimmungs-Tabellen und Prozesse auf die prinzipiell autonomen Services verteilt werden. Es ist immer schwieriger, die Abhängigkeiten untereinander richtig zu verstehen und zu validieren.

Wenn einmal ein Prozess implementiert wurde, ist es kaum möglich, Ausnahmen in der Schrittfolge zuzulassen. Dabei sollte eigentlich jeder Fall auch noch sicher umkehrbar oder stornierbar sein, was oft genug gar nicht mehr realisiert wurde.

Und nicht zuletzt wird übersehen, dass schon die kontinentale oder angelsächsische Buchungsphilosophie (HGB, US GAAP, IFRS) die Strukturen beeinflussen kann. Denn sie unterscheidet sich eben gerade in ihrem Umgang mit den Abweichungen (Variance Accounting), wie ein Blick auf die Standardsysteme (SAP, Oracle, Baan, Peoplesoft) zeigt.

Über die Folgeaktionen und Branchenbesonderheiten haben wir noch nicht einmal gesprochen.

Lösung

In meinen Analysen biete ich an, die genannten bzw. relevanten Fälle („Capabilities“) zu Projektbeginn aufzulisten und zumindest grob in der Lösungsarchitektur und Projektplanung zu berücksichtigen. So vermeiden wir zunächst einmal unnötige Projektrisiken. Vor allem, wenn wir auch noch einmal auf bestehende Systeme schauen.

Darauf aufbauend ist es nicht nur viel leichter zu sammeln, welche Attribute bzw. Felder eine Bestellung hat. Sondern eben auch sicherer vollständig zu formulieren, welche Folgeprozesse durch jede Veränderung und Abweichung bei jedem relevanten Attribut ausgelöst werden sollen. In einigen Projekten haben wir tatsächlich mehrere Räume mit Masken und Prozessen volltapeziert, bis jedem wirklich jeder Button vollständig klar war.

Und da waren auch solche Prozesse dabei, die man in den Standardsystemen als selbstverständlich hingenommen hat, aber von denen man sich jetzt erst bewusst gemacht hatte, wie sie am einfachsten in der individuellen Lösung realisiert werden können.

Ich halte bereits zu Beginn zumindest eine Vorstellung über das Gesamtbild für so wichtig, dass ich eine rudimentäre Basisimplentierung zur Systematisierung von Artikelarten, Varianzen und Prozessen in einem DemoService bereitgestellt habe. Er hilft Euch dabei, die Fälle in ihren Auswirkungen und Lösungen leichter aufzuschlüsseln.