Enterprise-Resource-Planning (ERP)

Von Joannes Vermorel, März 2020

ERP (Enterprise-Resource-Planning) bezieht sich auf eine Art von Unternehmenssoftware, die Alltagsaufgaben des Unternehmens unterstützt und dazu beiträgt, die Ressourcen des Unternehmens zu verfolgen, insbesondere Geld, Rohmaterialien, laufende Arbeiten, Endprodukte, Kundenbestellungen, erteilte Aufträge und Gehaltsabrechnungen. Normalerweise umfassen ERPs viele Module, die bestimmten Kernfunktionen gewidmet sind, etwa Buchhaltung, Beschaffung, Distribution, Finanzbuchhaltung, Vertrieb, usw., und die eine enge Integration innerhalb dieser Module zulassen. Dank dieser Integration wird der Fluss von Betriebsinformationen unter den verschiedenen Bereichen erleichtert. ERPs basieren auf relationale Datenbanken und bieten gewöhnlich ein sehr umfangreiches Design: eine Vielzahl an Entitäten (z.B. Produkte, Kunden, Rechnungen, usw.), vielfältige Screens und ein hohes Maß an Konfigurierbarkeit.

Ursprung und Begründung    Das Design der ERPs       Technologie       Angebotsgestaltung       Software-Ökosystem    Die Grenzen der ERPs       Für grobe Schreib- oder Leseaufgaben ungeeignet       Für neue oder differenzierte Paradigmen ungeeignet    Risiken bei der Umstellung vom ERP    Über den Monolith hinaus    Über relationale Datenbanken hinaus    Lokads Ansicht    Hinweise

Ursprung und Begründung

Im Laufe der 70er Jahre wurden nach und nach die vielfältigen Vorteile elektronischer Aufzeichnungen im Vergleich zur herkömmlichen Papierspur deutlich. Elektronische Aufzeichnungen wurden günstiger, schneller und zuverlässiger als Papieraufzeichnungen. Für die Stärkung von elektronischen Aufzeichnungen waren vor allem zwei Erfindungen vor den ERPs verantwortlich, nämlich die Barcodeleser (1950er) und die relationalen Datenbanken (1970er). Barcodeleser ermöglichten einen überlegenen Umgang mit Warenflüssen und erhöhten die Produktivität, während gleichzeitig Verwaltungsfehler reduziert wurden. Trotz der deutlichen Verbesserung, die die Barcodeleser in der Datengewinnung ermöglichten, war es in vielen Fällen noch zwei Jahrzehnte lang problematisch, die elektronischen Datensätze zu speichern, zur organisieren und zu verarbeiten. Die Lösung dieses Problem kam Ende der 70er Jahre aus der Softwareindustrie in Form von relationalen Datenbanken, die fünf Jahrzehnte später immer noch das Management von Unternehmensdaten dominieren.

Dennoch waren die bloßen relationalen Datenbanksystemen, wie sie Anfang der 80er angeboten wurde, sehr kostspielig, was die Implementierung betraf, da jedes Unternehmen von vorne überlegte, wie sie ihre Gegebenheiten, also etwa Produkte, Kunden, Zahlungen, usw. in ihrer Datenbank darstellen konnten. So kam im Laufe der 80er eine Reihe von Unternehmen auf, die „vorkonfigurierte“ relationale Systeme verkauften. Diese Produkte würde man später als ERPs bezeichnen, ein Begriff, der in den 90ern geprägt wurde. Leider ist das Akronym ERP eine Fehlbezeichnung, es hätte vielmehr Enterprise Resource Management als Planning heißen sollen. In der Tat ist die Planung bestenfalls eine zweitrangige Aufgabe der ERPs. Wie im Folgenden beschrieben wird, stehen prädiktive Analysen den ERPs von Grund auf im Design entgegen.

Historisch betrachtet, gewannen ERPs an Bedeutung, weil sie eine Reihe von Aufgaben, die zuvor mit einem hohen Verwaltungsaufwand verbunden waren, optimierten. Beispielsweise musste für die Erteilung eines Auftrags an einen Lieferanten ein Formular mit dem Namen und der Adresse des Lieferanten ausgefüllt werden. Die Auftragspositionen mussten ausschließlich gültige Produktbezeichnungen enthalten. Beim Erhalt der Ware mussten die erhaltenen Mengen mit denen aus dem Auftrag übereinstimmen. Wenn dies als konform betrachtet wurde, musste eine Zahlungsanweisung auf Grundlage einer Vorlage mit dem richtigen Betrag erstellt werden, in der auch das Datum mit den Zahlungsbedingungen des Lieferanten übereinstimmte, sowie die richtige Bankverbindung des Lieferanten vorhanden war. All diese Angaben finden sich in einem ERP wieder, mit dem einfach eine Kohärenzprüfung auch automatisiert erfolgen kann.

