Enterprise Resource Planning (ERP)

ERP (Enterprise Resource Planning) bezieht sich auf eine Klasse von Unternehmenssoftware die den täglichen Betrieb eines Unternehmens unterstützt und seine Ressourcen verfolgt, allen voran Bargeld, Rohstoffe, halbfertige Produkte, Endprodukte, Kundenaufträge, Einkaufsaufträge und Lohnabrechnung. ERPs beinhalten typischerweise viele Module, die für die zentralen Geschäftsprozesse vorgesehen sind, d.h. Buchhaltung, Beschaffung, Vertrieb, Finanzen, Verkauf, … und bieten eine enge Integration zwischen diesen Modulen, um den Fluss der (transaktionalen) Informationen zwischen den Funktionen zu erleichtern. ERPs basieren auf relationalen Datenbanken und zeichnen sich in der Regel durch ein sehr umfangreiches Design aus: eine große Anzahl an Entitäten (z. B. Produkte, Kunden, Rechnungen, etc.), zahlreiche Bildschirme und ein hohes Maß an Konfigurierbarkeit.

Ursprung und Motivation

Im Laufe der 70er-Jahre wurde allmählich deutlich, dass elektronische Aufzeichnungen gegenüber dem herkömmlichen Papierdokument zahlreiche Vorteile boten. Elektronische Aufzeichnungen wurden billiger, schneller und zuverlässiger als Papieraufzeichnungen. Zwei Erfindungen, die ERPs vorausgingen, waren entscheidend, um elektronische Aufzeichnungen zu ermöglichen: Barcode-Scanner (1950’s) und relationale Datenbanken (1970’s). Barcode-Scanner boten eine überlegene Methode zur Verwaltung von Warenflüssen, steigerten die Produktivität und reduzierten Verwaltungsfehler. Dennoch blieb das Speichern, Organisieren und Verarbeiten elektronischer Aufzeichnungen trotz der dramatischen Verbesserungen bei der Datenerfassung durch Barcode-Scanner über zwei Jahrzehnte hinweg ein ungelöstes Problem. Relationale Datenbanken waren die Antwort der Softwareindustrie auf dieses Problem in den späten 70er-Jahren und auch fünf Jahrzehnte später bleiben sie die vorherrschende Methode im Geschäftsdatemanagement.

Allerdings erwiesen sich reine relationale Datenbanksysteme, wie sie typischerweise in den frühen 80er-Jahren verkauft wurden, als sehr teuer in der Implementierung, da jedes Unternehmen neu erfinden musste, wie alles in seiner Datenbank dargestellt werden sollte: Produkte, Kunden, Rechnungen, Zahlungen, etc. So entstand in den 80er-Jahren eine Reihe von Softwareunternehmen, die „vorkonfigurierte“ relationale Systeme verkauften. Diese Produkte wurden später kollektiv als ERPs bezeichnet, ein in den 90er-Jahren geprägter Begriff. Leider ist das Akronym ERP ein Fehlbegriff; es hätte eigentlich Enterprise Resource Management statt Planning heißen müssen. Tatsächlich ist Planung bestenfalls eine nachgeordnete Angelegenheit in ERPs. Wie im Folgenden dargelegt, stehen prädiktive Analysen im Wesentlichen im Gegensatz zum Kerndesign der ERPs.

Historisch gesehen setzten sich ERPs durch, weil sie eine Reihe von Abläufen rationalisierten, die zuvor mit erheblichem Verwaltungsaufwand verbunden waren. Zum Beispiel erforderte das Erteilen einer Einkaufsbestellung an einen Lieferanten das Ausfüllen eines Formulars mit dem Namen und der Adresse des Lieferanten. Die Bestellpositionen durften nur gültige Produktreferenzen enthalten. Danach musste bei Wareneingang die empfangene Menge mit der ursprünglichen Einkaufsbestellung übereinstimmen, und sobald die Lieferung als konform eingestuft wurde, musste ein Zahlungsauftrag anhand einer Vorlage mit dem korrekten Betrag, dem Datum entsprechend den Zahlungsbedingungen des Lieferanten und der richtigen Angabe der Bankkontonummer des Lieferanten erstellt werden. All dies ist im ERP enthalten, und Stimmigkeitsprüfungen können leicht automatisiert durchgeführt werden.

