Wahl Ihres ERP

00:00:07 Wichtigkeit von ERP-Systemen.
00:02:42 ERP: Erklärung der Fehlbezeichnung.
00:03:54 Erste ERP-System-Implementierung.
00:05:07 Frühe Kernfunktionen von ERP-Systemen.
00:07:34 ERP-Systeme: Entitäten, Schnittstellen, Logik.
00:09:14 Die Rolle von ERP-Systemen in der Geschäftsautomatisierung.
00:09:54 Evolution der ERPs und Strategien.
00:11:32 Domänenspezifische Sprachen in ERPs.
00:12:07 Modulbasierte Struktur von ERP-Systemen.
00:14:22 Rolle von Integratoren in ERPs.
00:16:00 Integratoren fördern maßgeschneiderte ERP-Lösungen.
00:17:01 Relevanz traditioneller ERP-Einschränkungen.
00:19:01 Herausforderung des Bedarfs an einem einheitlichen ERP-System.
00:20:01 Schwierigkeiten bei ERP-Upgrades.
00:21:35 Rolle und Komplikationen des ERP-Betreibers.
00:22:53 Risiken/Vorteile spezialisierter ERP-Anbieter.
00:25:00 ERP-Systeme: Komplexität und Herausforderungen.
00:26:52 Kleine Unternehmen und SaaS-Anwendungen.
00:28:42 Komplexe ERP-Produkte für mittelständische Unternehmen.
00:30:16 Großunternehmen, die monolithische ERPs vermeiden.
00:31:46 Strategien führender Unternehmen.
00:33:39 Abschließende Gedanken.

Zusammenfassung

In einem Interview mit Kieran Chandler diskutiert der Lokad-Gründer Joannes Vermorel die Entwicklung von Enterprise Resource Planning (ERP)-Systemen. Er verfolgt ihre Anfänge bis in die 1970er Jahre und hebt zwei Schlüsselinnovationen hervor – den Einzug relationaler Datenbanken und von Barcode-Lesern – die entscheidend für die ERP-Entwicklung waren. Er schlägt vor, dass “Enterprise Resource Management” ein zutreffenderer Begriff für diese Systeme ist, die von maßgeschneiderten Unternehmenslösungen zu vorgefertigten Darstellungen von Geschäftsmodellen herangewachsen sind. Die modernen Funktionalitäten von ERP, wie CRUD Schnittstellen und Workflow-Logik, automatisieren routinemäßige Aufgaben und verbessern die Produktivität. Vermorel untersucht die Strategien erfolgreicher ERP-Anbieter, wie SAP, zur Bewältigung der Systemkomplexität und diskutiert zudem die Auswahl und Implementierung von ERP-Systemen für Unternehmen unterschiedlicher Größen.

Erweiterte Zusammenfassung

Im Interview spricht Moderator Kieran Chandler mit Joannes Vermorel, dem Gründer von Lokad, über die Entwicklung und Funktionalität von Enterprise Resource Planning (ERP)-Systemen.

Vermorel skizziert die Ursprünge der ERP-Systeme und ordnet ihr Aufkommen den 1970er Jahren zu, obwohl der Begriff “ERP” erst in den 90ern geprägt wurde. Laut Vermorel führten zwei Schlüsselinnovationen zur Entwicklung von ERP-Systemen. Die erste war der Fortschritt der Computing-Hardware, der relationale Datenbanken erst möglich machte. Diese Datenbanken boten – wenn auch in ihren Anfängen rudimentär – eine vielseitige Methode zur Organisation von Daten. Das relationale Format, bestehend aus Tabellen und Spalten, eignete sich zur Modellierung verschiedener Geschäftsaktivitäten, einschließlich Transaktionen, Zahlungen sowie Kunden- und Lieferanteninteraktionen.

Die zweite entscheidende Innovation, die Vermorel erwähnt, ist die Erfindung von Barcode-Lesern. Obwohl Barcode-Leser bereits in den 50er Jahren erfunden wurden, konnten sie erst in den 70er Jahren, als die Computerhardware weit genug fortgeschritten war, große Datenmengen speichern und verarbeiten. Die Kombination dieser beiden Technologien führte zu den ERP-Systemen, die wir heute kennen.

