Was ist schief gelaufen: SAP S4HANA - Ep 178

00:00:00 SAP-Fehler lösen diese eingehende Analyse aus
00:02:15 Milliardenverluste bei ERP - nur die Spitze des Eisbergs
00:06:15 Designfehler aus der Vergangenheit verfolgen moderne Systeme
00:10:20 Land Grabbing Logik hinter ERP-Ausbreitung
00:12:26 CRUD-Anwendungen und Kommerzialisierung von ERPs
00:16:30 HANA war SAPs strategischer Schwenk zu Analytics
00:20:38 Warum tabellarische Datenbanken bei Berichten versagen
00:26:23 Spaltenorientierte Datenbanken: Vor- und versteckte Kosten
00:30:21 Auf RAM zu setzen ist das gescheiterte Glücksspiel
00:34:31 Leistungsprobleme bei hybriden Datenbanken
00:40:41 Hybride Software versagt in allem
00:42:33 System der Intelligenz: ein drittes Paradigma
00:46:59 Frühe ERPs wurden fälschlicherweise als intelligent vermarktet
00:52:33 Warum S/4HANA nicht alles auf einmal sein kann
00:58:43 Googles Scheitern mit CRUD zeigt kulturelle Missverständnisse
01:05:02 Programmierbarkeit ist der Schlüssel für Entscheidungssysteme
01:10:38 Wirtschaftliches Scheitern des All-in-One-Ansatzes
01:16:30 Warum die Modernisierung von ERP so langsam und kostspielig ist
01:22:06 Entscheidungen optimieren - nicht nur Prozesse
01:27:24 Ratschläge zum Aufbau Ihrer eigenen Aufzeichnungsebene
01:34:13 Open Source und die wahren Kosten von Massentechnologie

Zusammenfassung

In einer aufschlussreichen Diskussion zwischen Conor Doherty von Lokad und CEO Joannes Vermorel gehen sie auf die finanziellen Rückschläge ein, die mit den Softwareimplementierungen von SAP verbunden sind. Vermorel erläutert die grundlegenden Probleme bei der Zusammenführung von Systemen der Aufzeichnungen, Systemen der Berichte und Systemen der Intelligenz zu einer einzigen ERP -Lösung, was zu Ineffizienzen und Konflikten führt. Sie heben die kostspieligen Misserfolge von Unternehmen wie DHL und Lidl aufgrund der fehlerhaften Strategien von SAP hervor, insbesondere der Integration von HANA. Vermorel setzt sich für spezialisierte Systeme und Open-Source-Lösungen wie PostgreSQL ein, die robuste Funktionalität zu geringeren Kosten bieten und Unternehmen von komplexen, ineffektiven Softwareamalgamationen fernhalten.

Erweiterte Zusammenfassung

Angesichts jüngster Enthüllungen über zahlreiche finanzielle Verluste im Zusammenhang mit der Implementierung von SAP-Software durch große Unternehmen setzte sich Conor Doherty, Kommunikationsdirektor bei Lokad, mit Joannes Vermorel, CEO und Gründer von Lokad, zu einer eingehenden Diskussion zusammen. Ihr Gespräch, das die Herausforderungen des Designs von Unternehmenssoftware und die Fallstricke ehrgeiziger, aber fehlerhafter SAP-Strategien umfasst, bietet eine reiche und aufschlussreiche Analyse.

Vermorel erläutert die feinen Unterschiede in den von Unternehmen verwendeten Softwaresystemen: Systeme von Aufzeichnungen, Systeme von Berichten und Systeme von Intelligenz. Das grundlegende Problem entsteht, wenn Unternehmen versuchen, diese drei verschiedenen Systeme innerhalb eines einzigen Softwarepakets zu amalgamieren, was zwangsläufig zu Konflikten und Ineffizienzen führt. Dieses Szenario wird durch die Integration von grundsätzlich inkompatiblen Elementen innerhalb seiner ERP-Lösungen, wie HANA, durch SAP exemplarisch dargestellt, was im Laufe der Zeit zu erheblichen strategischen und operativen Rückschlägen führt.

Die Beispiele für mit SAP verbundene Misserfolge sind überwältigend. Wie Conor berichtet, haben Unternehmen wie DHL, Lidl, Spar und Asda Verluste in Höhe von Hunderten von Millionen Dollar aufgrund ihrer SAP-ERP-Implementierungen gemeldet. Diese Verluste sind nur ein Bruchteil der größeren wirtschaftlichen Stagnation, die diese Organisationen während der langen Zeiträume, die den System-Upgrades gewidmet sind, erlebt haben. Vermorel weist darauf hin, dass solche Unternehmungen Modernisierungsbemühungen einfrieren und andere digitale Fortschritte ersticken, was die wahren Kosten dieser Projekte dramatisch erhöht.

Das Kernproblem, argumentiert Vermorel, geht auf wesentliche Entscheidungen zurück, die SAP vor Jahrzehnten getroffen hat. SAP konzentrierte sich ursprünglich auf Systeme von Aufzeichnungen - im Wesentlichen aufwendige elektronische Hauptbücher, die darauf abzielten, umfassende Aspekte des Unternehmensbetriebs abzudecken. Diese “Landnahme”-Strategie führte zu umfangreichen Umfängen, führte aber auch zu einer Kommerzialisierung von CRUD (Create, Read, Update, Delete) Operationen. Bis Anfang der 2000er Jahre begann ein Übergang zu Systemen von Berichten, was zu anspruchsvollen, aber umständlichen Analysetools führte.

Eine der entscheidenden Entscheidungen, die SAP traf, war die Integration von HANA, einer spaltenorientierten, im Speicher befindlichen Datenbank, die die analytischen Fähigkeiten verbessern sollte, aber als grundlegende Datenbank für Transaktionsoperationen ungeeignet war. Vermorel erläutert, wie dieser strategische Fehler weitreichende Auswirkungen hatte, die Kernprozesse verlangsamten und Leistungsprobleme schufen, die umfangreiche und kostspielige Überentwicklungen erforderten, um sie zu bewältigen.

Das Interview berührt den inhärenten Konflikt zwischen den Designanforderungen verschiedener Softwaresysteme. Systeme von Aufzeichnungen erfordern schnelle, hochintegre Transaktionsverarbeitung, während Systeme von Berichten umfangreiche Datenanalysefähigkeiten erfordern. Die Kombination dieser mit Systemen von Intelligenz, die darauf abzielen, Entscheidungen durch Programmierbarkeit zu automatisieren, kompliziert die Softwarearchitektur weiter. Dieses Dilemma wird mit dem Versuch verglichen, ein Fahrzeug zu bauen, das sowohl ein ausgezeichnetes Flugzeug als auch ein fantastisches Boot ist - ein Unterfangen, das dazu verurteilt ist, in einem unterdurchschnittlichen Hybrid zu enden.

Conor bringt die Rolle der mechanischen Sympathie bei der Auswahl von Softwarelösungen zur Sprache - im Wesentlichen das Verständnis der inhärenten Eigenschaften und Einschränkungen von Software, wie den Unterschieden zwischen tabellarischen und spaltenorientierten Datenbanken. Ein solches Grundwissen könnte Unternehmen helfen, teure Entscheidungen zu vermeiden.

Vermorels optimistischer Ton hebt das Potenzial von Open-Source-Lösungen wie PostgreSQL hervor. Er plädiert dafür, diese zugänglichen und robusten Systeme zu nutzen, da ihre bescheidenen Kosten und hohe Funktionalität einen gangbaren Weg bieten, um den Fallstricken zu entgehen, die durch die Fehltritte von SAP veranschaulicht werden.

Zusammenfassend unterstreicht die Diskussion von Vermorel und Doherty eine wesentliche Vorsicht: Während ehrgeizige Softwarelösungen versprechen, vielfältige Funktionalitäten unter einem Dach zu vereinen, führen solche Integrationen oft zu einer unnötigen Komplexität und Leistungsproblemen. Unternehmen sollten stattdessen spezialisierte Systeme in Betracht ziehen, die auf ihre spezifischen Bedürfnisse zugeschnitten sind, und von der Vielfalt der Open-Source-Angebote profitieren, die eine hohe Ingenieurskunst ohne die damit verbundenen exorbitanten Kosten bieten. Das Gespräch dient als Leitfaden für Unternehmen, um ihre digitale Transformation zu navigieren und historische Fehler zu vermeiden, die sich wirtschaftlich nachteilig ausgewirkt haben.

Vollständiges Transkript

Conor Doherty: Willkommen zurück bei Lokad. Angesichts der jüngsten Nachrichten, dass einige sehr große Unternehmen bei ihren SAP-Implementierungen sehr hohe Geldbeträge verloren haben, haben Joannes und ich beschlossen, uns hinzusetzen und zu diskutieren, was genau schief gelaufen ist. Joannes beschreibt die Herausforderungen bei der Gestaltung von Unternehmenssoftware sowie seine Perspektive auf die Unterschiede zwischen Systemen von Aufzeichnungen, Berichtssystemen und intelligenten Systemen. Wie Joannes argumentiert, wenn Unternehmen versuchen, alle drei in einem Softwarestück zu produzieren, treten Probleme auf.

Wie immer, wenn Ihnen gefällt, was Sie hören, abonnieren Sie den YouTube-Kanal und folgen Sie uns auf LinkedIn. Und damit gebe ich Ihnen das heutige Gespräch. Also Joannes, vielen Dank, dass Sie mich im Black Lodge begleiten. Ich möchte Ihnen ein wenig den Rahmen setzen.

In der Einleitung habe ich anerkannt, dass einer der Gründe, warum wir hier sind, ist, um über einige sehr große Unternehmen zu diskutieren, die sehr hohe Geldbeträge verloren haben. Nun, das ist eine sehr breite Aussage. Wie wir wirklich zu diesem Gespräch gekommen sind, war ein Beitrag, der auf LinkedIn von Anthony Miller, einem Freund des Kanals, etwas viral ging, in dem er viele ziemlich verheerende Zahlen zusammenstellte, die sich in vielen Fällen auf mehrere Milliarden Dollar Unternehmen bezogen, die Hunderte Millionen Dollar Verluste meldeten, die sie ihrer SAP-Implementierung zuschrieben.

Also, um zu zitieren oder zu paraphrasieren, sollte ich sagen, DHL hat anscheinend über 370 Millionen Dollar verloren, als sie versuchten, eine SAP- und IBM-Lösung zu implementieren. Lidl in Deutschland - bevor mich jemand in den Kommentaren korrigiert, es ist Lidl in Irland, es ist Lidl auf dem Kontinent, aber es ist Lidl in Irland - sie haben ihre Verluste nach Ausgaben von einer halben Milliarde Euro eingedämmt. Also haben sie nach einer halben Milliarde Euro den Stecker gezogen.

SPAR, die niederländische Kette, behauptete, aufgrund ihrer SAP-Implementierung 109 Millionen Dollar Umsatzverluste erlitten zu haben. Also eine Folge der Implementierung. Und ASDA meldete 25,5 Millionen Dollar an Lagerinkonsistenzen zwischen ihrem SAP-ERP und ihrem WMS. Auch hier gibt es andere, aber der Punkt hier ist zu sagen, dass es über eine Milliarde Dollar oder Euro an Verlusten sind. Also reden wir hier nicht von Kleingeld.

Also komme ich zur Frage: Joannes, was läuft genau schief bei diesen riesigen Unternehmen und ihren SAP-Implementierungen?

Joannes Vermorel: Und offensichtlich ist das gemeinsame Merkmal all dieser Probleme die Auswahl des falschen Anbieters, SAP. Aber, ähm, aber auch, ich denke leider, dass diese Zahlen nur die Spitze des Eisbergs sind. Tatsächlich ist meine eigene oberflächliche Beobachtung, dass die Verluste um Größenordnungen höher sind und dies sind nur diejenigen, die die Leute anerkennen. Ich meine, und sie erkennen die realen Kosten nicht wirklich an.

Sie erkennen nur, zum Beispiel, an, dass sie Geld für etwas bezahlt haben, das nicht funktioniert hat. Was sie nicht anerkennen, ist, dass der Prozess in vielen Fällen viele Jahre gedauert hat. Tatsächlich war das Unternehmen für ein halbes Jahrzehnt, manchmal ein Jahrzehnt, eingefroren, wo sie nichts tun konnten, außer sich auf das ERP-Upgrade zu konzentrieren.