Der ERP-Markt erlebte in den späten 90er-Jahren ein rasantes Wachstum, das in erster Linie durch den stetigen Fortschritt in der Computerhardware (Prozessor, Speicher, Speicherplatz) beflügelt wurde, die Unternehmen jeder Größe zugänglich wurde.

In den 90er-Jahren wurden ERPs zum Softwarekern der meisten großen Unternehmen, wenn das Geschäft hauptsächlich auf dem Warenfluss basierte. Im Gegensatz dazu setzten Unternehmen, die vorwiegend auf Dienstleistungen ausgerichtet waren, in der Regel ein CRM (Customer Relationship Management) als ihren Kern ein. ERPs und CRMs teilen viele Attribute, einschließlich ihres gemeinsamen Designs auf Basis relationaler Datenbanken. ERPs verfolgen typischerweise eine transaktionszentrierte Perspektive in den meisten ihrer Funktionen, während CRMs eine kundenorientierte Perspektive einnehmen.

Das Design von ERPs

ERPs sind vielfältig, da der Markt viele Anbieter umfasst, die über mehrere Jahrzehnte hinweg immer wieder neue Versionen ihrer ERP-Produkte auf den Markt gebracht haben und dennoch im Kern sehr ähnlichen Designprinzipien folgen. ERPs entstanden als „vorkonfigurierte“ Software-Schichten, die auf relationale Datenbanken aufgesetzt wurden. Somit umfasst der ERP-Design-Prozess die Katalogisierung von:

• Entitäten, d.h. alle Konzepte oder Objekte, die das ERP abbilden muss, wie Produkte, Zahlungen, Bestände, Lieferanten … Jede Entität kann eine oder mehrere Tabellen in der zugrunde liegenden relationalen Datenbank umfassen. Die meisten ERPs definieren Hunderte von Entitäten, und bei den komplexesten ERPs sogar bis zu Tausenden.
• Benutzeroberflächen, die es Endbenutzern ermöglichen, die Daten der Entitäten anzusehen und zu bearbeiten. Diese Oberflächen basieren auf dem CRUD-Design (Create / Read / Update / Delete), das die grundlegendsten Operationen darstellt, die Endbenutzer beim Umgang mit Entitäten erwarten.
• Geschäftslogik, die automatisierte Abläufe bereitstellt und dadurch viele Verwaltungsaufgaben überflüssig macht, da diese basierend auf klar definierten Regeln automatisiert werden können, wie zum Beispiel die Umwandlung von Kundenaufträgen in Kundenrechnungen.

Da Unternehmen unglaublich vielfältig und komplex sind, besteht ein unaufhörlicher Bedarf an neuen oder verfeinerten Entitäten, Benutzeroberflächen und Geschäftslogiken, die erforderlich sind, um sich wandelnde Geschäftspraktiken abzudecken. Dies stellt einen gewaltigen, andauernden Aufwand für ERP-Anbieter dar. Hinzu kommen die vielen Unklarheiten, die auftreten, wenn man versucht, sehr unterschiedliche Branchen zu bedienen. Derselbe Begriff, wie „Zahlung“, spiegelt in verschiedenen Branchen sehr unterschiedliche Realitäten und Prozesse wider. In der Software gehen die Komplexität oft mit nichtlinearen Kosten einher, d.h. die Unterstützung von doppelt so vielen Funktionen in einem Produkt kostet weit mehr als das Doppelte der ursprünglichen Kosten.

Infolgedessen haben ERP-Anbieter eine Reihe von Strategien übernommen, um ihre Softwareinvestitionen wettbewerbsfähiger zu gestalten.

Technologie

Um mit der Komplexität zurechtzukommen, besteht die erste von ERP-Anbietern verfolgte Strategie darin, Technologien zu entwickeln, die explizit darauf abzielen, die mit der Komplexität verbundenen Kosten zu senken.