Ende der 90er erfuhr der ERP-Markt einen rasanten Anstieg, der in erster Linie auf den stetigen Fortschritt der Hardware (Prozessoren, Arbeitsspeicher und Speicher) zurückging, auf die Unternehmen jeglicher Größe Zugang hatten.

So bildeten ERPs in den 90ern den Softwarekern der meisten großen Unternehmen, bei denen es hauptsächlich um Warenströme ging. Im Gegensatz hierzu setzten die meisten Dienstleistungsunternehmen grundsätzlich auf CRM-Software (Customer Relationship Management). So haben ERPs und CRMs viele gemeinsame Merkmale, wie auch ihr Design, das auf relationale Datenbanken basiert. Dabei agieren ERPs aus der Perspektive der Vorgänge, während CRMs die Perspektive der Kunden einnehmen.

Das Design der ERPs

ERPs sind sehr vielfältig, da jede Menge Anbieter auf dem Markt über Jahrzehnte Versionen ihrer ERPs herausgebracht haben, dennoch sind die meisten Implementierungen von Kern auf sehr ähnlich entwickelt. ERPs erschienen als „vorkonfigurierte“ Softwareschichten, die auf relationale Datenbanken implementiert wurden. Daher umfasst der Designprozess der ERPs die Katalogisierung von:

• Entitäten, also allen Konzepten und Objekten, die im ERP dargestellt werden müssen, wie Produkte, Zahlungen, Bestände, Lieferanten usw. Dabei können jeder Entität eine oder mehrere relationale Datenbaken zugrunde liegen. In den meisten ERPs sind hunderte Entitäten definiert oder gar tausende in den komplexesten ERPs.
• Benutzeroberflächen, über die sich Endkunden Daten zu den Entitäten anzeigen lassen und bearbeiten können. Diese Oberflächen werden vom sogenannten CRUD-Design (Create / Read / Update / Delete) dominiert, mit dem die grundlegendsten Funktionen, die die Endnutzer für den Umgang mit Entitäten erwarten, dargestellt werden.
• kaufmännische Logik, die das automatisierte Verhalten bietet, mit der viele Verwaltungsaufgaben auf Grundlage gut definierter Regeln automatisiert werden können und somit entfallen, wie etwa aus Kundenbestellungen eine Rechnung erstellen.
  

Da Unternehmen unglaublich vielseitig und komplex sind, werden ständig neuer oder spezifischere Entitäten, Benutzeroberflächen und kaufmännische Logiken benötigt, um mit dem Unternehmen am Puls der Zeit zu bleiben. Dies stellt einen riesigen und ständigen Aufwand für die ERP-Anbieter dar. Zusätzlich ist diese Herausforderung mit den Unstimmigkeiten verbunden, die aus dem Versuch entstehen, verschiedenen Branchen gerecht zu werden. Unter demselben Begriff, etwa „Zahlung“, können sich in verschiedenen Branchen sehr unterschiedliche Situationen und Prozesse verbergen. In der Softwarebranche ist Komplexität gewöhnlich mit nicht-linearen Kosten verbunden, so kostet die Unterstützung doppelt so vieler Features in einem Produkt mehr als das Doppelte der Originalkosten.

Folglich setzen ERP-Anbieter auf eine Reihe von Strategien, um ihre Investitionen in Software wettbewerbsfähiger zu gestalten.

Technologie

Die erste Strategie der ERP-Anbieter, um mit der Komplexität umzugehen, besteht darin, Technologien mit dem ausdrücklichen Ziel zu entwickeln, die Kosten im Zusammenhang mit der Komplexität zu senken.

Insbesondere haben viele ERP-Anbieter domänenspezifische Sprachen (DSL) zur Ergänzung der zugrundeliegenden Abfragesprache – gewöhnlich SQL – der relationalen Datenbanken entwickelt. Über eine gut durchdachte DSL lässt sich das ERP ressourcenschonender erweitern (Einführung neuer Entitäten, Benutzeroberflächen oder Logiken) als unter Einsatz einer universaler Programmiersprache.

Seit den 2000ern haben die Anbieter von open source ERPs, die sich die open source relationale Datenbanken aus dem Ende der 90er Jahre zu Nutze machten, eine alternative Plug-in-Strategy eingenommen. Statt DSLs einzusetzen, wird das ERP über benutzerdefinierten Code in derselben Allzwecksprache des ERPs für jeden Betriebskunden erweitert. Diese Strategie lässt sich für den ERP-Anbieter einfacher umsetzen (es muss keine DSL entwickelt werden) und entspricht auch der Open-Source-Philosophie.