Also, Sie sehen, das bedeutet, dass Sie nicht nur Hunderte Millionen verschwendet haben, sondern tatsächlich ist das nur eine Kleinigkeit, denn was Sie effektiv getan haben, war, alle Modernisierungen, die Digitalisierung, die laufende Transformation, die Sie sonst hätten vornehmen können, zu pausieren, weil Sie sich um Ihre ERP-Upgrades kümmern mussten. Und ich habe das viele Male gesehen, wo Unternehmen einen mehrjährigen Prozess durchlaufen, bei dem sie alles für dieses Ereignis pausieren. Die Kosten sind absolut gigantisch.

Das bedeutet, dass nicht nur Hunderte Millionen verschwendet wurden, sondern tatsächlich ist das nur eine Kleinigkeit, denn was Sie effektiv getan haben, war, alle Modernisierungen, die Digitalisierung, die laufende Transformation, die Sie sonst hätten vornehmen können, zu pausieren, weil Sie sich um Ihre ERP-Upgrades kümmern mussten. Und ich habe das viele Male gesehen, wo Unternehmen einen mehrjährigen Prozess durchlaufen, bei dem sie alles für dieses Ereignis pausieren. Die Kosten sind absolut gigantisch.

Ich meine, es ist offensichtlich ein Zeugnis für die Qualität dieser Unternehmen, dass sie diesen Prozess überleben, denn, seien wir realistisch, zum Beispiel in der Softwarebranche würde jeder, der seine eigene Entwicklung für ein halbes Jahrzehnt pausiert, einfach tot sein. Ich meine, sie würden durch Dinge ersetzt werden, die drei Generationen von Technologien über ihnen liegen. Also, Anerkennung an diese Unternehmen, dass sie überleben. Das bedeutet, dass sie ihr Spiel absolut beherrschen, um so lange mit einem solch dysfunktionalen Prozess zu überleben.

Die Realität ist, dass der Ausblick absolut schrecklich ist. Und wenn wir hinter dieses gemeinsame Merkmal gehen und die Ursache untersuchen wollen, denn die Schuld auf SAP zu schieben, erhellt den Fall nicht, denke ich, dass die Ursache eine Reihe von Fehlern ist, die vor langer Zeit begangen wurden, buchstäblich Jahrzehnte zurück.

Conor Doherty: Geschäftsentscheidungen oder meinen Sie Softwarefehler? Wenn Sie von Fehlern sprechen, was meinen Sie?

Joannes Vermorel: Ich meine, strategische Designfehler von Personen bei SAP, die vor Jahrzehnten begangen wurden. Diese Fehler lassen sich auf Fehler zurückführen, die vor Jahrzehnten gemacht wurden. Und das ist interessant, denn wenn Sie diese Fehler analysieren, wird es das Schuldspiel sein: “Der Integrator war nicht gut” oder “Das Change Management wurde im Unternehmen nicht korrekt durchgeführt” oder “Die IT-Abteilung des Unternehmens war nicht auf dem Niveau, auf dem sie sein sollte” oder dies oder das oder jenes oder jenes. Sie wissen schon, Ausreden, Ausreden, Ausreden.

Tatsächlich sieht jeder einzelne Fehler irgendwie einzigartig aus, weil es jedes Mal ein sehr spezifisches Durcheinander ist. Aber auch diese sind keine zufriedenstellenden Erklärungen. Ich denke, wenn Sie wirklich verstehen wollen, warum all diese Probleme entstehen, ist es wirklich etwas sehr Spezifisches für diese großen Unternehmenssoftwareanbieter. Es gibt klare Ursachen, die auf Entscheidungen zurückzuführen sind, die vor Jahrzehnten getroffen wurden. Jetzt sehen wir nur die Konsequenzen entfalten.

Das Publikum mag nicht erkennen, aber wenn Sie ein Softwareunternehmen betreiben, müssen Sie sehr lange, möglicherweise für immer, mit Ihren Sünden, mit Ihren vergangenen Fehlern leben. Und das ist sehr seltsam, denn man würde denken, dass Software vollständig veränderbar ist, dass Sie alles ändern können, was Sie getan haben. Die Realität ist anders.

Zurück zum Unterschied, normalerweise, wenn es um architektonische Entscheidungen geht, wenn Sie Fehler machen, können Sie auf unbestimmte Zeit damit stecken bleiben. Und diese Fehler kommen einfach immer wieder und verfolgen Sie für immer, und sie vergiften alles, was Sie tun. Die Leute sehen die Symptome - all die Probleme - aber verfolgen sie nicht unbedingt bis zur Wurzel, die häufig so alt ist, dass die Leute sie nicht sehen.

Conor Doherty: Nun, SAP ist ein riesiges Unternehmen, das seit mehr als 50 Jahren besteht. Wenn Sie also über Ursachen und strategische Designentscheidungen von vor Jahrzehnten sprechen und diese Fehler im Jahr 2025 immer noch mit sich herumtragen, sind das ziemlich extreme Behauptungen, die außergewöhnliche Beweise erfordern. Können Sie mir ein Beispiel dafür geben, was eine strategische Designentscheidung aus den 1970er Jahren sein könnte, die ein SAP-ERP im Jahr 2025 verfolgt?

Joannes Vermorel: Also, SAP begann Ende der 70er Jahre und sie sind das, was ich als Systeme der Aufzeichnung bezeichne. Das ist das, was die Leute ERP, CRM, WMS nennen, all diese Softwarestücke, die im Wesentlichen das elektronische Gegenstück zu dem darstellen, was im Unternehmen passiert. Diese Aufzeichnungssysteme, da gibt es keine Intelligenz; sie sind, würde ich sagen, schicke Bücher. Wenn wir in die Vergangenheit zurückgehen, waren die Anbieter, die Erfolg hatten, diejenigen, die das meiste Land eroberten.

Was meine ich mit Landgewinnung? Wenn Sie anfangen, Bestände zu verwalten, müssen Sie Mitarbeiter verwalten, dann müssen Sie Bestellungen, Zahlungen, Beschaffungen, Kunden, Lieferanten, Partner usw. verwalten. Die Idee ist, dass Sie das Land erobern müssen, um eine vollständige Abdeckung zu haben - eine Abdeckung, die so umfassend wie möglich für Ihre Aufzeichnungen ist. Wenn wir in die Vergangenheit zurückgehen, sagen wir in die 80er Jahre, fand dieser Wettbewerb um die Landgewinnung statt. Die Realität war, dass für jedes Unternehmen, das anfing, einen dominierenden Anbieter zu übernehmen (damals könnte es SAP, Oracle oder IBM sein), ein Gewinner-alles-Prinzip innerhalb des Unternehmens herrschte.

Sie sind ein Kundenunternehmen, Sie betreiben Software von einem Anbieter, sobald Sie mit diesem Anbieter zu tun haben, werden Sie praktisch Ihr gesamtes Geschäft diesem Anbieter zuwenden. Warum? Weil zu dieser Zeit die verteilte Softwareentwicklung absolut war. Das bedeutete, dass, wenn nicht alles softwaremäßig im gleichen Mainframe lebte, waren Sie erledigt. Theoretisch könnte man Netzwerke aufbauen (wir sind in den 80ern) und einige Banken taten das damals, aber es war einfach extrem kompliziert, extrem teuer.

Realistisch gesehen war die einzige wirtschaftlich tragfähige Lösung, um Bestände und Lieferanten zu verwalten und die Punkte zu verbinden, all das in dasselbe System zu stecken. Ein Anbieter musste also alles abdecken, um zu gewinnen. Das ist es letztendlich, was die Anbieter erfolgreich gemacht hat - diejenigen, die das entwickeln würden, was ERP und CRM genannt wird. Diese großen Megensysteme waren diejenigen, die erfolgreich waren, mit massiver Abdeckung. Was bedeutet das? Es bedeutet, dass Sie so viel Land wie möglich abdecken müssen und letztendlich alles berühren.

Nun, das schafft nicht viel Anreiz für hyperkonsistenz, Hyperintegrität. Es geht wirklich darum, so viel Land wie möglich so schnell wie möglich zu erobern. Im Prozess erkannten große Unternehmen, dass CRUD (Create, Read, Update, Delete)-Apps vollständige Waren sind. Im Zuge dessen erkannte die Softwarebranche, dass dieser Prozess eine vollständige Ware ist. Wenn Sie ein Aufzeichnungssystem, eine CRUD-App haben möchten, ist das sehr einfach.

Sie benötigen eine relationale Datenbank und ein Framework, um eine Reihe von Ansichten für jede Entität bereitzustellen, die eine Benutzeroberfläche bietet, um CRUD-Operationen für alle Entitäten auszuführen. Sie können einen Kunden erstellen, aktualisieren, löschen usw. Sie können das für Kunden, Lieferanten, Rechnungen usw. tun. Sehr schnell erkannten diese Anbieter, dass dieses Ding einfach eine vollständige Ware ist. Die Phase der Landgewinnung endet praktisch in den 2000er Jahren. Bis 2000 war nicht alles abgedeckt - es gab neue Bereiche, die entstanden, zum Beispiel E-Commerce.

Zu dieser Zeit war es nicht da; das mussten Sie hinzufügen. Es gibt ständig neue Dinge, aber der größte Teil der Landgewinnung war abgedeckt, was ein Problem ist. Anbieter wie SAP sahen, dass die Kommerzialisierung sehr stark aufkam. Diese Aufzeichnungssysteme sind einfach und sollten spottbillig sein - spottbillig. Also, wie wollen Sie Ihre Gewinne und Margen aufrechterhalten, wenn Sie eine Technologie verkaufen, die eine vollständige Ware ist?

Das ist, wo sie ein Silberstreif am Horizont sahen: Berichtssysteme. In den mittleren 90er Jahren tauchte ein Unternehmen namens Business Objects auf und schuf den ersten groß angelegten Erfolg beim Verkauf von OLAP (Online Analytical Processing) -Technologie - ein Berichtssystem. Dies war ein großer Erfolg. Business Objects wurde 2006 oder 2007 von SAP übernommen. Die Leute erkannten, dass der Wert vielleicht mehr in den Berichtssystemen liegt. Zu dieser Zeit schien es schick zu sein.

Offensichtlich, im Gegensatz zu elektronischen Aufzeichnungen, bei denen, sobald Sie alles über Ihre Kunden in der Datenbank wissen, Ihr Wert irgendwie begrenzt ist. Sie sollen elektronische Gegenstücke für das Geschäft bereitstellen. Wenn Sie eine zufriedenstellende elektronische Darstellung des Unternehmens haben, gibt es nicht viel hinzuzufügen. Es gibt nur so viele Dinge, die Sie hinzufügen können, um ein Produkt in Ihrer Datenbank zu beschreiben, einen Kunden usw. Letztendlich gibt es diesen Drang zur Analytik. SAP erkannte das und beschloss, ab 2010 mit HANA voll einzusteigen.

Das wäre für mich der Kern der meisten Probleme heute. Ich denke, das kommt von dieser Entscheidung für HANA. Wenn wir zu dieser Entscheidung zurückkehren, hatte SAP damals immer noch ein strategisches Problem: seine Abhängigkeit von Datenbanken von Drittanbietern. In den 2000er Jahren verließen sie sich hauptsächlich auf Oracle-Datenbanken, ein wenig auf Microsoft und IBM DB2, aber hauptsächlich auf Oracle. Das bedeutete, dass das ERP zu dieser Zeit, SAP ECC und all ihre Suiten (mit vielen Produkten und Übernahmen), von einer Datenbank eines Drittanbieters abhängig waren.

Das war ein Problem, weil ein großer Teil des Werts an ein anderes Softwareunternehmen ging. Aufgrund der Kommerzialisierung war es problematisch, um einen schrumpfenden Markt zu konkurrieren. SAP beschloss, seine eigene Datenbankebene herauszubringen, unter dem Codenamen HANA. Sie sahen klar, dass sie stark in diese analytische Richtung drängen wollten, und strebten nach einem System, das spaltenorientiert und im Speicher ist. Diese Entscheidung allein, zurück im Jahr 2010, entfaltete den Fehler.

Das ERP S4 wurde erst 2015 veröffentlicht. Sobald sie ihr neues Datenbanksystem haben, benötigen sie einige Jahre, um ihre eigene ERP-Technologie auf Basis dieser neuen Datenbank neu aufzubauen. Aber wenn wir in der Zeit zurückgehen, denke ich, dass der Kern des Fehlers, der sich jetzt entfaltet, auf HANA zurückgeführt werden kann. Jetzt müssen wir ein wenig mehr verstehen. Das ist ein wenig komplizierter, also werde ich vielleicht etwas Zeit brauchen, um zu erklären, was hier vor sich geht.