Insbesondere haben viele ERP-Anbieter DSL (Domain Specific Programming)-Sprachen entwickelt, die die zugrunde liegende Abfragesprache – heutzutage typischerweise eine Variante von SQL – der relationalen Datenbank ergänzen sollen. Durch ein gut entwickeltes DSL kann das ERP erweitert werden (d.h. neue Entitäten, Schnittstellen oder Logik), um die Besonderheiten eines bestimmten Unternehmens mit weniger Ressourcen abzudecken, als wenn derselbe Aufwand mit einer universellen Programmiersprache betrieben würde.

Seit den 2000er-Jahren haben Open-Source-ERP-Anbieter – die auf den in den späten 90er-Jahren verfügbaren Open-Source-relationalen Datenbanken aufbauten – in der Regel eine alternative Plug-in-Strategie (anstelle von DSLs) übernommen, bei der das ERP so konzipiert ist, dass es durch die Einführung von kundenspezifischem Code erweitert werden kann, der für jedes Kundenunternehmen maßgeschneidert und in derselben universellen Programmiersprache wie das ERP selbst geschrieben ist. Diese Strategie ist für den ERP-Anbieter leichter umsetzbar (kein DSL muss entwickelt werden) und entspricht der Open-Source-Natur des ERPs.

Angebot

Da die Kosten für die Implementierung und Unterstützung von Funktionen mit der Anzahl der Funktionen wachsen, setzen die meisten ERP-Anbieter auf eine modullbasierte Preisstrategie: Funktionen werden in „Module“ gebündelt, die sich auf unterschiedliche Funktionsbereiche innerhalb des Unternehmens konzentrieren: Bestandsverwaltung, Finanzen, Lohnabrechnung, etc. Das ERP wird auf Modulbasis verkauft, sodass die Kundenunternehmen die dringendsten Module auswählen und die anderen für spätere Investitionen aufschieben können.

Die modullbasierte Preisstrategie bietet dem ERP-Anbieter zudem eine natürliche Upselling-Strategie, bei der die bestehende Kundenbasis zum Hauptziel für zukünftige Verkäufe wird. Geschäftsbereiche, die ursprünglich nicht durch das Standardsortiment des ERPs abgedeckt waren, erhalten neue, dedizierte Module, die wiederum an Kundenunternehmen verkauft werden können.

Diese modullbasierte Preisstrategie ist ein effektiver Mechanismus, um mit der Komplexität umzugehen, da sie dem ERP-Anbieter direktes Feedback über die Funktionsbereiche gibt, in denen die willingness to pay am größten ist. Dadurch wird dem Anbieter geholfen, seine Softwareentwicklungsanstrengungen korrekt zu priorisieren.

Ökosystem

Jedes zusätzliche Feature, das zum ERP hinzugefügt wird, bringt in der Regel abnehmende Erträge für den ERP-Anbieter, der seine Softwareentwicklungsanstrengungen korrekt priorisiert hat¹. Tatsächlich, wenn dieses Feature nicht schon früher hinzugefügt worden wäre, liegt das vermutlich daran, dass es zunächst nicht viele Unternehmen betreffen würde. Darüber hinaus unterliegen auch Organisationen – einschließlich ERP-Anbietern – tendenziell Skalennachteilen: Das Hinzufügen weiterer Softwareingenieure zu einem Softwareprodukt führt bekanntermaßen nicht zu linearen Steigerungen der Verbesserungsrate.

Deshalb verfolgen die meisten ERP-Anbieter eine Ökosystemstrategie, um die letzten Entwicklungsschritte, die notwendig sind, um das ERP in einem Unternehmen betriebsbereit zu machen, an Drittunternehmen – typischerweise Integratoren – zu delegieren. Diese Integratoren berechnen den Kundenunternehmen Gebühren für die Implementierung und den Rollout aller Funktionen, die vom „rohen“ ERP nicht angeboten werden. Historisch gesehen, bis in die 2000er-Jahre, als Unternehmen ERPs zum ersten Mal einführten, konzentrierte sich die Arbeit der Integratoren in der Regel auf die Einführung zusätzlicher Funktionen für das ERP. Heutzutage hingegen sind die meisten ERP-Projekte Upgrades, da bereits ein Altsystem vorhanden ist. Somit besteht der primäre Mehrwert des Integrators darin, einen reibungslosen Übergang vom alten zum neuen ERP zu gewährleisten. In der Praxis umfasst diese Arbeit die Migration von Daten und Prozessen zwischen den Systemen.