Angebotsgestaltung

Während die Kosten für die Implementierung und den Support von Features mit der steigenden Anzahl dieser Features wächst, greifen die meisten ERP-Anbieter auf eine Preisstrategie nach Modulen zurück. Es werden also Features als Paket in „Modulen“ angeboten, die sich auf bestimmte Funktionsbereiche im Unternehmen konzentrieren, etwa Bestandsmanagement, Finanzbuchhaltung, Gehaltsabrechnungen, usw. So wird das ERP in Modulen verkauft und den Betriebskunden steht frei, die dringendsten Module zu beschaffen und die anderen für spätere Investitionen aufzuheben.

Diese modulbasierte Preisstrategie bietet den Anbietern eine natürliche Upselling-Möglichkeit, indem der aktuelle Kundenstamm zum wesentlichen Zielpublikum künftiger Umsätze wird. Für Unternehmensbereiche, die ursprünglich nicht vom ERP abgedeckt wurden, werden neue Module eigens entwickelt, die an Unternehmen verkauft werden können.

Diese modulbasierte Preisstrategie stellt einen effektiven Mechanismus zum Umgang mit Komplexität dar, da die ERP-Anbieter direktes Feedback über die Funktionsbereiche, in denen die Zahlungsbereitschaft am höchsten ist, erhalten und entsprechend ihre Softwareentwicklung priorisieren können.

Software-Ökosystem

Jedes zusätzliche Feature im ERP stellt für den ERP-Anbieter, der seine Kapazitäten in der Softwareentwicklung richtig priorisiert hat, gewöhnlich geringere Einnahmen dar (1). In der Tat ist es so, dass wenn das Feature nicht schon früher hinzugefügt wurde, es wahrscheinlich nicht genug Unternehmen gefehlt hat. Zusätzlich tendieren Unternehmen selbst, auch ERP-Anbieter, dazu, unter negativen Skaleneffekte zu leiden. So ist bereits bekannt, dass zusätzliche Softwareentwickler, die an einem Produkt arbeiten sollen, nicht zu linearen Vorteilen in der Umsetzung von Verbesserungen am Produkt führen.

Daher setzen die meisten ERP-Anbieter auf eine Ökosystemstrategie, um das ERP betriebsfähig zu machen, und delegieren diese Entwicklungskapazitäten für die letzte Meile auf Dritte, die oft als Integratoren bezeichnet werden. Diese Integratoren werden von den Unternehmenskunden der Anbieter für die Implementierung und das Rollout aller Fähigkeiten, die im „rohen“ ERP nicht vorhanden sind, bezahlt. Historisch betrachtet, bestand bis zu den 2000ern die Arbeit der Integratoren darin, bei der Ersteinführung eines ERP in einem Unternehmen zusätzliche Fähigkeiten bereitzustellen. Heutzutage stellen die meisten ERP-Projekte Upgrades dar, da ein ERP bereits vorhanden ist. Daher besteht der Mehrwert der Integratoren hauptsächlich darin, einen reibungslosen Übergang vom alten ERP zum neuen zu gewährleisten. In der Praxis umfasst diese Arbeit die Migration von Daten und Prozessen von einem System auf das andere.

Im Gegensatz zu den ERP-Anbietern, dessen Unternehmensstrategie in erster Linie auf das ERP selbst abzielt, das als immaterieller Vermögenswert in Form von geistigen Eigentum behandelt wird, richtet sich das Honorar der Integratoren gewöhnlich nach Personentagen. So rechnen sie nach der Anzahl der Tage, die sie gearbeitet haben, und das geistige Eigentum der gelieferten Leistungen geht gewöhnlich vertraglich auf den Unternehmenskunden über.

Die Schaffung eines vielfältigen Ökosystems an Integratoren, sowohl was die Standorte als auch die Wirtschaftszweige betrifft, stellt eine effektive Chance dar, die inhärente Komplexität, die mit der Entwicklung eines ERPs einhergeht, zu mindern. Fast alle großen ERP-Anbieter haben umfangreiche Integratoren-Netzwerke entwickelt.

Die Grenzen der ERPs