Vermorel spricht auch das Fehlbenennen von ERP an und erklärt, dass es sich um einen Marketingtrick handelte, der in den 90ern entstand. Er erläutert, dass ERPs im Grunde nichts mit Planung zu tun haben, sondern vielmehr auf Management ausgerichtet sind – weshalb “Enterprise Resource Management” ein passenderer Name wäre. Er veranschaulicht dies, indem er beschreibt, wie in den frühen Phasen zahlreiche Unternehmen begannen, ihre eigenen Softwaresysteme zur Verwaltung von Ressourcen zu entwickeln – basierend auf den damals verfügbaren Datenbanken und Eingabegeräten.

Indem er Gemeinsamkeiten in den Darstellungsbedürfnissen von Unternehmen – wie Zahlungen, Beständen und Mitarbeitern – beobachtete, boten einige Firmen vorgefertigte Versionen dieser Geschäftsmodell-Darstellungen an. Vermorel weist darauf hin, dass dies der Ursprung dessen war, was wir heute als ERP-Systeme bezeichnen, wenngleich er vorschlägt, sie aufgrund ihrer tatsächlichen Funktionalität eher als Enterprise Resource Management-Systeme zu verstehen.

Die Benutzeroberflächen, die typischerweise als CRUD (Create, Read, Update, Delete)-Schnittstellen kategorisiert werden, operieren auf diesen Entitäten. Sie ermöglichen grundlegende Dateneingabeaufgaben, wie das Hinzufügen eines neuen Produkts (create), das Anzeigen der Eigenschaften eines bestehenden Produkts (read), das Ändern eines Produkts (update) und das Löschen eines Produkts (delete). Dieses CRUD-Muster gilt für jede Entität innerhalb des ERP-Systems.

Die Workflow-Logik, die dritte Komponente, ist der Bereich, in dem Automatisierung ins Spiel kommt. Vermorel gibt das Beispiel eines Einkaufsprozesses, der mit einer Bestellung beginnt, gefolgt vom Erhalt einer Rechnung des Lieferanten und schließlich dem Versand der Waren durch diesen. Das ERP-System verfolgt diese Schritte und warnt den Benutzer, falls etwas fehlt. Stimmen die empfangenen Mengen nicht mit der Bestellung überein, schlägt das System nächste Schritte vor, etwa den Lieferanten zu kontaktieren, um den Rest zu senden, oder die Waren zurückzusenden. Diese Automatisierung routinemäßiger Aufgaben führt zu einer erheblichen Steigerung der Produktivität.

Im Weiteren der Entwicklung von ERP-Systemen betont Vermorel die Rolle der Anbieter bei der Gestaltung dieser Systeme. Er stellt fest, dass die größte Herausforderung für Anbieter darin besteht, die Komplexität zu managen, da sie einen endlosen Strom von Entitäten, Benutzeroberflächen und Logik implementieren müssen. Er verweist auf eine “dreifache” Strategie, die erfolgreiche ERP-Anbieter nutzen, um diese Komplexität zu bewältigen und konkurrenzfähig zu bleiben.

Zunächst übernehmen Anbieter spezifische Technologien, um die Produktion von Entitäten, Benutzeroberflächen und Logik zu optimieren. Vermorel nennt das Beispiel von SAP, einem erfolgreichen ERP-Anbieter, der seine eigene domänenspezifische Programmiersprache, ABAP, erfand, um den Implementierungsprozess zu beschleunigen.

Zweitens passen Anbieter die Struktur ihrer Angebote und Preisgestaltung an, um die Kosten und den Aufwand für die Produktion und Unterstützung der vielfältigen Entitäten widerzuspiegeln. Dies führt häufig zu einer modulbasierten Preisstruktur, bei der Entitäten in Module gruppiert werden, die aus geschäftlicher Sicht sinnvoll sind, und Kunden entsprechend der genutzten Module berechnet werden.

ERP-Systeme, die zu einem dominierenden Teil der Unternehmenssoftware geworden sind, entwickeln sich ständig weiter und passen sich an die Bedürfnisse von Unternehmen und deren komplexen Abläufen an.

Vermorel beginnt damit, die Anreize und das Geschäftsmodell der ERP-Anbieter zu erörtern. Er erklärt, dass diese Anbieter kontinuierlich dazu angereizt werden, neue Module oder Funktionen zu entwickeln, die sie ihren Kunden verkaufen können. Jede erfolgreiche Implementierung wird oft als Chance gesehen, ein zusätzliches Modul zu erstellen und zu verkaufen – was einen fortwährenden Kreislauf von Verkauf und Entwicklung erzeugt.