Anders als ERP-Anbieter, deren Geschäftsstrategie in erster Linie auf das ERP als schützenswertes IP (intellectual property) ausgerichtet ist, setzen Integratoren in der Regel auf Tagessätze. Sie berechnen ihre Arbeit basierend auf der Anzahl der gearbeiteten Tage, und das geistige Eigentum der geleisteten Arbeit geht in der Regel vertraglich an das Kundenunternehmen über.

Die Entwicklung eines vielfältigen Integratoren-Ökosystems, sowohl geografisch als auch branchenbezogen, ist ein effektiver Weg, um die inhärente Komplexität der ERP-Entwicklung abzumildern. Fast alle großen ERP-Anbieter haben umfangreiche Netzwerke von Integratoren aufgebaut.

Die Grenzen von ERPs

ERPs erben die meisten Einschränkungen ihrer zugrunde liegenden relationalen Datenbanksysteme². Darüber hinaus ergeben sich weitere Einschränkungen aus den eben beschriebenen Strategien zur Komplexitätsminderung. Diese Einschränkungen sind besonders interessant, weil sie Designbeschränkungen darstellen und daher bei neueren ERP-Versionen wahrscheinlich nicht behoben werden – oder genauer gesagt, das Beheben dieser Einschränkungen würde vermutlich dazu führen, dass ERPs so entstellt werden, dass es kaum noch sinnvoll wäre, diese Softwareprodukte weiterhin als ERPs zu bezeichnen.

Ungünstig für umfangreiche Lese- oder Schreibvorgänge

Die von ERPs verwendeten relationalen Datenbanken gewährleisten die ACID-Eigenschaften (Atomicity, Consistency, Isolation, Durability) mit einem Design, das weitgehend auf Arbeitslasten ausgelegt ist, die überwiegend aus kleinen Lese- und Schreiboperationen bestehen, welche mit niedrigen Latenzzeiten – typischerweise einem Bruchteil einer Sekunde – durchgeführt werden sollen, wobei Lese- und Schreibvorgänge in etwa gleich verteilt sind. Eine detaillierte Analyse relationaler Datenbanken sprengt den Rahmen dieses Artikels, jedoch erklärt diese Beobachtung hinsichtlich der für ERPs vorgesehenen Arbeitslast von sich aus viele nur schwer verständliche Einschränkungen.

Aufgrund ihres auf relationalen Datenbanken basierenden Designs sind ERPs weitgehend ungeeignet für Analysen, Statistiken und Berichterstattung, sobald die Datenmenge nicht trivial ist. Der Zugriff auf eine nicht triviale Datenmenge in einem ERP – während die Geschäftsprozesse andauern – ist stets problematisch, denn wenn das System aufgrund zu vieler Lese- oder Schreibvorgänge ausgebremst wird, verlangsamt es sich. In der Praxis bedeutet dies, dass alltägliche Operationen, wie das Ablesen von Barcodes, ebenfalls langsamer werden. Im schlimmsten Fall kommt das ganze Unternehmen zum Stillstand. Daher muss jede Operation im ERP, ob Lese- oder Schreibzugriff, klein bleiben, idealerweise „trivial“. Die Datenmenge, die als nicht trivial betrachtet werden kann, hat in den letzten vier Jahrzehnten dramatisch zugenommen – zusammen mit besserer und billigerer Computerhardware. Unternehmen haben diesen Fortschritt jedoch genutzt, um die in ihre ERPs eingespeiste Datenmenge erheblich zu erweitern. Infolgedessen sind heutige ERP-Systeme typischerweise nicht merklich schneller als noch vor zwei Jahrzehnten.