Für ein Aufzeichnungssystem benötigen Sie eine tabellarische Datenbank - das heißt, eine traditionelle Datenbank. Was ist also eine tabellarische Datenbank? Das ist eine Datenbank, in der die Daten zeilenweise organisiert sind. Das ist eine Sache, die Sie bei Computersystemen im Kopf behalten müssen: Die Lokalität des Verweises ist für die Leistung äußerst wichtig. Das bedeutet, dass, wenn Sie auf eine Datensammlung zugreifen möchten, wenn Sie Leistung haben möchten, sollten sich alle diese Daten an einem Ort im System befinden, am selben Ort.

Angenommen, Sie möchten einen Lieferanten aktualisieren. Der Lieferant hat viele Informationen - seinen Namen, seinen Standort, seine Zertifizierung, dies, das. Ich meine, Sie können sich alle Attribute der Lieferantenentität in Ihrem System vorstellen. Es wird eine Tabelle sein. Es wird vielleicht eine Tabelle namens “Lieferanten” geben, und diese Tabelle wird Dutzende, möglicherweise hunderte, Spalten haben. Wenn Sie Ihre Datenbank in tabellarischer Form organisieren, bedeutet das, dass, wenn Sie einen Lieferanten auswählen, der Lieferant angezeigt wird.

Aber sie sind völlig unbrauchbar, wenn es um Analytik geht. Das ist ein Problem. Das ist die Unbrauchbarkeit dieser tabellarischen Datenbanken. Es ist der Hauptgrund, warum Geschäftsobjekte, wissen Sie, das eine und all diese BI, Business Intelligence -Tools, überhaupt erfolgreich waren. Es liegt daran, dass sie in den 90er Jahren begonnen haben, das zu bieten, was als OLAP bezeichnet wird, das sind Würfel, Hyperwürfel, die neben der Datenbank existieren und viel bequemer sind, um Analysen bereitzustellen.

Und warum ist das so? Ich meine, denken Sie nur darüber nach. Wenn Sie beispielsweise eine Tabelle haben, die Bestellungen sind, und die Tabelle Bestellungen hat, sagen wir, eine Spalte, die der Betrag ausgedrückt ist, sagen wir der Einfachheit halber, in Dollar. Aber die Tabelle Bestellungen hat sonst wie 100 Spalten. Jetzt möchten Sie berechnen, wie viel Umsatz in Dollar Sie im letzten Jahr hatten. Die Realität ist, dass, wenn Sie diesen Umsatz für das letzte Jahr berechnen möchten, der einfach eine Summe der Spalte, wissen Sie, Beträge ist, werden Sie in der Lage sein, wenn Sie eine tabellarische Datenbank haben, praktisch die gesamte Tabelle zu durchsuchen. Ihr System wird jede einzelne Zeile durchgehen, aber als Ergebnis wird es nicht in der Lage sein, die Betragsspalte herauszufiltern, weil sie sich komplett in der Mitte aller anderen befindet.

Um also diese Addition dieser einen Spalte zu berechnen, schauen Sie sich die gesamte Tabelle an, was möglicherweise hundertmal mehr Informationen ist als die eine Zahl, die Sie für jede Zeile möchten, was das System massiv verlangsamt. Nun, es gibt eine Lösung, und das ist, die Datenbank entlang eines spaltenbasierten Setups zu organisieren. Was bedeutet das? Dass Sie die Daten nicht zeilenweise gruppieren oder packen, sondern spaltenweise.

Plötzlich, wenn Sie eine Spalte auswählen und eine Operation wie “Ich möchte alles in dieser Spalte summieren” durchführen möchten, wird dies super schnell, weil Sie Zugriff auf diese Spalte isoliert haben. Sie müssen nicht die Auftrags-ID, die Kunden-ID, die Produkt-ID und all die anderen Spalten haben, die Sie in der Tabelle Bestellungen finden würden. Sie werden die eine Spalte herausfiltern, die Sie möchten. Gleiches gilt, wenn Sie eine Auswahl für ein Datum treffen möchten, Sie können die Datums-Spalte auswählen und einfach Ihren Filter anwenden.

Es wird um Größenordnungen effizienter sein. Das ist sehr cool. Also, und übrigens, dieses spaltenbasierte Setup ist historisch gesehen, wissen Sie, als die Leute begannen, Unternehmensanalysen durchzuführen, begannen sie mit Hyperwürfeln, diesen OLAP-Technologien. Aber sehr schnell, gegen Ende der 2000er Jahre, hatten die Leute erkannt, dass spaltenbasierte Datenbanken einfach besser waren. Es gab also eine Phase in Bezug auf Technologie, in der Geschäftsobjekte mit Hyperwürfeln umgingen, und die Technologie verwandelte sich sehr schnell in eine überlegene Version davon, die spaltenbasierte Datenbanken waren.

Okay, jetzt sind spaltenbasierte Datenbanken für Analysen viel besser. Also für all diese Berichtssysteme ist das fantastische Nachrichten. Wir haben etwas, das für das Publikum viel besser ist. Übrigens wäre eine spaltenbasierte Datenbank beispielsweise Spark, eine Open-Source-Implementierung, die eine spaltenbasierte Datenbank bereitstellt.

Das ist unglaubliche Skalierbarkeit, mit der umgegangen werden muss, und das ist sehr, sehr effizient in Bezug auf Leistung. Das bedeutet jedoch nicht, dass diese Sache ohne einen Kompromiss kommt. Der Kompromiss besteht darin, dass eine spaltenbasierte Datenbank für ein System von Aufzeichnungen völlig unbrauchbar ist. Das heißt, von Grund auf ist das auf zwei Ebenen. Erstens, wenn Sie Ihre Daten in Spalten organisieren, dann berühren Sie bei jedem Update einer Zeile viele Spalten. Sie müssen die richtige Position in jeder Spalte identifizieren, und wenn Sie 100 Spalten haben, bedeutet das, dass Sie 100 verschiedene Stellen in Ihrem System haben, die aktualisiert werden müssen.

Früher konnten Sie mit Ihrer tabellarischen Datenbank einfach ein Update durchführen; es wäre nur lokal. Aber hier sind Ihre Daten in Spalten organisiert. Wenn Sie also einen Datensatz aktualisieren möchten, wird er über viele Spalten verteilt. Es wird um Größenordnungen weniger effizient sein. Auch hier gibt es kein kostenloses Mittagessen. Entweder organisieren Sie Ihre Daten als tabellarisches System, und das ist großartig für Aufzeichnungssysteme, oder Sie verwenden spaltenbasierte Datenbanken, und das ist großartig für Berichtssysteme. Sie können es nicht auf beide Arten haben.

SAP entschied sich voll und ganz für HANA, eine spaltenbasierte Datenbank. Ich denke, dass allein diese Entscheidung das Schicksal von allem besiegelte, was sie als Grundlage taten, nämlich die Aufzeichnungssysteme.

Conor Doherty: Okay, nur um hier einzuspringen, weil das viel war, was behandelt wurde, das war gut, danke. Aber nur für den Fall, dass sich jemand, der das jetzt hört, fragen könnte: “Meinen Sie ernsthaft, dass DHL und Spar und Asda insgesamt eine Milliarde Dollar an Inventar oder nur Geld verloren haben, weil sie versucht haben, nur aufgrund von spalten- gegen tabellenanalytischen Fehlern zu implementieren? Das ist die Wurzel des Problems. Wird das behauptet?”

Joannes Vermorel: In großem Maße ja. Ich meine…

Conor Doherty: Beweisen Sie das für mich.

Joannes Vermorel: Ja, das Ding ist, wenn Sie kritische architektonische Fehler haben, neigen sie dazu, außer Kontrolle zu geraten und Tausende von Nebenwirkungen zu verursachen. Es liegt nicht daran, dass etwas super chaotisch und komplex ist, dass die Wurzelursache selbst etwas sehr Kompliziertes und Chaotisches ist. Ein Beispiel wäre die Rotation der Erde. Die Erde hat im Vergleich zur Sonne eine Neigung ihrer Achse, was ein super kompliziertes System von Jahreszeiten mit heißen und kalten Perioden, Winden und Tonnen von Dingen verursacht, die nur eine Folge dieser einfachen Neigung sind.

Sie können also eine Wurzelursache haben, die extrem einfach ist, aber wenn Sie sich die Konsequenzen ansehen, sind sie unglaublich komplex und vielfältig, und dennoch kann sie auf etwas sehr Einfaches zurückgeführt werden.

Conor Doherty: Ich stimme zu, und das ist ein schönes astronomisches Beispiel.

Joannes Vermorel: Hier bedeutet das, dass sie durch eine Entscheidung, die positiv für ihre Analytik, aber nachteilig für ihr Aufzeichnungssystem ist, ein System geschaffen haben, das unglaublich träge ist. Hier können wir auch die Art von Wagnis sehen, das SAP 2010 eingegangen ist. Sie haben es nicht nur spaltenbasiert gemacht; sie haben es auch im Speicher gemacht. Das war ein weiterer Fehler. Die Idee, es im Speicher zu machen, bedeutet, dass sie gesagt haben, dass alle Daten im DRAM leben werden, im Wesentlichen dem RAM, den Sie für Server haben.

Die Denkweise damals war, dass DRAM im Laufe der Zeit unvorstellbar billig und viel schneller werden würde, was schön wäre. Softwareunternehmen neigen dazu zu sagen: “Wir haben jetzt ein Leistungsproblem, aber wenn wir die richtigen Entscheidungen treffen, wird der Fortschritt der Hardwareindustrie dieses Problem für uns in Zukunft aufheben.” Sie glauben, dass, wenn die Rechenhardware hundertmal schneller oder besser entlang der richtigen Richtung wird, dann jedes Leistungsproblem, das sie jetzt haben, innerhalb weniger Jahre verschwunden sein könnte.

Microsoft war lange dafür berüchtigt. Sie würden Software veröffentlichen, die auf keiner Maschine richtig funktionieren würde, dann, einige Jahre später, lief alles schneller und die Software würde einwandfrei laufen. Das Problem ist, dass sich seit 2010 der RAM in einem Jahrzehnt und einem halben kaum weiterentwickelt hat. Er hat sich weiterentwickelt, aber im Vergleich zu allem anderen nur wenig, insbesondere im Vergleich zu anderen Formen der Datenspeicherung wie SSDs.

Der RAM hat sich in Bezug auf Kosten, Geschwindigkeit, Latenz und alles andere kaum bewegt, aber Solid-State-Laufwerke (SSDs) haben sich im gleichen Zeitraum um das Tausendfache verbessert. Also setzten sie alles darauf, dass sich diese Technologie um Größenordnungen verbessern würde, aber das tat sie nicht, und höchstwahrscheinlich wird sie aus vielen Gründen auch in Zukunft nicht. Andere Dinge entwickeln sich in der Informatik wie verrückt.

Die Grafikkarten, die für KI verwendeten GPUs, entwickeln sich enorm. Ich meine, es gibt viele andere Bereiche, die sich enorm entwickeln, aber dieser nicht. Und das Problem war, dass das eine Opfer, das Sie bringen, wenn Sie Ihre Datenbank nutzen, indem Sie sie spaltenbasiert machen, um ein Aufzeichnungssystem auszuführen, ist, dass Ihre Latenz einfach schrecklich sein wird.

Die Dinge werden im Grunde genommen langsam sein. Und das war bereits ein Problem mit dem Flaschenhals im tabellarischen Design. Das war bereits ein Problem, aber hier machen Sie es viel, viel schlimmer. Das bedeutet, dass Sie als Konsequenz ständig damit beschäftigt sein werden, alle Probleme zu bekämpfen, die durch Ihre falsche Architektur verursacht wurden.

Conor Doherty: Nun, das stellt den perfekten Übergang dar, denn ich war gerade dabei, Ihnen die Worte aus dem Mund zu nehmen. Wenn Sie einfach das anwenden, was Sie gerade beschrieben haben - das Aufzeichnungssystem und das Berichtssystem - das Aufzeichnungssystem, Ihr ERP, in einem konkreten Anwendungsfall scannen Sie Barcodes und das System wird aktualisiert, sodass Sie jederzeit wissen, wie viel von einem Ding Sie in Ihrem Lager haben oder wie viel Sie im Geschäft haben. Okay, cool. Das erfordert vermutlich eine ziemlich geringe Latenz, würde ich annehmen?