Das Gespräch wendet sich anschließend der Wahl zwischen verschiedenen ERP-Ansätzen zu. Vermorel schlägt vor, dass Unternehmen sich fragen sollten, ob die in ERPs eingebauten Beschränkungen aus den späten 70ern noch für ihre heutige Situation relevant sind. Er hinterfragt den Bedarf an einem einzigen, integrierten System und argumentiert, dass dieser Ansatz zu erhöhter Komplexität und einer Vielzahl von Sonderfällen führen kann. Stattdessen sollte man die Annahme überdenken, dass ein System alles leisten muss, und warnt zugleich vor zu vielen unterschiedlichen Systemen.

Im Gespräch über die Implementierung neuer ERP-Systeme spricht Vermorel die erheblichen Risiken und Kosten an, die mit der Umstellung auf ein neues System oder der Aufrüstung eines bestehenden Systems verbunden sind. Er nennt das Beispiel eines Unternehmens, das 2009 eine halbe Milliarde Euro für ein SAP-Upgrade verschwendete, und betont, dass sich die Semantik der Entitäten innerhalb eines ERP-Systems – weitgehend von den Betreibern bestimmt – oft subtil, aber signifikant zwischen den Versionen ändert, was zu zahlreichen Sonderfällen und Herausforderungen führt.

Vermorel ist der Ansicht, dass kleinere Anbieter gewisse Risiken bergen, dass es jedoch besser sei, ein Produkt mit einem engen Kern zu wählen, das der aktuellen Komplexität und Größe des Unternehmens entspricht. Er rät von übermäßigen Funktionen ab, die Prozesse stören können, und empfiehlt, ein Produkt auszuwählen, das bei Bedarf durch Integrationen ergänzt werden kann.

Die Diskussion berührt auch die angemessene ERP-Wahl für Unternehmen unterschiedlicher Größen. Vermorel schlägt vor, dass kleinere Unternehmen mit weniger als 100 Mitarbeitern sich für schmale, einfache und kosteneffektive Software-as-a-Service (SaaS)-Anwendungen entscheiden sollten. Er empfiehlt, zwei oder drei separate Apps zu verwenden, die spezifische Bedürfnisse abdecken, anstatt sich auf ein umfassendes ERP zu verlassen. Für mittelständische Unternehmen mit rund 500 Mitarbeitern rät er, ein komplexeres ERP-Produkt in Betracht zu ziehen, das eine breitere Palette typischer Geschäftsprozesse abbilden kann. Für größere Unternehmen mit tausenden von Mitarbeitern empfiehlt Vermorel hingegen, von einem monolithischen ERP-Ansatz abzusehen und stattdessen eine Divide-and-Conquer-Strategie zu verfolgen. Er rät, die Landschaft in funktionale Bereiche zu unterteilen und Lösungen zu entwickeln oder zu erwerben, die speziell auf diese Bereiche zugeschnitten sind, anstatt zu versuchen, ein einziges ERP-System zu implementieren.

Vollständiges Transkript

Kieran Chandler: Heute werden wir entdecken, wie diese Art von Unternehmenssoftware überhaupt entstand und wie Unternehmen zwischen der Vielzahl unterschiedlicher Optionen wählen können. Also, Joannes, vielleicht könnten wir damit beginnen, uns die Ursprünge von ERP-Systemen anzusehen. Wie sind sie entstanden?