Zum Beispiel sind ERPs gut geeignet, den Lagerbestand einer SKU anzuzeigen oder dessen Wert zu aktualisieren, wenn eine Einheit entnommen oder geladen wird, jedoch sind ERPs in der Regel nicht dazu geeignet, den konsolidierten täglichen Verlauf der Lagerbestandsveränderungen einer SKU über die letzten drei Jahre darzustellen. Das gesamte Segment Business Intelligence (BI) von Softwareprodukten entstand in den 90er-Jahren als branchenweite Antwort auf die analytischen Einschränkungen von ERPs (und CRMs gleichermaßen). Im Gegensatz zu ERPs werden BI-Tools um In-Memory-Hyperwürfel entwickelt, die üblicherweise als OLAP (Online Analytical Processing) bezeichnet werden. Durch den Verzicht auf die ACID-Eigenschaften erzielen OLAP-Systeme hardwareseitig dramatisch höhere Effizienz bei der Bereitstellung aggregierter Statistiken, wie z. B. Verkaufszahlen pro Tag, pro Filiale, pro Kategorie, etc.

Es ist bemerkenswert, dass die meisten ERP-Anbieter diese Designbeschränkung in ihren eigenen Produkten nicht vollständig zu erkennen schienen, selbst bei jenen, die nach den 90er-Jahren aufkamen, als das BI-Segment den lebenden Beweis für diesen Zustand lieferte. So wagten die meisten ERP-Anbieter den Schritt zu Funktionen der Bedarfsprognose, die per Design völlig im Widerspruch zu ihrer zugrunde liegenden relationalen Datenbank stehen – noch mehr als reine Berichtsfunktionen. Prognosen erfordern den Zugriff auf die gesamte Historie der Transaktionsdaten eines Unternehmens: Verkäufe, Retouren, Lagerbestände, Rabatte, etc. Während die Berechnung typischerweise nachts in Chargen erfolgt – um das zuvor erwähnte Problem der Ressourcenknappheit abzumildern –, verursachen relationale Datenbanken erhebliche, unbeabsichtigte Overheads, wenn versucht wird, diese Art von Berechnung durchzuführen. Infolgedessen verfügen die meisten ERPs heutzutage über „Legacy“-Prognosefunktionen³, die vor Jahren und manchmal sogar Jahrzehnten in Vergessenheit geraten sind.

Ungünstig gegenüber neuen oder markanten Paradigmen

Die Strategie der Entitätskatalogisierung, die von ERP-Anbietern verwendet wird, skaliert in Bezug auf die Komplexitätsverwaltung nicht linear. Bessere Werkzeuge, wie oben besprochen, bringen nur eine lineare Entlastung – bezogen auf die Anzahl der Entitäten – während die Komplexitätskosten überlinear zunehmen. Infolgedessen erweisen sich neue oder besondere Paradigmen in der Regel als teuer, sowohl in den Kosten als auch in den Verzögerungen bei der Integration, wodurch häufig der Punkt erreicht wird, an dem es vorteilhafter ist, das ERP ganz zu umgehen. Diese Situationen sind vielfältig; wir werden im Folgenden einige von ihnen auflisten, aber sie reduzieren sich alle ähnlich auf Paradigmen, die schwer zu integrieren sind, weil sie spät im ERP-Entwicklungsprozess aufkamen⁴.

Das Erreichen von null betrieblicher Ausfallzeit ist schwierig, weil, wie oben erwähnt, jede umfangreiche Lese- oder Schreiboperation das ERP dem Risiko einer Systemverlangsamung aussetzt. Daher werden all diese Operationen typischerweise als nächtliche Batch-Jobs ausgeführt, wenn nur wenige oder gar keine Operationen im Gange sind. Dieses Design steht jedoch im Widerspruch zu den E-Commerce-Anforderungen, die relativ spät in der Geschichte der ERPs entstanden sind. Infolgedessen haben die meisten ERP-Anbieter ihr E-Commerce-Modul umfangreich getrennt, häufig unter Nutzung eines separaten Datenbanksystems, wodurch die implizite Designregel gebrochen wird, dass alle ERP-Module in derselben Datenbank(en) leben. Folglich erweisen sich ERP-unterstützte E-Commerce-Module als genauso schwierig und teuer in der Einführung wie Drittanbieter-Apps.

Der Umgang mit Wiederaufbereitungs-Branchen, in denen Waren komplexen, zyklischen Abläufen folgen (z. B. Reparaturen), während herkömmliche ERPs stark auf Vorwärtsflüsse – von Produzenten zu Konsumenten – ausgerichtet sind, wie sie üblicherweise in FMCG und Distribution zu finden sind, gestaltet sich schwierig. Obwohl die meisten relevanten Entitäten, die für Wiederaufbereitungszwecke notwendig sind (z. B. Produkte, Bestände, Aufträge), bereits in ERPs existieren, stehen ihre Designs in der Regel völlig im Widerspruch zu den Anforderungen der Wiederaufbereitung. Es ist häufig einfacher, diese Entitäten komplett neu zu implementieren, anstatt zu versuchen, die eines herkömmlichen ERPs in diesen Branchen wiederzuverwenden.