Joannes Vermorel: Absolut.

Conor Doherty: Okay, cool. Und was ist mit der Designstruktur für dieses Aufzeichnungssystem bedeutet das oder geht es auf Kosten eines guten Berichtssystems, das im Wesentlichen nur für Geschäftsberichtszwecke ist. Wo ist der Konflikt? Denn Sie sagen mir, es gibt einen Konflikt, aber ich verstehe es in Bezug auf… Sie möchten, dass das System, dass Ihr rationaler Kern hyper-schnell ist, wenn es darum geht, den Barcode zu scannen. Sie scannen den Barcode und es piept, das Ding wird bestätigt, alles ist in Ordnung. Der Barcode existiert in Ihrem System. Alles. Das ist der Piepton, den Sie bekommen - das System bestätigt, dass alles erfasst ist. Wir sind gut. Gehen Sie voran. Perfekt.

Joannes Vermorel: Nun, das Problem ist, wenn Sie sich zuerst für ein spaltenbasiertes Setup entscheiden, wird dieser eine Vorgang, der nur bestätigt, dass Sie gerade etwas gescannt haben, per Definition viel langsamer sein, weil es Dutzende von Informationen gibt, die die Punkte mit vielen Spalten verbinden müssen, die in Ihrem System getrennt sind.

Deshalb haben Sie als erste Hürde, dass es viel schwieriger ist, ein so schnelles System zu haben, weil spaltenbasierte Datenbanken großartig für groß angelegte Analysen sind. Sie sind nicht schnell. Es gibt nichts in diesen Datenbanken, das wirklich für geringe Latenzen ausgelegt ist. Dafür wurden sie nicht entworfen. Das Design selbst ist irgendwie antagonistisch dazu.

Das Problem wird nun durch eine weitere Sache verschärft, nämlich dass Sie angeben, dass Ihre Datenbankebene genau die gleiche sein wird, die Sie für Ihr Aufzeichnungssystem verwenden. Also die Dinge, die Ihr Inventar verwalten, die Mitarbeiter, die ein- und ausstempeln, alles, wo Sie absolute Präzision wollen. Und Sie möchten auch eine extrem schnelle Reaktion, wenn jemand einstempelt und sich ausweist.

Sie möchten nicht, dass das System sagt “Geben Sie mir 20 Sekunden, während ich herausfinde, ob Sie tatsächlich ein Mitarbeiter sind und ob Sie heute tatsächlich einsteigen können.” Nein! Sie möchten, dass das sofort super schnell geht. Ausweis, Piepton, sofort! Ansonsten verlangsamt sich alles irgendwie.

Nun ist das Problem, dass das genau gleiche System, weil Sie es als spaltenbasierte Datenbank konzipiert haben mit dem ausdrücklichen Ziel, Analysen durchzuführen. Dann - das Aufzeichnungssystem für das Berichtssystem - ja. Was passiert ist, dass die Leute Berichte erstellen werden. Sie sagen: “Okay, wir haben dieses System, das buchstäblich so konzipiert ist, dass wir ausgefallene Analysen durchführen können. Lassen Sie uns ausgefallene Analysen durchführen!”

Aber was sind die Konsequenzen ausgefallener Analysen? Die Konsequenz ist, dass Sie Operationen durchführen, bei denen Sie sehr große Datenmengen verarbeiten müssen. Und das ist völlig konträr zu geringen Latenzen. Sie haben diesen Datenbankkern, der von allen Prozessen gemeinsam genutzt wird. Er muss geteilt werden, denn sonst haben Sie keine Integrität. Die Leute haben nicht die gleiche Vorstellung davon, was der aktuelle Lagerbestand ist.

Wenn Sie nicht die gleiche Vorstellung davon haben, was der Lagerbestand ist, bedeutet das, dass jemand auf der Website eine Einheit bestellen kann, die Sie nicht haben, weil jemand anderes diese Einheit bereits ausgewählt hat und es Verzögerungen bei der Verbreitung dieser Informationen gab. Der E-Commerce glaubt, dass noch eine Einheit übrig ist, wenn keine mehr da ist. Das ist ein großes Durcheinander!

Sie müssen also diese Integrität haben, damit Sie nicht mit vielen dummen Problemen enden. Jetzt wird Ihre relationale Datenbankressource zwischen Dingen geteilt, die sehr leicht sind und super schnell sein müssen, und Dingen, die super schwer sind - Ihre Berichte, in denen Sie sagen “Analysieren Sie alle Kunden, die letztes Jahr pro Kategorie mehr als drei Einkäufe getätigt haben” und so weiter.

Sie haben Anfragen, die rechenintensiv sind und einen beträchtlichen Teil aller Daten durchlaufen, die Sie haben. Das ist der Konflikt. Das ist der ganze Sinn von Analysen. Analysen bedeuten nicht, dieses SKU oder diesen Kunden abzurufen. Analysen bedeuten, jeden einzelnen Kunden zu scannen, um Statistiken zu diesem und jenem zu haben.

Ich werde meine gesamte Verkaufshistorie der letzten Jahre durchsuchen, um Trends zu analysieren. Sie haben also die gleichen Systeme, in denen Sie viele Operationen haben, die sehr ressourcenintensiv sind. Und wie mildern Sie wiederum die Tatsache ab, dass es Ihre Latenz vollständig beeinträchtigt?

Ich meine, die Antwort ist, dass Sie Hardware auf das Problem werfen. Welche Art von Hardware müssen Sie auf das Problem werfen? Nun, Sie müssen Speicher werfen, weil Sie sich 2010 dafür entschieden haben, dass es sich um ein spaltenbasiertes In-Memory-System handeln würde. Pech gehabt!

Wenn die Welt eine andere Richtung eingeschlagen hätte, wenn DRAM tausendmal billiger und schneller geworden wäre, wäre das die perfekte Wahl. Aber das ist nicht passiert und höchstwahrscheinlich wird es auch nicht passieren. Ich meine, diese Technologie - DRAM - entwickelt sich immer noch weiter, aber nirgendwo so schnell wie die meisten anderen Technologien in der Computerhardware.

Es ist eine der Technologien, die sich am langsamsten entwickelt, insbesondere bei der Latenz, wo sie seit fast zwei Jahrzehnten kaum Fortschritte gemacht hat. Es gibt sogar Klassen von Dingen, insbesondere auf der Latenzseite, bei denen Sie in absehbarer Zeit keine Verbesserung erwarten sollten.

Es wird viele Verbesserungen geben, aber nicht auf dieser Ebene. Also Leute, die alles auf eine Karte gesetzt haben - wie beim Pokern und alles auf eine Karte setzen - aber ihre Karten sind überhaupt nicht gut. Das ist so ziemlich das, was 2010 passiert ist. Und wir sehen die Konsequenzen heute auf sehr vielfältige Weise.

Conor Doherty: Noch einmal, ich möchte versuchen, so viel wie möglich davon zusammenzufassen. Korrigieren Sie mich, wenn ich falsch liege. Die Designentscheidungen, die man trifft, um in der ersten Klasse von Software - Unternehmenssoftware, die Sie als Systeme des Berichts beschreiben - herausragend zu sein, stehen im Widerspruch zu den Designentscheidungen, die Sie treffen würden, wenn Sie in einem analytischen Softwarestück wie einem Berichtssystem herausragend sein wollten.

Und der Versuch, beides zu tun - Hybridisierung, wie Sie sagten - gleichzeitig zu tun, führt im Grunde genommen zu einem Kräftemessen, bei dem Sie möglicherweise beides tun, aber Sie werden sie weniger gut machen, als wenn Sie sie einzeln gemacht hätten.

Joannes Vermorel: Mehr oder weniger, ja. Genau. Ich meine, das ist das Problem: Sie können nicht etwas haben, das sowohl ein sehr gutes Boot als auch ein sehr gutes Flugzeug ist. Es ist entweder oder. Wenn Sie versuchen, beides zu tun, ist es möglich, aber es wird ein mieses Boot und ein mieses Flugzeug sein.

Conor Doherty: Nun, weil ich wieder mit dem Blog vertraut bin, in dem Sie dieses Konzept zuerst vorgestellt haben - es wird gleich etwas kniffliger. Aber bevor wir das tun, lassen Sie uns das Gelände abdecken oder das zusammenfassen, was wir bisher behandelt haben. Sie verwenden die Analogie des Sprintens und Gewichthebens. Die Dinge, die Sie sehr gut machen - und das gefällt mir, weil Analysen bedeuten, alles zu berücksichtigen. Mir gefiel die Idee des Gewichthebens als Analogie.

Sie können ein sehr, sehr guter Gewichtheber sein. Wenn Sie 200, 300 oder 400 Kilo vom Boden heben wollen, müssen Sie groß sein, um das zu tun. Es ist eine kraftbasierte Bewegung. 100 Meter in weniger als 10 Sekunden laufen? Das schaffen Sie nicht, wenn Sie 150 Kilo wiegen; das passiert einfach nicht. Sie können sehr gut im aeroben Laufen sein oder Sie können sich hervorragend und weltklasse in anaeroben Gewichthebungsübungen beweisen. Sie können nicht beides sein, und wenn Sie versuchen, beides zu sein, sind Sie in keinem wirklich gut.

Joannes Vermorel: Ja, das ist genau richtig. Ja, nun, das Ding ist wieder, weil ich mit dem Ort vertraut bin, an dem Sie diese Perspektive eingeführt haben, gibt es tatsächlich eine dritte Kategorie von Unternehmenssoftware. Weil wir wieder Systeme von Aufzeichnungen behandelt haben - ERPs, die Listen von Daten, Einheiten des Lagerbestands aufzeichnen - haben Sie Ihre Berichtssysteme - im Wesentlichen BI-Tools für analytische und Präsentationszwecke. Es gibt eine dritte Klasse von Software, die wir noch nicht behandelt haben.

Conor Doherty: Was ist das?

Joannes Vermorel: Der dritte ist Systeme der Intelligenz. Das Interessante ist, dass ein System der Intelligenz im Gegensatz zu den ersten beiden Klassen darauf abzielt, direkt Entscheidungen zu treffen. Das ist es. Das Interessante ist, dass wenn Sie sich die Geschichte der Unternehmenssoftware seit dem Beginn Ende der 70er Jahre ansehen, wurde alle Unternehmenssoftware immer, egal was sie effektiv taten, als Systeme der Intelligenz vermarktet, was irgendwie sehr verwirrend ist.

Also spielt es keine Rolle, ob das, was Sie verkaufen, ein System der Intelligenz ist oder nicht. Solange Sie Unternehmen ansprechen, wird es als System der Intelligenz vermarktet - bessere Entscheidungen für Sie.

Conor Doherty: Ja, und das ist sehr verwirrend. Schauen wir uns zum Beispiel die Lagerverwaltungssoftware an. Effektiv ist dieses Ding nur ein Konto. Es zählt nur, wie viel Sie auf Lager haben. Wenn Sie etwas auswählen, wird Ihr Lagerbestand verringert. Wenn Sie etwas hinzufügen, wird der Bestand erhöht. Das ist es. Es tut nichts anderes, als eine elektronische Abbildung Ihres Bestands zu sein.

Joannes Vermorel: Diese Produkte wurden unweigerlich als “Sie werden weniger Fehlbestände und weniger Überbestände haben” vermarktet, was nichts mit dem Konto selbst zu tun hat.

Conor Doherty: Nein, ich meine, Sie könnten sagen, dass Sie effizienter sind, wenn Sie Ihren Bestand führen. Sie haben vielleicht weniger Verwaltungsfehler, aber zu sagen, dass Sie bessere Lagerentscheidungen treffen werden - warum würden Sie das denken? Die Software tut das nicht. Sie sagt Ihnen nur, was Sie haben. Sie ermöglicht es Ihnen nur, Ihre Entscheidungen vielleicht auf eine etwas bessere Weise zu treffen.

Aber es ist wie Schach auf einem echten Schachbrett oder auf einem Computer-Schachbrett zu spielen. Sicher, wenn Sie alle Ihre vergangenen Spiele verfolgen möchten, ist die elektronische Version bequemer, aber die Tatsache, dass es auf einem Computer ist, macht Sie nicht zu einem besseren Schachspieler. Wahrscheinlich wird es Sie sogar ablenken und Sie tatsächlich zu einem schlechteren Schachspieler machen.