Joannes Vermorel: ERP-Systeme entstanden aus zwei treibenden Kräften in den Siebzigern. Nebenbei bemerkt, wurde der Begriff ERP in den Neunzigern geprägt, aber das, was wir üblicherweise als ERP-Systeme bezeichnen, begann tatsächlich schon in den Siebzigern. Es gab zwei entscheidende Innovationen. Die eine war die Entwicklung von Datenbanksystemen. Die Computerhardware fortschritt so weit, dass relationale Datenbanken möglich wurden. Das war die erste Innovation. Die zweite Innovation waren Barcode-Leser. Wenn man diese beiden Innovationen kombiniert, erkennt man, dass relationale Datenbanken unglaublich vielseitig und gut geeignet waren, die meisten Geschäftsaktivitäten zu modellieren – etwa Zahlungen, Kunden, Lieferanten und Transaktionen. Es wurde klar, dass dieses Format bestens geeignet war, Daten aufzunehmen. Barcodes wurden in den 50er Jahren erfunden, aber bis die Hardware in den 70er Jahren weit genug vorangeschritten war, um große Datenmengen zu speichern und zu verarbeiten, hatten sie nicht die gleiche Wirkung. Dennoch waren sie bereits im Vergleich zu manueller Verarbeitung enorm. Kieran Chandler: Also, du hast es gerade angesprochen. Der Name ERP kam erst etwas später in den 90ern. ERP steht für Enterprise Resource Planning. Aber woher stammt der Name eigentlich? Warum hat man sich dafür entschieden? Joannes Vermorel: Eigentlich ist ERP eine Fehlbezeichnung. Leider war der Name mehr ein Marketing-Gimmick, das in den 90ern entstand. ERP-Systeme haben im Grunde genommen nichts mit Planung zu tun – ein besserer Name wäre Enterprise Resource Management gewesen. Was passiert ist, sobald sowohl Datenbanken als auch Barcode-Leser verfügbar waren, merkten viele Unternehmen, dass sie ein computergestütztes System zur Verwaltung all dieser Ressourcen benötigten. Sie begannen, ihre eigenen Softwareimplementierungen auf Basis der Datenbank und der damals verfügbaren Dateneingabegeräte auszurollen. Einige Unternehmen erkannten zudem, dass viele Geschäftsbereiche ähnliche Darstellungsbedürfnisse haben – zum Beispiel müssen Zahlungen, Bestände (insbesondere bei physischen Materialien) und die Lohnabrechnung der Mitarbeiter dargestellt werden. Einige Softwarefirmen dachten also: “Lassen Sie uns vorgefertigte Versionen dieser Geschäftsmodelle anbieten”, und so wurde das Konzept des ERP geboren. Heutzutage sollte man es als ERP verstehen – nicht als Enterprise Resource Planning, sondern als Enterprise Resource Management. Kieran Chandler: Also, was waren die Kernfunktionen der frühen ERP-Systeme? Joannes Vermorel: Ein ERP besteht im Wesentlichen aus drei Dingen: Entitäten, Benutzeroberflächen und Workflow-Logik. Entitäten sind Abstraktionen, die auf Tabellen aufsetzen. Wenn man beispielsweise Produkte darstellen möchte, hätte man eine Tabelle namens “products”, wobei es für unterschiedliche Attribute oder Lieferanten mehrere Tabellen geben kann. Entitäten repräsentieren übergeordnete Konzepte wie Produkte, Kunden oder Transaktionen – im Gegensatz zu den detaillierten Implementierungsaspekten, wie sie in einer Datenbank abgelegt werden. Benutzeroberflächen sind speziell für CRUD-Operationen (Create, Read, Update, Delete) konzipiert. Meistens arbeitet man bei der Bearbeitung von Entitäten mit CRUD-Schnittstellen: Man gibt neue Produkte ein, überprüft Details bestehender Produkte, ändert Produkte oder löscht sie. Dies gilt für jede Entität, wie Transaktionen, Kunden und weitere. Die dritte Komponente ist die Workflow-Logik. Nehmen wir das Beispiel des Einkaufs: Zuerst wird eine Bestellung aufgegeben, dann bestätigt der Lieferant diese mit einer Rechnung. Anschließend werden die Waren empfangen, und dieser Vorgang muss im System nachverfolgt werden. Die Workflow-Logik sorgt dafür, dass Warnmeldungen erscheinen, falls etwas fehlt, und überprüft, ob die Mengen mit der Bestellung übereinstimmen. Daraufhin kann entschieden werden, die Waren an den Lieferanten zurückzusenden oder die restlichen Artikel anzufordern. ERP automatisiert diese alltäglichen Aufgaben und steigert die Produktivität, indem es die Konsequenzen grundlegender Geschäftsprozesse verwaltet. Kieran Chandler: In der Softwarewelt – wie sehr haben sich diese Systeme im Vergleich zu den frühesten Versionen verändert? Interessant ist, dass man, um diesen Wandel zu verstehen, die Dynamiken, die den ERP-Markt antreiben, kennen muss. ERP, insbesondere die ERP-Anbieter, spielen eine bedeutende Rolle bei der Implementierung dieser Systeme, anstatt dass Unternehmen dies selbst übernehmen. Lassen Sie uns darauf eingehen: Die meisten Anbieter haben eine dreifache Strategie übernommen, die ich als Allah bezeichne. Diese Strategie war erfolgreich, um den Markt zu erobern, und heutzutage wenden die meisten erfolgreichen ERP-Anbieter diese drei Techniken an.

