Enterprise Resource Planning (ERP)

ERP (Enterprise Resource Planning) bezieht sich auf eine Klasse von Unternehmenssoftware, die die Routinebetriebsabläufe des Unternehmens unterstützt und seine Ressourcen verfolgt, insbesondere Bargeld, Rohstoffe, Arbeiten im Gange, Endprodukte, Kundenaufträge, Bestellungen und Gehaltsabrechnungen. ERPs umfassen in der Regel viele Module für Kerngeschäftsfunktionen wie Buchhaltung, Beschaffung, Vertrieb, Finanzen, Vertrieb usw. und bieten eine enge Integration innerhalb dieser Module, um den Fluss der (transaktionalen) Informationen zwischen den Funktionen zu erleichtern. ERPs basieren auf relationalen Datenbanken und weisen in der Regel ein sehr umfangreiches Design auf: eine große Anzahl von Entitäten (z. B. Produkte, Kunden, Rechnungen usw.), zahlreiche Bildschirme und einen hohen Grad an Konfigurierbarkeit.

Ursprung und Motivation

In den 70er Jahren wurde allmählich deutlich, dass elektronische Aufzeichnungen im Vergleich zur traditionellen Papierdokumentation mehrere Vorteile boten. Elektronische Aufzeichnungen wurden billiger, schneller und zuverlässiger als Papierdokumente. Zwei Erfindungen, die den ERPs vorausgingen, waren entscheidend für die Nutzung elektronischer Aufzeichnungen: Barcode-Lesegeräte (1950er Jahre) und relationale Datenbanken (1970er Jahre). Barcode-Lesegeräte boten eine überlegene Möglichkeit, den Warenfluss zu verwalten, die Produktivität zu steigern und gleichzeitig Fehler bei der Datenerfassung zu reduzieren. Obwohl Barcode-Lesegeräte die Datenerfassung in vielen Situationen erheblich verbessert hatten, blieb die Speicherung, Organisation und Verarbeitung elektronischer Aufzeichnungen zwei Jahrzehnte lang ein offenes Problem. Relationale Datenbanken waren die Antwort der Softwareindustrie auf dieses Problem Ende der 70er Jahre, und auch fünf Jahrzehnte später sind relationale Datenbanken die dominierende Praxis im Bereich des Datenmanagements von Unternehmen.

Allerdings erwiesen sich nackte 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 usw. Daher entstanden in den 80er Jahren eine Reihe von Softwareunternehmen, die “vorkonfigurierte” relationale Systeme verkauften. Diese Produkte wurden später gemeinsam als ERPs bezeichnet, ein Begriff, der in den 90er Jahren geprägt wurde. Leider ist die Abkürzung ERP irreführend; es hätte Enterprise Resource Management statt Planning heißen sollen. Tatsächlich ist die Planung für ERPs bestenfalls von sekundärer Bedeutung. Wie im Folgenden detailliert beschrieben, stehen prädiktive Analysen im Widerspruch zum Kernkonzept von ERPs.

Historisch gesehen gewannen ERPs an Bedeutung, weil sie eine Reihe von Operationen optimierten, die zuvor umfangreiche Büroarbeiten erforderten. Zum Beispiel erforderte das Ausstellen einer Bestellung an einen Lieferanten das Ausfüllen eines Formulars mit dem Namen und der Adresse des Lieferanten. Die Bestellpositionen mussten nur gültige Produktreferenzen enthalten. Dann mussten bei Erhalt der Ware die empfangenen Mengen mit denen in der ursprünglichen Bestellung übereinstimmen, und sobald die Lieferung als konform erachtet wurde, musste eine Zahlungsanweisung gegen eine Vorlage mit dem richtigen Betrag, dem Datum entsprechend den Zahlungsbedingungen des Lieferanten und der korrekten Identifizierung der Bankkontonummer des Lieferanten generiert werden. All dies kann im ERP gefunden werden und die Kohärenzprüfungen können leicht automatisiert durchgeführt werden.