Es ist nicht selbstverständlich, dass die Entscheidungen, die Sie mit einem Computer treffen, automatisch besser sind, nur weil Sie mit einem Computer interagieren, anstatt es mit einem Stift auf Papier zu tun. Es kann passieren, aber es ist nicht logisch darauf ausgelegt. Ich würde sogar behaupten, dass meine eigene lockere Erfahrung zeigt, dass ein Computerbildschirm in der Regel eine Ablenkung ist, wenn Sie möchten, dass die Leute wirklich über etwas nachdenken.

Ich würde sagen, wenn Sie wirklich gute Entscheidungen treffen wollen, bin ich mir nicht sicher, ob ein Bildschirm mit einer großen Menge an Unordnung dabei hilft, sich zu konzentrieren und wirklich gründlich darüber nachzudenken.

Joannes Vermorel: Das ist eine sehr kühne Behauptung. Nur um klar zu sein, wir leugnen nicht den Wert eines Systems von Aufzeichnungen. Der Punkt, soweit ich das verstehe, besteht darin, Ihr System von Aufzeichnungen und seine Fähigkeiten nicht mit den Fähigkeiten eines Softwarestücks zu verwechseln, das explizit darauf ausgelegt ist, Entscheidungen zu treffen.

Um diese frühen Unternehmenssoftwareanbieter zu verteidigen, war es extrem unklar. Was uns jetzt sehr klar ist - diese Aufzeichnungssysteme, grobe Apps, Berichtssysteme mit allen Business-Intelligence-Tools und modernen Analysen, und dann Systeme der Intelligenz, in denen Sie Vorhersagefähigkeiten, Optimierungsfähigkeiten haben, mit dem Gedanken, Entscheidungsprozesse buchstäblich zu automatisieren - diese Art der Klassifizierung war damals einfach super unklar.

Sie versuchten alles drei zu tun, und in den 70ern wurden die allerersten Bestandsmanagement-Systeme als “Wir werden alle Bestandsentscheidungen direkt automatisieren” vermarktet. Sie wurden als solche vermarktet. Die Gemeinschaft erkannte, dass es sehr einfach war, Bestände zu verwalten. Verwalten im Sinne, dass es sogar eine Wendung im Begriff Management gibt.

Als die Leute in den 70ern von Bestandsmanagement sprachen, meinten sie all die Dinge, die ein Manager tun würde, und ein Manager würde nicht nur Buchführung machen. Er würde auch Bestandsentscheidungen treffen. Also sagten die Leute, wenn sie an Bestandsmanagement dachten, dachten sie an etwas, das das gesamte Paket machen würde - den Bestand verfolgen und alle relevanten Entscheidungen treffen. Es stellte sich heraus, dass dem nicht so war.

Daher haben wir das Gebiet in Bestandsmanagement, Bestandsoptimierung unterteilt - Optimierung gehört zum System der Intelligenz. Aber damals war es super unklar. Das Gleiche gilt für die Analytik - man konnte Dinge anzeigen, aber die Leute hatten nicht erkannt, wie groß die Datenbanken wachsen würden und welche Herausforderungen es geben würde, Statistiken daraus zu erstellen.

Statistiken zu haben war von Anfang an möglich. Diese Systeme liefen typischerweise nachts und gingen einmal durch die gesamte Datenbank, um Statistiken zu sammeln. Es war also irgendwie möglich, auch mit einer tabellarischen Datenbank konnten Sie nächtliche Chargen haben, die die Statistiken sammelten, nach denen Sie gesucht haben, aber es war sehr umständlich, weil es sehr langsam war.

Sie mussten Ihre Logik im Voraus vorbereiten, und sobald Sie Ihre Logik hatten, mussten Sie bis zur nächtlichen Charge warten, damit sie ausgeführt wurde. Sie würden erst am nächsten Tag feststellen, dass Sie einen Tippfehler in Ihrem Code hatten. Betrieblich war es ein Albtraum. Es war möglich, aber die Reibung war einfach übertrieben.

Deshalb haben Tools wie Business Objects im Wesentlichen OLAP-Technologien mit Hyperwürfeln entwickelt, mit denen Sie innerhalb von Sekunden Analysen durchführen konnten. Das war ein kompletter Spielwechsler, denn plötzlich mussten Sie nicht mehr, sagen wir mal, etwas implementieren und bis morgen warten, um zu sehen, ob Sie etwas falsch gemacht haben. Sie konnten das mit 100-facher Geschwindigkeit tun, als Sie es zuvor konnten.

Conor Doherty: Sie haben zuvor S4/HANA erwähnt, das 2015 veröffentlicht wurde. Zum Zeitpunkt dieses Gesprächs ist es fast zehn Jahre alt - ich glaube, es waren genau zehn Jahre bis zum Tag, vor zwei Tagen. Nachdem Sie das Marketingmaterial dazu überprüft haben, insbesondere unter Verwendung Ihrer Klassifizierung, wurde es als mit allen Fähigkeiten eines Systems von Aufzeichnungen, eines Berichtssystems und durch seine KI-gesteuerte Entscheidungsfindung, eines Systems der Intelligenz präsentiert. Sie haben also die Probleme behandelt, die entstehen, wenn man versucht, Systeme von Aufzeichnungen und Systeme von…

Joannes Vermorel: Einige Analysen waren, würde ich sagen, ein kompletter Spielwechsler, denn plötzlich mussten Sie nicht mehr, wissen Sie, etwas implementieren und bis morgen warten, um zu sehen, ob wir falsch lagen. Nur um es zu wiederholen, Sie konnten das mit 100-facher Geschwindigkeit tun, als Sie es zuvor konnten.

Conor Doherty: Nun, wie gesagt, haben Sie zuvor SAP S/4HANA erwähnt, das 2015 veröffentlicht wurde. Tatsächlich ist es zum Zeitpunkt dieses Gesprächs fast 10 Jahre alt - ich glaube, es waren genau 10 Jahre bis zum Tag vor zwei Tagen. Nachdem Sie das Marketingmaterial dazu überprüft haben, insbesondere unter Verwendung Ihrer Klassifizierung, wurde es im Wesentlichen als mit allen Fähigkeiten eines Systems von Aufzeichnungen, eines Berichtssystems und durch seine KI-gesteuerte Entscheidung - ein System der Intelligenz - präsentiert. Sie haben also bereits die Probleme behandelt, wenn Sie versuchen, gleichzeitig Systeme von Aufzeichnungen und Berichtssysteme zu erstellen. Was passiert, wenn Sie versuchen, alle drei dieser Systeme unter einem Dach zu vereinen?

Joannes Vermorel: Ja, ich meine, hier versuchen wir, gleichzeitig ein Zug, ein Boot und ein Flugzeug zu sein, also ist es noch schlimmer. Sie wissen, es ist wie das Betreten des Frankenstein-Territoriums, wo es wirklich hässlich wird. Die Realität ist, dass alles irgendwie gegen Sie als Softwareanbieter gerichtet ist, wenn Sie alle drei versuchen. Machen Sie einfach mal eine Pause, um zu realisieren, was genau das bedeutet.

Ein System von Aufzeichnungen würden Sie normalerweise nach Betreiber, pro Sitz, pro Benutzer berechnen. So verkaufen Sie heute diese Art von Dingen; das wird eine sehr typische Metrik sein. Wenn Sie ein System der Intelligenz betreiben, ergibt das keinen Sinn, weil Sie irgendwie die Benutzer eliminieren. Oh ja, also das ist Ihre Absicht - Sie möchten gute Entscheidungen treffen. Offensichtlich, je besser Sie sind, desto weniger Benutzer haben Sie. Letztendlich hätten Sie nur eine Handvoll Benutzer im Kundenunternehmen, um Ihre Entscheidungen zu überwachen und damit fertig zu werden. Wenn Sie also pro Benutzer berechnen, funktioniert das nicht; Sie haben einen solchen Gegensatz in Bezug auf Anreize. Aber natürlich ist das nur ein Detail; es gibt viele andere Probleme.

Das Problem ist, dass die Art von Software-Ingenieuren, die Sie benötigen, einfach nicht dieselben sind. Übrigens denke ich, dass ein Unternehmen, dieses Softwareunternehmen, das ein massives Problem vom gegenteiligen Problem hatte, Google war. Google wurde um Dinge herum pioniert, die sehr stark im Bereich der Systeme der Intelligenz lagen. Welche intelligente Entscheidung traf Google damals? Das war die Suche; hier ist meine Abfrage, identifiziere, was am relevantesten ist aus einer Milliarde Websites. Das ist eine Entscheidung, die getroffen wird, und sie muss sehr clever gemacht werden. Google hat sein Vermögen damit gemacht, dass diese Entscheidungen extrem gut getroffen wurden - zumindest besser als ihre Konkurrenz. Sie haben eine ganze Belegschaft aufgebaut mit der Idee, dass sie sehr kluge Ingenieure haben würden, die sehr schwierige Probleme angehen, weil Entscheidungsfindung, die Eigenschaft ist, dass sie fast sehr schwierig sind.

Deshalb möchten Sie sie einem Computer delegieren. Wenn sie nicht schwierig wären, würde es nicht einmal als Entscheidung qualifizieren. Wenn etwas nur eine einfache arithmetische Angelegenheit ist, würden Sie sagen “Okay, es ist nur eine grundlegende Berechnung, nichts zu sehen hier, weitermachen.” Google hat tonnenweise fähige Ingenieure eingestellt, um diese ausgeklügelten Systeme zu entwickeln. Als es darum ging, Systeme von Aufzeichnungen zu entwickeln, die banal, langweilig und repetitiv sind, sind sie gescheitert.

Wenn Sie sich die Geschichte von Google ansehen, wurde alles, was banal war, aus dem Fenster geworfen. Sie hatten Google Reader, einen Blog-Reader, der weit verbreitet war. Es war einfach, eine grobe App, aber eine grobe App reicht Google nicht aus, also haben sie sie weggeworfen. Sie hatten Dutzende ähnlicher Produkte, bei denen, wenn es sich um eine grobe App handelt - grob im Sinne von Erstellen, Lesen, Aktualisieren, Löschen - sie es veröffentlichten, aber nicht aufrechterhalten konnten, weil es unter ihnen lag.

Dies ist ein echtes Problem, wenn Ihr gesamtes Unternehmen darauf ausgerichtet ist, intelligente Systeme zu entwickeln: Ihre Ingenieurbelegschaft ist nicht daran interessiert, mühsame, repetitive Arbeit zu leisten. Im Gegensatz dazu, wenn Sie seit Jahrzehnten Systeme von Aufzeichnungen erstellen, ist Ihre Belegschaft einfach daran gewöhnt, Tausende von Bildschirmen zu gestalten und anzuerkennen: “Okay, diese Software wird 5.000 oder 20.000 verschiedene Funktionen benötigen, die alle einzeln super einfach sind, ohne jegliche Herausforderung”, aber sie müssen dennoch erledigt werden.

In Bezug auf die Ingenieurbelegschaft und die Unternehmenskultur ist es völlig anders. Meiner Wahrnehmung nach endete SAP mit einer Belegschaft, die auf diese Mentalität des Landgewinns ausgerichtet war - lassen Sie uns eine unendliche Anzahl von Ingenieuren haben, die eine unendliche Anzahl von Bildschirmen und eine unendliche Anzahl von Funktionen erstellen können, von denen jede einzeln super einfach ist. Dann versuchen sie, zu intelligenten Systemen zu springen, und es ist super schlecht gescheitert.

Ein Bereich, in dem Sie sehen können, dass Personen, die gut in intelligenten Systemen sind, technologische Durchbrüche erzielen, und es sickert in Form von Open-Source-Projekten durch. Google hat beispielsweise möglicherweise versäumt, grobe Apps zu pflegen, aber es gelang ihnen, wertvolle Stücke von Open-Source-Technologien zu veröffentlichen, die aufgrund ihrer talentierten Belegschaft sehr kompliziert und schwierig zu entwickeln sind. Wenn Sie sich SAP ansehen, bin ich mir nicht sicher, ob ich auch nur ein einziges interessantes Open-Source-Projekt nennen könnte, das aus SAP hervorgegangen ist, um es zu vergleichen.