Die Bereitstellung von garantiert niedrigen Latenzen, sagen wir unterhalb der menschlichen Wahrnehmung (d. h. unter 50 ms), ist schwierig, da weder das ERP noch seine relationale Datenbank mit solchen Anforderungen konzipiert wurden. Dennoch erfordern die Steuerung hochautomatisierter Systeme wie robotergestützter Lagerhäuser diese Art von Latenzen, um zu verhindern, dass die softwaregesteuerte Orchestrierung zum Flaschenhals des Systems wird. In der Praxis verfügen daher die meisten Bereiche, die mit „Echtzeit“(4)-Verarbeitung verbunden sind, über dedizierte Systeme außerhalb des ERPs.

Interessanterweise gibt es spezialisierte ERPs – sie bezeichnen sich jedoch nicht immer selbst als ERPs – die alternative Entwicklungswege eingeschlagen haben, um gerade diesen Situationen präzise zu begegnen. Diese ERPs richten sich typischerweise an Nischenbranchen, die von herkömmlichen ERPs nicht angemessen bedient werden. Allerdings stehen diese alternativen Entwicklungswege in der Regel im Widerspruch zu den Anforderungen des Mainstreams.

Risiken bei ERP-Übergängen

Auch wenn es paradox erscheinen mag, ist es in der Regel weitaus schwieriger, ein ERP zu aktualisieren, als es zum ersten Mal zu implementieren. Updates sind berüchtigt dafür, mehrjährige Prozesse zu sein. Selbst einfache Versionsupgrades des ERPs – bei Beibehaltung desselben Anbieters – erweisen sich gewöhnlich als schwierige, mehrmonatige Unternehmungen. Anekdotisch sorgt diese Schwierigkeit regelmäßig für Schlagzeilen, wenn große Unternehmen Pressemitteilungen veröffentlichen, in denen sie angeben, dass ihre ERP-Upgrade-Bemühungen das Budget um Hunderte Millionen Dollar oder Euro überschritten haben. In solchen Situationen wird der ERP-Anbieter, der Integrator und/oder das Unternehmen selbst verantwortlich gemacht. Dennoch scheint es, dass die meisten nicht anerkennen, dass solche Probleme im Wesen der ERPs selbst liegen, wie sie durch die oben aufgeführten Marktkräfte gestaltet wurden.

Komplexitätskosten steigen nicht linear, sondern überlinear. Wenn ein Unternehmen ein ERP zum ersten Mal einführt, hat es den Luxus, jedes Modul schrittweise zu übernehmen, also etwa ein Modul nach dem anderen. Somit ist die Anzahl der bei jeder Iteration beteiligten Entitäten / Schnittstellen / Logiken relativ gering, und maßgeschneiderte Erweiterungen können schrittweise implementiert werden, um das ERP den Bedürfnissen des Unternehmens anzupassen.

Wenn das Unternehmen jedoch zu einem anderen ERP wechseln muss, steht es vor dem Problem, alle Module gleichzeitig zu migrieren. Tatsächlich sind ERPs – durch Design und wirtschaftliche Zwänge⁵ – Softwaremonolithen, die auf einer kleinen Anzahl von Datenbanken aufgebaut sind. Daher kann, wenn das neue ERP eingeführt werden muss, der schrittweise Übernahmepfad, der beim ursprünglichen ERP genutzt wurde, nicht repliziert werden. Das Unternehmen muss folglich in einem Alles-oder-Nichts-Modus migrieren. Infolgedessen sind die anfänglichen Implementierungskosten in der Regel sehr hoch, während der Zustand nach der Einführung oft halbfertige Situationen aufweist, deren Behebung mehrere Jahre in Anspruch nehmen kann.