Die meisten Einschränkungen der ERPs sind auf die relationalen Datenbanksysteme, auf denen sie beruhen, zurückzuführen (2). Weitere Einschränkungen stammen von der oben beschriebenen Strategie zur Eindämmung der Komplexität. Diese Grenzen sind von besonderem Interesse, weil sie von Design aus entstehen und sie daher mit relativ geringer Wahrscheinlichkeit von einer neueren ERP-Version behoben werden. Gleichzeitig kann man auch sagen, dass die Behebung dieser Einschränkungen in die ursprüngliche Natur der ERP so tief eingreifen würde, dass man diese Softwareprodukte nicht mehr sinnvollerweise als ERPs bezeichnen könnte.

Für grobe Schreib- oder Leseaufgaben ungeeignet

Die von ERPs genutzten relationalen Datenbanken bieten ACID-Eigenschaften (Atomarität, Konsistenz, Isolation und Dauerhaftigkeit) mit einem Design, das für eine durch kleine Lese- und Schreibaufgaben erzeugte Arbeitsbelastung gedacht ist. Dabei sollen diese Aufgaben mit geringen Latenzzeiten ausgeführt werden – gewöhnlich einem Sekundenbruchteil –, wobei das Volumen an Lese- und Schreibaufgaben sich die Wage hält. Eine detaillierte Analyse der relationalen Datenbanken geht über das Ziel dieses Artikels hinaus, dennoch werden durch diese Beobachtung zur vorgesehenen Arbeitsbelastung viele der Einschränkungen der ERPs, die bislang nicht richtig verstanden wurden, deutlich.

Da sich das Design der ERPs auf relationale Datenbanken stützt, sind sie für die Erstellung von Analysen, Statistiken und Berichten, bei denen eine beachtliche Anzahl an Daten involviert sind, nicht geeignet. Der Zugriff auf eine große Datenmenge während des Betriebs stellt in jedem ERP immer ein Problem dar, weil das System verlangsamt wird, wenn es aufgrund zu vieler Lese- oder Schreibaufgaben über unzulängliche Ressourcen verfügt. In der Praxis bedeutet dies, dass Alltagsaufgaben wie die Verarbeitung von Barcodes auch langsamer werden. Im schlimmsten Falle kommt das gesamte Unternehmen zum Stocken. Daher sollte jegliche Schreib- oder Leseaufgabe im ERP klein und idealerweise „unbedeutend“ gehalten werden. Die Datenmengen, die als unbedenklich gelten, sind in den letzten vier Jahrzehnten mit der besseren und günstigeren Hardware deutlich gestiegen. Jedoch haben viele Unternehmen diese Entwicklung dazu genutzt, auch die Anzahl der Daten, die in ihren ERPs eingespeist werden, deutlich zu erhöhen. Folglich sind heutige ERPs nicht viel schneller als vor zwanzig Jahren.

Beispielsweise eigenen sich ERPs besonders für die Anzeige der Bestandshöhen einer SKU oder die Aktualisierung dieser Werte, wenn eine Einheit entnommen wird. Im Gegensatz hierzu eignen sie sich eher nicht, um die konsolidierten täglichen Timelines der Bestandsvariationen einer SKU im Laufe der letzten drei Jahre anzuzeigen. Das gesamte Segment der BI-Softwareanwendungen (Business Intelligence) kam in den 90er Jahren auf und stellte die Antwort der Industrie auf die Einschränkungen der ERPs (sowie auch der CRMs) im Bereich der Analysen dar. Im Gegensatz zu den ERPs, dreht sich die Entwicklung der BI-Tools um In-Memory-Hypercubes, die oft als OLAP (Online Analytical Processing) bezeichnet werden. Da OLAP-Systeme auf ACID-Eigenschaften verzichtet haben, können sie in Bezug auf die Software deutlich effizienter als relationale Datenbanken aggregierte Statistiken, wie etwa Umsatz pro Tag, pro Niederlassung, pro Kategorie, usw. liefern.

Interessanterweise erkannten viele der ERP-Anbieter diese im Design verankerten Einschränkungen ihrer eigenen Produkte, sogar bei Produkten, die nach den 90ern erschienen, als das BI-Segmente diese deutlich aufzeigte, nicht. So wagten sich viele ERP-Anbieter in die Welt der Bedarfsprognose, die vom Design den relationalen Datenbanken vollkommen entgegengesetzt ist – sogar noch mehr als einfache Berichtfunktionen. Für die Prognostizierung ist der Zugriff auf die gesamten historischen Betriebsdaten des Unternehmens erforderlich: Umsatz, Retouren, Bestandshöhen, Nachlässe, usw. Während eine solche Berechnung gewöhnlich nachts vorgenommen wird, um das Problem der Auslastung der Kapazitäten im System zu vermeiden, führen relationale Datenbanken bei dieser Art von Berechnungen ungewollt zu jeder Menge Mehraufwand. Folglich bieten die meisten ERPs heutzutage noch „Altsysteme“ für die Prognose (3), die seit Jahren, wenn nicht sogar Jahrzehnten, überholt sind.

