Enterprise Resource Planning (ERP)

ERP (Enterprise Resource Planning) bezieht sich auf eine Klasse von Unternehmenssoftware, die die Routinebetriebe 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 Büroarbeit zu reduzieren. Obwohl Barcode-Lesegeräte die Datenerfassung in vielen Situationen erheblich verbessert hatten, blieb die Speicherung, Organisation und Verarbeitung elektronischer Aufzeichnungen etwa 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 vorherrschende Praxis im Bereich des Geschäftsdatenmanagements.

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 wird, 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 gemäß einer 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 werden.

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

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 grundlegendsten 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¹. Tatsächlich wurde dieses Feature wahrscheinlich deshalb nicht hinzugefügt, weil es anfangs nicht genügend Unternehmen betraf. 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 konzentrierte sich die Arbeit der Integratoren bis in die 2000er Jahre hinein in der Regel auf die Einführung zusätzlicher Funktionen für das ERP, wenn Unternehmen ERPs 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. Diese sollten mit geringen Latenzzeiten durchgeführt werden - typischerweise 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 auch von diesem Fortschritt profitiert, um die Menge an Daten, die in ihre ERPs eingeflossen sind, 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 über die letzten drei Jahre 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 Datenbankmodell grundsätzlich unterscheiden - noch mehr als einfache Berichtsfunktionen. Für die Prognose ist der Zugriff auf die gesamte Historie der Transaktionsdaten des Unternehmens erforderlich: Verkäufe, Rücksendungen, Lagerbestände, Rabatte usw. Obwohl die Berechnung in der Regel nachts in Chargen durchgeführt werden soll, um das oben genannte 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 die Komplexitätsverwaltung. Bessere Tools, wie oben diskutiert, bringen nur eine lineare Erleichterung - in Bezug auf die Anzahl der Entitäten - während die Komplexitätskosten überproportional steigen. Als Ergebnis erweisen sich neue oder unterschiedliche Paradigmen in der Regel sowohl in Bezug auf Kosten als auch Verzögerungen als teuer, um sie zu integrieren, und erreichen häufig den 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 hinaus, die aufgrund ihres späten Erscheinens 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 Systemverlangsamung aussetzt. Daher werden all diese Operationen in der Regel als nächtliche Stapelverarbeitungen durchgeführt, wenn nur wenige oder keine Operationen im Gange sind. Dieses Design 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 umfassend getrennt, wobei häufig ein separates Datenbanksystem verwendet wird, was gegen die implizite Designregel verstößt, dass alle ERP-Module in derselben Datenbank leben. Als Ergebnis 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 - von Produzenten zu Verbrauchern - ausgerichtet sind, 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, stehen ihre Designs typischerweise im völligen 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 wiederzuverwenden.

Die Bereitstellung von garantiert niedrigen Latenzzeiten, zum Beispiel unterhalb der menschlichen Wahrnehmungsschwelle (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 Lagerhäuser solche Latenzzeiten, um zu vermeiden, dass die softwaregesteuerte Orchestrierung zum Engpass des Systems wird. In der Praxis haben die meisten Bereiche, die mit “Echtzeit”-Verarbeitung (4) 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 nur zum ersten Mal einzusetzen. Upgrades sind dafür bekannt, mehrjährige Prozesse zu sein. Selbst einfache Version-Upgrades des ERPs - bei 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. Dennoch scheinen die meisten nicht anzuerkennen, dass solche Probleme intrinsisch mit ERPs selbst verbunden sind, wie sie durch die oben genannten Marktkräfte entworfen wurden.

Die Komplexitätskosten skalieren nicht linear, sondern überproportional. 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. Die Anzahl der Entitäten / Schnittstellen / Logiken, die mit jeder Iteration verbunden sind, ist daher 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 wechseln. Tatsächlich sind ERPs, durch Design und wirtschaftliche Kräfte bedingt⁵, Software-Monolithen, die auf einer kleinen Anzahl von Datenbanken aufbauen. Daher kann der inkrementelle Einführungspfad, 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 wechseln. Als Ergebnis neigen 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 der 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. Im Laufe der Zeit muss der Anbieter jedoch die neueren 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 ERP-Version erheblich.

Es gibt jedoch nicht nur die Möglichkeit, auf ein neues ERP oder auf 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 inneren 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 es deutlich schwieriger und kostspieliger⁶, verteilte Systeme zu erstellen - d.h. Software, die auf einer Flotte von Maschinen anstatt auf wenigen zentralen Maschinen arbeitet. Daher hatten ERP-Anbieter (von denen die meisten Jahrzehnte alt sind) weitgehend keine andere Wahl, als ihre Produkte als Monolithen zu entwickeln.

Dennoch wurden mit dem Aufkommen des Cloud Computing Tools und Bibliotheken - häufig Open Source - immer beliebter und zugänglicher. Als Ergebnis sind die Kosten und Aufwände, die mit dem Design von verteilten Anwendungen verbunden sind, in den letzten zehn Jahren stetig gesunken. Die Softwareindustrie hat begonnen, umfassend 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 genau dazu dienen, maßgeschneiderte Integrationen in verschiedene Anwendungsumgebungen zu erleichtern. 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

Relationale Datenbanken sind seit den 80er Jahren 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 gesamte Ereignisprotokoll zu behalten - vorausgesetzt, der Speicherplatz ist billig genug, um diese Strategie rentabel zu machen - bringt zahlreiche Vorteile: bessere Rückverfolgbarkeit, Nachvollziehbarkeit, Sicherheit… Darüber hinaus erleichtert der unveränderliche Aspekt 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 Lesezugriffen zu Schreibzugriffen stark unausgewogen ist. In vielen Situationen übersteigt das Volumen der (Daten-)Lesezugriffe das Volumen der Schreibzugriffe um mehrere Größenordnungen. Relationale Datenbanken sind jedoch auf (etwas) symmetrische Volumina von Lese- und Schreibzugriffen ausgerichtet. CQRS trennt explizit die Verantwortlichkeiten für Lese- und Schreibzugriffe, normalerweise in zwei separaten Teilsystemen. Dieses Design bringt auch Vorteile, hauptsächlich in Bezug auf Latenz, Skalierbarkeit und Hardware-Effizienz.

Dennoch sind ES und CQRS zwar bereits bei großen technologieorientierten Unternehmen und im quantitativen Handel (Finanzwesen) beliebt, haben aber erst vor kurzem begonnen, in der Mainstream-Unternehmenssoftware Fuß zu fassen. Als Ergebnis ist die ES+CQRS-Tooling im Vergleich zu ihren Pendants im Bereich der relationalen Datenbanken noch in den Anfängen. Dennoch bietet dieser Ansatz 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 Ansatz

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 beispielhafter Beweis dafür haben keine der Revolutionen im Bereich maschinelles Lernen / Data Science in ERPs stattgefunden, und wenn es um solche 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 innerhalb von ERP-Systemen schlichtweg nicht praktikabel umzusetzen.

Anmerkungen