Technisch gesehen sind diese Upgrades immer schwierig zu implementieren, da der Import der Entitäten / Schnittstellen / Logiken zwischen dem alten und dem neuen System keine Eins-zu-eins-Übertragung darstellt. Die Semantik der Entitäten entwickelt sich im Laufe der Zeit weiter. So könnte der ERP-Anbieter beispielsweise mit einer Tabelle namens „Orders“ begonnen haben, die für Kundenaufträge bestimmt war. Später muss der Anbieter jedoch auf die neueren, ursprünglich nicht geplanten Anforderungen zur Verwaltung von Kundenretouren eingehen. Die nächste Version des ERPs verwendet dann die Tabelle „Orders“ für die Kundenretouren, wobei diese Zeilen nun negative Bestellmengen aufweisen. Diese scheinbar unbedeutende Änderung erschwert letztlich die Migration von der alten zur neuen ERP-Version erheblich.

Das Upgrade zu einem neuen ERP oder zu einer späteren Version desselben ERPs ist jedoch nicht die einzige Option für Unternehmen. Es stehen tatsächlich mehrere Alternativen zur Verfügung, um den Übergang risikofrei zu gestalten. Natürlich hat das gesamte Ökosystem der ERP-Anbieter und Integratoren ein ausgeprägtes finanzielles Interesse daran, das Gegenteil zu fördern, um das Überleben ihres wirtschaftlichen Modells zu sichern.

Jenseits des Monolithen

ERPs entstanden als ein Softwaremonolith, also als Softwareprodukte, bei denen alle inneren Komponenten eng miteinander gekoppelt sind – eine Notwendigkeit, um einen Plug-and-Play-Rollout aller Module zu gewährleisten. Zudem war es bis in die 2010er Jahre wesentlich schwieriger und kostspieliger, verteilte Systeme zu entwickeln – also Software, die über eine Flotte von Maschinen betrieben wird, anstatt über einige zentrale Maschinen zu laufen⁶. Somit hatten ERP-Anbieter (die meisten von ihnen sind Jahrzehnte alt) weitgehend keine andere Alternative, als ihre Produkte als Monolith zu entwickeln.

Nichtsdestotrotz wurden mit dem Einzug des Cloud Computing Werkzeuge und Bibliotheken – oft Open Source – populärer und zugänglicher. Infolgedessen sind die Kosten und Overheads, die mit der Entwicklung verteilter Anwendungen verbunden sind, in den letzten zehn Jahren stetig gesunken. Die Softwarebranche hat begonnen, intensiv zu überdenken, wie der Mehrwert, der historisch nur von ERPs (oder ERP-ähnlicher Software) bereitgestellt wurde, geliefert werden kann.

Der moderne Ansatz in der Unternehmenssoftware besteht darin, den Monolithen in einer Reihe kleinerer Apps aufzubrechen, die idealerweise jeweils eine Sache gut erledigen⁷. Das Zusammenfügen der Apps erfolgt über APIs (Application Programming Interfaces), die genau dazu gedacht sind, maßgeschneiderte Integrationen in unterschiedliche Applikationslandschaften zu ermöglichen. Die meisten APIs sind darauf ausgelegt, populäres Open-Source-API-Tooling zu nutzen, wodurch die Entwicklungskosten für diese individuellen Integrationen erheblich gesenkt werden.

Diese Apps haben manchmal höhere anfängliche Integrationskosten als die eingebauten ERP-Module. Langfristig bieten sie jedoch erhebliche Vorteile, da sie zukünftige Entwicklungen in der Applikationslandschaft weitgehend risikofrei machen. Das Unternehmen erhält die Möglichkeit, eine App nach der anderen zu aktualisieren oder auszutauschen, was nicht nur wesentlich einfacher umzusetzen ist, sondern auch kostengünstiger und mit geringeren Risiken verbunden ist. Schließlich setzen SaaS (Software as a Service)-Apps typischerweise auf eine kontinuierliche Bereitstellung kleiner inkrementeller Änderungen. Zwar erzeugt dieses Muster eine fortlaufende – wenn auch begrenzte – Arbeitsbelastung für IT-Teams, jedoch ist der SaaS-Änderungsprozess organischer, kostengünstiger und weniger risikoreich im Vergleich zu jährlichen oder zweijährigen Upgrades.