Für neue oder differenzierte Paradigmen ungeeignet

Die Strategie der ERP-Anbieter, Entitäten zu katalogisieren, lässt keine lineare Skalierbarkeit bei steigender Komplexität zu. Wie oben beschrieben, bringen bessere Tools eine lineare Erleichterung in Bezug auf die Anzahl der Entitäten, mit einem superlinearen Wachstum der Kosten bei Komplexität. Folglich führen neue bzw. differenzierte Paradigmen zu hohen Kosten und zu Verzögerungen bei der Integration, wodurch häufig die bessere Alternative wäre, das ERP einfach zu umgehen. Dies kommt in vielfältigen Situationen vor – einige davon folgen –, dennoch sind die Schwierigkeiten darauf zurückzuführen, dass sich die Paradigmen nur schwer integrieren lassen, weil sie in einer späten Phase des Entwicklungsprozesses des ERP erst auftauchen (4).

Null Betriebsunterbrechungen zu erreichen ist, wie bereits beschrieben, schwierig, da größere Lese- oder Schreibaufgaben das ERP-System verlangsamen können. Daher werden solche Aufgaben normalerweise nachts im Batch-Modus ausgeführt, wenn keine, bzw. nur kleinere, Aufgaben ausgeführt werden. Dieses Design widerspricht jedoch den Anforderungen des E-Commerce, das vergleichsweise ziemlich spät in der Geschichte der ERPs aufkam. Aufgrund dessen trennen viele ERP-Anbieter ihre E-Commerce-Module und nutzen gar ein separates Datenbanksystem, womit die im Design verankerte, ungeschriebene Regel, dass alle ERP-Module in derselben bzw. denselben Datenbank/en vorhanden sind, gebrochen wird. Folglich ist das Rollout von E-Commerce-Modulen, die sich auf ERPs stützen, oft genau so kompliziert und teuer wie die Umsetzung von Drittanwendungen.

In Zweigen, die mit Reparaturen zusammenhängen, sind komplexe zyklische Warenflüsse (also Reparaturen) zu beobachten, während die Flüsse in allgemeinen ERPs sich gewöhnlich nach vorne orientiert sind – von Produzenten zu Verbrauchern –, wie es normalerweise bei Schnelldrehern oder im Vertrieb der Fall ist. Während die meisten relevanten Entitäten, die für Reparaturen erforderlich sind (also Produkte, Bestände, Bestellungen) bereits im ERP vorhanden sind, stimmen sie vom Design her nicht mit den Bedingungen für Reparaturen überein. Oft ist es einfacher diese Entitäten erneut zu implementieren, als die in allgemeinen ERPs in diesen Zweigen bereits vorhandenen Entitäten zu recyceln.

Dabei ist es schwierig niedrige Latenzzeiten, die etwa unter der menschlichen Wahrnehmung liegen (also unter 50 ms), zu gewährleisten, weil weder das ERP noch seine relationale Datenbank für solche Anforderungen entwickelt wurden. Jedoch benötigen automatisierte Systeme, wie etwa robotergesteuerte Warenlager, solche Latenzzeiten, damit die softwaregestützte Orchestrierung nicht zu einem Engpass im System führt. Daher verfügen in der Praxis die meisten Bereiche mit Bearbeitung in „Echtzeit“ (4) über spezifische Systeme außerhalb des ERPs.

Interessanterweise gibt es spezialisierte ERPs – die sich jedoch nicht immer ERPs nennen –, die eine andere Richtung in ihrer Entwicklung eingeschlagen haben, um genau solche Situationen zu bewältigen. Diese ERPs richten sich hauptsächlich an Marktnischen, denen allgemeine ERPs nicht gerecht werden. Dennoch stehen diese alternativen Entwicklungsrichtungen gewöhnlich den allgemeinen Anforderungen entgegen.

Risiken bei der Umstellung vom ERP