Joannes Vermorel: Die größte Herausforderung, der sich ERP-Anbieter gegenübersehen, ist Komplexität. Um diese Herausforderung zu meistern, müssen sie endlose Ströme von Entitäten implementieren und Benutzeroberflächen sowie Arbeitsabläufe bereitstellen, die sinnvoll sind. Der erste Weg, wettbewerbsfähiger zu sein, besteht darin, spezifische Technologien einzusetzen, die die Produktion von Entitäten, Benutzeroberflächen und Logik rationalisieren. Ein Beispiel für eine solche Technologie ist eine domänenspezifische Programmiersprache. Beispielsweise erfand der erfolgreiche ERP-Anbieter CP seine eigene domänenspezifische Programmiersprache namens ab app, was ihnen half, Entitäten, Benutzeroberflächen und Logik schneller als die Konkurrenz einzuführen.

Kieran Chandler: Interessant. Also ist der zweite Weg, die Struktur des Angebots und der Preisgestaltung anzupassen. Kannst du das näher erläutern?

Joannes Vermorel: Natürlich. Als Anbieter wird der Aufwand zur Produktion eines ERPs stark davon beeinflusst, wieviel Mühe nötig ist, um all die verschiedenen Elemente zu implementieren. Obwohl die einzelnen Bestandteile für sich genommen einfach erscheinen mögen, geht es bei ERPs darum, alltägliche Aufgaben wie die Bearbeitung von Belegen zu bewältigen. Da Anbieter zahlreiche Entitäten produzieren und unterstützen müssen, ist es sinnvoll, nicht pro Entität abzurechnen, sondern vielmehr nach Modulen. Module gruppieren verwandte Entitäten und orientieren sich an betriebswirtschaftlichen Überlegungen. Das wirft einen interessanten Punkt hinsichtlich der Preisgestaltung von ERP-Systemen auf.

Kieran Chandler: Absolut. Es gibt also einen zusätzlichen Preis für das Hinzufügen von Modulen. Wir haben zuvor das Vendor Lock-in besprochen. Stimmen die wirtschaftlichen Interessen der ERP-Anbieter mit dieser modulbasierten Preisgestaltung überein?

Joannes Vermorel: In der Tat, sobald Module eingeführt werden, bietet das einen effizienten Weg, die Preisgestaltung mit den Kosten für die Implementierung aller Funktionen in Einklang zu bringen. Gleichzeitig schafft es spezifische Anreize. Anbieter sind motiviert, weiterhin neue Module zu entwickeln, die zusätzlich zu den bestehenden verkauft werden. Das kann zu einem endlosen Kreislauf führen, in dem immer mehr Module an Kunden verkauft werden. Aber bevor wir ins Detail gehen, kommen wir zur dritten Idee.

Kieran Chandler: In Ordnung. Was ist die dritte Idee?

Joannes Vermorel: Die dritte Idee ist, dass erfolgreiche ERP-Anbieter, aufgrund der enormen Komplexität, alle feinen Details der Realität abzubilden, Wege finden, noch schneller durch Integratoren zu wachsen. Da ein Unternehmen nicht alles alleine bewältigen kann, arbeiten ERP-Anbieter mit externen Firmen zusammen, die als Integratoren bekannt sind, um die „letzte Meile“ zu übernehmen und so eine vollständige und umfassende Lösung zu gewährleisten.

Kieran Chandler: Also, Joannes, du hast vorhin erwähnt, dass Lokad eine neue Funktion für seine Kunden einführt. Könntest du uns dazu mehr erzählen?

Joannes Vermorel: Ja, in der Tat. Wir führen eine neue Funktion für unsere Kunden ein. Sie umfasst neue Entitäten, eine neue Benutzeroberfläche und neue Logik. Wir bauen ein Netzwerk von Partnern auf, die als Integratoren fungieren, um diese Funktion zu implementieren. Aus Sicht des Geschäftsmodells ist das für ERP-Anbieter interessant, weil sie so die Kosten und Risiken, die mit dieser Funktion verbunden sind, auslagern können. Es gibt eine lange Liste von Funktionen, die an Drittanbieter ausgelagert werden können.