Der ERP-Markt erlebte Ende der 90er Jahre ein rasantes Wachstum, das hauptsächlich durch die stetigen Fortschritte in der Computertechnik (Prozessor, Speicher, Speicherplatz) angetrieben wurde, die für Unternehmen jeder Größe zugänglich geworden waren.

In den 90er Jahren wurden ERPs zum Softwarekern vieler großer Unternehmen, als das Geschäft hauptsächlich um den Warenfluss herum organisiert war. Im Gegensatz dazu haben Unternehmen, die sich hauptsächlich auf Dienstleistungen konzentrieren, in der Regel eine CRM (Customer Relationship Management)-Software als Kern verwendet. ERPs und CRMs haben viele gemeinsame Merkmale, einschließlich ihres gemeinsamen Designs auf der Grundlage relationaler Datenbanken. ERPs nehmen in der Regel eine transaktionszentrierte Perspektive auf die meisten ihrer Funktionen ein, während CRMs eine kundenorientierte Perspektive einnehmen.

Das Design von ERPs

ERPs sind vielfältig, da der Markt viele Anbieter umfasst, die im Laufe mehrerer Jahrzehnte viele Versionen ihrer ERP-Produkte entwickelt haben und dennoch im Kern dennoch hochgradig ähnlichen Designlinien folgen. ERPs entstanden als “vorkonfigurierte” Softwareebenen, die auf relationalen Datenbanken implementiert wurden. Der ERP-Designprozess umfasst daher die Katalogisierung von:

• Entitäten, das heißt alle Konzepte oder Objekte, die das ERP darstellen muss, wie Produkte, Zahlungen, Lagerbestä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 die komplexesten ERPs können Tausende von Entitäten haben.
• Benutzeroberflächen, mit denen Endbenutzer die Daten der Entitäten anzeigen und bearbeiten können. Diese Oberflächen werden von dem CRUD-Design (Create / Read / Update / Delete) dominiert, das die grundlegenden Operationen darstellt, die Endbenutzer bei der Arbeit mit Entitäten erwarten.
• Geschäftslogik, die automatisierte Verhaltensweisen bereitstellt, die viele Büroarbeiten überflüssig machen, die aufgrund klar definierter Regeln automatisiert werden können, wie z.B. die Umwandlung von Kundenaufträgen in Kundenrechnungen.

Da Unternehmen unglaublich vielfältig und komplex sind, besteht ein ständiger Bedarf an neuen oder verfeinerten Entitäten, Benutzeroberflächen und Geschäftslogiken, die erforderlich sind, um sich entwickelnden Geschäftspraktiken gerecht zu werden. Dies erfordert einen massiven fortlaufenden Aufwand von ERP-Anbietern. Diese Herausforderung wird dann durch alle Unklarheiten verstärkt, die entstehen, wenn man versucht, sehr unterschiedliche Branchen zu bedienen. Der gleiche Begriff wie “Zahlung” spiegelt sehr unterschiedliche Realitäten und Prozesse von einer Branche zur anderen wider. In der Softwareentwicklung tendieren komplexe Systeme dazu, nichtlineare Kosten zu verursachen, d.h. die Unterstützung von 2x mehr Funktionen in einem Produkt kostet viel mehr als das Doppelte der ursprünglichen Kosten.

Als Ergebnis haben ERP-Anbieter eine Reihe von Strategien übernommen, um ihre Softwareinvestitionen wettbewerbsfähiger zu machen.

Technologie

Um mit der Komplexität umzugehen, besteht die erste Strategie, die von ERP-Anbietern genutzt wird, 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 dazu dienen sollen, die zugrunde liegende Abfragesprache - heutzutage in der Regel eine Variante von SQL - der zugrunde liegenden relationalen Datenbank zu ergänzen. Durch eine gut konzipierte DSL kann die Erweiterung des ERPs (d.h. neuere Entitäten, Schnittstellen oder Logik) zur Abdeckung der Besonderheiten eines bestimmten Unternehmens mit weniger Ressourcen durchgeführt werden im Vergleich zu demselben Aufwand mit einer allgemeinen Programmiersprache.