Auch wenn es paradox erscheinen mag, ist es deutlich schwieriger, ein Upgrade für ein bestehendes ERP durchzuführen, als das ERP erstmals bereitzustellen. Upgrades sind dafür bekannt, einen mehrjährigen Prozess hinter sich zu ziehen. Sogar einfache Upgrades auf die neue Version des ERPs vom selben Anbieter entwickeln sich oft zu einem monatelangen Projekt. So sorgen solche Schwierigkeiten immer wieder für Schlagzeilen, wenn große Unternehmen in ihren Pressemitteilungen bekanntgeben, dass ihr ERP-Upgrade das Budget um mehrere hunderte Millionen Dollar oder Euro überstiegen haben. In solchen Fällen trifft die Schuld den ERP-Anbieter, den Integrator und/oder das Unternehmen selbst. Dennoch scheint keiner zu erkennen, dass solche Probleme intrinsisch mit dem ERP selbst und seinem Design – aufgrund der oben beschriebenen Marktkräfte – einhergehen.

Die Kosten für Komplexität steigen nicht linear sondern superlinear. Wenn ein Unternehmen erstmalig ein ERP einsetzt, hat es den Luxus, ein Modul nach dem anderen einführen zu können. Daher handelt es sich bei jedem Durchlauf um eine relativ kleine Anzahl an Entitäten/Benutzeroberflächen/Logiken, und durch sukzessive maßgeschneiderte Erweiterung wird das ERP an die Bedürfnisse des Unternehmens angepasst.

Beim Umstieg auf ein anderes ERP, steht das Unternehmen jedoch vor dem Problem, dass alle Module gleichzeitig betroffen sind. In der Tat sind ERPs von Design her und gemäß den Marktkräften (5), auf kleinen Datenbankgruppen errichtete Software-Monolithe. Somit kann beim Umstieg auf ein neues ERP die ursprüngliche inkrementelle Umsetzung nicht erfolgen. Deshalb erfolgt der Umstieg praktisch gänzlich nach dem Alles-oder-Nichts-Prinzip. Infolgedessen sind die Vorabausgaben für die Umsetzung gewöhnlich sehr hoch, während es nach der Bereitstellung zu einer Situation kommt, in der viele Teile nicht funktionieren und teilweise jahrelang an Lösungen dafür gearbeitet wird.

Technisch gesehen, sind Upgrades immer schwer umzusetzen, da der Import der Entitäten / Benutzeroberflächen / Logiken aus dem alten in das neue System nicht eins zu ein funktioniert. So ändert sich die Semantik der Entitäten mit der Zeit. Beispielsweise kann ein ERP-Anbieter die Tabelle „Bestellungen“ für Kundenbestellungen erstellt haben. Doch im Laufe der Zeit muss der Anbieter sich den neuen und anfänglich nicht geplanten Bedürfnissen anpassen und die Rücksendung der Kunden berücksichtigen. So wird die Tabelle „Bestellungen“ in der neuen Version für die Rücksendung der Kunden umfunktioniert und diese Zeilen enthalten nun negative Bestellmengen. Diese augenscheinlich harmlose Änderung gestaltet jedoch die Migration aus der alten ERP-Version in die neue deutlich schwieriger.

Dennoch ist der Upgrade auf eine neue oder spätere Version desselben ERPs nicht die einzige Option, die Unternehmen offensteht. Es bestehen viele Alternativen, um die Risiken bei einem Übergang zu reduzieren. Selbstverständlich liegt es im Interesse der ganzen ERP-Anbieter und Integratoren, das Gegenteil zu verlauten, um ihr Wirtschaftsmodell fortzusetzen.

Über den Monolith hinaus

ERPs kamen als Software-Monolith auf, also als Software, deren Komponenten eng miteinander verflochten sind, was für ein plug-and-play Rollout aller Module erforderlich ist. Außerdem war es bis zu den 2010ern deutlich schwieriger und teurer, verteilte Systeme, also Software die auf einer Reihe von Rechnern statt auf ein paar zentralen Rechnern laufen, aufzubauen (6). So hatte ein Großteil der ERP-Anbieter, von denen einige jahrzehntealt waren, keine andere Wahl, als ihre Produkt als Monolith zu bauen.

Im Zuge der Popularisierung des Cloud Computings, wurden Tools und Sammlungen beliebter und zugänglicher. Folglich sind die Kosten und der Mehraufwand für das Design von verteilten Anwendungen im Laufe des letzten Jahrzehnts stetig gesunken. Die Softwareindustrie hat nun begonnen, sich darüber Gedanken zu machen, wie auch heutzutage der historische Mehrwert, den ausschließlich ERPs (bzw. ERP-ähnlicher Software) lieferten, geboten werden kann.