Jenseits relationaler Datenbanken

Relationale Datenbanken sind seit den 80er Jahren das De-facto-Rückgrat von ERPs. Seit den 2010er Jahren sind jedoch überzeugende Alternativen entstanden. Die bemerkenswerteste ist wahrscheinlich Event Sourcing (ES) in Kombination mit Command Query Responsibility Segregation (CQRS). Dieser Ansatz bietet überlegene Skalierbarkeit und niedrigere Latenzzeiten und ermöglicht gleichzeitig ausdrucksstärkere Designs, d. h. er vermag in verschiedenen Situationen Geschäftsabsichten präziser abzubilden.

Der Kern des Event Sourcing besteht darin, jede Veränderung im System als ein unveränderliches Ereignis zu behandeln. Der Unveränderlichkeitsansatz ist von Buchhaltungspraktiken inspiriert: Wenn sich eine Zeile in einem Journal als fehlerhaft erweist, löscht der Buchhalter die Zeile nicht, um das Problem zu beheben, sondern fügt stattdessen eine korrigierende Zeile hinzu. Die komplette Historie der Ereignisse zu speichern – vorausgesetzt, die Datenspeicherung ist günstig genug, um diese Strategie praktikabel zu machen – bringt zahlreiche Vorteile: bessere Rückverfolgbarkeit, Auditierbarkeit, Sicherheit… Zudem erleichtert der Unveränderlichkeitsansatz die Skalierung ereignisgesteuerter Systeme. Daten können umfangreich kopiert und repliziert werden, ohne dass man sich mit deren Änderungen auseinandersetzen muss.

Das CQRS-Design erkennt an, dass in den meisten Systemen die Mengen an Lese- und Schreibvorgängen stark unausgeglichen sind. In vielen Fällen übersteigt das Volumen der (Daten-)Lesen das der Schreibvorgänge um mehrere Größenordnungen. Relationale Datenbanken hingegen sind auf (etwas) symmetrische Volumen von Lese- und Schreibvorgängen ausgelegt. CQRS trennt ausdrücklich die Verantwortlichkeiten für Lese- und Schreibvorgänge, typischerweise in zwei separate Subsysteme. Dieses Design bringt vor allem Vorteile in Bezug auf Latenz, Skalierbarkeit und Hardwareeffizienz.

Doch obwohl sowohl ES als auch CQRS bereits in großen, verbraucherorientierten Technologieunternehmen und im quantitativen Handel (Finanzen) populär sind, haben sie erst vor Kurzem begonnen, in der Mainstream-Unternehmenssoftware an Bedeutung zu gewinnen. Infolgedessen ist das ES+CQRS-Tooling im Vergleich zu seinen Gegenstücken im Bereich relationaler Datenbanken noch in den Kinderschuhen. Dennoch bietet dieser Ansatz Möglichkeiten, nicht nur die Hardwarekosten drastisch zu senken, sondern auch Latenzen zu reduzieren, die bei den meisten ERP-Implementierungen häufig ein akutes Problem darstellen.

Lokads Sichtweise

Da ERPs nicht einmal für analytische Zwecke geeignet sind – daher der Bedarf an BI (Business Intelligence)-Tools – sollte es keine Überraschung sein, dass ihre Erfolgsbilanz mager ist, sobald es um prädiktive Analysen geht. Anekdotisch lässt sich belegen, dass keine der Revolutionen im Bereich Machine Learning / data science in ERPs stattfand und dass Teams bei der Bewältigung dieser Anforderungsklassen stets auf Tabellenkalkulationen oder Ad-hoc-Skripte zurückgreifen.

Lokad selbst entstand als eine spezialisierte App, die dazu gedacht ist, ERPs als analytische Schicht zur prädiktiven Optimierung von supply chain zu ergänzen – jedoch nicht zu ersetzen. Die meisten unserer Kernfunktionen, wie die Fähigkeiten zur probabilistischen Prognose, die zur Unterstützung von alltäglichen Entscheidungen – beispielsweise bei Beständen, Einkauf, Produktion, Sortiment und Preisgestaltung – dienen, sind schlichtweg unpraktisch, um sie in ERP-Systemen zu implementieren.

Anmerkungen