Seit den 2000er Jahren haben Open-Source-ERP-Anbieter - die auf den Open-Source-Relationdatenbanken aufbauten, die Ende der 90er Jahre verfügbar wurden - in der Regel eine alternative Plug-in-Strategie (anstelle von DSLs) übernommen, bei der das ERP durch die Einführung von benutzerdefiniertem Code erweitert wird, der für jedes Kundenunternehmen maßgeschneidert ist und in derselben allgemeinen Programmiersprache wie das ERP selbst geschrieben ist. Diese Strategie ist für den ERP-Anbieter leichter umzusetzen (keine 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 Gesamtzahl der Funktionen steigen, verwenden die meisten ERP-Anbieter eine modulbasierte Preisstrategie: Funktionen werden in “Module” gebündelt, die sich auf verschiedene funktionale Bereiche im Unternehmen konzentrieren: Bestandsverwaltung, Finanzen, Gehaltsabrechnung usw. Das ERP wird auf Modulbasis verkauft, sodass die Kundenunternehmen ihre wichtigsten Module auswählen und die anderen für spätere Investitionen verschieben können.

Die modulbasierte Preisstrategie bietet dem ERP-Anbieter auch 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 von der ursprünglichen Modulsammlung des ERPs abgedeckt wurden, erhalten neue dedizierte Module, die wiederum an Kundenunternehmen verkauft werden können.

Diese modulbasierte Preisstrategie ist ein effektiver Mechanismus, um mit Komplexität umzugehen, da sie dem ERP-Anbieter direktes Feedback zu den funktionalen Bereichen gibt, in denen die Zahlungsbereitschaft am größten ist. Dadurch hilft es dem Anbieter, seine Softwareentwicklungsbemühungen richtig zu priorisieren.

Ökosystem

Jedes zusätzliche Feature, das dem ERP hinzugefügt wird, führt in der Regel zu abnehmenden Erträgen für den ERP-Anbieter, der seine Softwareentwicklungsbemühungen richtig priorisiert hat¹. Wenn dieses Feature nicht zuvor hinzugefügt wurde, liegt dies wahrscheinlich daran, dass es anfangs nicht genügend Unternehmen betroffen hat. Organisationen selbst - einschließlich ERP-Anbieter - neigen ebenfalls zu Diseconomies of Scale: Das Hinzufügen zusätzlicher Softwareingenieure zu einem Softwareprodukt ist bekannt dafür, dass es keine linearen Gewinne bei der Verbesserung des Produktdurchsatzes bringt.

Daher setzen die meisten ERP-Anbieter eine Ökosystemstrategie ein, um diese letzten Entwicklungsanstrengungen zu delegieren, die erforderlich sind, um das ERP für ein bestimmtes Unternehmen betriebsbereit zu machen, an Drittunternehmen, die in der Regel als Integratoren bekannt sind. Diese Integratoren berechnen den Kundenunternehmen die Implementierung und Einführung aller Funktionen, die nicht vom “rohen” ERP angeboten werden. Historisch gesehen drehte sich die Arbeit der Integratoren bis in die 2000er Jahre hauptsächlich um die Einführung zusätzlicher Funktionen für das ERP, wenn Unternehmen es zum ersten Mal einführten. Heutzutage handelt es sich jedoch bei den meisten ERP-Projekten um Upgrades, da bereits ein Legacy-ERP im Einsatz ist. Der Hauptmehrwert des Integrators besteht daher darin, einen reibungslosen Übergang vom alten ERP zum neuen zu gewährleisten. In der Praxis umfasst diese Arbeit die Migration von Daten und Prozessen zwischen Systemen.

Im Gegensatz zu ERP-Anbietern, deren Geschäftsstrategie hauptsächlich auf das ERP selbst ausgerichtet ist und als geistiges Eigentum behandelt wird, verwenden Integratoren in der Regel eine Art von Tagessatz. Sie berechnen ihre Arbeit basierend auf der Anzahl der gearbeiteten Tage, und das geistige Eigentum der erbrachten Arbeit fällt normalerweise vertraglich an das Kundenunternehmen selbst.

Die Entwicklung eines vielfältigen Ökosystems von Integratoren, sowohl geografisch als auch vertikal, ist ein effektiver Weg, um mit der inhärenten Komplexität der ERP-Entwicklung umzugehen. Nahezu 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 zuvor beschriebenen Strategien zur Komplexitätsminderung. Diese Einschränkungen sind besonders interessant, weil es sich um Design-Einschränkungen handelt und daher wahrscheinlich nicht durch neuere ERP-Versionen behoben werden können. Oder anders ausgedrückt: Die Lösung dieser Einschränkungen würde wahrscheinlich dazu führen, dass ERPs so stark verändert werden, dass es nicht mehr sinnvoll wäre, diese Softwareprodukte immer noch als ERPs zu bezeichnen.

Nicht geeignet für grobe Lese- oder Schreibvorgänge

Die relationalen Datenbanken, die von ERPs verwendet werden, liefern die ACID-Eigenschaften (Atomicity, Consistency, Isolation, Durability) mit einem Design, das weitgehend auf eine Workload ausgerichtet ist, die überwiegend aus kleinen Lese- und Schreibvorgängen besteht, die mit geringen Latenzzeiten durchgeführt werden sollten - in der Regel ein Bruchteil einer Sekunde - wobei Lese- und Schreibvorgänge in etwa ausgeglichen sind. Eine detaillierte Analyse relationaler Datenbanken geht über den Rahmen dieses Artikels hinaus, aber diese Beobachtung bezüglich der beabsichtigten Workload für ERPs erklärt für sich genommen viele schlecht verstandene Einschränkungen von ERPs.

Aufgrund ihres Designs auf der Grundlage relationaler Datenbanken sind ERPs für Analysen, Statistiken und Berichte in der Regel ungeeignet, wenn die Datenmenge nicht unerheblich ist. Der Zugriff auf eine nicht unerhebliche Datenmenge in einem beliebigen ERP-System - während die Geschäftsabläufe laufen - ist immer ein Problem, denn wenn das System aufgrund zu vieler Datenlese- oder -schreibvorgänge ausgehungert wird, verlangsamt sich das System. In der Praxis bedeutet dies, dass banale Vorgänge wie das Verarbeiten von Barcodes ebenfalls verlangsamt werden. Im schlimmsten Fall kommt das gesamte Unternehmen zum Stillstand. Daher muss jede Operation im ERP, sei es Lese- oder Schreibvorgänge, klein bleiben, idealerweise “trivial”. Die Menge an Daten, die als nicht trivial betrachtet werden kann, hat sich in den letzten vier Jahrzehnten dramatisch erhöht, zusammen mit besserer, günstigerer Computerhardware. Unternehmen haben jedoch von diesem Fortschritt profitiert, um die Menge der in ihre ERPs eingegossenen Daten erheblich zu erweitern. Als Ergebnis sind heutige ERP-Systeme in der Regel nicht spürbar schneller als vor zwei Jahrzehnten.

Zum Beispiel eignen sich ERPs gut, um den Lagerbestand einer SKU anzuzeigen oder dessen Wert zu aktualisieren, wenn eine Einheit abgeholt oder geladen wird. ERPs eignen sich jedoch in der Regel nicht dazu, die konsolidierte tägliche Zeitleiste der Bestandsveränderungen einer SKU in den letzten drei Jahren anzuzeigen. Das gesamte Segment der Business Intelligence (BI) von Softwareprodukten entstand in den 90er Jahren als branchenweite Antwort auf die analytischen Einschränkungen von ERPs (und auch von CRMs). Im Gegensatz zu ERPs sind BI-Tools um In-Memory-Hypercubes, in der Regel als OLAP (Online Analytical Processing) bezeichnet, konzipiert. Durch den Verzicht auf die ACID-Eigenschaften werden OLAP-Systeme hardwareseitig deutlich effizienter als relationale Datenbanken, um aggregierte Statistiken wie Verkäufe pro Tag, pro Geschäft, pro Kategorie usw. zu liefern.

Es ist interessant festzustellen, dass die meisten ERP-Anbieter anscheinend nicht vollständig über diese Design-Einschränkung in ihren eigenen Produkten im Bilde waren, auch nicht diejenigen, die nach den 90er Jahren aufkamen, als das BI-Segment der lebende Beweis für diesen Zustand war. Zum Beispiel haben die meisten ERP-Anbieter Funktionen zur Nachfrageprognose entwickelt, die sich von ihrem zugrunde liegenden relationalen Datenbankdesign grundsätzlich unterscheiden - noch mehr als einfache Berichtsfunktionen. Die Prognose erfordert Zugriff auf die gesamte Historie der Transaktionsdaten des Unternehmens: Verkäufe, Rücksendungen, Lagerbestände, Rabatte usw. Während die Berechnung in der Regel nachts in Chargen durchgeführt werden soll, um das oben erwähnte Ressourcenmangelproblem zu mildern, verursachen relationale Datenbanken enorme zufällige Overheads, wenn versucht wird, diese Art von Berechnung durchzuführen. Als Ergebnis verfügen die meisten ERPs heutzutage über “veraltete” Prognosefunktionen³, die seit Jahren, manchmal sogar Jahrzehnten, nicht mehr genutzt werden.

Nicht geeignet für neue oder unterschiedliche Paradigmen

Die von ERP-Anbietern verwendete Strategie zur Katalogisierung von Entitäten skaliert nicht linear in Bezug auf das Management der Komplexität. Bessere Tools, wie oben diskutiert, bringen nur eine lineare Erleichterung - in Bezug auf die Anzahl der Entitäten - während die Komplexitätskosten superlinear wachsen. Als Ergebnis erweisen sich neue oder unterschiedliche Paradigmen in der Regel als teuer sowohl in Bezug auf Kosten als auch Verzögerungen bei der Integration, häufig bis zu dem Punkt, an dem es eine bessere Alternative ist, das ERP ganz zu überspringen. Diese Situationen sind vielfältig, wir werden einige davon unten auflisten, aber sie alle kommen letztendlich auf Paradigmen zurück, die aufgrund ihrer späten Entwicklung im ERP-Entwicklungsprozess schwer zu integrieren sind⁴.

Es ist schwierig, null Betriebsausfallzeiten zu erreichen, da, wie oben erwähnt, jede große Lese- oder Schreiboperation das ERP einem Systemverlangsamungsrisiko aussetzt. Daher werden all diese Operationen in der Regel als nächtliche Chargen durchgeführt, wenn nur wenige oder keine Operationen im Gange sind. Diese Gestaltung steht jedoch im Widerspruch zu den Anforderungen des E-Commerce, die relativ spät in der Geschichte der ERPs aufgetaucht sind. Als Ergebnis haben die meisten ERP-Anbieter ihr E-Commerce-Modul umfangreich getrennt, wobei häufig ein separates Datenbanksystem genutzt wird, was gegen die implizite Designregel verstößt, dass alle ERP-Module in der gleichen Datenbank leben. Daher sind ERP-gestützte E-Commerce-Module oft genauso schwierig und teuer einzuführen wie Apps von Drittanbietern.

Der Umgang mit Remanufacturing-Branchen, in denen Waren komplexen zyklischen Flüssen folgen (z. B. Reparaturen), während Mainstream-ERPs stark auf Vorwärtsflüsse ausgerichtet sind - von Produzenten zu Verbrauchern -, wie sie in FMCG und Distribution häufig vorkommen. Während die meisten relevanten Entitäten, die für Remanufacturing-Zwecke erforderlich sind (z. B. Produkte, Bestände, Aufträge), bereits in ERPs vorhanden sind, sind ihre Designs typischerweise völlig im Widerspruch zu den Anforderungen des Remanufacturing. Es ist oft einfacher, diese Entitäten vollständig neu zu implementieren, anstatt zu versuchen, diejenigen eines Mainstream-ERPs in diesen Branchen zu recyceln.

Die Bereitstellung von garantiert niedrigen Latenzzeiten, sagen wir unterhalb der menschlichen Wahrnehmung (d. h. unter 50 ms), ist schwierig, da weder das ERP noch seine relationale Datenbank mit solchen Anforderungen im Hinterkopf entwickelt wurden. Dennoch erfordern hochautomatisierte Systeme wie robotergesteuerte Lager solche Latenzzeiten, um zu verhindern, dass die softwaregesteuerte Orchestrierung zum Engpass des Systems wird. Daher haben die meisten Bereiche, die mit “Echtzeit” (4) Verarbeitung verbunden sind, dedizierte Systeme außerhalb des ERPs.

Interessanterweise gibt es spezialisierte ERPs - sie bezeichnen sich jedoch nicht immer selbst als ERPs -, die alternative Entwicklungspfade eingeschlagen haben, um genau mit diesen Situationen umzugehen. Diese ERPs zielen in der Regel auf Nischenbranchen ab, die von Mainstream-ERPs nicht angemessen bedient werden. Diese alternativen Entwicklungspfade stehen jedoch typischerweise im Widerspruch zu den Anforderungen des Mainstreams.

Risiken bei ERP-Übergängen

Es ist typischerweise weitaus schwieriger, ein ERP zu aktualisieren, als es zum ersten Mal einzusetzen, obwohl dies paradox erscheinen mag. Upgrades sind berüchtigt dafür, mehrjährige Prozesse zu sein. Selbst einfache Versionsupgrades des ERPs - unter Beibehaltung desselben Anbieters - erweisen sich in der Regel als schwierig und dauern mehrere Monate. Anekdotisch gesehen machen solche Schwierigkeiten regelmäßig Schlagzeilen, wenn große Unternehmen Pressemitteilungen veröffentlichen, in denen sie angeben, dass ihre ERP-Upgrade-Bemühungen das Budget um Hunderte von Millionen Dollar oder Euro überschritten haben. In solchen Situationen wird der ERP-Anbieter, der Integrator und/oder das Unternehmen selbst beschuldigt. Doch die meisten scheinen nicht anzuerkennen, dass solche Probleme intrinsisch mit ERPs selbst verbunden sind, wie sie durch die oben genannten Marktkräfte entworfen wurden.

Die Komplexitätskosten steigen nicht linear, sondern überlinear an. Wenn ein Unternehmen zum ersten Mal ein ERP übernimmt, hat es den Luxus, jedes Modul nach und nach anzunehmen, ein Modul nach dem anderen oder so. Daher ist die Anzahl der beteiligten Entitäten / Schnittstellen / Logiken bei jeder Iteration relativ gering, und maßgeschneiderte Erweiterungen können schrittweise bereitgestellt 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 Kräfte⁵, Software-Monolithen, die auf einer kleinen Anzahl von Datenbanken aufbauen. Daher kann der inkrementelle Annahmepfad, der für das ursprüngliche ERP verwendet wurde, nicht repliziert werden, wenn das neue ERP bereitgestellt werden muss. Das Unternehmen muss daher in einer Alles-oder-Nichts-Weise migrieren. Als Ergebnis tendieren die Implementierungskosten im Voraus dazu, sehr hoch zu sein, während der Status nach der Bereitstellung dazu neigt, halb defekte Situationen zu sein, die bis zu mehreren Jahren dauern, um zu beheben.

Technisch gesehen sind diese Upgrades immer schwierig zu implementieren, da der Import von Entitäten / Schnittstellen / Logiken zwischen dem alten und dem neuen System keine eins-zu-eins-Angelegenheit ist. Die Semantik der Entitäten entwickelt sich im Laufe der Zeit. Zum Beispiel könnte der ERP-Anbieter mit einer Tabelle namens “Aufträge” begonnen haben, die für Kundenaufträge vorgesehen war. Später muss der Anbieter jedoch die neuen Anforderungen, die ursprünglich nicht geplant waren, für die Verwaltung von Kundenrücksendungen angehen. Die nächste Version des ERPs verwendet die “Aufträge” -Tabelle für die Kundenrücksendungen, jedoch haben diese Zeilen jetzt negative Auftragsmengen. Diese scheinbar harmlose Änderung erschwert die Migration von der alten ERP-Version zur neuen erheblich.

Es ist jedoch nicht die einzige Option für Unternehmen, auf ein neues ERP oder eine spätere Version desselben ERPs zu aktualisieren. Tatsächlich stehen mehrere Alternativen zur Verfügung, um den Übergang zu entlasten. Natürlich haben das gesamte Ökosystem der ERP-Anbieter und Integratoren ein lebhaftes finanzielles Interesse daran, das Gegenteil zu fördern, um ihr wirtschaftliches Modell zu überleben.

Jenseits des Monolithen

ERPs haben sich als Software-Monolithen herausgebildet, das heißt, Softwareprodukte, bei denen alle internen Komponenten eng miteinander verbunden sind - eine Notwendigkeit, um eine Plug-and-Play-Bereitstellung aller Module zu gewährleisten. Bis in die 2010er Jahre hinein war der Aufbau verteilter Systeme - d. h. Software, die über eine Flotte von Maschinen anstatt über einige zentrale Maschinen arbeitet - erheblich schwieriger und kostspieliger⁶. Daher hatten ERP-Anbieter (von denen die meisten Jahrzehnte alt sind) in hohem Maße keine andere Wahl, als ihre Produkte als Monolithen zu entwickeln.

Dennoch wurden mit dem Aufkommen des Cloud-Computings Werkzeuge und Bibliotheken - häufig Open Source - immer beliebter und zugänglicher. Dadurch sind die Kosten und Aufwände für die Entwicklung verteilter Anwendungen in den letzten zehn Jahren kontinuierlich gesunken. Die Softwarebranche hat begonnen, intensiv zu überdenken, wie der Mehrwert, der historisch gesehen nur von ERPs (oder ERP-ähnlicher Software) geliefert wurde, bereitgestellt werden kann.

Der moderne Ansatz für Unternehmenssoftware besteht darin, den Monolithen durch eine Reihe von kleineren Apps aufzubrechen, die idealerweise eine Sache gut machen⁷. Die Verbindung der Apps erfolgt über APIs (Application Programming Interfaces), die speziell für die erleichterte Integration in verschiedene Anwendungsumgebungen entwickelt wurden. Die meisten APIs sind darauf ausgelegt, beliebte Open Source API-Tools zu nutzen, die die Entwicklungskosten für diese maßgeschneiderten Integrationen erheblich senken.

Diese Apps haben manchmal höhere anfängliche Integrationskosten als integrierte ERP-Module. Sie bieten jedoch erhebliche langfristige Vorteile, da sie weitere Entwicklungen der Anwendungsumgebung erheblich entlasten. Das Unternehmen hat die Möglichkeit, eine App nach der anderen zu aktualisieren oder zu ersetzen, was nicht nur viel einfacher, sondern auch kostengünstiger und risikoärmer ist. Schließlich entscheiden sich SaaS (Software as a Service)-Apps in der Regel für eine kontinuierliche Bereitstellung kleiner inkrementeller Änderungen. Obwohl dieses Muster eine fortlaufende - aber begrenzte - Arbeitsbelastung für IT-Teams erzeugt, ist der SaaS-Änderungsprozess im Vergleich zu jährlichen oder zweijährlichen Upgrades organischer, kostengünstiger und weniger riskant.

Jenseits von relationalen Datenbanken

Seit den 80er Jahren waren relationale Datenbanken das Rückgrat von ERPs. Seit den 2010er Jahren sind jedoch überzeugende Alternativen aufgetaucht. Die bemerkenswerteste davon ist wahrscheinlich Event Sourcing (ES) in Verbindung mit Command Query Responsibility Segregation (CQRS). Dieser Ansatz bietet eine überlegene Skalierbarkeit und Latenz und ermöglicht gleichzeitig expressivere Designs, die in verschiedenen Situationen geschäftliche Absichten enger erfassen können.

Das Wesentliche des Event Sourcing besteht darin, jede Änderung im System als ein unveränderliches Ereignis zu behandeln. Der Aspekt der Unveränderlichkeit ist von der Buchhaltungspraxis inspiriert: Wenn eine Zeile in einem Buchungsjournal falsch ist, löscht der Buchhalter die Zeile nicht, um das Problem zu beheben, sondern fügt eine weitere korrigierende Zeile in das Journal ein. Das Beibehalten der gesamten Ereignishistorie - vorausgesetzt, die Datenspeicherung ist billig genug, um diese Strategie rentabel zu machen - bietet zahlreiche Vorteile: bessere Rückverfolgbarkeit, Nachvollziehbarkeit, Sicherheit… Darüber hinaus erleichtert der Aspekt der Unveränderlichkeit das Skalieren von ereignisgesteuerten Systemen. Daten können umfangreich kopiert und repliziert werden, ohne dass Änderungen an den Daten berücksichtigt werden müssen.

Das CQRS-Design erkennt an, dass in den meisten Systemen das Verhältnis von Lesevorgängen zu Schreibvorgängen stark unausgewogen ist. In vielen Situationen übersteigt das Volumen der (Daten-)Lesevorgänge das Volumen der Schreibvorgänge um mehrere Größenordnungen. Relationale Datenbanken sind jedoch auf (etwas) symmetrische Volumina von Lese- und Schreibvorgängen ausgerichtet. CQRS trennt explizit die Verantwortlichkeiten für Lese- und Schreibvorgänge, normalerweise in zwei separaten Teilsystemen. Dieses Design bietet auch Vorteile, hauptsächlich in Bezug auf Latenz, Skalierbarkeit und Hardware-Effizienz.

Dennoch sind sowohl ES als auch CQRS bereits bei großen technologieorientierten Unternehmen und im quantitativen Handel (Finanzwesen) beliebt, haben jedoch erst kürzlich in der Mainstream-Unternehmenssoftware an Bedeutung gewonnen. Als Ergebnis ist die ES+CQRS-Tooling im Vergleich zu ihren Pendants im Bereich der relationalen Datenbanken noch in den Anfängen. Diese Herangehensweise bietet jedoch Möglichkeiten, nicht nur die Hardwarekosten stark zu reduzieren, sondern auch Latenzen zu komprimieren, die für die meisten ERP-Implementierungen häufig ein akutes Problem darstellen.

Lokads Standpunkt

Da ERPs nicht einmal für analytische Zwecke geeignet sind - daher die Notwendigkeit von BI (Business Intelligence)-Tools - sollte es nicht überraschen, dass ihre Erfolgsbilanz immer dann miserabel ist, wenn vorhersagende Analysen im Spiel sind. Als belegbare Evidenz ist keine der Machine-Learning-/ Data-Science-Revolutionen in ERPs passiert, und wenn es um diese Art von Anforderungen geht, greifen Teams unweigerlich auf Tabellenkalkulationen oder Ad-hoc-Skripte zurück.

Lokad selbst hat sich als spezialisierte App entwickelt, die ERPs als analytische Ebene ergänzen - nicht ersetzen - soll und sich der prädiktiven Optimierung von Lieferketten widmet. Die meisten unserer Kernfunktionen wie probabilistische Prognosen, die dazu dienen, alltägliche Entscheidungen wie Bestände/Einkauf/Produktion/Sortiment/Preisgestaltung zu unterstützen, sind in ERP-Systemen schlichtweg nicht praktikabel umzusetzen.

Anmerkungen