Ein moderner Ansatz für Unternehmenssoftware besteht darin, den Monolithen über eine Reihe kleinerer Apps, die sich idealerweise auf eine einzige Sache spezialisieren, aufzuteilen (7). Dabei werden die Apps über Programmschnittstellen (auch, API oder Application Programming Interfaces genannt) zusammengeschweißt, die gerade die Integration diverser maßgeschneiderter Anwendungslandschaften erleichtern sollen. Die meisten APIs sind so konzipiert, dass sie weitverbreitete Open Source API-Tools nutzen können, um die Entwicklungskosten solcher maßgeschneiderter Integrationen zu senken.

Bei solchen Apps sind die Integrationskosten im Voraus manchmal höher als bei integrierten ERP-Modulen. Dennoch bieten sie langfristig deutliche Vorteile, da sie das Risiko der künftigen Entwicklung der App-Landschaft reduzieren. Somit verfügt das Unternehmen über die Möglichkeit, eine App nach der anderen upzugraden oder zu ersetzen, was nicht nur viel einfacher, sondern auch günstiger ist und weniger Risiken birgt. Zuletzt tendieren SaaS-Apps (Software as a Service) dazu, immer wieder kleinere inkrementelle Änderungen zu bieten. Obwohl dieses Muster, die IT kontinuierlich – wenn auch nur in geringem Maße – beschäftigt, ist der Änderungsprozess bei SaaS organischer, kostengünstiger und weniger riskant im Vergleich zu jährlichen oder zweijährlichen Upgrades.

Über relationale Datenbanken hinaus

Relationale Datenbanken sind seit den 80er Jahren das tatsächliche Rückgrat der ERPs. Doch seit den 2010ern sind auch attraktive Alternativen aufgekommen. Die nennenswerteste ist wahrscheinlich das Event Sourcing (ES) gekoppelt an die Command Query Responsibility Segregation (CQRS). Dieser Ansatz bietet eine höhere Skalierbarkeit und bessere Latenzzeiten, sowie ein ausdrucksfähigeres Design, mit dem Geschäftsziele in verschiedenen Situationen genauer erfasst werden können.

Die Quintessenz des Event Sourcing besteht darin, jede Änderung im System als unveränderbares Ereignis zu behandeln. Diese Unveränderlichkeit stammt aus der Buchhaltung: hier löscht der Buchhalter nicht eine Zeile aus dem Hauptbuch, die falsch ist, um das Problem zu lösen, sondern fügt eine korrigierte Zeile im Buch hinzu. Die gesamte Historie der Ereignisse zu speichern – sofern die Datenspeicherung günstig genug zur Umsetzung dieser Strategie ist –, bietet viele Vorteile: bessere Nachverfolgbarkeit, Nachvollziehbarkeit, Sicherheit, usw. Zusätzlich lassen sich ereignisgesteuerte Systeme aus der Perspektive der Unveränderlichkeit einfacher skalieren. Daten können umfänglich kopiert und vervielfältigt werden, ohne auf Änderungen in den Daten achten zu müssen.

Das CQRS-Design geht davon aus, dass in den meisten Systemen, die Lese- und Schreibvolumina sehr unausgewogen sind. In vielen Fällen übersteigt das Datenvolumen der Leseaufgaben um einige Größenordnungen das der Schreibaufgaben. Doch relationale Datenbanken sind vielmehr auf (etwas) symmetrischere Volumina ausgerichtet, was die Verteilung der Lese- und Schreibaufgaben betrifft. Bei CQRS wird die Zuständigkeit für die Lese- und Schreibaufgaben gewöhnlich in zwei Untersysteme aufgeteilt. Dieses Design bietet auch Vorteile, insbesondere für die Latenzzeiten, die Skalierbarkeit und die Hardware-Effizienz.

Doch während sowohl ES als auch CQRS in größeren verbraucherorientierten Technologieunternehmen und im quantitativen Trading (Finanzen) bereits beliebt sind, gewinnt sie erst seit kurzem in allgemeinen Unternehmenssoftware an Bedeutung. Folglich stecken ES+CQRS Tools im Gegensatz zu deren Pendant im Bereich der relationalen Datenbanken noch in den Kinderschuhen. Dennoch bietet dieser Ansatz neue Möglichkeiten, nicht nur die Kosten für Hardware zu senken, sondern auch Latenzzeiten, die häufig ein akutes Problem in den meisten ERP-Implementierungen bleiben, zu verkürzen.

Lokads Ansicht

Da ERPs nicht einmal für Analyseaufgaben geeignet sind – weshalb auch BI-Tools erforderlich sind –, überrascht es nicht, dass ihre Erfolgsbilanz beim Einsatz für prädiktive Analysen schlecht ausfällt. Nebenbei lässt sich auch erwähnen, dass keine der Revolutionen im maschinellen Lernen / Data Science aus den ERPs hervorgekommen ist, und, dass Teams bei solchen Anforderungen stets auf Kalkulationstabellen oder ad hoc Scripts zurückgreifen.