Kieran Chandler: Also übertragen die Softwareanbieter das Risiko an die Integratoren und letztlich an ihre Kunden. Die Integratoren haben ihre eigenen Anreize, die nicht vollständig mit denen des Softwareanbieters übereinstimmen. Ist das korrekt?

Joannes Vermorel: Genau. Die Integratoren haben einen Anreiz, den Kunden ein hohes Maß an Individualisierung zu bieten, da sie für maßgeschneiderte Module mehr bezahlt bekommen als für Standardmodule. Sie können den Kunden vermitteln, dass ihr Unternehmen einzigartig ist und daher eine Lösung benötigt, die diese Einzigartigkeit widerspiegelt. Es ist eine interessante Dynamik.

Kieran Chandler: Ich verstehe. Es gibt also unterschiedliche Ansätze, die Unternehmen bei ERP-Systemen verfolgen können. Wie bestimmt man, was ein guter Ansatz und was ein schlechter ist?

Joannes Vermorel: Heutzutage muss man bei der Wahl eines ERPs hinterfragen, ob alle Zwänge, die in den 70er Jahren in ERPs eingebaut wurden, noch für die eigene Situation relevant sind. Das hängt von verschiedenen Faktoren ab. Zum Beispiel ist die Idee, alles in ein einziges System zu integrieren, oft unsinnig, da Komplexität nicht linear zunimmt. Das Hinzufügen weiterer Entitäten führt zu mehr Randfällen und zu unterschiedlichen Auffassungen, was in verschiedenen Branchen als „Produkt“ gilt.

Kieran Chandler: Also sagst du, dass wir die Annahme überdenken müssen, dass wir immer noch ein einziges System benötigen, um alles zu verwalten?

Joannes Vermorel: Genau. Diese Annahme ist nicht mehr korrekt. 100 verschiedene Systeme, die koordiniert werden müssen, sind herausfordernd, aber auch ein einziges Master-System als Allheilmittel zu betrachten, ist problematisch. Wenn man Änderungen an einem solchen System vornehmen möchte, wird es zu einem gigantischen Projekt, das jede Funktion im Unternehmen betrifft.

Kieran Chandler: Ich verstehe. Es scheint, der Übergang zu einem neuen System kann ziemlich schwierig sein. Einige Unternehmen haben kostspielige Fehlschläge erlebt, als sie versucht haben, auf neue ERP-Systeme umzusteigen. Wie praktikabel ist dieser Übergang?

Joannes Vermorel: In der Tat, der Übergang zu einem neuen ERP-System kann herausfordernd sein. Wir haben gesehen, wie Unternehmen Milliarden von Dollar verschwendet haben, während sie solche Übergänge versuchten. Es ist in der Praxis keine leichte Aufgabe.

Kieran Chandler: Im Jahr 2009 haben sie eine halbe Milliarde Euro in ein ASAP-Upgrade investiert. Es war nicht einmal eine vollständige Einführung, sondern nur ein Upgrade. Also stellt sich die Frage: Ist es schwieriger, ein ERP zu aktualisieren, als zu einem neuen zu wechseln?

Joannes Vermorel: Das ist eine sehr interessante Frage. Überraschenderweise ist das Upgrade eines ERPs in der Regel schwieriger als der Wechsel zu einem neuen. Es mag kontraintuitiv erscheinen, aber das habe ich beobachtet. Wenn man zu einem neuen ERP migriert, hat man nicht die Illusion, dass es ein mammutprojekt wird. Betrachtet man es jedoch als ein Upgrade, klingt es vielleicht einfach, aber es kann tatsächlich sehr, sehr schwierig sein.

Das Problem ist, dass beim Übergang von einer Version zur nächsten ein semantischer Wandel in den Entitäten stattfindet. Sehen Sie, ERPs dienen dazu, Entitäten abzubilden, die verschiedene Aspekte Ihres Geschäfts widerspiegeln, wie etwa Produkte. Man könnte meinen, dass die Semantik dieser Entitäten in einem ERP vom Anbieter vorgegeben wird, aber das ist nicht ganz richtig. Die endgültige Semantik einer Entität liegt im Auge des Betreibers, also der Person, die mit dem System interagiert und Dateneingaben sowie Arbeitsabläufe durchführt.

