Wenn Customizing zur Legacy wird

Gegenüber „Enterprise Resource Planning Systems” (ERP-Systeme) habe ich gemischte Gefühle. Sie sind einerseits allumfassende Schweizer Taschenmesser: Mächtige Werkzeuge, um Prozessabläufe (teil-)automatisiert mit Software umzusetzen, ohne eine Armada an Softwareentwickler*innen zu beschäftigen. Auf der anderen Seite können größere eigene Anpassungen von ERP-Systemen zu immensen Kostenfaktoren ohne Nutzen und somit zu großen Bürden werden: den gefürchteten „Legacy-Systemen”.

Einleitung

Ich möchte anhand einer (mehr oder weniger) fiktiven Geschichte erzählen, wie ein Unternehmen in tiefen Schwierigkeiten mit seinem eingekauften ERP-System gerät. Dazu verwende ich die Werkzeuge Wardley Maps von Simon Wardley sowie die Core Domain Pattern (aus dem Bereich des strategischem Domain-driven Design) von Nick Tune, um die normalerweise nicht sichtbaren Vorgänge und Herausforderungen auf einer strategischen Ebene darzustellen.

Rudimentäre Kenntnis von Wardley Maps wird empfohlen, ist jedoch zum Grundverständnis des Blog-Artikels nicht zwingend notwendig.

Infos zu Wardley Maps

Wardley Maps sind evolvierende Strategielandkarten, welche ein kontextspezifisches Situationsbewusstsein für die eigene IT-Landschaft schaffen.

Die y-Achse einer Wardley Map zeigt die Wertschöpfungskette ausgehend von den Stakeholder-Bedürfnissen zu den betrachteten Komponenten, welche diese Bedürfnisse befriedigen. Komponenten werden teils direkt von den Stakeholder wahrgenommen (wenn sie z. B. direkt genutzt werden) oder sind teils überhaupt nicht mehr sichtbar (da sie z. B. technische Details sind).

Die x-Achse unterteilt die Evolution einer Komponente in vier aufeinanderfolgende Phasen: 1) Genesis: Es ist völlig unklar, wie man die Komponente herstellt oder ob sie überhaupt jemand braucht. 2) Custom Built: Herstellungsprozesse sind noch sehr wacklig und wenig wiederholbar, es gibt aber schon einen ersten Bedarf. 3) Product: Das Hergestellte wird mit beherrschbaren Prozessen zuverlässig erzeugt und der Markt nimmt es in großer Stückzahl ab. 4) Utility: Der sichere Massenmarkt bezieht das Angebotene quasi direkt aus der Steckdose.

Für Wardley Maps gibt es ein hervorragendes 5-Minuten-Intro-Video, ein paar Einstiegsempfehlungen sowie ein kurzes Online-Video-Tutorial von mir.

Nachfolgend wechseln sich zudem die Visualisierungen und die zugehörige Terminologie zusammen mit erklärenden Texten ab.

Die Geschichte

Unsere Geschichte beginnt in den frühen 2000ern. Wir waren Softwareentwickler*innen in einem mittelständischen E-Commerce-Unternehmen. Das Unternehmen verkaufte Waren auf Online-Marktplätzen wie eBay oder Amazon. Kein anderes Unternehmen konnte APIs von verschiedenen Marktplätzen so integrieren wie wir. Wir waren die Stars unter den API-Integratoren. Die flexible API-Integrationen war unser Kerngeschäft („core”). Als Vehikel verwendeten wir dazu ein brandneues ERP-System, das wir entsprechend den Wünschen nach flexiblen API-Integrationen „gecustomized” hatten.

Das ERP-System wurde aber nicht nur für die API-Integration allein eingeführt, sondern auch für all diese allgemeinen Dinge wie etwa für die Rechnungsstellung, für die wir natürlich keine eigene separate Anwendung erstellen wollten. Auch dafür nutzten wir die mitgelieferten ERP-Module (wir waren ja nicht dumm!).