Lokad selbst entstand als spezialisierte App, die ERPs mit einer Analyseschicht für die prädiktive Optimierung in Supply-Chains ergänzen – und nicht ersetzen – sollte. Die meisten unserer Hauptfeatures, wie etwa die Fähigkeiten für probabilistische Prognosen, die Alltagsentscheidungen beispielsweise im Zusammenhang mit dem Bestand, dem Einkauf, der Herstellung, dem Sortiment oder den Preisen unterstützen soll, erweisen sich bei einer Implementierung innerhalb eines ERP-Systems als äußerst unpraktisch.

Hinweise

(1) Diese Ansicht ist etwas vereinfachend. In der Praxis hat die Softwareentwicklung in den letzten Jahrzehnten zusammen mit den rohen Rechenressourcen einen großen Fortschritt erfahren. Folglich sind Kapazitäten, deren Entwicklung in den 80ern noch unglaublich kostspielig gewesen wäre, ein paar Jahrzehnte später deutlich günstiger. ERP-Anbieter priorisieren ihre Entwicklungsprojekte in Anbetracht dieses Phänomens erneut.

(2) Historisch betrachtet, stützten sich die allerersten ERPs aus den 70ern, bzw. die ERP-ähnlichen Software – da der Begrifft ERP erst später geprägt wurde – auf rohe Flat-File-Datenbanken. Relationale Datenbanken kamen als eine in praktisch jedem Aspekt überlegene Alternative für die Flat-File-Datenbanken auf. Daher verbesserten die frühen ERP-Anbieter das Design ihrer ERPs mit relationalen Datenbanken. Dennoch waren im Zusammenhang mit Batch-Datenprozessen, die sich auf die gesamte Datenbank bezogen, Flat-File-Datenbanken praktisch überlegen – im Vergleich zur selben Investition in Hardware –, bis sich in den 2010ern relationale Datenbanken mit Spalten verbreiteten.

(3) Da viele ERP-Anbieter versuchten, Features für Prognosen zu entwickeln und anzubieten, versuchten Anbieter von Datenbanken im Gegenzug auch Fähigkeiten für Prognosen in ihre Systeme einzubauen. Meines Wissens sind solche nativen „Prognosefähigkeiten“ von Datenbanken weit verbreitet und werden recht selten genutzt (bzw. stark durch manuelle Eingriffe über Excel ergänzt). Sie werden lediglich für die Abwärtskompatibilität mit Anbietern aufrechterhalten.

(4) Die Verarbeitung in Echtzeit stellt eine relativ subjektive Terminologie dar. Technisch betrachtet sind die Latenzzeiten, die in verteilten Systemen erreicht werden könne, sogar von der Lichtgeschwindigkeit begrenzt. Das eigentliche Ziel eines ERPs ist die Koordination von Lieferanten, Anlagen, Lager, usw., die geographisch entfernt sind.

(5) Das Hauptargument einer Preisstrategie nach Modulen besteht darin, dass das das Nutzererlebnis für den Kunden beim Hinzufügen eines Moduls (praktisch) eine plug-and-play-Sache ist. Dennoch ist der Preis, den man im Design für diese einfache Umsetzung zahlt, eine Strenge Verkopplung der Module, also ein monolithisches Design. Zusätzlich wirken sich die Änderungen eines Moduls auf viele andere Module aus.

(6) Verteilte Computersysteme sind seit Jahrzehnten vorhanden. Doch bis ein allgemeiner Zugang zu Cloud-Computing in den 2010ern möglich war, wurde jedes einzelne Teil einer Unternehmenssoftware um die Client-Server-Architecture entwickelt, mit der alle Prozesse und alle Daten auf eine Handvoll Maschinen verteilt waren, die im Wesentlichen aus einem Front-End, einem Back-End und einer Datenbank bestanden. Im Gegensatz hierzu beruht das Cloud-Computing, mit dem Ziel mehr Zuverlässigkeit und Performanz zu bieten, auf eine ganze Flotte von Maschinen.

(7) Das war die ursprüngliche Entwicklungsphilosophie von Unix. Nach den 2010ern sind spezialisierte Unternehmensapps gewöhnlich nicht so eng und spezifisch wie Unix-Tools. Trotzdem sind diese Apps zwei bis drei Größenordnungen weniger komplex als ERPs. Dieser Ansatz sollte im Übrigen nicht mit Microservices verwechselt werden, bei denen Apps intern selbst entwickelt werden.