Also wird die wahre Semantik einer Entität von der Person bestimmt, die das ERP bedient. Unglücklicherweise haben ERP-Anbieter kaum Kontrolle darüber, was die Nutzer tatsächlich mit dem Produkt machen. Sie können Empfehlungen und Schulungsprogramme anbieten, aber letztlich ist es eine Herausforderung. Manche Unternehmen entscheiden sich dafür, die Semantik geringfügig anzupassen, um das ERP in ihrer speziellen Situation zum Laufen zu bringen. Nicht, weil sie Rebellen sind, sondern weil es notwendig ist, damit das ERP funktioniert.

Allerdings entsteht das Problem, wenn man zur nächsten Version übergeht. Es können zahlreiche subtile Randfälle auftreten, bei denen die Entität aufgrund neuer Entwicklungen und zahlreicher verschiedener Randfälle plötzlich nicht mehr exakt dasselbe bedeutet.

Kieran Chandler: Das ist interessant. Auf der einen Seite gibt es diese großen monolithischen Ansätze, und auf der anderen Seite kleinere, spezialisiertere ERP-Unternehmen. Wie viel Vertrauen kann man in diese kleineren Firmen setzen, die möglicherweise im nächsten Jahrzehnt nicht überleben?

Joannes Vermorel: Wenn Sie ein kleines Unternehmen sind, möchten Sie ein System, bei dem die Komplexität im Verhältnis zu Ihrer eigenen Größe sinnvoll bleibt. ERP-Produkte neigen dazu, im Laufe der Zeit immer komplexer zu werden. Wenn Sie also ein junges Unternehmen sind, vielleicht erst fünf Jahre alt, und schnell wachsen, wäre es falsch, bei einem ERP zu bleiben, das drei oder vier Jahrzehnte alt ist. Diese älteren Produkte können unglaublich komplex sein, mit Hunderten oder sogar Tausenden von Tabellen und Entitäten. Der Umgang mit solch hoher Komplexität kann überwältigend sein.

Also, mein Rat ist, jüngere ERP-Unternehmen in Betracht zu ziehen, auch wenn damit ein gewisses Risiko einhergeht. Vermeiden Sie es, sich in einem Berg aus Komplexität zu verlieren. Nach meiner über ein Jahrzehnt langen Erfahrung mit Lokad habe ich noch nie ein Unternehmen gesehen, das allein aufgrund der Wahl seines ERPs in eine dramatische Lage geraten ist. Allerdings kann die Einführung eines Produkts, das deutlich komplexer ist als Ihre Unternehmensgröße, tatsächlich nachteilig sein und Ihr Geschäft sogar ruinieren. Ich habe häufig beobachtet, dass Unternehmen Schwierigkeiten haben, weil sie Software angenommen haben, die in Bezug auf Komplexität und Funktionen einfach zu viel für sie ist.

Kieran Chandler: Es scheint, dass bei der Wahl der Software ein starker Kern und miteinander verbundene Apps entscheidend für ein wachsendes Unternehmen sind. Joannes, könntest du diese Idee näher erläutern?

Joannes Vermorel: Absolut. Das kontraintuitive Prinzip ist, dass es besser ist, etwas mit einem schmalen Kern zu haben, der Ihre derzeitige Komplexität und Größe widerspiegelt, auch wenn noch einige Funktionen fehlen. Die fehlenden Elemente können Sie immer noch durch Integration ergänzen. Andererseits kann zu viel widersprüchliche Funktionalität Probleme verursachen. Ungenutzte Funktionen tendieren dazu, Ihre Prozesse zu stören und zu verhindern, dass einfache Aufgaben erfüllt werden. Hochintegrierte Softwareprodukte machen es schwer, bestimmte Funktionen zu entfernen oder zu ändern, ohne das gesamte System zu beeinträchtigen.

Kieran Chandler: Also beseitigt die Wahl eines kleineren Produkts diese Probleme nicht vollständig?

Joannes Vermorel: Nein, das Ausmaß und die Bedeutung dieser Probleme hängen von der Komplexität und den Entitäten der Software ab. Aber auch die Größe des Unternehmens spielt eine Rolle. Für kleinere Unternehmen mit weniger als 100 Mitarbeitern ist es ratsam, eine schmale, einfache und kostengünstige Lösung wie eine SaaS-App zu wählen. Möglicherweise benötigen Sie zwei oder drei dieser Apps, um verschiedene Bereiche wie Personalwesen, Gehaltsabrechnung und inventory management abzudecken. Es ist nicht notwendig, ein einziges ERP zu haben, das alles umfasst. Stellen Sie lediglich sicher, dass diese Apps über APIs zur Datenextraktion verfügen, sodass Sie sie später bei Bedarf integrieren können.