Conor Doherty: Nun, mir fällt auf, dass wir ziemlich viel Zeit damit verbracht haben, die Struktur von Systemen von Aufzeichnungen und Systemen von Berichten abzugrenzen, aber wir haben tatsächlich nicht behandelt, was genau die architektonischen Designentscheidungen - die strategischen architektonischen Designentscheidungen - für ein System von Intelligenz wären und warum das mit den anderen beiden Architekturen unvereinbar wäre. Lokad ist beispielsweise ein System von Entscheidungen, ein System von Intelligenz; was ist es an seiner Struktur, das bedeutet, dass der Versuch, das mit einem System von Aufzeichnungen in Einklang zu bringen, problematisch wäre, um es vorsichtig auszudrücken?

Joannes Vermorel: Ich würde sagen, ein System von Intelligenz hat in seinen Grundlagen einige Ähnlichkeiten mit einem System von Berichten. Sie möchten diese spaltenweise Darstellung; das macht für Analysen viel Sinn. Aber dann, was Sie von einem System von Intelligenz erwarten, ist sehr schnell Programmierbarkeit. Wenn Sie die Flexibilität haben möchten, einen Entscheidungsprozess zu entwickeln, benötigen Sie etwas äußerst Ausdrucksstarkes. Übrigens werden Excel-Tabellen häufig zur Unterstützung von Entscheidungsprozessen verwendet; Mit Excel erhalten Sie eine Programmiersprache, die sehr wichtig ist.

Excel-Formeln können beliebig komplex gemacht werden, und wenn Sie es sich leisten können, können Sie sogar Programmierung durch VBA oder Python durchführen. Excel ist programmierbar, und deshalb wird es häufig als Werkzeug zur Unterstützung von Systemen von Intelligenz verwendet. Sie benötigen Programmierbarkeit, was ein völlig anderes Spiel ist im Vergleich zu Systemen von Berichten, bei denen es für jeden zugänglich sein sollte. Sie befinden sich im Bereich von WYSIWYG (What You See Is What You Get); Sie haben schicke Oberflächen, was die Welt der Berichtssysteme ist.

Conor Doherty: Mir fällt auch auf, dass hier eine wirtschaftliche Perspektive ist, die wir noch nicht angesprochen haben. Und wieder sind Sie ein Mann der Wirtschaft, ein Mann von Thomas Sowell.

Mir fällt auf, ob es in Bezug auf Software eine intelligente Entscheidung ist, zu versuchen, eine Drei-in-Eins-Lösung zu kaufen, bei der Sie Ihr System von Aufzeichnungen, Berichten und Intelligenz zusammen haben. Das können wir beiseite lassen. Gibt es nicht ein wirtschaftliches Argument, das besagt, dass es als Satz von Abwägungen möglicherweise billiger wäre, im Wesentlichen eine Software zu kaufen, die zumindest behauptet, alle drei Dinge tun zu können, anstatt drei separate Abonnements für drei separate Softwareprodukte, drei separate Probleme, haben zu müssen, um alle zu trainieren, drei separate Dinge zu verwenden?

Joannes Vermorel: Ja, ich meine, das ist buchstäblich die Geschichte des F-35. Sie sprechen über diesen amerikanischen Kampfjet, der das teuerste Flugzeug aller Zeiten sein wird. Das Problem ist, dass diese Dinge nicht linear sind.

Wenn Sie sagen: “Ich möchte, dass mein Flugzeug im Nahkampf super gut ist, im Langstreckenbetrieb super gut ist, und stealthy ist und vertikal starten kann”, landen Sie bei etwas, wo jedes Mal, wenn Sie eine Funktion hinzufügen, den Preis des gesamten Dings verdoppeln.

Am Ende haben Sie also ein Flugzeug, das den typischen Preis von vielleicht zehn anderen Flugzeugen kostet - eines für den Langstreckenbetrieb, eines für den taktischen Kampf mit einem anderen Flugzeug, eines, um stealthy zu sein, eines für den vertikalen Start. Sie müssen nicht unbedingt all das haben, usw. usw. Also, sehen Sie, es ist nicht linear. Sie können nicht einfach all diese Dinge in einem Setup haben.

Nun könnte man sagen, dass, wenn SAP sich entschieden hätte, drei völlig unabhängige Systeme zu haben - eines, das sich mit dem System der Aufzeichnungen befasst, eines, das sich mit dem System der Berichte befasst, das dritte, das sich mit dem System der Intelligenz befasst - und Sie chinesische Mauern zwischen all diesen Abteilungen setzen und sie unabhängig betreiben, das hätte funktionieren können. Aber das ist nicht passiert.

Die Versuchung war viel zu groß, alles zusammenzuziehen, einschließlich der erworbenen Lösungen von Drittanbietern. Die Mischung ist einfach giftig. Sie nehmen Produkte, die sich sehr schlecht mischen, und Sie bekommen etwas, das dysfunktional ist. Ich denke, das ist es, was wir jetzt sehen.

Wenn wir auf die Zeitachse zurückblicken, hatten wir 2010 HANA. Es dauerte fünf Jahre, um S/4 darauf aufzubauen. Die meisten dieser Misserfolge waren buchstäblich ein Jahrzehnt lang in Arbeit. Wir betrachten Dinge, die ein Jahrzehnt gebraucht haben, um sich zu entfalten.

Wir betrachten HANA-Misserfolge, die gerade öffentlich sichtbar werden. Es ist nur die Spitze des Eisbergs. Die Opportunitätskosten vieler Unternehmen sind einfach verrückt, weil es so viele Jahre dauert, ein Upgrade durchzuführen. Wir sprechen von Upgrades von fünf Jahren oder mehr, was einfach völlig verrückt ist.

Es ist wahnsinnig. Bedenken Sie, dass ChatGPT und generative KI vor fünf Jahren nicht existierten. Sie werden so spät in den Kampf kommen. Darüber hinaus wurden sehr schlechte Entscheidungen getroffen, wie z.B. das Festlegen auf In-Memory-Systeme, was bedeutet, dass man zu viel in die Infrastruktur investiert.

Wenn Sie Tonnen von Hardware haben, viel mehr als Sie haben sollten, bedeutet das, dass Sie mehr Systemadministratoren, mehr IT-Mitarbeiter benötigen, um all das zu verwalten. Alles wird unglaublich komplex. Es wird nicht nur komplexer, sondern auch langsamer. Diese Dinge addieren sich. Es ist viel kostspieliger, langsamer, Sie benötigen mehr Personal, und die Opportunitätskosten steigen noch weiter an.

Dann werden die Menschen in der Managementebene ängstlich, weil so viel auf dem Spiel steht. Das verlangsamt den Prozess noch weiter. Es ist wie ein Teufelskreis. Die Probleme werden gerade sichtbar. Unternehmen tun ihr Möglichstes, um sicherzustellen, dass interne Fehler nie öffentlich bekannt werden, weil es keine gute Presse ist. Sie möchten Ihre eigene Inkompetenz nicht bewerben. Wenn Sie das hinter verschlossenen Türen regeln können, ist das viel besser.

Denken Sie darüber nach, wie extrem das Problem sein muss, um all diese Wäsche öffentlich zu enthüllen. Fast alle Situationen, es sei denn, das Unternehmen ist börsennotiert und steht mit dem Rücken zur Wand und muss Dinge offenlegen, weil es sonst als Betrug eingestuft würde, werden nicht offengelegt.

Conor Doherty: Nun, Sie haben ein paar Mal von Opportunitätskosten gesprochen. Sie haben die Opportunitätskosten erwähnt, die entstehen, wenn man in eine Implementierung hineingezogen wird. Plötzlich steckt man in diesem Prozess fest und kann nicht zu etwas anderem wechseln. Es hat auch die steigenden Kosten, die mit der Aufrechterhaltung von Personen verbunden sind.

Es gibt tatsächlich noch eine andere Dimension dazu, und ich habe hier “Perfektionierbarkeit” notiert. In Bezug auf Opportunitätskosten, wenn Sie alle drei dieser Softwareklassen einzeln betrachten, sind sie theoretisch am besten, wenn sie getrennt gehalten werden, weil Sie ein separates System von Aufzeichnungen, ein separates Berichtssystem und ein separates Intelligenzsystem haben.

Sie versuchen, jedes einzelne zu perfektionieren. Es gibt eine Obergrenze dafür, wie perfekt ein Aufzeichnungssystem sein kann. Wenn Sie zum Beispiel eine 100%ige Genauigkeit haben, ist das alles. Wie viele Flaschen stehen auf dem Tisch? Es sind zwei. Das ist alles. Sie können es nicht besser machen als das.

Wenn die Latenz bei 50 Millisekunden liegt, ist das unerheblich; die Leute bemerken es nicht mehr. Ein Berichtssystem - wie gut kann ein Dashboard aussehen? Wir können über Ästhetik diskutieren, aber es gibt eine Obergrenze dafür, wie viel Zeit und Geld Sie investieren möchten, bevor sich die Erträge verringern.

Ein Intelligenzsystem, wie Sie sagten, beinhaltet Entscheidungen. In der Philosophie von Lokad bedeutet das, den Return on Investment für jede getroffene Entscheidung zu berücksichtigen. Theoretisch fällt mir auf, dass es keinen Perfektionspunkt gibt, an dem Sie sagen können: “Das ist die beste Entscheidung, die ich je treffen könnte.”

Es ist nicht unbedingt perfektionierbar. Sie können einen Algorithmus kontinuierlich verbessern, um bessere Entscheidungen zu treffen. Liege ich falsch?

Joannes Vermorel: Nein, aber wir müssen auch ein Missverständnis ausräumen. Mathematiker würden sagen: “Oh, aber wenn Sie das Optimum erreichen, sind Sie der Beste.” Sie wissen, dass, per Definition, wenn Sie das Optimum erreicht haben, es nicht besser gemacht werden kann. Und für jedes, würde ich sagen, gegebene mathematische Rätsel, wenn Sie ein mathematisches Rätsel nehmen und sagen: “Das ist es, das ist ein Rätsel”, dann können Sie die optimale Lösung für dieses Rätsel haben.

Aber wo es falsch ist, so zu denken, ist im Geschäft, dass die Wahl des Rätsels sehr willkürlich ist. Sie können entscheiden: “Okay, ich habe vielleicht das, was für dieses Framework optimal ist, aber ich kann vielleicht mein eigenes Geschäft neu erfinden und dann habe ich ein neues Framework, das mir noch höhere Renditen bringt.” Die Möglichkeiten, die Sie haben, sind also nicht statisch. Sie entscheiden, was Sie überhaupt tun möchten, und innerhalb der Dinge, die Sie tun möchten, könnte es ein Optimum geben, aber grundsätzlich sind Ihre Möglichkeiten endlos.

Es gibt keine - die einzige Obergrenze, so wie ich es sehe, ist die menschliche Ingeniosität selbst. Also sagen Sie: “Mein Optimum ist bedeutungslos, weil das Optimum innerhalb formaler Grenzen liegt.” Wo ich sage: “Ich kann nur innerhalb, wissen Sie, ich ziehe eine Linie im Sand, ich sage, ich kann nur diesen Bereich betrachten und sagen, okay, innerhalb dieses Bereichs, den ich im Sand abgesteckt habe, ja, mein Optimum könnte das sein, vielleicht kann ich das sogar mathematisch beweisen.”

Aber die Realität ist, dass es nur eine Linie im Sand ist. Sie können überall hingehen, wo Sie wollen. Also ja, das Fazit ist, dass, wenn Sie in Bezug auf Geschäftsentscheidungen denken, es keine Grenze gibt, außer der Intelligenz und Ingeniosität der Menschen, die an dem Fall arbeiten werden.

Jetzt glaube ich, dass die Softwarebranche das sehr früh erkannt hat. Sie wissen, deshalb haben schon in den 70ern alle Anbieter auf Vorteile gedrängt, die sich in Form einer besseren Entscheidungsfindung ausdrücken. Sie haben buchstäblich ein System der Intelligenz beworben, weil sie erkannt haben, dass das Problem, eine elektronische Darstellung Ihres Bestands zu haben, endlich war. Wenn es richtig gemacht wurde, was würden Sie dann tun?

Es stellte sich heraus, dass die Menschen verschiedene Phasen durchliefen. Zuerst hatten Sie Textschnittstellen, dann hatten Sie grafische Schnittstellen wie mit dem Desktop - dem Desktop, der fetten Client-Generation der 90er Jahre. Heutzutage haben Sie Web-Apps und jetzt mobile Apps. Es stellte sich also heraus, dass selbst auf der Benutzeroberfläche, der Benutzeroberfläche, es eine Reihe von Übergängen gab.