Wie es eben so ist, kamen mit der Zeit immer spezielle Anforderungen von Vertriebler*innen zu uns ERP-Systementwickler*innen. Wir konnten (und wollten auch) dem Vertrieb einfach keinen Wunsch abschlagen. Dies hatte aber seinen Preis: Das ganze Customizing bei den API-Anbindungen war teuer und stark von den Interna des ERP-Systems abhängig (ERP v1 base). Ja, es gab Dinge wie Schnittstellen und ein herstellerspezifisches Datenbankschema, aber wer scherte sich denn damals wirklich um die x-te Normalform, oder? Und die paar zusätzlichen Spalten in den vorhandenen Tabellen waren schnell gemacht. Niemand konnte das ERP-System so aufmotzen wie wir! Als technisch richtig fitte Entwickler*innen haben wir sogar das Basismodul unseres ERP-Systems (ERP v1', grün) angepasst.

Einige Jahre strichen ins Land und plötzlich (wer hätte das gedacht!): Eine Gesetzesänderung in der Rechnungsstellung! Der Hersteller des ERP-Systems veröffentlichte eine neue Version (ERP v2, rot), die alle Updates für Einhaltung der neuen gesetzlichen Vorschriften für das Rechnungsmodul kostenlos mit sich brachte (ebenfalls rot). Wir würden nur auf diese Version aktualisieren müssen und alles wäre wieder in Ordnung.

Aber nicht so schnell! Vor einigen Jahren haben wir das ERP-Basismodul so stark verändert, dass wir nicht auf neue ERP-Versionen aktualisieren konnten. Es war eine von uns ganz bewusst getroffene Entscheidung, das supercoole API-Integrationstool auf der Basisfunktionalität des ERP-Systems umzusetzen, um schnell die Bedürfnisse des Vertriebs befriedigen zu können. Damals war es auch völlig in Ordnung für uns, dies so zu tun. Aber wir steckten damit auf einmal auch in der Vergangenheit fest, da wir die Interna des ERP-Systems massiv angepasst hatten. Dadurch entstand eine enorme Trägheit in der Weiterentwicklung des ERP-Systems (rote dicke Linien).

Wir hatten auch eine Menge Geld in die Anpassungen gesteckt. Wir wollten also nicht alle Investitionen einfach so von Bord werfen. Aber selbst, wenn wir bereit gewesen wären, den Preis dafür zu zahlen, hätten wir nicht aktualisieren können: Alle Module in unserem System waren von einer undefinierten Masse an kundenspezifischem Code im Basismodul abhängig. Das Risiko, all die wertvollen Mikrooptimierungen zu verlieren, war uns einfach zu hoch. Damit blieb uns nur eine Option übrig: Wir mussten sicherstellen, dass die alte Version unseres Moduls für die Rechnungsstellung den neuen gesetzlichen Bestimmungen entsprach. Wir programmierten unser eigenes Ergänzungsmodul für die Rechnungserstellung (rot gefärbte Komponente unten links) – einer Funktion, welche uns keine Differenzierung gegenüber dem Wettbewerb liefert („generic subdomain”). Oder anders ausgedrückt: Wir verbrannten Geld!

Aber es kam noch dicker: Mit dem neuen ERP-System gab es auch eine neue, supercoole API-Integration einfach „out of the box” (violett eingefärbt). Alle unsere Konkurrenten konnten nun auf das neuere System updaten. Unsere Differenzierung verschwand im Vergleich zu unseren Mitbewerbern völlig und ließ uns mit dem alten System zurück, weil wir diese Chance nicht nutzen konnten. Wir steckten in der Vergangenheit fest (violette dicke Linie)!

Wir stießen auf „Table Stakes Former Core” (sinngemäße Übersetzung etwa „Ballast des früheren Differenzierungsmerkmals”): Unser früheres Kernelement des Erfolgs wurde zu einer bloßen unterstützenden Funktion degradiert und lastete schwer auf uns. Auf einmal standen wir komplett mit der bloßen Aufrechterhaltung gewöhnlicher Systemfunktionen („generic”, „supporting”) da. Kein neuer, differenzierender Wettbewerbsvorteil („core”), dafür aber ein Berg von Herausforderungen, um das alte System irgendwie am Laufen zu halten, weil wir kein Geld mehr hatten, aus diesem Schlamassel herauszukommen. Unser eigenes Customizing ist nun unser Legacy!

Das unglückliche Ende.

Und nun?

Was ist die Moral der Geschichte?

Natürlich ist diese Geschichte überspitzt erzählt worden. Was lief denn nun gut und was lief schlecht? Nun ja, niemand kann die Zukunft vorhersehen. Und manchmal läuft es auch einfach nur unglücklich. Es gibt immer wieder sehr verzwickte Lagen, in die wir auch ohne ERP-Systeme laufen können. Aber es gibt einige Dinge insbesondere beim Einsatz von ERP-Systemen zu beachten:

Wenn wir ein ERP-System verwenden, schlagen wir uns nicht mit der Anpassung des Basismoduls des ERP-Systems als Differenzierungselement herum. Dies führt früher oder später ansonsten nur zu Lasten einer fehlenden Updatemöglichkeit. Wir denken bei Erweiterungen auch immer daran, dass es Abhängigkeiten zu Modulen anderer strategischer (Nicht-)Bedeutung gibt, die vom Basismodul abhängen. Im schlimmsten Fall wendet sich hier auf einmal das Blatt und wir stehen mit der kostenintensiven Pflege von unterstützenden und generischen Modulen dar, die keine Differenzierung gegenüber dem Wettbewerb bietet.

Und auf der Metaebene hoffe ich, einen Beitrag dazu geleistet zu haben, wie solche Situationen mit Hilfe von Simon Wardleys „Wardley Maps” und Nick Tunes „Core Domain Patterns” aufgezeigt und analysiert werden können. Ich schätze beide Werkzeuge als großartige Hilfen für mehr kontextspezifisches, strategisches Denken im IT-Bereich.

Hinweis: Diesen Blog-Post habe ich mit ähnlichem Inhalt auch als englischsprachige Version (externe Seite) veröffentlicht.

Header-Bild von Ghinzo auf Pixabay