Kieran Chandler: Das macht Sinn. Was ist mit mittelständischen Unternehmen?

Joannes Vermorel: Für mittelständische Unternehmen, etwa mit 500 Mitarbeitern, könnte ein umfassenderes ERP-Produkt in Betracht gezogen werden. Es wird komplexer sein, mit zahlreichen Tabellen und Funktionen. An diesem Punkt müssen verschiedene typische Geschäftsaspekte abgedeckt werden, und ein ERP kann diese Bedürfnisse erfüllen. Es mag ein längeres Implementierungsprojekt und einen guten Integrator erfordern, bietet aber die gewünschte Funktionalität.

Kieran Chandler: Das ist produktiver im Vergleich zu kleinen Apps, die an ihre Grenzen stoßen. Wenn man größer wird, ändert sich die Situation wieder. Wenn Sie ein großes Unternehmen sind – sagen wir, mit etwa 5.000 Mitarbeitern – dann treten in der Regel zwei Dinge in den Vordergrund. Erstens möchten Sie die Dinge aufteilen. Ein monolithisches System wird für ein großes Unternehmen einfach nicht funktionieren. Wenn Sie sich für ein monolithisches ERP entscheiden, wie es die meisten Großunternehmen tun, wird es meiner Meinung nach in den meisten Fällen hässlich, jahrelang und unglaublich kostspielig.

Joannes Vermorel: Wenn man sich anschaut, was die allerbesten Großunternehmen tun, dann implementieren sie in der Regel ziemlich maßgeschneiderte Lösungen. Und sie haben sehr gute Gründe dafür. Wenn Sie ein großes Unternehmen sind, haben Sie wahrscheinlich einen einzigartigen Wettbewerbsvorteil, der nicht trivial ist. Er ist in Ihrer großen und komplexen Organisation verankert, und vielleicht gab es auch Akquisitionen. So kann es von Anfang an eine unregelmäßige Genius-Landschaft geben. Anstatt also zu sagen: “Ich will ein ERP, das alles regelt”, was vielleicht funktionierte, als Sie nur 500 Mitarbeiter hatten, wird es sehr schwierig, wenn Sie etwa 5.000 Mitarbeiter haben. Meine Empfehlung ist also, dass Sie im Grunde das Prinzip „Teile und herrsche“ anwenden. Den Ansatz, den ich vorschlug, als Sie klein waren und nur ein paar Apps hatten, können Sie in völlig anderer Weise wiederholen, wenn Ihr Unternehmen wächst.

Also, um es auszudrücken: Ich werde die Landschaft in, sagen wir, vielleicht bis zu ein Dutzend funktionaler Bereiche aufteilen. Und in jedem Bereich werde ich entweder selbst entwickeln oder kaufen, je nachdem, ob die Anbieter, die ich finde, gut sind oder nicht. Und die größte Herausforderung, die ich größeren Unternehmen empfehlen würde, besteht darin, das Dogma zu überwinden, dass man ein einziges ERP braucht, das alles regelt. Ich glaube, das ist größtenteils… ich meine, es ist meist unsinnig. Und wenn man sich sehr wettbewerbsfähige Akteure anschaut – sagen wir Amazon, Alibaba, Rakuten, Zalando –, diese Tech-Unternehmen, die sich auch mit der physischen supply chain beschäftigen, dann stelle ich fest – und ich spreche nicht von Microsoft, das ein fast reiner, aber nicht ganz digitaler Akteur ist, da sie auch die Xbox haben, ein sehr physisches Produkt –, dass diese Unternehmen einen sehr konsequenten Divide-and-Conquer-Ansatz in ihrer Anwendungslandschaft verfolgen. Im Grunde haben diese Firmen eigentlich gar kein klassisches ERP. Sie verfügen über Listen von Produkten. Einige von ihnen kommen einem ERP näher, und die meisten haben für spezifische Teile dessen, was man normalerweise als ERP-Modul bezeichnet, sogar ihre eigenen Systeme entwickelt.

Kieran Chandler: Nun, wir müssen hier abschließen, aber vielen Dank für deine Zeit heute Morgen.

Joannes Vermorel: Danke, Kieran.

Kieran Chandler: Das ist alles für diese Woche. Bis bald.