Selbst wenn die Herausforderung endlich war, stellte sich heraus, dass Softwareunternehmen immer noch damit beschäftigt waren, vom Textterminal zur grafischen Benutzeroberfläche zur Web-App und jetzt zur mobilen App zu wechseln. Aber das Ding ist, dass es für alle sehr klar war, dass diese Sache irgendwie enden würde, in dem Sinne, dass sie nicht unendlich wachsen würde, um zu etwas extrem Großem zu werden.

Deshalb sind sehr früh viele Anbieter, einschließlich SAP, dazu übergegangen, sich gegen diese Entscheidungen zu positionieren, auch wenn ihre Software in der Praxis nichts damit zu tun hatte, bessere Entscheidungen zu generieren.

Conor Doherty: Nun, mir fällt auf, dass wir viel über Theorie gesprochen haben, und das ist gut. Nun, Theorie gemischt mit etwas Praxis hier, aber sicherlich möchte ich versuchen, es etwas praktischer zu gestalten. Ich möchte die Frage so formulieren: Am Anfang der Episode habe ich DHL, Asda, Spar erwähnt. Es gab weitere Beispiele aus Anthony Millers Beitrag.

Wenn Sie heute in einem Raum wären, wenn Sie im Vorstand mit den Entscheidungsträgern, den Großen, den wichtigen Akteuren wären und sie sagen würden: “Okay Joannes, was sollten wir als nächstes tun?” Wir haben das versucht, das hat nicht funktioniert. Was wäre Ihr Rat?

Joannes Vermorel: Mein Rat ist sehr einfach. Systeme der Aufzeichnungen wurden vor mehr als einem Jahrzehnt vollständig standardisiert, tatsächlich vor mehr als einem Jahrzehnt. Also, lassen Sie uns Schritt für Schritt vorgehen. Ihre Datenbank wird, sagen wir, PostgreSQL sein. Es ist Open Source, es ist ausgezeichnet.

Das war das Ding im Jahr 2010, als SAP sagte: “Wir hatten so viele Probleme, wir sehen Oracle als eine strategische Bedrohung.” Was sie nicht realisierten, war, dass Oracle unbedeutend war. Der eigentliche Herausforderer war tatsächlich Open Source.

Also, die relationale Datenbank, die heute effektiv gewonnen hat, sind Open-Source-Datenbanken. Relationale Datenbanken sind jetzt ein komplettes Handelsprodukt, bis hin zu dem Punkt, dass die allerbesten Produkte Open-Source-Projekte sind, und PostgreSQL ist Oracle und privaten weit voraus.

Also, hier sind wir in einer Situation, in der ein großer Anbieter, SAP, der einen anderen Anbieter, Oracle, eindämmen wollte, letztendlich eine Technologie entwickelte, die sich als unterlegen gegenüber einem Open-Source-Produkt herausstellte - das ist nur PostgreSQL.

Und wie weiß ich, dass es unterlegen ist? Ich meine, schauen Sie einfach auf Hacker News oder diskutieren Sie, was Startups heutzutage tun. Ich habe eine dreistellige Anzahl von Startups geprüft. Ich habe noch nie ein Startup gesehen, das in den letzten zehn Jahren keine nicht Open-Source-relationale Datenbank verwendet hat. Nie.

Sie würden nur Open-Source-Datenbanken verwenden. Ich habe noch nie ein Startup gesehen, das zum Beispiel Oracle Database verwendet hat. Nie. Das gibt Ihnen das Gefühl, dass Leute, die sich mit Technologie auskennen, die mit Technologie umgehen, diese Wahl nicht treffen. Zuerst würde ich diesem Gremium von Führungskräften sagen: “Für die Datenbankebene müssen Sie eine der ausgezeichneten Open-Source-Optionen auswählen, die auf dem Markt sind.”

Das kann PostgreSQL sein. Diese Lösungen sind ausgezeichnet, und wenn Sie das nicht tun, ist der Verlust an Möglichkeiten enorm, denn wenn Sie eine dieser Datenbanken auswählen, haben Sie buchstäblich mehr als eine Million Software-Ingenieure, die bereits kompetent in diesen Technologien sind, im Vergleich zu privaten, obskuren Firewall-Technologien, die viel schwieriger zu bedienen sind. Das war das erste Problem.

Dann, was brauchen Sie noch oben drauf? Sie benötigen im Wesentlichen ein Framework, um eine rudimentäre App auf der Datenbank bereitzustellen. Es gibt Unmengen solcher Frameworks, und auch sie sind als Open Source verfügbar. Das wäre Django, wenn Sie in Python sind, das wäre das MVC-Framework in ASP.NET für Microsoft, das ebenfalls Open Source ist. Die Liste geht weiter. Diese Frameworks existieren für alle wichtigen Stacks - Python, Java, .NET.

Weil es komplett standardisiert ist, entweder wählen Sie für Ihr System der Aufzeichnungen einen Anbieter, der bereits Open Source ist - diese existieren - oder Sie erstellen einfach Ihr eigenes, und das ist nicht einmal so teuer. Das Ding ist, wenn Sie am Ende mit einem fünfjährigen Projekt für ein ERP-Upgrade enden, wären Sie viel besser dran, wenn Sie einfach Stück für Stück Ihr eigenes Ersatzstück einführen würden.

In sechs Monaten könnten Sie eine Reihe von Modulen haben, die bereits aktualisiert und ausgetauscht werden, wenn Sie es einfach intern machen oder mit Hilfe eines IT-Unternehmens. Nochmals, das Schöne daran, dass diese Aufzeichnungssysteme komplett standardisiert sind, ist, dass es super einfach ist, Leute zu finden, die es tun können. Es ist super einfach, diese Dinge auszulagern - es ist auch super einfach, es intern zu tun, wenn Sie möchten.

Die Hürde ist sehr niedrig; es ist sehr günstig. Wenn Sie sich alle technikaffinen Unternehmen dieser Welt ansehen - die Zalandos dieser Welt - haben sie ihr eigenes ERP entwickelt; sie sind damit zufrieden. Wenn Sie sich Amazon ansehen, tun sie dasselbe; JD.com tut dasselbe. Alle digitalen Natives haben das als offensichtliche Lösung für das Aufzeichnungssystem gesehen.

Aufzeichnungen sind komplett standardisiert. Letztendlich ist es nicht schwierig, ich meine, diese Produkte sollten sicherlich nicht teuer sein. Wenn sie teuer sind, sollte Ihr Plan B sein: “Okay, wissen Sie, ich werde es einfach selbst machen.” Wenn Sie einen Maler bitten, ein Gemälde für eine Wand in Ihrem Haus anzufertigen und er sagt, dass das 2 Millionen Euro kosten wird.

Sie wissen, es sind vier Quadratmeter, aber wissen Sie, wenn ich es nicht besser kann, würden Sie sagen: “Okay, ich werde es einfach selbst machen.” Sie wissen, wenn es die einzige Option ist, würde ich es selbst machen. Ja, ich würde es lieber nicht machen, aber wissen Sie, wir reden nicht darüber, Raketen ins All zu schicken. Wir reden über etwas, das sowieso ziemlich unkompliziert ist.

Conor Doherty: Nun, das, wieder, weil ich ausführliche Notizen mache, wie Sie sehen können. Aber die nächste Frage, die ich stellen wollte, nachdem ich die drei Klassen abgegrenzt habe, und wieder sind Sie in diesem Raum mit den Führungskräften, und unsere potenzielle Voreingenommenheit ist klar, wie Sie wissen. Lokad ist selbst ein Anbieter. In Bezug auf die Kosten für jede dieser Klassen, denn wieder haben Sie in den letzten zwei oder drei Minuten mehrmals kommentiert, wie, “Schauen Sie, ich meine, Sie könnten das im Grunde genommen selbst machen.”

Ich meine, wenn Sie technologisch versiert sind, könnten Sie und Sie sind digital - der Begriff “digital native” wurde verwendet - könnten Sie Ihr eigenes Aufzeichnungssystem entwerfen. Nun, dann sollte es vermutlich weniger kosten als ein Berichtssystem und ein Intelligenzsystem oder wie verteilen Sie das Budget in dieser Hinsicht?

Joannes Vermorel: Ich meine, klar, Aufzeichnungssysteme sind viel einfacher als der Rest. Sie wissen, sie waren diejenigen, die zuerst kamen. Die Technologie ist vollständig standardisiert. Open Source bietet alle Teile, die Sie benötigen. Die Entwicklung einer einfachen App ist ein Paradebeispiel dafür, wofür integrierte Entwicklungsumgebungen gedacht sind.

Also, das Werkzeug ist ausgezeichnet, das Framework ist ausgezeichnet, und das Werkzeug ist ausgezeichnet. Sie haben Unmengen von Ingenieuren, die eine enorme Produktivität haben, und noch besser mit LLMs heutzutage. Dies ist genau das, wo generative KI brilliert, wenn es darum geht, Tonnen von unintelligentem Code zu schreiben. Diese Tools sind super gut darin.

Conor Doherty: Also 20 Milliarden Dollar, das ist das, was wir verlangen sollten.

Joannes Vermorel: Ja, das sollte relativ sein, ich meine, das sollte für Unternehmen wieder als Basis ziemlich günstig sein. Wenn Sie mehr als ein Zehntel dessen zahlen, was Sie vor 10 Jahren für ähnliche Systeme bezahlt haben, ist das Abzocke. Das sollte Ihre Basislinie sein. Sie sollten also nach “Wir werden es wieder tun, aber zu einem Zehntel des Budgets” suchen. Und das ist noch nicht einmal übertrieben.

Ich denke, angesichts der Entwicklung der Technologie ist das ein Ausgangspunkt. Ich bin ziemlich sicher, dass, wenn Sie verrückt aggressiv werden würden - sagen wir, Elon Musk übernimmt den Fall -, es heißen würde: “Ich werde es für 100 Mal billiger machen.” Aber ich würde sagen, dass Ihr nächstes ERP-Projekt ein Zehntel der Kosten dessen sein sollte, was Sie vor 10 Jahren ausgegeben haben. Ich denke, das ist eine vernünftige Basislinie, zumindest für Aufzeichnungssysteme.

Für das Berichtssystem ist die Technologie ziemlich verpackt. Das Problem ist, dass es in der Regel sehr teuer wird, weil das Unternehmen einfach eine unendliche Anzahl von Berichten haben möchte. Die Kosten sind die Implementierung, maßgeschneidert, einer unbegrenzten Anzahl von Berichten - einer verrückt hohen Anzahl von Berichten.

Also, wenn Sie ein Berichtssystem haben, würden die Leute irgendwann sagen: “Oh, aber ich hätte gerne einige Berichte, die sofort einsatzbereite Vorlagen sind.” Und dann würde der Anbieter sagen: “Ja, kein Problem, wie viele möchten Sie?” Und dann listen sie auf, und Sie enden mit Tausenden von Berichten. Wenn Sie das tun, wird es unglaublich teuer, nur weil Sie so viel verlangen.

Hier sollte es ziemlich günstig sein, weil die Technologie ziemlich verpackt ist, aber mehr als Aufzeichnungssysteme. Es ist schwieriger, also ist es etwas, bei dem ich davon abraten würde, Ihr eigenes System zu entwickeln. Aber wiederum, mit Open-Source-Technologien wie Spark ist es nicht so schwierig. Obwohl es schwieriger ist als Aufzeichnungssysteme.

Hier denke ich, wenn Sie das Budget knapp halten wollen, müssen Sie Ihre Anforderungen im Griff behalten. Es gibt diese Versuchung, insbesondere in großen Unternehmen, eine endlose Liste von Berichten anzufordern, die niemand jemals nutzen wird. Es stellt sich heraus, dass es sehr teuer wird, weil all diese Leute sich diese Zahlen von Zeit zu Zeit ansehen müssen, und es ergibt nicht wirklich Sinn.

Halten Sie es also kurz und fokussiert, und die Kosten werden nicht sehr hoch sein. Es sollte tatsächlich viel kleiner sein als Ihre Basis-ERP-Kosten von vor 10 Jahren. Ich habe gesagt, dass das neue ERP fast ein Zehntel davon sein sollte. Das Berichtssystem sollte nur ein Bruchteil dieser Kosten sein, nicht mehr als 20% der Kosten dieses ERP der nächsten Generation.

Darum geht es, um etwas sehr Kleines. Letztendlich sollten Berichte nicht Millionen oder zig Millionen kosten, um grundlegende deskriptive Statistiken über Ihr Unternehmen zu berichten. Das ergibt keinen Sinn. Die Technologie hat sich genug weiterentwickelt, sodass es sehr günstig sein sollte.

Conor Doherty: Als Sie erstmals die Kategorisierung der drei Klassen oder Klassifizierung der drei Arten von Unternehmenssoftware vorgeschlagen haben - Ich kann mich nicht an das genaue Verhältnis erinnern, aber es war etwas wie 90% Ihres IT-Budgets sollten in Systeme der Intelligenz fließen.

Joannes Vermorel: Die Aufteilung, die ich vorgeschlagen habe, war 20% für ERP, 5% für Systeme der Intelligenz und 75% für - Entschuldigung, 20% für Systeme der Aufzeichnungen, 5% für Systeme der Berichte und 75% für Systeme der Intelligenz. Das ist das, was ich als Faustregel für die quasi Gesamtheit der Unternehmen vorschlage.

Im Gegensatz dazu liegt der Anteil heute bei 75% für ERP, 20% für Business Intelligence oder Systeme der Berichte und nur 5% für Systeme der Intelligenz. Ich sage, diese Zahlen sind falsch. Wir müssen sie vertauschen. Warum sollten Sie den Großteil Ihres Geldes in Systeme der Intelligenz investieren?

Offensichtlich sind bei Lokad Systeme der Intelligenz im Spiel, daher sollte das Publikum viel Geld ausgeben. Aber die Realität ist, dass es tatsächlich eine Rendite gibt. Hier können Sie eine große Rendite erzielen, wenn die Entscheidungen richtig getroffen werden. Systeme der Berichte dienen größtenteils dazu sicherzustellen, dass Sie nicht in Flammen stehen.

Es geht darum zurückzublicken, um festzustellen, ob Sie mit Ihren eigenen Prozessen konform sind, ob Sie auf Kurs sind. Aber im Grunde ist noch kein Unternehmen massiv erfolgreich geworden, indem es nur zurückblickt. Das ist das Problem bei Systemen der Berichte. Sie schauen in den Rückspiegel.

Wenn Sie ein Rennen gewinnen wollen, gewinnen Sie kein Rennen, indem Sie die Augen auf den Rückspiegel richten. Irgendwann müssen Sie nach vorne schauen.

Conor Doherty: Mir fällt auf, dass ich tatsächlich einen Laptop vor mir habe, und dieser hat WLAN. Der Blog, auf den ich mich bezog, heißt tatsächlich “Die drei Klassen von Unternehmenssoftware”. Er stammt aus dem Juni des letzten Jahres.

Nur um die Zahlen zu klären, Sie erinnerten sich richtig daran, wie Unternehmen, die quasi Gesamtheit der Unternehmen, typischerweise ihre Ausgaben aufteilen - Ihr IT-Budget beträgt 75% für Systeme der Aufzeichnungen, und Sie haben spielerisch “falsch” in Klammern dahinter gesetzt. 20% für Systeme der Berichte, ebenfalls “falsch”, und 5% für Systeme der Intelligenz, mit “völlig falsch” am Ende.

Umgekehrt 75% für Systeme der Intelligenz, fünf für Systeme der Berichte und 20 für Systeme der Aufzeichnungen. Nun, ähm, ich empfehle dringend, den Blog zu lesen. Er ist sehr gut.

Nun, ähm, eine letzte Frage, bevor wir anfangen, zusammenzufassen, aber es fällt mir ein. Ähm, es ist ein Punkt, den Sie zuvor gemacht haben und in Ihren Vorlesungen gemacht haben, und den ich hier ein paar Mal in Gesprächen gemacht habe: die Rolle des mechanischen Mitgefühls. Und wir müssen nicht lange darüber sprechen, aber es fällt mir ein, dass eine grundlegende Vertrautheit mit, sagen wir, welche Parameter erforderlich sind oder welche architektonischen Designentscheidungen erforderlich sind, um mit dem Tool, das Sie kaufen möchten, erfolgreich zu sein?

Wenn Sie damit einigermaßen vertraut sind, können Sie zumindest ein Gefühl dafür bekommen, ob “Das könnte nichts für mich sein.” Also, schon allein der Unterschied zwischen spaltenorientierten und tabellarischen Datenbanken - wenn Sie gut verstehen, was dieses System verwendet und wofür ich dieses System möchte? Das könnte Sie sofort dazu bringen, eine potenziell teure Wahl zu überdenken.

Joannes Vermorel: Ja. Und noch einmal, wenn wir zu den Fehlern zurückkehren, die SAP, ähm, im Jahr 2010 gemacht hat… Ich meine, HANA wurde 2010 veröffentlicht, also waren sie wahrscheinlich schon seit einigen Jahren dabei, das zu durchdenken. Und damals sah es wahrscheinlich wie eine gute Idee aus, wissen Sie, es sah aus wie: “Okay, nehmen wir an, dass diese Latenzen, die wir in Computersystemen haben, einfach besser werden, sich weiter verbessern, dass der Speicher viel billiger wird.”

Denn noch einmal, wenn wir uns anschauen, was der große Unterschied zwischen 2010 und, sagen wir, ähm, dem Jahr, ähm, 15 Jahre zuvor ist, wissen Sie, 1995. In diesen 15 Jahren war der Speicher radikal billiger geworden und radikal reichlicher vorhanden. Ich erinnere mich, dass ich damals, 1995, den ersten Computer, den ich benutzt habe, Windows 95, hatte, mit ungefähr 8 Megabyte Speicher.

Und dann, als es 2010 war, war das, glaube ich, zu der Zeit Windows 7 oder so. Ich glaube, zu der Zeit hatte ich 8 Gigabyte, wissen Sie, also hatte es sich in diesem Zeitraum um das Tausendfache erhöht. Und die Latenz war um etwa den Faktor 50 oder so reduziert worden.

Also, wenn es so weitergegangen wäre, wäre das unglaublich gewesen. Das würde bedeuten, wissen Sie, ich hatte 2010 8 GB auf meinem Computer. Wenn es 15 Jahre später genauso verbessert worden wäre, hätte ich heute 8 Terabyte auf meinem Computer gehabt. Das ist natürlich nicht das, was ich auf meinem Computer habe. Niemand hat 8 Terabyte auf seinem Computer.

Aber Sie sehen, dass, wenn die Technologie sich so entwickelt hätte wie in den 15 Jahren zuvor, das wäre gewesen, was die Leute gehabt hätten. Und wenn wir auch die ähnliche Reduzierung der Latenz gehabt hätten, das Problem ist, dass die Lichtgeschwindigkeit so ein Ärgernis ist, wissen Sie. Die Physik spielt nicht nett mit Ihnen. Sie haben diese Lichtgeschwindigkeit, die irgendwie im Weg ist.

Aber trotzdem war es, glaube ich, dass sie diesen tragischen Fehler gemacht haben. Und dann mussten so viele Dinge überkonstruiert werden, weil das wie die Ursünde war. Aufgrund dessen mussten so viele Vertuschungen vorgenommen werden, die Sie nur machen müssen, um… Wenn Sie ein massives Designproblem wie dieses haben, können Sie versuchen, sich mit Klebeband aus dem Problem herauszuwinden. Sie können, aber alles wird umständlich sein.

Und wenn Sie also Leistungsprobleme haben, können Sie sie lösen, indem Sie Hardware darauf kleben. Ja, Sie können natürlich damit beginnen, super teure Hardware zu kaufen, das wäre Schritt eins. Aber dann können Sie verrückte Dinge überkonstruieren, damit es nicht zu dysfunktional wird. Denn im Grunde genommen können Sie mit genügend Ingenieurskunst einige dieser Probleme mildern.

Aber dennoch möchte SAP alles abdecken, mit dem Ehrgeiz, den ich beschrieben habe. Sie möchten das System der Aufzeichnung für eine Sache sein, aber sie möchten das System der Aufzeichnung für alles sein. Das bedeutet, dass die Oberfläche, auf der Sie Leistungsprobleme haben können, nur aufgrund dieser Wahl, absolut gigantisch ist.

Und ich glaube, dass das, was wir sehen, einfach, wissen Sie, in Zeitlupe implodiert, in Zeitlupe. Das ist, was wir sehen. Es dauert viel Zeit. Es dauerte fünf Jahre, um ein ERP auf HANA zu veröffentlichen, das ist S/4. Und dann dauerte es Jahre, um das ERP an ihr erstes Unternehmen zu verkaufen.

Denn wenn Sie Unternehmenssoftware verkaufen möchten, schließen Sie den Deal nicht in sechs Monaten ab; es dauert häufig mehrere Jahre. Dann dauert es wie ein halbes Jahrzehnt, um zu implementieren. Und vielleicht ist das dann Ihr Plan für das Upgrade.

Das ist verrückt. Aber die Realität ist, dass Sie anfangen zu scheitern, weil es nicht ein halbes Jahrzehnt dauert, sondern ein ganzes Jahrzehnt. Wir sind also Zeugen von Fehlern, die durch schlechte Entscheidungen verursacht wurden, die vor langer Zeit getroffen wurden. Und wir verfolgen die vergangenen Jahrzehnte zurück. Ich denke, wir werden sehen, dass diese Probleme weiterhin auftauchen, aber es ist nicht neu. Es spiegelt nur Fehler wider, die vor langer Zeit gemacht wurden.

Und jetzt ist das Einzige, was wir wirklich vorschlagen können, wiederholen Sie keine alten Fehler. Aber das Verrückte ist, dass diese Fehler vor so langer Zeit gemacht wurden, dass die Leute von SAP… Ich meine Fehler von SAP und die Leute, die sie angenommen haben, dachten, es sei richtig.

Und das Interessante ist, dass diese Fehler vor so langer Zeit gemacht wurden, dass die Leute vielleicht denken, “Oh, aber heutzutage sollte es richtig sein.” Sie haben ihre Dinge zusammen. Sie haben ihre Gedanken zusammen. Das ist gelöst. Denn offensichtlich würde ich als Anbieter, wenn ich ein solches Produkt anpreisen würde, sagen: “Liebe Interessenten, seien Sie versichert, dass wir aus unseren Fehlern gelernt haben. Diese Dinge wurden korrigiert. Diese Fehler, wir haben so viel gelernt. Sie werden nicht wieder passieren.”

Ich würde sagen, nicht ganz, denn das Problem liegt immer noch im Kern Ihrer Technologie. HANA ist immer noch das Herzstück aller SAP-Angebote. Solange es so ist… Ja, Sie sind erledigt. Sie müssen das alles rückgängig machen, um möglicherweise in vernünftigere Gebiete einzutreten.

Heutzutage, es sei denn, sie ändern den Kurs und entfernen einfach HANA, gehen zu PostgreSQL oder was auch immer Open Source ist, und dann ihr Angebot in Scheiben schneiden, damit sie schlanke Apps haben, die eng gekoppelt sind. Dinge über das Internet zu integrieren ist heutzutage ziemlich einfach, sodass sie ein super modulares Design haben könnten.

Es sei denn, sie fangen damit an, sind die ursprünglichen Sünden immer noch da; der Ehrgeiz, das System für alles zu sein, plus der falsche Motor im Kern des Systems.

Conor Doherty: Nun, um auf einer positiven Note zu enden, gibt es konstruktive Ratschläge, die Sie mit den Menschen teilen können, damit sie vielleicht die, in Anführungszeichen, Minenfelder umgehen können, die einige dieser riesigen Unternehmen gemacht haben?

Joannes Vermorel: Ich meine, der wirklich positive Ausblick, und das macht mich sehr traurig, wenn ich diese Fehler sehe, ist, dass die Open-Source-Community etwas geliefert hat, das unglaublich großartig ist. PostgreSQL ist ein Wunder der Ingenieurskunst. Das ist Open Source. Das ist Magie.

Wir leben in einer Ära, in der, buchstäblich für den Preis, es nicht genau kostenlos ist - Sie müssen natürlich für Ihre Internetverbindung bezahlen - aber für einen unglaublich niedrigen Preis können Sie unglaublich gut konstruierte Systeme oder Ingenieursstücke haben, die Hunderte von Jahren einiger der brillantesten Ingenieure unseres Jahrhunderts repräsentieren. Das ist unglaublich, und Sie können das kostenlos bekommen. Das ist meine Meinung.