Warum supply chain digitale Transformationen scheitern (Eric Kimberling) - Ep 181

00:00:00 Eric Kimberling und Third Stage Einführung
00:04:31 Fokus auf Menschen statt Technologie in Projekten
00:06:14 Digitale Transformationen korrekt einordnen
00:08:08 Inkrementalismus in Transformationen überwinden
00:10:53 Anbietervoreingenommenheiten gefährden die Bemühungen
00:12:40 Herausforderungen bei erzwungenen Cloud-Migrationen
00:14:46 Geringer Nutzen beim Upgrade von Systemen oder Datensätzen
00:19:26 Systemsensitivitäten und Auswirkungen von Transformationen
00:21:38 Verwundbarkeiten großer Unternehmen in Transformationen
00:23:39 Führungsprobleme erhöhen die Risikoscheu
00:26:22 Mangel an strategischer Perspektive in Transformationen
00:29:42 Bedeutung von mechanischem Einfühlungsvermögen in der Führung
00:32:42 Datenlatenz hemmt verteiltes Rechnen
00:35:42 Hohe Kosten der Terabyte-Datenverarbeitung
00:38:38 Technologietransformations-Risikoanalyse
00:41:43 Visionäre Strategien für digitale Transformationen
00:44:25 Projektbudgets mit Erträgen in Einklang bringen
00:47:42 Realistische Kostenerwartungen in Transformationen
00:50:58 Überladung mit Softwarefunktionen hemmt die Produktivität
00:53:29 Fokus auf Geschäftsprozesse statt Technologie
00:56:39 Interne Steuerung technologischer Transformationen
00:59:45 Bürokratie bei der Umsetzung strategischer Planung
01:02:48 Governance verhindert Chaos in supply chain
01:06:27 Umfassende Neugestaltung für ambitionierte Transformationen
01:09:34 Optimierung von Capex für den Wert der supply chain
01:12:20 Ineffizienzen in aktuellen Transformationen
01:15:28 Nutzung von Anbieterdaten für Wettbewerbsvorteile
01:18:11 Finanzielle Anreize, die die Produktivität beeinflussen
01:21:13 Verfolgung vielversprechender Software-Technologieentwicklungen
01:23:19 Vermeidung kostspieliger Fehler durch Anerkennung versunkener Kosten

Zusammenfassung

Bei ihrer Diskussion über supply chain digitale Transformationen heben Eric Kimberling und Joannes Vermorel häufige Misserfolge hervor, die auf von Anbietern vorangetriebene Zwänge und falsch ausgerichtete Prioritäten zurückzuführen sind. Kimberling, der die Third Stage Consulting Group leitet, plädiert für technologieagnostische Strategien und stellt dabei die Geschäftsbedürfnisse über bloße Software-Upgrades. Er warnt vor vorschnellen, von Anbietern getriebenen Entscheidungen, die oft keine transformativen Ergebnisse liefern. Vermorel betont die Bedeutung, bestehende Systeme mit innovativen Zusatzlösungen zu erweitern, anstatt sie disruptiv zu ersetzen. Beide Führungskräfte unterstreichen, dass Transformationsbemühungen mit greifbaren Geschäftszielen in Einklang gebracht werden müssen, und heben das Veränderungsmanagement als entscheidend für den Erfolg hervor. Sie befürworten eine schrittweise, achtsame Einführung von Technologie, wobei sichergestellt wird, dass Ziele klar definiert und Risiken gemanagt werden.

Erweiterte Zusammenfassung

Wenn man untersucht, warum supply chain digitale Transformationen häufig scheitern, ist es unerlässlich, die von Branchenexperten wie Eric Kimberling und Joannes Vermorel in ihrem jüngsten Dialog, moderiert von Conor Doherty, geteilten Erkenntnisse zu berücksichtigen. Sowohl Kimberling als auch Vermorel verfügen über einen reichen Erfahrungsschatz in der Begleitung von Unternehmen durch die tückischen Gewässer technologischer Umwälzungen, und ihre Perspektiven offenbaren entscheidende Wahrheiten, die von Organisationen, die sich auf solche Unternehmungen einlassen, oft übersehen werden.

Eric Kimberling, ein Leuchtturm in der technologischen Vordenkerschaft, leitet die Third Stage Consulting Group – eine Firma, die sich der unabhängigen und technologieagnostischen Beratung von Organisationen verschrieben hat, die erfolgreiche digitale Transformationen anstreben. Seine Firma arbeitet unter einer klaren Mission: Kunden durch unparteiische Beratung zu stärken, die die Geschäftsbedürfnisse vor bloße technologische Upgrades stellt. Eric’s Ansatz verdeutlicht, dass Transformationen nicht nur auf technologische Lösungen fokussieren sollten, sondern vielmehr auf einen ganzheitlichen organisatorischen Wandel, der Prozess und Menschen über die Technologie stellt.

Das Gespräch rückt schnell den Begriff der “tech agnosticism” in den Mittelpunkt, ein Prinzip, von dem Kimberling behauptet, es sollte das Kernstück jedes erfolgreichen Transformationsprojekts sein. Er warnt vor von Anbietern getriebenen Vorurteilen, die Software-Upgrades gegenüber echten Geschäftsbedürfnissen bevorzugen – ein Gefühl, das auch Vermorel teilt. Anbieter drängen häufig auf rasche Upgrade-Zeitpläne – eine Strategie, die Unternehmen ungewollt in vorschnelle Entscheidungen verstrickt, die eher inkrementelle als transformative Verbesserungen hervorrufen. Eric warnt, dass solche unter Druck gesetzten Upgrades selten mit den langfristigen Zielen der Organisation übereinstimmen und oft den Wert schmälern, den eine digitale Transformation liefern soll.

Joannes Vermorel, Gründer von Lokad, unterteilt den Bereich der enterprise software in “systems of records”, “systems of reports” und “systems of intelligence” und argumentiert, dass Transformationen sich nicht einseitig auf systems of records konzentrieren sollten, die nur einen minimalen Mehrwert bieten. Sowohl Vermorel als auch Kimberling erkennen alternative Strategien von Unternehmen wie Palantir und Snowflake an, die bestehende Systeme verbessern, ohne dass ein disruptiver Ersatz erforderlich ist, und betonen den strategischen Vorteil, bestehende Infrastrukturen mit innovativen Zusatzlösungen anzupassen.

Ein wiederkehrendes Thema in ihrem Dialog zeigt, dass Großunternehmen besonders anfällig für kostspielige Fehlschläge bei digitalen Transformationen sind. Kimberling stellt fest, dass diese Fehltritte häufig aus komplexen Lösungen, hoher Risikoscheu und einem Mangel an entschlossener Verantwortlichkeit resultieren, was den intrinsischen Bedarf an mechanischer Neugier – ein Konzept, das Führungskräfte dazu auffordert, die digitalen Anforderungen ihres Unternehmens genau zu kennen – hervorhebt. Ohne diese Neugier scheitern Unternehmen, wenn sie zu stark auslagern und Anbieter eher als primäre Treiber denn als Unterauftragnehmer des Wandels behandeln.

Die Führungskräfte betonen die Bedeutung, digitale Transformationsstrategien mit greifbaren Geschäftszielen in Einklang zu bringen. Sie präsentieren die beunruhigende Aussicht auf aufgeblähte Budgets, die ERP Upgrades ohne klaren ROI zugeordnet werden – oder noch schlimmer, Projekte, die ROI und Nutzwertanalysen völlig vernachlässigen. Die Diskussion unterstreicht die entscheidende Bedeutung des Veränderungsmanagements – dem oft übersehenen Schlüsselfaktor für den Erfolg von Transformationen. Transformationen, die kulturelle Anpassung und umfassende Schulungen außer Acht lassen, sind ungeachtet der technischen Expertise zum Scheitern verurteilt.

Bei der Identifizierung von Erfolgsgeschichten unterstreichen Kimberling und Vermorel die Bedeutung von Klarheit und Kürze in Planungsdokumenten. Anstelle von umständlichen PowerPoints fördern prägnante Textpläne ein tieferes Verständnis und ermöglichen eine klarere Kommunikation unter den Stakeholdern. Sie preisen die Tugenden, Technologieinvestitionen wie Kapitalausgaben zu behandeln – sie als dauerhafte Vermögenswerte zu bewerten, statt sie lediglich als Betriebskosten abzutun.

Als der Dialog zu Ende geht, betont das Duo, dass obwohl tech-getriebene Transformationen potentielle Katalysatoren für die Geschäftsentwicklung sein können, ihr Erfolg von einer sorgfältigen Balance zwischen der Einführung von Software-Innovationen und der Förderung organisatorischen Wandels abhängt. Kimberling rät, diese Transformationen mit schrittweiser Achtsamkeit anzugehen und sicherzustellen, dass Ziele rigoros definiert werden, bevor die Implementierung beschleunigt wird. Vermorel stimmt zu und befürwortet inkrementelle Ansätze sowie einen “fail fast”-Ansatz, der Risiken dämpft und gleichzeitig Raum für Anpassungen lässt.

Durch ihren Austausch erhellen Kimberling und Vermorel den Weg für Organisationen, die digitale Transformationen in Betracht ziehen – und fordern Führungskräfte dazu auf, mehr als nur der Verlockung trendiger Technologien nachzujagen, indem sie stattdessen den Fokus auf die Ausrichtung dieser Projekte an den übergeordneten Geschäftszielen und Ambitionen legen.

Vollständiges Transkript

Conor Doherty: Willkommen zurück bei Lokad. Heute freue ich mich, ein Gespräch zwischen Eric Kimberling und Joannes Vermorel zu moderieren. Eric ist der CEO und Gründer von Third Stage Consulting Group und schließt sich uns an, um seine einzigartige Perspektive darauf zu teilen, warum so viele digitale Transformationen in supply chain scheitern. Falls euch gefällt, was wir bei Lokad machen, abonniert doch Lokad TV hier auf YouTube. Ich warte.

Okay, danke. Folgt uns auch auf LinkedIn, und damit präsentiere ich euch das heutige Gespräch mit Eric Kimberling. Zunächst einmal, Eric, vielen Dank, dass du heute dabei bist, und herzlich willkommen bei Lokad.

Eric Kimberling: Danke, dass ich hier sein darf. Es ist schön, hier zu sein.

Conor Doherty: Also, Eric, bevor wir in die eigentlichen Details des Gesprächs einsteigen, muss ich sagen, dass du online eine sehr beliebte Stimme bist. Tatsächlich bin ich zuerst über LinkedIn auf dich aufmerksam geworden. Du hast eine große Anhängerschaft und bist auch auf YouTube sehr aktiv. Unser Publikum ist hauptsächlich in Europa, daher kennt dich vielleicht nicht jeder. Kannst du daher einen kurzen Überblick für diejenigen geben, die nicht in Nordamerika sind? Was macht Third Stage Consulting Group, wie bist du hierher gekommen, etc.?

Eric Kimberling: Ja, Third Stage Consulting Group ist ein in den USA ansässiges Beratungsunternehmen für digitale Transformationen. Der Schlüssel zu unserem Geschäftsmodell liegt darin, dass wir unabhängig und technologieagnostisch sind. Wir unterstützen unsere Kunden während des gesamten Lebenszyklus – von der digitalen Strategie sowie Softwarebewertung und -auswahl über die Implementierungsplanung bis hin zum eigentlichen Implementierungsprogramm-Management und Veränderungsmanagement.

Wir haben fast 100 Berater. Tatsächlich haben wir ein kleines Büro in Europa, ansässig im Vereinigten Königreich, das die EMEA-Region betreut. Es stimmt also, dass wir in Europa noch nicht so präsent sind, aber unser Ziel ist es, in der EMEA-Region genauso stark vertreten zu sein wie in Nordamerika. Ich habe das Unternehmen wirklich 2018 gegründet, weil ich das Gefühl hatte, dass es nicht genug Berater gibt, die wirklich technologieagnostisch, objektiv und im Interesse der Kunden tätig sind.

Das ist also der Grund, warum ich das Unternehmen gegründet habe. Es sollte den Kunden eine Alternative zum typischen Beratungsmodell bieten.

Conor Doherty: Wenn du vom typischen Beratungsmodell sprichst, nehme ich an, dass Technologieagnostizismus ein wichtiger Bestandteil davon ist, aber könntest du erläutern, was du damit meinst? Es ist ein schöner Begriff, aber was genau verstehst du unter Technologieagnostizismus?

Eric Kimberling: Natürlich, tech atheism – mir gefällt dieser Begriff auch. Er ist sogar noch besser. Aber nein, technologieagnostisch bedeutet, dass wir nicht von den Softwareanbietern beauftragt werden. Mit anderen Worten, wir verdienen kein Geld, wenn die Anbieter Geld verdienen. Wir verdienen ausschließlich direkt von unseren Kunden. Und das ist eine wirklich wichtige Nuance, denn die meisten Beratungsfirmen werden entweder direkt von den Softwareanbietern dazu angereizt, den Software-Fußabdruck so weit wie möglich in einem Markt oder einer Region auszubauen.

Sie verfügen über einen Pool von Ressourcen, der sich auf eine bestimmte Technologie konzentriert, und ihr Ziel ist es, diese Berater in Projekten einzusetzen, die auf dieser einen Technologie basieren. Diese Voreingenommenheit schafft eine technologiezentrierte Denkweise bei Transformationen, während meiner Meinung nach die erfolgreichsten Transformationen – sei es bei supply chain Transformationen oder ERP-Implementierungen, was auch immer es sein mag – von den Geschäftsbedürfnissen getrieben sind und eine Strategie sowie einen Fahrplan definieren, der zu diesen Geschäftsbedürfnissen passt – und nicht damit beginnen, mit Technologie voranzugehen und dann zu versuchen, herauszufinden, wie sie überhaupt in Ihr Unternehmen passen könnte. Das mag wie ein sehr kleines Detail klingen, ist aber tatsächlich von großer Bedeutung und ein wesentlicher Faktor für den Erfolg oder Misserfolg auf dem Markt.

Conor Doherty: Nun, danke, und Joannes wird gleich zu dir kommen, aber ich denke, es wäre wichtig, die Grundlagen ein wenig zu erläutern, damit wir Technostizismus verstehen – danke! Wenn du von digitaler Transformation sprichst, sagst du, dass sie nicht nur auf ERPs beschränkt ist. Kannst du dafür einen kurzen Überblick für den weiteren Gesprächsverlauf geben? Handelt es sich bei digitaler Transformation um einen End-to-End-Prozess? Wie definierst du den Umfang dieser Idee?

Eric Kimberling: Wirklich, so definieren wir es: als technologische Ermöglichung im gesamten Unternehmen. Es geht nicht nur um Technologie; vermutlich ist sogar noch wichtiger der operative und organisatorische Aspekt, also die Prozess- und Mitarbeiterseite.

Wenn wir uns spezifische Technologien anschauen, fällen die meisten Menschen zunächst die Entscheidung, dass sie ihre Technologie ersetzen müssen. Das ist in der Regel die Problemstellung: “Wir müssen eine bestimmte Technologie ersetzen.” Diese Technologie könnte ein supply chain System sein, es könnte sich um ein ERP-System handeln, um ein CRM- oder Customer Relationship Management-System; es könnte ein HR-System sein, ein Finanzsystem oder, mittlerweile, angesichts der großen Bedeutung von KI, auch um KI, oder um business intelligence.

Es gibt all diese verschiedenen Technologien, aus denen man wählen kann. In unseren Augen ist der Begriff digitale Transformation ziemlich breit und vage. Er umfasst viele unterschiedliche Aspekte und Technologien, und was daran noch wichtiger ist, ist, dass der Begriff digitale Transformation etwas irreführend ist, weil er einen dazu verleitet zu denken, es ginge allein um Technologie. Tatsächlich geht es bei diesen Projekten meist viel stärker um die Verarbeitung von Menschen und weniger um Technologie.

Conor Doherty: Danke, Eric, und nun kommst du, Joannes. Eric hat Problemstellungen erwähnt. Ich weiß, dass ein besseres Verständnis der Problemstellung grundsätzlich die Grundlage für alles bildet, was man erreichen möchte. Wie passen deine Gedanken dazu in dein Verständnis von digitaler Transformation?

Joannes Vermorel: Ich stimme absolut zu, was die Bedeutung von Technologieagnostizismus angeht, wenn man gute Beratung bieten will. Es ist absolut grundlegend; andernfalls wird das Problem buchstäblich so formuliert, dass alles, was den Fußabdruck von jemandem vergrößert, der bereits als Anbieter Fuß in der Tür hat, berücksichtigt wird. Das würde dazu führen, dass das Projekt in die Frage mündet, wie wir das ERP dieses Anbieters von Version N auf N+1 upgraden. Am Ende gleicht das einem Rezept für massive Investitionen bei nur sehr geringem Ergebnis.

Die Anreize unterschätzen nicht die Macht des Anreizes, das anfängliche Problem korrekt zu umrahmen. Es mag sich nach sehr wenig anhören, aber was ich beobachtet habe, ist, dass diese wenigen Entscheidungen, die typischerweise sehr früh im Prozess getroffen werden, dann völlig den Rahmen für die Millionen Dollar setzen, die in den folgenden Jahren ausgegeben werden. Also stimme ich voll und ganz zu, dass es absolut grundlegend ist, die Seite des Geschäfts einzunehmen. Was wollen wir liefern, ohne schon die Frage zu stellen, welcher Anbieter? Und dann gibt es die Nebenfrage, die wirklich – und ich stimme auch sehr Ihrer Vision zu –, dass digitale Transformation tatsächlich darum geht, was für ein Unternehmen wir werden, wenn wir Dinge besser mit diesen schickeren Werkzeugen und dergleichen machen können.

Im Gegensatz dazu, anstatt an einen linearen Fortschritt von Version N zu Version N+1 zu denken – und das ist normalerweise eine sehr knifflige Frage, denn zum Beispiel könnte man denken: “Okay, wir haben so viele Leute, die dies und das machen,” – stellte sich heraus, dass wir, wenn wir besser organisiert wären, diese Dinge vielleicht überhaupt nicht erst tun müssten. Es hat also keinen Sinn, zu versuchen, das zu optimieren, was sie tun, denn die beste Organisation müsste das von vornherein gar nicht erst machen. Ich sehe das als eine Herausforderung, wirklich über das Geschäft nachzudenken. Was erreichen Sie eigentlich?

Und dann müssen Sie ein gutes Verständnis der Technologie haben, was sie kann und was nicht. Aber ich würde sagen, es ist eine untergeordnete Rolle im Vergleich zu einem sehr klaren Verständnis des Geschäfts und dessen, was Sie zu erreichen versuchen. Diese Rahmung gefällt mir sehr gut, und ich glaube, dass für mich die größte Herausforderung der meisten Unternehmen – ich denke in Europa, aber vielleicht auch in den USA in gewissem Maße – in dieser digitalen Transformation der Fluch des Inkrementalismus ist. Sie denken wirklich immer an dasselbe plus ein paar zusätzliche Features, oder “wir hätten gerne das gleiche ERP, aber mit einer Webschnittstelle statt einer Desktopoberfläche” oder so.

Und für mich, ja, das wäre zwar nett, aber grundsätzlich rechtfertigen die Art von Kapitalrendite dieser sehr teuren Projekte das nicht. Man aktualisiert ein ERP nicht, weil man seine hässliche Schnittstelle satt hat. Wenn es funktioniert, funktioniert es – auch wenn es nicht gut aussieht. Wenn Sie ein Upgrade vornehmen und Jahre damit verbringen, müssen Sie etwas haben, wodurch Ihr Unternehmen danach viel besser dasteht, und nicht nur ein hübscheres Werkzeug, sondern dass das Unternehmen selbst zu etwas anderem geworden ist. Das wäre für mich die wahre Bedeutung einer echten und korrekt ausgeführten digitalen Transformation.

Eric Kimberling: Ja, das ist ein großartiger Punkt, denn Sie haben darin eine Reihe wirklich guter Argumente aufgeführt. Eines davon ist, dass Sie über die Planung und die frühen Entscheidungen gesprochen haben, die getroffen werden, und wie diese den Kurs für das Projekt festlegen. Das ist sehr wahr, und viele Organisationen haben, denke ich, das Gefühl, dass sie diese Entscheidungen einfach überstürzen, direkt ins Projekt einsteigen und dann während des Projekts alles klären. Und genau da wird es chaotisch und es fehlt an klarer Richtung.

Aber das andere, worauf Sie anspielen, ist, dass es manchmal in Ordnung ist zu sagen, wir werden unsere Technologie nicht aktualisieren. Was, wenn Sie nicht auf das neueste, schickste System umsteigen? Was, wenn Sie stattdessen das, was Sie haben, optimieren? Was, wenn Sie sich darauf konzentrieren, Ihre Geschäftsprozesse zu optimieren? Was, wenn Sie Ihre Mitarbeiter darin schulen, die Software besser zu nutzen? Was, wenn Sie all diese kostengünstigen Maßnahmen ergreifen, die dem Unternehmen extrem viel Wert und ein geringes Risiko bieten? Warum nicht diese Option in Betracht ziehen?

Nun, Softwareanbieter würden mir vehement widersprechen. Wenn ich ein Softwareanbieter wäre, würde ich sagen, das ist eine schreckliche Idee; Sie müssen all Ihre Technologien aktualisieren, Sie müssen in die Cloud wechseln, Sie brauchen KI, Sie brauchen all diesen Kram, weil ich Ihnen Technologie verkaufen möchte. Aber wenn man einen Schritt zurücktritt und die Emotion aus der Gleichung nimmt und den Anbieter-Bias ignoriert, kommen viele Organisationen zu dem Schluss: “Wissen Sie was? Wir müssen nicht überstürzt in die Cloud wechseln, nur weil uns unser Anbieter sagt, dass wir eine Frist einhalten müssen.”

Und ich denke, es ist wirklich wichtig, dass Sie die Transformation selbst in die Hand nehmen und sie basierend auf den Bedürfnissen Ihres Geschäfts, Ihrer Prioritäten und Strategien gestalten – nicht auf Basis der Softwareanbieter.

Conor Doherty: Eric, wenn ich darauf kurz aufbauen darf – und ich will Ihnen keine Worte in den Mund legen – impliziert das, dass die Leute vielleicht von Beratern oder Anbietern ein wenig in die Irre geführt werden und das zu Misserfolgen bei digitalen Transformationen führt? Wenn nein, was sehen Sie als einige der häufigsten Gründe dafür, dass digitale Transformationen scheitern?

Eric Kimberling: Ja, das ist eine großartige Frage. Wir könnten das ganze Interview lang über diese eine Frage sprechen. Aber um es zusammenzufassen: Ja, die Vorurteile sind mit Sicherheit beitragende Faktoren für das Scheitern. Wenn ich ein Softwareberater bin und mit einer kurzsichtigen Ansicht hereinkomme, dass dies die Technologie ist, die in Ihre Organisation passt, haben Sie von Anfang an eine Diskrepanz, weil ich nicht mit Ihrem Geschäft starte, sondern mit meiner Technologie.

Meine Technologie hat Best Practices; meine Technologie hat integrierte Workflows; Sie müssen sich an meine Software anpassen, weil sie großartig ist. Das ist einfach ein sehr disruptiver Prozess deswegen. Also denke ich, dass dieser Bias ein Teil davon ist – ein großer beitragender Faktor. Aber was ich für noch einen viel größeren beitragenden Faktor halte, den viele nicht erkennen, ist, dass viele dieser großen Softwareanbieter, wie wenn man an SAP oder Microsoft denkt, im Grunde genommen ihre Kunden zwingen, auf neue Technologie umzusteigen, indem sie sagen: “Wir werden den Wartungs- und Supportservice für Ihr altes System einstellen; wir nehmen ihn zu diesem Datum weg, und Sie haben bis zu diesem Datum Zeit, auf das neue System umzusteigen, sonst lassen wir den Support fallen.”

Und ich denke, das ist extrem unüberlegt; es ist keine kundenorientierte Problemstellung. Es ist im Grunde, als würde man ein Anbieterproblem nehmen und es zum Problem des Kunden machen. Das eigentliche Anbieterproblem lautet: Wir müssen in die Cloud wechseln, weil es für uns profitabler ist; unsere Investoren fordern es. Also wird dieses Problem zum Kundenproblem, denn nun sagen sie: “Hey, ich weiß, vielleicht haben Sie vor zwei Jahren gerade eine On-Premise-Lösung implementiert, aber wissen Sie was? Wir stellen den Support für dasselbe System ein, das Sie gerade implementiert haben; in zwei oder drei Jahren stellen wir den Support ein, und bis dahin müssen Sie auf das neue System umsteigen.”

Das erzeugt in Organisationen eine überstürzte Panik, und das ist der schlimmste Ort, an dem man sich befinden kann, wenn man versucht, diese Transformation durchzuführen – denn es führt zu all den Dingen, die Sie erwähnt haben, nämlich dass man einfach diese inkrementellen Verbesserungen vornimmt. Man gibt all diese Zeit, Geld und Risiken aus, nur um vielleicht ein paar geringfügige Verbesserungen im Geschäft zu erzielen, und es ist schwer, die Rendite zu rechtfertigen, wenn man diesen Prozess verfolgt.

Conor Doherty: Joannes, ich weiß, Sie sind ein großer Fan von Anbietern und verteidigen sie kompromisslos, aber darf ich Sie um einen Kommentar dazu bitten?

Joannes Vermorel: Ja, ich meine, meine Sichtweise ist, dass die Softwareindustrie – ich sehe die Welt der Unternehmenssoftware übrigens in drei verschiedene Königreiche aufgeteilt – wir haben Systeme der Aufzeichnungen, Systeme der Berichte und Systeme der Intelligenz. Systeme der Aufzeichnungen betreffen im Wesentlichen Dateneingaben und Workflows. Das umfasst alles, was zum Management in einem System der Aufzeichnungen gehört, das CRM, ERP (welches eigentlich ERM, Enterprise Resource Management, heißen sollte, da Planung nur zweitrangig ist), TMS, Transportmanagementsysteme usw. sind. All diese Managementsysteme sind Systeme der Aufzeichnungen.

Meine Auffassung ist, dass sobald Sie ein System der Aufzeichnungen haben, das einigermaßen passt, funktioniert und nicht allzu träge ist, dann sind Sie in Bezug auf diese Ebene quasi fertig. Was ich als digitale Transformation sehe, ist, dass die Leute versuchen, Dinge zu verbessern, die eigentlich kaum verbesserbar sind. Wenn Sie zum Beispiel Buchhalter sind, haben Sie bereits ein Hauptbuch, es ist gut, es ist vielleicht nicht schick, aber enthält dieses Hauptbuch alles, was Sie brauchen? Ja, und genau das sind Systeme der Aufzeichnungen.

Systeme der Aufzeichnungen sind es, und so sehe ich bei diesen digitalen Transformationen, dass viel darüber diskutiert wird, Systeme der Aufzeichnungen zu aktualisieren, die bereits alles erfassen, was sie sollten. Für mich ist der Mehrwert dieser Art von Transformation, die typischerweise über 80 % des Budgets verschlingt, nahezu null, weil Ihre Workflows bereits vorhanden sind. Sie funktionieren schon. Ihre Software – ich meine, die nächste Schnittstelle wird nichts verändern, da es um Dateneingaben und Ähnliches geht.

Und wenn Sie das haben, und es funktioniert, und es erfasst funktional alles, was benötigt wird, dann sind Sie quasi fertig. Und ich denke, dass der Fluch dieser Unternehmensanbieter darin besteht, dass sie – besonders Unternehmen wie SAP – erkennen, dass sie einen Punkt erreicht haben, an dem der Job erledigt war. Mission erfüllt für das System der Aufzeichnungen vor zwei Jahrzehnten.

Und nun, und übrigens, Sie können alle Bewegungen von SAP HANA dahingehend erklären, “Oh, lasst uns dieses System transformieren,” also ein System der Aufzeichnungen in ein System der Berichte mit allen möglichen analytischen Ebenen umzuwandeln. Aber meine Analyse ist, dass man einfach zu seinen Prinzipien stehen sollte. Sie sind ein System der Aufzeichnungen. Und wenn Unternehmen es so betrachten, sagen sie dann: “Wir sollten nicht investieren, weil die nächste Version nur Fehler, Regressionen und neue Schulungen bringt – sofern die alten Systeme nicht unerträglich waren, weil sie viel zu langsam, viel zu fehlerhaft waren oder nicht einmal die Aufzeichnungen erfassen konnten, die wir benötigten. Dann gibt es keinen Mehrwert.”

Und für uns in der supply chain ist es wirklich wichtig, denn ich sehe viele Kunden, die Bestandsverwaltungssysteme haben, die etwa 30 Jahre alt sind. Sie zeigen nur schwarz-weißen Text auf Konsolen, aber funktional erfüllen sie 100 % das, was diese Unternehmen brauchen. Und Bestandsverwaltung, wissen Sie, ist keine Raketenwissenschaft. Ich nehme etwas plus/minus eins vom Regal. Ich lege etwas ins Regal plus eins.

Also diese Software ist veraltet, und funktional erledigt sie 100 % das, was benötigt wird. Hierbei handelt es sich um Fälle, bei denen es für mich nicht zum gewünschten Ergebnis führt, wenn man eine Menge Geld ausgibt, nur um diese Systeme zu aktualisieren, so wie viele denken, dass sie dadurch den erhofften Nutzen erhalten.

Eric Kimberling: Ich stimme zu. Und ich glaube, deshalb gibt es Unternehmen wie Palantir und Snowflake – einige dieser Bolt— ich möchte nicht sagen, es sind Bolt-On-Systeme, aber es sind Systeme, die darauf ausgelegt sind, mit anderen Systemen der Aufzeichnungen zu interagieren. So könnten Sie sagen: “Nun, mein System der Aufzeichnungen ist vielleicht veraltet, aber es funktioniert, und ich möchte nicht all das Risiko, die Kosten und den Aufwand auf mich nehmen, dieses System der Aufzeichnungen zu ersetzen.” Aber ich möchte bessere Berichte. Ich möchte bessere Intelligenz. Vielleicht möchte ich einige KI-Funktionen. Aber ich will das ohne… ich muss das Back-Office-System der Aufzeichnungen nicht herausreißen.

So haben Unternehmen wie Palantir, Snowflake und andere Lösungen entwickelt, die sagen: “Behalten Sie Ihr altes System. Es ist uns egal. Wir bieten Ihnen eine Lösung an, die daran nichts ändert. Stattdessen baut sie darauf auf und liefert Ihnen bessere Workflows, bessere KI, bessere Berichterstattung, bessere Intelligenz und all das.”

Also denke ich, dass Sie recht haben. Das sind die Optionen, die vielen Organisationen und Teams oft nicht bewusst sind. Sie haben Möglichkeiten, weil sie von anderen Anbietern hören, die sagen: “Nein, nein, nein, Sie müssen Ihr System der Aufzeichnungen ersetzen, weil es auf veralteter Technologie basiert. Sie haben technische Schulden. Sie werden zurückfallen.” Wissen Sie, es ist ein Verkauf, der auf Angst basiert – und es funktioniert.

Glücklicherweise funktioniert das für die Anbieter. Unglücklicherweise funktioniert es für die Kunden. Daher denke ich, der Schlüssel ist, sich selbst zu bilden, objektiv zu bleiben und sich eine externe, objektive Meinung einzuholen, was Ihre wirklichen Optionen sind, denn es könnte sein, dass Sie Ihr System der Aufzeichnungen beibehalten, aber etwas hinzufügen, das Ihnen mehr Möglichkeiten bietet – ohne all das Risiko.

Joannes Vermorel: Schamloser Plug, das ist genau das Geschäftsmodell von Lokad. Es ist genau wie bei Palantir oder Snowflake ausgerichtet. Wir machen genau das aus diesen Gründen. Aber natürlich wollte ich Sie nicht dazu zwingen, das zu sagen. Aber ja, das ist mein Punkt. Das Problem mit diesen Systemen der Aufzeichnungen ist, dass, wenn man sie anfasst, der Umfang der Disruption für die Organisation immens ist.

Man kann einen Snowflake an- und ausschalten, der nebenbei Analysen durchführt – kein großes Problem, bis man wirklich von ihm im täglichen Betrieb abhängig wird. Aber bis dahin können Sie dieses System so oft an- und ausschalten, wie Sie möchten. Anders als bei einem System der Aufzeichnungen, bei dem, wenn man es anfasst und es zusammenbricht, dann bricht die Hölle los, weil man plötzlich nicht weiß, wem man zahlen soll – ob es Ihre Lieferanten sind, oder wer Ihnen Geld schuldet von Ihren Kunden usw.

Also sind Systeme der Aufzeichnungen eine Schicht, die viel sensibler und heikler ist. Und deshalb würde ich sagen, dass der Aufwärtsteil nicht so groß ist, denn wenn Sie etwas haben, das funktional bereits zufriedenstellend ist, wird das Upgrade nicht viel bewirken. Aber der Abwärtsteil, wenn es kaputt geht, kann absolut immens sein.

Kürzlich in Frankreich hatten wir ein großes Unternehmen, das einfach bankrottging – GiFi – allein aufgrund einer, ich habe das hier direkt vor mir, schlecht gemanagten digitalen Transformation. Ein Milliardenunternehmen, das wegen einer misslungenen digitalen Transformation Insolvenz anmelden musste.

Eric Kimberling: Sagen wir, es ist auch ein großes, in Frankreich bekanntes Unternehmen, oder?

Joannes Vermorel: Ja, es war, sagen wir, eines der Top-Ten landesweiten Einzelhandelsnetzwerke.

Conor Doherty: Das ist eigentlich ein perfekter Übergang, denn ich wollte tatsächlich etwas ansprechen, worüber Sie oft kommentieren, Eric – nämlich Beispiele von großen Unternehmen, die jeder kennt. Eigentlich habe ich hier vor mir eine Liste. Sie haben zum Beispiel über Lidl geschrieben und gesprochen. Ich habe es hier: 600-Millionen-Fehlschlag beim Versuch, ihr ERP-System zu transformieren. Entschuldigung. Aber es gibt weltweit Beispiele, nicht nur in Europa.

Da gibt es DHL, das Hunderte von Millionen verliert, Lidl in Deutschland, das eine halbe Milliarde verliert, Asda, GE, Spar. Tatsächlich erinnere ich mich, dass ich auch ein Video von Ihnen über Spar gesehen habe. Also wieder: Das sind riesige Unternehmen, sodass es nicht nur auf Europa oder nur Frankreich, zum Beispiel, oder nur Washington beschränkt ist. Es ist nahezu ein systemisches Phänomen.

Nun, ich will Ihnen nicht in den Mund legen, aber falls es tatsächlich bei großen Unternehmen systematisch auftritt, stellt sich die Frage, ob es etwas Einzigartig Verletzliches an großen Unternehmen gibt, das einfach dazu führt? Fehlt es ihnen an Agilität oder was? Warum verlieren diese großen Unternehmen so viel Geld?

Eric Kimberling: Das ist eine großartige Frage. Zunächst einmal weiß ich es nicht. Ich könnte es Ihnen auch nicht sagen. Ja, ich vermute, dass es bei großen Unternehmen wahrscheinlich etwas höhere Ausfallraten gibt, obwohl ich sagen muss, dass auch viele kleine und mittelständische Unternehmen scheitern. Der einzige Unterschied ist, dass man nichts von ihnen hört, weil es niemanden interessiert.

Man hat noch nie von diesen Unternehmen gehört, aber von Lidl schon. Von der Spar Group schon. Von Asda oder welcher großen Marke auch immer. Aber um Ihre Frage zu beantworten, warum große Unternehmen anfälliger für diese Fehlschläge sind, würde ich sagen, dass die Dynamiken, die bei einem großen Unternehmen am Werk sind, das Scheitern begünstigen – teilweise aufgrund des organisatorischen Verhaltens. Teilweise liegt es daran, dass ein großes Unternehmen beispielsweise eher dazu neigt, eine große, komplexe Lösung zu implementieren, weil es ein großes, komplexes Unternehmen ist und das Gefühl hat, eine noch größere, komplexe Lösung zu benötigen.

Sie neigen also eher dazu, ein SAP- oder ein Oracle-System oder ein anderes großes System zu kaufen. Das ist also ein Risikofaktor. Dadurch steigt Ihr Risiko sofort, weil Sie jetzt ein großes, komplexes System implementieren wollen.

Eine weitere Dynamik, die bei großen Unternehmen häufiger auftritt als bei kleineren, ist – sagen wir mal – der Mangel an Verantwortlichkeit. Auf der Führungsebene gibt es weniger Transparenz und Verantwortlichkeit. Oft haben diese Führungskräfte so viel zu tun. Sie expandieren. Sie erobern neue Märkte und kaufen Unternehmen. Sie konzentrieren sich auf diese strategischen Dinge und betrachten digitale Transformation als etwas Unstrategisches, was ein Fehler ist.

Und sie delegieren das in der Organisation weiter. Dieser Mangel an Führungsverantwortung, Transparenz, Sichtbarkeit und Akzeptanz – eben das fehlende Engagement der Führungskräfte – führt zum Scheitern. Das ist eine der großen Ursachen. Und dann würde ich noch eine dritte Sache, eine dritte Dimension nennen, die gegen große Unternehmen arbeitet: Große Unternehmen sind so risikoscheu, dass sie ironischerweise das Risiko sogar erhöhen.

Und damit meine ich, dass sie sagen: “Nun, wenn ich SAP implementiere, ist SAP ein bekanntes Produkt. Wenn ich Accenture, Deloitte oder KPMG beauftrage, handelt es sich um sehr bekannte Firmen. Also werde ich auf Nummer sicher gehen und dafür sorgen, dass ich die Blue-Chip-Namen beauftrage, die mir das Gefühl geben, dass sie die Experten sind, die das bewältigen können.”

Und was dann passiert, ist, dass Sie ein offenes Scheckbuch haben und der Systemintegrator Ihr Projekt übernimmt, weil Ihre Führungskräfte nicht stark eingebunden sind und den großen Markennamen vertrauen. Und diese großen Unternehmen werden den Weg der Technologisierung einschlagen und die Dinge überkomplizieren, selbst wenn das für Ihr Geschäft nicht unbedingt sinnvoll ist, weil das das ist, was sie kennen. Das tun sie eben.

Das tun sie, und ich glaube nicht, dass es tatsächlich etwas böswillig Intentioniertes ist. Aber ich denke, dass der Mangel an Verantwortung und Transparenz dazu führt, dass Menschen ihren eigenen Interessen nachgehen, was dazu führt, dass Anbieter und Systemintegratoren, die ihre eigenen Interessen verfolgen, Ihnen mehr Software verkaufen wollen. Sie wollen Ihnen mehr Stunden in Rechnung stellen, und der ROI spielt dabei überhaupt keine Rolle. Es ist egal, ob es einen Mehrwert liefert oder nicht. Sie werden bezahlt.

Die Anreize sind also nicht ausgerichtet. Bei einem großen, komplexen Unternehmen werden diese Dimensionen verstärkt, weil es ein größeres Unternehmen ist und mehr auf dem Spiel steht. Ich denke, diese drei Dinge sind wahrscheinlich die drei wichtigsten Punkte, die mir einfallen, wenn es darum geht, was bei einem großen Unternehmen stärker gegen es arbeitet als bei einem kleineren. Allerdings muss ich sagen, dass auch kleine und mittelständische Unternehmen scheitern können, wenn sie nicht die grundlegenden Prinzipien befolgen.

Und die gute Nachricht ist, dass es keine Raketentechnik oder geheime Formel gibt, um diese erfolgreich zu gestalten. Es ist eigentlich ziemlich einfach, aber Organisationen nehmen sich nicht die Zeit, anzuhalten, nachzudenken und von Anfang an die richtigen Entscheidungen zu treffen. Das führt zu vielen der Probleme, über die wir sprechen.

Conor Doherty: Danke, Eric. Joannes, du hast einmal oder zweimal über Bürokratie in großen Unternehmen kommentiert. Könntest du diese Gedanken wiederholen?

Joannes Vermorel: Ja, ich meine, meiner Meinung nach können kleine Unternehmen scheitern, weil ihnen die Ressourcen fehlen, um Experten und dergleichen zu haben. Ich glaube, dass große Unternehmen, obwohl sie alle Experten haben, oft scheitern, weil diese mit einer Agenda kommen. Alle diese Experten werden eingestellt und bringen allerlei Agenden mit.

Manchmal handelt es sich, würde ich sagen, um ziemlich dumme Agenden, wie dass Leute einfach eine neue Technologie ausprobieren wollen, weil sie gut im Lebenslauf aussieht. Unterschätzen Sie daher nicht auch die Tatsache, dass Technikfreaks technologische Dinge einfach aus dem Grund tun, weil sie experimentieren und basteln wollen.

Aber auch denke ich, dass ein Problem darin besteht – wie du schon angemerkt hast – dass digitale Transformation nicht als strategisch angesehen wird. Als Kaskadeneffekt davon haben sie kein, ich habe häufig gesehen, dass das Top-Management in großen Unternehmen keine mechanical sympathy hat.

Was meine ich also mit mechanical sympathy? Sie zeigen keinerlei Neugier dafür, was unter der Haube vor sich geht, wie diese Dinge verdrahtet sind, worum es überhaupt geht. Ich rede nicht davon, ein Experte im Software-Engineering zu sein, aber reden wir hier einfach von etwas, das wie eine primitive App ist – create, read, update, delete in einer Datenbank, die zufällig aus vielen Tabellen besteht?

Oder brauchen wir Echtzeit? Was meinen wir mit Echtzeit? Brauchen wir Mikrosekunden, Millisekunden, Sekunden oder Stunden? Brauchen wir so etwas wie usw., usw.? Ich meine, es gibt viele Fragen, die relativ grundlegend sind, aber wenn Sie so etwas wie keinerlei mechanical sympathy haben, dann sind die Objekte oder Softwareobjekte, mit denen Sie arbeiten, völlig abstrakt.

Und für Sie sind es eine Reihe von Codenamen, die überhaupt keinen Sinn ergeben. “Oh, wir brauchen das Widget ABC20, aber damit ABC20 funktioniert, müssen wir auch Contoso12 upgraden.” Und Contoso12, oh, das braucht auch noch Teil Nummer sieben, usw., usw.

Ich meine, das ist wie eine lange Liste von Codenamen, die keinen Sinn ergeben. Wenn Sie dann eine derartige Umgebung haben, die, würde ich sagen, sich sehr leicht einer technokratischen Übernahme öffnet – wissen Sie, die geschäftliche Perspektive wird vollkommen vernachlässigt, einfach weil Geschäftsleute ihre Ansprüche komplett aufgegeben haben, da sie keine mechanical sympathy besitzen. So können sie nicht einmal in der Lage sein, eine Meinung darüber zu äußern, ob die Dinge grundsätzlich in eine Richtung gehen, die mit dem Geschäft in Einklang steht oder nicht.

Entschuldigung, das ist eine lange Antwort, aber diese Komponente der mechanical sympathy habe ich bei vielen, vielen Unternehmen vermisst. Und es erfordert nicht so viel Fachwissen. Wissen Sie, es ist wie bei einem Autofan: Er nimmt sich einfach ein wenig Zeit, um zu wissen, was unter der Haube vor sich geht, damit es nicht wie pure Magie wirkt, wenn das Auto vorwärts fährt. Es gibt ein gewisses Verständnis für die grundlegenden Bausteine, die das Ganze bewirken.

Eric Kimberling: Ja, absolut. Das ist ein interessanter Begriff. Ich hatte noch nie vom mechanical curiosity gehört, und ich denke, es führt zurück zu einem Punkt, den ich oft anspreche. Ich glaube, sie sind stark miteinander verbunden, und das ist die allgemeine Verantwortung und Neugierde für das Produkt insgesamt.

Und so denke ich, dass das das umfasst, was du sagst, nämlich die mechanical curiosity. Aber ich denke, du hast hier einen Punkt erkannt: Wenn man nicht das tut, was du gerade über diese mechanical curiosity gesagt hast, dann gibt es keine Möglichkeit, die Verantwortung und die nötige Intelligenz zu haben, um intelligente Entscheidungen in diesen Projekten zu treffen.

Und wenn man nicht diese praktische Neugier und Erfahrung besitzt, muss man nicht so erfahren sein wie die Experten, aber zumindest so erfahren, dass man diese Experten managen kann, denn es ist Ihre Aufgabe, sie zu führen. Sie sollten Sie nicht managen, nur weil sie die Experten sind. Es ist Ihr Unternehmen. Sie sind es, der die Ergebnisse tragen muss, also führen Sie sie entsprechend.

Es erstaunt mich, wie viele dieser großen Organisationen sagen: “Ich bin kein Technikexperte. Ich bin nicht verantwortlich, ich lasse die Experten das übernehmen.” Aber es ist eine Geschäftstransformation, und wenn Sie es richtig machen, ist es tatsächlich eine Geschäftstransformation, und Sie müssen sich einbringen, sehr engagiert.

Auch wenn Sie nicht in die technische mechanical curiosity involviert sind, sollten Sie zumindest an der operativen Neugier beteiligt sein. Was wird das für meine Organisation bedeuten? Wie werden meine Abläufe aussehen? Wie werden die Arbeitsplätze der Menschen beeinflusst? Möchte ich das so, ist das in Ordnung, oder will ich etwas anderes?

Und wenn Sie daran nicht beteiligt sind, wird der Systemintegrator unweigerlich das kreieren, was seiner Meinung nach richtig ist, und das wird einfach nicht mit Ihrer Vision und Strategie übereinstimmen.

Conor Doherty: Wenn ich auch etwas hinzufügen darf, nur weil ich beiden zustimme, wollte ich nur kurz anmerken, dass ich euch schon ein paar Mal über mechanical sympathy sprechen gehört habe. Kürzlich in einem anderen Podcast mit dem Supply Chain Connect – Gruß an alle – habe ich genau über dieses Konzept gesprochen.

Es gab zwei wirklich gute Punkte, die direkten Vorteile von mechanical sympathy. Offensichtlich, wenn man ein wenig über die Software versteht, weiß man, wie man sie besser nutzen kann, wodurch sich der direkte ROI der Nutzung erhöht. Aber es schützt Sie auch vor fragwürdigen Behauptungen der Anbieter.

Und das hattest du schon vorher gesagt, dass ein gewisses Verständnis dafür, was entworfen wird und was die Software leisten kann, Sie möglicherweise vor irreführenden Ansprüchen der Anbieter schützen kann.

Joannes Vermorel: Ja, ich meine, nur als Beispiel: Nehmen wir zum Beispiel LLMs. Okay, KI ist großartig, fantastisch, also haben wir diese großen Sprachmodelle. Was kostet es, einen Megabyte an Daten in ein LLM einzuspeisen, nur mal grob geschätzt?

Grob gesagt kostet ein Megabyte, selbst wenn man ein günstiges Modell nimmt, sozusagen etwa 1 Dollar, und das ist im unteren Bereich. Jedes Mal, wenn Sie eine Antwort erhalten wollen und einen Megabyte an Daten als Input in Ihr LLM einfließen lassen müssen, kostet das Sie 1 Dollar, selbst mit dem günstigsten Modell.

Wenn Sie diese Zahl im Kopf haben, wissen Sie, dass es viele Dinge gibt, die sofort verfügbar sind und wahrscheinlich mehr als ein Jahrzehnt lang unsichtbar bleiben. Denn wenn Sie denken: “Okay, ich habe Terabytes an Daten, also werde ich diese nicht zuerst durch LLMs verarbeiten.”

Und dann müssten Sie jedes Mal, wenn jemand klickt, 1 Dollar bezahlen. Ich meine, wenn man das einfach mit grundlegender Mathematik berechnet, kommt man zu dem Schluss: “Okay, das kann nicht funktionieren. Es ist wirtschaftlich nicht tragbar.”

Selbst wenn der Preis um den Faktor 100 sinkt, liegen wir immer noch mit vier Nullen daneben, wenn es um etwas Sinnvolles geht. Nur ein Beispiel, und ich habe viele Situationen erlebt, in denen ich mit potenziellen Kunden darüber gesprochen habe – nehmen Sie einfach ein paar grundlegende Größenordnungen, damit wir wissen, wovon wir sprechen.

Das Gleiche gilt zum Beispiel für verteiltes Rechnen. Verteiltes Rechnen ist stark durch die Lichtgeschwindigkeit begrenzt. Leute sagen: “Warum sollte ich die Lichtgeschwindigkeit kennen?” Aber die Antwort ist, wenn Sie ein System haben, bei dem Ihr warehouse mit Ihrem zentralen System kommuniziert und Informationen hin und her fließen, haben Sie eine Latenz von 200 Millisekunden.

Man merkt einfach, dass man tausend Roundtrips benötigt, um etwas zu erreichen. Dann reden wir schon von 200 Sekunden allein für die Roundtrips. Es ist wieder keine hochkomplizierte Mathematik, aber es zeigt, dass wir ein Designproblem haben.

Man muss kein fortgeschrittener Ingenieur sein, wir sprechen hier einfach von einfacher Multiplikation, von ein paar Grundlagen. Ich habe viele Projekte bei unseren Kunden gesehen, die einfach zum Scheitern verurteilt waren, weil einige grundlegende Faustregelberechnungen nicht durchgeführt wurden.

Dann würden die Leute erkennen, dass es angesichts der Geschäftsziele einfach nicht funktionieren würde. Denn der Technologe könnte sagen: “Nun, es wird 200 Sekunden dauern. Viele Berechnungen brauchen Zeit, warum also nicht 200 Sekunden?”

Aber derjenige würde sagen: “Nein, das ist etwas, worauf ein Bediener wartet, also ist es gar nicht möglich.” Oder das LLM würde sagen: “Oh, ein Megabyte kostet 1 Dollar.” Der Ingenieur würde sagen: “Ja, warum nicht? Es ist ja nur ein Preis, das ist mir egal.”

Ist egal, und dann sagt das Geschäft: “Aber wissen Sie, dass eine Person, die etwa 20 Dollar pro Stunde verdient, dieses Ding 60 Mal pro Stunde anklicken wird?” Also werden Ihre LLM-Kosten etwa das Vierfache dessen betragen, was wir demjenigen zahlen, der es bedient.

Wiederum – das ist einfach – aber dennoch ist das der einzige Weg, um sicherzustellen, dass es irgendwie Sinn macht: Wenn das Geschäft mit etwas mechanical sympathy, einer entsprechenden Rahmung des Projekts und des beabsichtigten Mehrwerts einbezogen wird, macht das Sinn. Das wäre meine Einschätzung.

Eric Kimberling: Ja, und einfach diese versteckten Kosten zu verstehen und all die Dinge, die auf den ersten Blick so aussehen, als würden sie Ihr Geschäft tatsächlich verbessern. Vielleicht verbessert es Ihr Geschäft, aber wenn es Ihre Kosten dramatisch und erheblich erhöht, werden Sie wahrscheinlich nicht den ROI erzielen, den Sie sich erhoffen.

Joannes Vermorel: Ja, und unterschätzen Sie nicht, wie – das ist meine Erfahrung mit Ingenieuren – wie Ingenieure Ihnen fünf präzise Zahlen geben können, aber das Komma ist einfach ein wenig falsch gesetzt in der Berechnung.

Das ist also der Grund, warum ich sage, dass Führungskräfte wirklich diese mechanical sympathy haben müssen, dieses Interesse an der digitalen Transformation und dem, was dahintersteckt. Denn sonst befinden Sie sich in den Händen von Technologen, die von der Technologie begeistert sind – in Ordnung, perfekt – aber die sich sehr leicht ablenken lassen und die Größenordnungen aus den Augen verlieren können, die darüber entscheiden, ob Sie einen positiven ROI erzielen oder nicht.

Conor Doherty: Nur um sicherzustellen, dass ich das richtig verstanden habe: Der Einfluss, den du vorhin erwähnt hast – ein Terabyte sind eine Million Megabytes, richtig? Also würde die Verarbeitung eines Dollars pro Megabyte einfach…

Joannes Vermorel: Ein Terabyte sind tausend Gigabytes. Also ja, es sind eine Million Megabytes. Bei dem von mir genannten Preis würde ein Terabyte also eine Million Dollar kosten, um verarbeitet zu werden.

Conor Doherty: Nur um sicherzustellen, dass ich das verstehe.

Joannes Vermorel: Also ja, ich meine, wenn du das tun willst, willst du es wahrscheinlich gar nicht erst tun. Und wenn du es unbedingt tun musst, solltest du wirklich darauf achten, dass du es nicht öfter als einmal im Jahr durchführst, denn offensichtlich sprechen wir selbst bei einem großen Unternehmen von ziemlich extravaganten IT-Kosten.

Conor Doherty: Na ja, tatsächlich, Eric, wenn ich darauf zurückkommen darf, denn der allgemeine Tenor, der Gesamtrahmen war, dass etwas fehlt. Aber ich möchte noch auf etwas anderes zurückkommen, das ebenso fehlte. Wir haben bereits über mechanical sympathy gesprochen, aber dabei habt ihr beide das Konzept eines ROI, einer finanziellen Rendite, ins Spiel gebracht.

Und etwas, das du vorhin gesagt hast, Eric, als du über große Unternehmen sprachst, die auswählen, welche Software sie einsetzen werden – “Oh, wir nehmen einfach den großen Namen, den nehmen wir. Und welche große Beratungsgesellschaft? Die nehmen wir auch, weil, weißt du, Haken abgehakt.” Und du hast gesagt, dass in diesem Zusammenhang oft der ROI keine Rolle spielt. Ich weiß, dass Joannes schon früher über finanzielle KPIs und ROI in supply chain gesprochen hat, aber ich wollte wissen, ob du das ein wenig näher erläutern könntest, warum die finanzielle Perspektive deiner Meinung nach in der supply chain vielleicht nicht so präsent ist, wie sie es sein sollte?

Eric Kimberling: Ja, ich denke, bei der sich so schnell und exponentiell verändernden Technologie ist es fast wie ein nukleares Wettrüsten, bei dem die Menschen FOMO haben – also die Angst, etwas zu verpassen. Und sie wollen sicherstellen, dass sie nicht unter technischer Schuld und all diesen ausgefallenen Begriffen leiden, die Analysten und Softwareanbieter sich ausdenken.

Und so verlieren sie den Überblick. Ich glaube, dass die Branche aus den Augen verliert, warum wir diese Technologieprojekte überhaupt durchführen. Wir tun das nicht, weil wir Cloud-Fähigkeiten wollen. Wir tun das nicht, weil wir KI wollen. Wir tun es nicht einmal, weil wir bessere Intelligenz, Berichterstattung oder ein verbessertes System als Referenz benötigen.

Wir haben das alles aus den Augen verloren. Wir haben uns einfach nicht darauf konzentriert, warum wir diese Technologie überhaupt brauchen. Warum müssen wir beispielsweise in die Cloud wechseln? Manchmal frage ich Kunden, und ich bekomme verwirrte Blicke, so als ob: “Weil wir derzeit on prem sind.” Dann sage ich: “Okay, ihr seid vor Ort. Also, was ist das Schlimmste, das passieren kann, wenn ihr einfach noch fünf Jahre on prem bleibt?”

Nun, weißt du, dann sind wir nicht in der Cloud, oder der Softwareanbieter wird unseren Support abschalten. Okay, Moment mal. Lass uns darüber sprechen. Vielleicht schalten sie deinen Support ab – was ist das Schlimmste, das passieren kann? Nun, wir müssen es selbst warten und können den Anbieter nicht für Unterstützung kontaktieren. Okay, dann müsstest du vielleicht jemanden einstellen.

Schauen wir mal. Aber betrachten wir diese Option, denn sie könnte für dich tatsächlich ein viel geringeres Risiko darstellen, als beispielsweise bei Lidl eine riesige Transformation im Wert von 600 Millionen Dollar durchzuführen.

Unternehmen tun das also nicht oft genug, weil sie das Gefühl haben, dass sie es müssen. Sie glauben, dass sie ein Upgrade durchführen müssen. Sie müssen in die Cloud wechseln. Sie müssen KI einsetzen, bla, bla, bla. Ich denke also, dass all die Veränderungen in der Technologie und die Geschwindigkeit des Wandels so schnell vor sich gehen, dass Unternehmen den Überblick verlieren, durcheinander geraten und vergessen, warum sie diese Projekte überhaupt starten.

Joannes Vermorel: Ich denke, finanzielle KPIs können irreführend sein, weil ich nicht glaube, dass sie der richtige Ansatz sind. Eure digitale Reise, nennen wir es so, erstreckt sich über etwa 10 Jahre. Man muss etwa 10 Jahre vorausdenken – wo wollt ihr sein? Diese Zeiträume sind lang. Das sind buchstäblich die Unternehmen, die ihr gestaltet.

Mein Fazit ist also, dass für mich das Betrachten von eher kurzfristigen KPIs nicht wirklich relevant ist, um zu beurteilen, ob etwas richtig oder falsch ist. Wenn man diesen KPIs folgen würde, wären das genau die Kriterien, mit denen Walmart im Jahr 2002 sagen würde: “Oh nein, E-Commerce, das ist uns egal.”

Das ist die Art von Sache, die einen dazu führt zu denken: “Okay, E-Commerce ist relevant; er ist so unbedeutend, dass es uns egal ist.” Aber nein, er ist tatsächlich sehr relevant, und es wird in ein paar Jahren ein Riese kommen, der einfach größer ist als ihr, wenn ihr nichts unternehmt. Das war eine verpasste digitale Transformation. Ich meine, die große Einzelhandelskette hätte zum E-Commerce-Riesen werden können; sie haben es nicht geschafft, weil sie die digitale Transformation in gewisser Weise verpasst haben.

Aber zurück zum Punkt: Ich würde sagen, ich tendiere eher dazu, aus einer langfristigen Geschäftsperspektive zu denken. Haben wir eine grobe Berechnung, die uns sagt, dass dies der richtige Schritt ist? Risikoadjustiert, also – glaubst du, dass es ein Risiko von 90 %, 50 % oder 10 % gibt – und versuche, mit einer einfachen Annahme das zu rechtfertigen und in diese Richtung zu gehen.

Und nun denke ich, dass typischerweise etwas fehlt, nämlich das, was ich bereits vom Inkrementalismus erwähnt hatte. Die Leute betrachten ihre digitale Transformation als das Gleiche, nur ein wenig besser. Nochmals: Wenn wir auf Walmart 2002 zurückblicken, war die Zukunft E-Commerce, also ist es definitiv nicht dasselbe wie einfach nur Walmart mit einem etwas besseren Point-of-Sale-System und LCD-Bildschirm.

Das ist es nicht, verstehst du, das ist der Haken. Die Zukunft ist grundlegend etwas anderes, und ich denke, an dieser Stelle greifen Unternehmen meist nicht präzise genug, um in Frage zu stellen, wie das Unternehmen in 10 Jahren aussehen wird. Welche Rollen wird es geben? Ich glaube, es gab kürzlich ein sehr interessantes Memo vom CEO von Shopify, das auf LinkedIn kursierte.

Er sagte buchstäblich zu allen: “Wir setzen die Einstellung neuer Mitarbeiter vorerst aus, und jede Abteilung muss rechtfertigen, dass die Aufgaben, für die sie einstellen möchten, nicht bereits mit den KI-Technologien, LLMs und so weiter, die wir bereits erworben, implementiert und in unser System integriert haben, erledigt werden können.” Shopify ist ein ziemlich hochmodernes Unternehmen, daher haben sie bereits mehrere Jahre Erfahrung damit.

Und er sagte: “Okay, wir haben ein Problem in Bezug auf die Transformation. Offensichtlich war das Wesentliche des Memos, dass das übergeordnete Management nicht bei sehr inkrementellen Perspektiven bleibt, sondern viel ambitionierter in Bezug auf das Endziel sein sollte.” Und ich finde, die Botschaft war sehr interessant. Es ging nicht darum zu sagen: “Wir investieren nicht, wir stellen nicht ein.” Es hieß: “Ihr müsst ein Endziel haben, das anerkennt, dass diese Technologien existieren, und ihr solltet nicht versuchen, eine Entwicklung zu verfolgen, die so tut, als ob sie nicht existieren.”

So war es bei dem Memo, und das war sehr interessant. Ich sehe viele große Unternehmen, bei denen es in Bezug auf ihre 10-Jahres-Vision für das digital transformierte Unternehmen – was auch immer das bedeuten mag – einfach dasselbe ist, nur mit einer etwas besseren Benutzeroberfläche. Und für mich ist das sehr wenig beeindruckend.

Denke 10 Jahre voraus – du musst an etwas denken, bei dem die Hälfte der Jobs, insbesondere der Bürojobs, die heute existieren, nicht mehr existieren. Das bedeutet nicht, dass du Leute entlassen musst; du kannst sie umschulen, umorientieren und so weiter. Aber die Jobs selbst – mindestens die Hälfte von ihnen – sollten 10 Jahre in der Zukunft einfach wegfallen, und das werden sie auch.

Eric Kimberling: Ja, und ich denke, du triffst einen wirklich wichtigen Punkt, nämlich dass es für die Zuhörer, die Technologie- oder Transformationsinitiativen in ihren supply chains oder wo auch immer sie arbeiten, wichtig ist, sich zu fragen: Was soll diese Initiative eigentlich sein? Soll diese Initiative dazu dienen, alte Technologie zu ersetzen und einfach auf dem neuesten Stand zu bleiben – was vielleicht eher eine inkrementelle, idealerweise kostengünstigere, aber potenziell auch geringere ROI-Option ist? Oder wollen wir unser Geschäft wirklich transformieren, es vollständig wandeln und neue Geschäftsmodelle sowie Innovationen in den Blick nehmen? Das sind zwei sehr unterschiedliche Wege, und keiner davon ist richtig oder falsch. Man muss nur sicherstellen, dass man übereinstimmt und Entscheidungen trifft, die zu dem Weg passen, den man einschlägt. Es sollte auch kein Einheitskonzept sein; es muss darauf basieren, wer man ist. Die digitale Strategie von Shopify sollte ganz anders aussehen als deine, meine oder die von irgendjemand anderem.

Joannes Vermorel: Ich stimme voll und ganz zu, aber das Problem, das ich sehe, ist, dass der erste Weg – nur inkrementelle Upgrades mit niedrigem ROI – derjenige ist, bei dem man die massiven Budgets bekommt.

Eric Kimberling: Ja.

Joannes Vermorel: Ja, und für mich stellt sich die Frage: Wie kann man ein Projekt haben, bei dem jede vernünftige, grobe Kalkulation zeigt, dass der ROI sehr dürftig ausfallen wird? Warum gibt man da Geld aus? Ich habe Unternehmen gesehen – ich nenne keine Namen – aber ich habe Gespräche mit Firmen geführt, die ERP-Upgrades im Wert von über 100 Millionen Dollar für Projekte über fünf Jahre durchführen. Wenn ich mit dem Top-Management spreche, ist es sehr schwer zu erkennen, ob es überhaupt irgendeine Rendite geben wird – nicht nur den Return on Investment, sondern einfach eine Rendite. Sobald man ein Upgrade durchführt, wird das Geschäft tatsächlich besser? Das ist nicht einmal klar, vor allem, wenn man auf die Art von Hardwareanforderungen von SAP HANA angewiesen ist – ich rede hier nur von SAP; sie sind nicht die einzigen.

Conor Doherty: Keine Sorge, das ist in Ordnung.

Joannes Vermorel: Ja, aber wenn du deine IT fünf Jahre lang einfrierst, sind allein die Opportunitätskosten enorm. Es kann nicht nur etwas Inkrementelles sein; es muss viel mehr sein als das.

Conor Doherty: Also, Eric, wenn ich darauf aufbauen darf, denn buchstäblich, Joannes, was habe ich gerade geschrieben – erste Ordnung, zweite Ordnung Opportunitätskosten – buchstäblich habe ich genau diese Worte verwendet, um das wieder aufzunehmen. Eric, als Berater wollte ich dich gerade fragen: Wie genau erklärst du das Konzept der Kosten erster und zweiter Ordnung? Denn offensichtlich, die Kosten erster Ordnung: Du kaufst diese Software, sie wird dich 50, 100, 150 Millionen kosten; du musst Leute einstellen, die das überwachen, was weitere x Millionen kosten wird, wie auch immer. Das sind die Kosten erster Ordnung.

Die Kosten zweiter Ordnung sind, wie Joannes gerade sagte, die Opportunitätskosten. Das Geld, das du dafür ausgegeben hast, kannst du jetzt nicht woanders ausgeben, weil ein Dollar hier nicht gleichzeitig dort ausgegeben werden kann.

Joannes Vermorel: Außerdem ist dein IT-Team überlastet und für eine gewisse Zeit in diesem Projekt gefangen.

Conor Doherty: Das spricht erneut die finanzielle Perspektive an, die ich vorhin meinte. Wie erklärst du persönlich, wenn du als technikagnostischer Berater in einem Raum stehst, den Leuten – und ich meine das nicht herablassend, ich meine buchstäblich – du nimmst einen Dollar, du kannst nicht zwei Schokoriegel kaufen, wenn einer einen Dollar kostet und der andere auch einen Dollar; du kannst nicht beides mit nur einem Dollar kaufen. Also, wie gehst du beim Thema Kosten erster und zweiter Ordnung bzw. Opportunitätskosten vor, damit es bei den Leuten wirklich Anklang findet, die, wie du schon gesagt hast, FOMO haben – sie wollen nichts verpassen, sie wollen auf der Welle mitreiten usw.?

Eric Kimberling: Du spielst etwas an, das wir bisher noch nicht wirklich angesprochen oder im Detail behandelt haben, nämlich realistische Erwartungen zu haben und diese hinsichtlich der Kosten erster und zweiter Ordnung realistisch einzuschätzen. Ich denke, eine der Ursachen des Problems ist, dass Organisationen nicht verstehen, was die tatsächlichen Kosten sind; deshalb können sie diese Opportunitätskosten nicht einschätzen, weil sie denken, es wird 100 Millionen kosten, obwohl es in Wirklichkeit nie 100 Millionen gekostet hätte, sondern immer 300 Millionen. Aber jemand hat dich davon überzeugt, dass es für 100 Millionen machbar sei, und dieser jemand hat den Aufwand unterbewertet und dabei die Komplexitäten und Risiken ignoriert, die die Kosten vermutlich erhöhen werden. Wenn du darüber nachdenkst: Wenn dir ein Software- oder Lösungsanbieter eine Lösung verkauft, nützt es ihnen aus eigennützigem Interesse nicht, die Kosten zu überschätzen. Was ihnen hilft, ist, sie zu unterschätzen und zu sagen: “Nein, nein, es ist risikoarm und kostengünstig.” Dort fängt das Problem an.

Also, wenn ich sage, dass ich die Opportunitätskosten – also die Kosten zweiter Ordnung – bewerten werde, tue ich das mit fehlerhaften Informationen. Selbst wenn ich es tue, spielt es keine Rolle, weil ich nicht die genauen Informationen habe, um diese Entscheidung zu treffen. Aber ich denke, wenn mehr Unternehmen wüssten, was die tatsächlichen Kosten wirklich sein würden, würden sie sagen: “Whoa, halt mal, das ist eine Menge Geld. Das ist Geld, das wir nutzen könnten, um eine weitere Fabrik zu bauen. Wir könnten für diesen Betrag 10 weitere Geschäfte eröffnen. Ist das, was wir wollen?” Die meisten Organisationen erreichen diesen Entscheidungspunkt nie, weil sie auf einer unterschätzten, nie realistischen Kostenbasis beruhen.

Ein weiteres Thema – naja, es gibt noch etwas, und ich dachte, vielleicht wollt ihr mit den Kosten erster und zweiter Ordnung dahin gehen – aber eine weitere Kostenart, die wir noch nicht angesprochen haben, ist die betriebliche Störung. Weißt du, was passiert, wenn du eine neue Technologie einführst, egal wie gut das Projekt gemanagt wird? Es wird einen Rückgang der Produktivität geben. Hoffentlich ist es nicht ein kompletter, steiler Einbruch der Produktivität – oft ist es das leider. Aber selbst wenn du es sehr gut managst, wirst du einfach einige Störungen haben.

Was sind also die Kosten dieser Störung, und was würde zum Beispiel passieren, wenn du zwei Wochen, vier Wochen oder drei Monate lang keine Produkte ausliefern kannst? Das passiert in Organisationen; sie führen diese Projekte durch, es geht etwas schief, sie gehen live und dann können sie keine Produkte ausliefern. Kunden werden verärgert, stornieren Bestellungen. Das sind die tatsächlichen Kosten. Diese Kosten musst du ebenfalls in deinen ROI einbeziehen, damit du deine Implementierung optimieren und sicherstellen kannst, dass du sie gut managst und verstehst, welches das tatsächliche Risiko ist.

Conor Doherty: Du hast da einen wirklich guten Punkt angesprochen, Eric, und Joannes, ich möchte noch einmal auf dein Beispiel zurückkommen, das Eric gerade gegeben hat. Wenn man jemanden heranzieht – und ich will hier niemanden herausgreifen – aber wenn man das durchschnittliche Niveau aus der Automobilindustrie, der Luftfahrt oder der Öl- und Gasbranche betrachtet und fragt: “Wie viel kostet eine Stunde Ausfallzeit an verlorener Produktivität?” könnten sie dir einen groben Richtwert nennen, aber die Arten von Ausfallzeiten, die Eric gerade beschrieben hat, lassen sich möglicherweise nicht quantifizieren.

Joannes Vermorel: Ja, und ich denke auch, dass es bei den Betriebskosten völlig zutrifft. Eines, was die Leute nicht merken, ist, dass die Produktivität sinkt, wenn die Komplexität Ihrer Umgebung zunimmt. Also sehen Sie, Sie haben ein Stück Software; sie ist veraltet, sie tut nur sehr wenige Dinge, aber sie tut die Dinge, die Sie benötigen. Das heißt, was meine IT-Umgebung betrifft, hat meine Benutzeroberfläche nicht so viele Tasten, nicht so viele Optionen, nicht so viele Schnörkel und Extras, die ich damit machen kann. Nun aktualisiere ich auf etwas, das weitaus leistungsfähiger ist. Warum? Weil der Anbieter – es gab so viele Kästchen, die im AFP abgehakt werden mussten – wir fragten den Anbieter: “Es sollte dies und das und das und das und das und das können, okay, 100 Kästchen später.” Jetzt haben wir das aktualisierte System, das zusätzlich jede Menge Dinge kann.

Aber das bedeutet, dass für die Person, die die Software bedient, so viele weitere Menüs vorhanden sind.

Und so habe ich sehr häufig miterlebt, dass Leute eine Software aktualisieren, besonders diese Systeme der Aufzeichnung, zu einem neuen, besseren. Ja, die UI ist schöner, aber sie hat so viele Funktionen, dass die Produktivität tatsächlich sinkt, einfach weil die Leute sich in einem Labyrinth von Funktionen verirren.

Jede einzelne Funktion in einem System, die Sie nicht nutzen, ist einfach Ballast. Das bedeutet, dass jeder neue Rekrut, der kommt und anfängt, es zu benutzen, verwirrt wird. Er wird sagen: “Warum funktioniert es nicht?” Ach, weil es etwa fünf verschiedene Bildschirme für die Bearbeitung von Bestellungen gibt, wir aber nur einen dieser fünf nutzen. Die anderen vier – nein, sie führen nur in Sackgassen. Wenn Sie dort Ihre Eingaben tätigen, werden diese nicht verarbeitet; sie gehen einfach verloren und werden ignoriert. So etwas kann vorkommen.

Eric Kimberling: Ja, absolut. Ich meine, das ist ein so guter Punkt und führt uns zurück zur wirklichen Definition dessen, was Sie benötigen. Brauchen Sie all diese Technologie? Oftmals übernehmen Unternehmen mehr, als sie verkraften können, und sie verpflichten sich übermäßig zu den Technologiekosten. Und dann entsteht schon allein auf technischer Seite so viel Komplexität, dass Sie nicht mehr die Zeit oder die Ressourcen haben.

Zurück zu Ihrem Punkt bezüglich Opportunitätskosten: Jetzt haben Sie nicht die Zeit oder Ressourcen, in die Dinge zu investieren, die wirklich zählen. Und die Dinge, die wirklich zählen, sind: Lassen Sie uns unsere Geschäftsprozesse optimieren, dafür sorgen, dass die Mitarbeitenden gut geschult sind, sicherstellen, dass wir Akzeptanz erreichen, dafür sorgen, dass die Rollen und Verantwortlichkeiten der Mitarbeitenden neu definiert werden, um der neuen Technologie und dem neuen Betriebsmodell gerecht zu werden.

Diese Dinge entscheiden über den Erfolg oder Misserfolg eines Systems oder einer Transformation. Dennoch investieren Unternehmen übermäßig in Technologie. Ich würde viel lieber ein Unternehmen sehen, das nur ein wenig Technologie erwirbt, diese aber wirklich gut implementiert, denn ein solches Unternehmen wird erfolgreicher sein. Es wird das Risiko reduzieren und wahrscheinlich eine bessere Rendite erzielen.

Und dann, nachdem Sie das getan haben – übrigens, sobald Sie diese kleine Technologieinvestition getätigt und sehr gut umgesetzt haben – bauen Sie Vertrauen, Fähigkeiten und Reife in Ihrer Organisation auf, sodass Sie jetzt sagen können: “Okay, ich werde jetzt ein größeres Projekt in Angriff nehmen. Jetzt bin ich zuversichtlich, dass wir genug gelernt haben, um in ein wenig mehr Technologie zu investieren.”

Und anstatt einfach ein riesiges System zu kaufen, all dieses Geld auszugeben und dann unter dem Druck zu stehen, alles zu implementieren, weil wir dafür bezahlt haben, und dann all diese Komplexität entsteht, investieren wir nicht in Akzeptanz und Prozessverbesserung – all die Dinge, die wichtig sind. Und genau hier geraten viele dieser Projekte außer Kontrolle.

Conor Doherty: Tatsächlich, und wie Joannes vorhin, haben Sie genau das in den Raum gestellt, was ich als nächste Frage oder Anschlussfrage notiert habe. Wir haben ausführlich über die Probleme und die Minenfelder gesprochen, denen man ausweichen muss. Aber das bringt wirklich das eigentliche Konzept der Implementierung und des Change Managements, also den Prozess des Change Managements, zur Sprache.

Also, Eric, zunächst zu Ihnen: Gibt es auf einer positiveren Note Dinge, die Sie bei erfolgreichen digitalen Transformationen beobachtet haben – sicherlich im Kontext des Change Managements, der Kultur, der Erwartungen usw.? Was sind die Dinge, die dabei tatsächlich helfen?

Eric Kimberling: Ja, ich meine, ich gehe zurück auf den von Ihnen verwendeten Begriff – Ehrlichkeit – Sie sagten, war es “mechanical sympathy”, “sympathy”? In meinem Kopf sagte ich “mechanical curiosity”. Beide Begriffe funktionieren, um ehrlich zu sein – es ist im Grunde dasselbe. Mechanical sympathy – ich weiß, das habe ich vorhin vermasselt – aber mechanical sympathy ist wirklich wichtig.

Denn die erfolgreichsten Projekte, die wir gesehen haben, sind die, bei denen die Führungskräfte in der Organisation praktisch mit anpacken. Sie verstehen die Technologie; sie müssen keine Experten in Konfiguration und Programmierung sein – das ist nicht nötig –, aber sie verstehen, wie die Technologie funktioniert. Und sie verstehen definitiv, wie ihr Geschäft funktioniert und wie sie es in Zukunft haben möchten.

Diese mechanical empathy führt zu mehr Verantwortungsübernahme und zu ergebnisorientierten Resultaten, die vom Geschäft getrieben sind, statt von der Technologie. Das ist also etwas, das wir häufig sehen: die Übernahme des Projekts und das aktive Engagement der Führungskräfte in der Organisation.

Das andere ist, dass sie die Transformation nicht outsourcen. Sie sagen nicht einfach: “Wir holen große Anbieter herein und überlassen ihnen alles.” Sie sagen: “Wir holen Experten herein, aber wir werden sie managen.” Genau so, wie Sie einen Subunternehmer oder Generalunternehmer betreuen würden, wenn Sie jemanden beauftragen, eine neue Fabrik zu bauen.

Wahrscheinlich würden sie nicht einfach sagen: “Es ist uns egal, baut die Fabrik, nutzt Best Practices, tut, was nötig ist, um die Fabrik zu bauen.” Nein, sie werden stark eingebunden sein, um sicherzustellen, dass die Fabrik den Vorgaben entspricht und so weiter. Aber bei Technologieprojekten machen das viele Unternehmen nicht. Daher behandeln die erfolgreichsten Unternehmen Technologieinvestitionen und Transformationen wie jede andere Kapitalinvestition.

Sie behandeln es nicht anders; sie erwarten eine Rendite, sie begrenzen das Budget, sie sind stark eingebunden und haben viel Mitspracherecht, wie die Dinge ablaufen. All das geschieht von Anfang an, und das ist ein wichtiger Erfolgsfaktor.

Ein weiterer Punkt, der an etwas anknüpft, das einer von Ihnen vorhin erwähnte, sind die Entscheidungen, die früh getroffen werden. Ich möchte nicht sagen, dass die Ausführung unwichtig ist – sie ist wichtig – aber noch wichtiger sind die Dinge, die zur eigentlichen Ausführung führen: die getroffenen Entscheidungen, die gesetzten Prioritäten, die Abstimmung.

Die Abstimmung im Team zu erreichen, denn oft, wenn wir einen Raum mit, sagen wir, sieben Führungskräften betreten und dort unser Lenkungsausschuss ist, und ich sie frage: “Was bedeutet diese Transformation für die Organisation?”, bekommt man in der Regel sieben verschiedene Antworten. Keine davon ist per se richtig oder falsch, aber alle sagen unterschiedliche Dinge, und so kann man nicht erfolgreich sein.

Sie werden einfach nicht erfolgreich sein, egal wen Sie einstellen, egal in welche Technologie Sie investieren – wenn Sie nicht alle auf derselben Seite sind. Es ist ein chaotischer Prozess, und theoretisch könnte es das Projekt kurzfristig verlangsamen, weil Sie dann sagen: “Moment mal, stoppen wir die Technologie, machen wir das noch nicht, lasst uns zuerst abstimmen.”

Die Leute denken: “Aber wir müssen heute anfangen.” Sie wissen, wir liegen schon im Verzug, wir müssen los, und wir sagen: “Langsamer, denn wenn Sie sich hineinstürzen, stürzen Sie einfach von einer Klippe.” Also sorgen wir dafür, dass Sie nicht von der Klippe stürzen; nehmen Sie sich die zusätzliche Zeit, um sicherzustellen, dass Sie einen klaren Weg haben, und stimmen Sie sich dann ab.

Diese Abstimmung und sich die Zeit zu nehmen, strategische Ziele, Parameter, Prioritäten, den Business Case, Erwartungen, Governance und die Definition unserer zukünftigen Geschäftsprozesse festzulegen – wie sollen unsere Prozesse zukünftig aussehen? Wie soll die Organisation zukünftig sein? All das muss von Anfang an definiert werden, bevor Sie mit der Technologieeinführung beginnen, und das ist ein wirklich wichtiger Erfolgsfaktor.

Und dann der letzte Punkt, den ich erwähnen möchte, ist die Investition in das Change Management. Die Unternehmen, die stark investieren – und wenn ich stark investiere sage, meine ich damit nicht unbedingt viel Geld –, investieren Zeit und Fokus in organisatorischen Wandel, Kommunikation, Akzeptanz und Klarheit für die Organisation. All das erhöht die Erfolgsquote dramatisch.

Joannes Vermorel: Stimme Ihrer Anekdote zu. Tatsächlich – wissen Sie, ich bin auch Softwareingenieur – gibt es dieses Sprichwort: “Oh, ich habe drei Stunden damit verbracht, über das Problem nachzudenken, das ich implementieren wollte. Drei Stunden, und es kostete mich drei Wochen zusätzliche Implementierung.”

Aber zurück zum ursprünglichen Fall: Ich sehe viele Unternehmen – große Unternehmen nehmen diese Idee auf, “Oh ja, wir müssen sorgfältig planen.” Sie haben diesen Rat gehört; wir sind nicht die Ersten, die das sagen. Also tun sie das, aber ich sehe eine Perversion dieses Denkens, obwohl ich vollkommen zustimme, dass es der richtige Weg ist. Man muss sehr klar denken und sich vermutlich ein wenig Zeit in dieser super kritischen Phase nehmen.

Aber was ich beobachtet habe, ist, dass viele große Unternehmen diese Idee in ihrer Organisation zu einer Kästchen-Ankreuzübung oder zu einem bürokratischen Ritual verkommen lassen, wie: “Oh, wir befinden uns in der Planungsphase, also brauche ich diesen Bericht und jenen Bericht und diese Validierung und diesen Audit und diese Diagnose-Mission und dies und das und jenes.” Und was dabei herauskommt, ist nicht Klarheit; letztlich endet man mit einem Fall, der tausende Seiten umfassen kann und keinerlei Klarheit bietet. Das nenne ich Technokratie.

Es ist diese Planungsphase, in der man einfach Dinge aus der Organisation zusammenträgt und alle den Antrag übermäßig erfüllen. Stellen Sie sich also vor, Sie sind der Vorstand, und in einem Monat haben Ihre Teams mehrere tausend Seiten an Bewertungen, Diagnosen usw. zusammengetragen, und niemand hat irgendeine Ahnung vom Inhalt. Es ist ein wenig wie das Omnibus-Ausgabengesetz des Kongresses in den USA – ein massives Dokument, mehrere tausend Seiten lang, bei dem niemand weiß, was drinsteht.

Meine Ansicht ist, dass man sich in dieser Planungsphase auch bewusst werden muss, dass das nicht als technokratische Übung durchgeführt werden sollte. Man muss in der Lage sein, Klarheit in einem Dokument zu bewahren, das wahrscheinlich – würde ich sagen – maximal zwischen fünf und 20 Seiten lang ist. Wenn Sie nichts haben, das in maximal 20 Seiten klar ausgedrückt ist, idealerweise sogar kürzer, dann haben Sie sich wahrscheinlich in einem technokratischen Labyrinth verirrt.

Ihr Weg wird danach sehr fehlgeleitet sein. Und ich meine damit, dass Seiten in Fließtext geschrieben werden sollten, nicht als PowerPoints, denn bei PowerPoints kann man mit Stichpunkten schummeln – es gibt keinen logischen Zusammenhang, sodass man etwas haben kann, das super mehrdeutig ist. Wenn Sie in Englisch mit korrekter Signalisierung und Verbindung schreiben, können Sie nicht schummeln; Sie müssen etwas haben, das Sinn ergibt und ein Dokument, das man laut vorlesen kann. Das ist so meine Ansicht zu dieser Denkweise.

Eric Kimberling: Das ist ein großartiger Punkt. Und das Team, das das Projekt umsetzt, muss ebenfalls diese Klarheit besitzen. Wissen Sie, wenn Sie an eine supply chain Transformation denken – sagen wir, Sie sind eine Organisation, die überlegt, eine komplette supply chain Technologie einzuführen – ist es leicht, sich in vielen Komplexitäten und Details zu verlieren.

Wenn Sie es als eine Art Demokratie behandeln, in der jeder gleiches Mitspracherecht, Prioritäten, Anforderungen und Wünsche bezüglich des Systems hat, gerät das Projekt außer Kontrolle. Es bedarf einer Governance, die sagt: “Wissen Sie was? Ja, wir führen die supply chain Transformation durch, aber Beschaffung hat gerade nicht oberste Priorität. Stattdessen geht es um Lieferantenmanagement, es geht um Vendor Management.”

Denn wissen Sie was? Die US-Regierung verhängt jetzt all diese Zölle oder es gibt all diese geopolitischen Herausforderungen, die wir meistern müssen, also benötigen wir ein besseres Lieferantenmanagement – das ist unser Fokus. Sie müssen Prioritäten setzen und sagen: “Wir tun das, weil wir unsere Lieferantenmanagement-Prozesse überarbeiten wollen,” und es entsprechend steuern.

Wenn Sie diese Klarheit in diesem 5- bis 20-seitigen Dokument nicht erreichen und niemand alle auf derselben Seite ist, wird es zu einem freien Durcheinander, in dem jeder einfach das fordert, was er für wünschenswert hält.

Joannes Vermorel: Übrigens, zur Information: Ich habe viele Unternehmen gesehen, und ich habe nie hochwertige Dokumente gesehen – abgesehen von geleakten Dokumenten amerikanischer Tech-Unternehmen wie Amazon, Shopify, Apple – geleakte Memos, die super klar, in fünf Seiten geschrieben und wunderschön formuliert sind. Man sieht, dass das Management ein sehr scharfes Verständnis dafür hat, wo sie stehen, wohin sie wollen usw., und sie schreiben sehr klar und prägnant.

Wenn man zu Non-Tech-Unternehmen geht, ist das äußerst selten zu sehen. Äußerst selten. Ich kann mir vielleicht nur ein Dutzend Unternehmen einfallen. Berkshire Hathaway zum Beispiel – ihre Memos sind absolut brillant; es ist glasklar, was sie tun und warum. Aber typischerweise, bei den Unternehmen, die wir erwähnten, wie Lidl und so weiter, bin ich mir 100 % sicher, dass niemand ein simples Memo hatte, in dem stand: Was wollen wir überhaupt erreichen? Warum sind wir überzeugt, dass dieses Vorhaben überhaupt eine vernünftige Chance auf Erfolg hat?

Die meisten dieser großen Projekte, die ich miterlebe – Lokad ist manchmal Teil davon – wissen Sie, sie aktualisieren ihr ERP, sie aktualisieren ihre supply chain Analysen mit uns. Es ist einfach so selten; deshalb erwähne ich es. Ich sehe fast nie einen Funken von Klarheit, wenn es um digitale Transformation geht. Es stapeln sich einfach Schicht um Schicht von Technokratien.

Nochmals, Sie erwähnten Outsourcing – also Parteien, die völlig außerhalb des Unternehmens stehen. So würden von diesen Dossiers, tausend Seiten, die Hälfte von Drittanbietern bereitgestellt werden.

Eric Kimberling: Ich frage mich, ob das wirklich interessant ist, was Sie über Tech-Unternehmen sagen. Das war mir nicht bewusst oder ich hatte diese Verbindung zuvor nicht hergestellt. Wissen Sie, vielleicht sind Tech-Unternehmen dazu fähiger und reifer, wenn es darum geht, diese Klarheit zu liefern.

Aber ich frage mich, manchmal frage ich mich, ob – wissen Sie – die Führungskräfte heutzutage – man denke nur an Führungskräfte, die seit vielleicht den 90ern in der Tech-Branche aufgewachsen sind, okay, vielleicht sind sie in meinem Alter oder ein wenig älter. Ich erinnere mich, als Windows 98 herauskam, und es war ein riesiges Ereignis, als Windows 98 eingeführt wurde.

Es war eine Art Umbruch für viele Unternehmen, weil sie diese großen Windows-Upgrades durchlaufen mussten. Aber letztlich war es einfach ein Windows-Update; es war keine Transformation. Es hieß: “Wir brauchen neue Betriebssysteme für unsere PCs sowie für unsere Desktops und Laptops.”

Ich frage mich, ob die Führungskräfte, die in jener Zeit in der IT-Branche aufgewachsen sind, Tech-Projekte immer noch als ein Windows-98-Upgrade betrachten und nicht erkennen, dass dies kein Windows-98-Upgrade ist. Es handelt sich um eine massive Überarbeitung – nicht nur Ihrer Back-Office-Systeme und Datenbanken, sondern auch Ihrer Prozesse, Ihrer Organisationsstruktur und all dem Drum und Dran.

Das ist nur eine reine Hypothese. Ich weiß nicht, ob es wahr ist oder nicht, aber ich versuche, der Ursache auf den Grund zu gehen, worüber wir hier sprechen, um herauszufinden, warum das so ist.

Joannes Vermorel: Meiner Meinung nach, wenn ich die Pläne zur digitalen Transformation der meisten Non-Tech-Unternehmen betrachte – normalerweise, als Technologe selbst – Lokad ist ein Softwareunternehmen, das im Wesentlichen robotisierte decision-making für supply chain betreibt – sehe ich, dass diese digitalen Transformationen für mich äußerst zahm erscheinen.

Wenn ich an die digitale Transformation meines eigenen Unternehmens denke, weil sich diese Technologien, wie Sie erwähnt haben, weiterentwickeln und sich bei Lokad vieles verändert, sehe ich in 10 Jahren vielleicht, dass mehr als die Hälfte der Aufgaben in unseren Jobs wegfallen wird. Die Mitarbeiter werden zwar noch da sein, kein Problem, aber sie werden andere Dinge tun.

Wenn ich mir die klassischen Non-Tech-Unternehmen ansehe – denken Sie an ein aviation Unternehmen, ein Fertigungsunternehmen, ein Einzelhandelsunternehmen, ein Modeunternehmen – wissen Sie, Unternehmen, für die Technologie nur etwas Nebensächliches ist – dann ist ihre digitale Transformation sehr, sehr zahm.

Es wird fast kein Job abgebaut, keine Aufgabe von vornherein eliminiert. Wenn man an Werkzeuge wie zum Beispiel ChatGPT denkt, sieht man, dass ganze Klassen von Aufgaben offensichtlich automatisiert werden können.

Jedenfalls ist meine Auffassung, dass digitale Transformationen sehr häufig ambitionslos sind; sie sind extrem zahm. Das Einzige, was nicht zahm ist, ist das Budget, das sie für das Upgrade zur Verfügung haben.

Conor Doherty: Greifen Sie einfach darauf auf und bauen Sie darauf auf, denn ich denke, im Hintergrund ist es so etwas wie das Öffnen von Schleifen. Wenn man zur eigentlichen anfänglichen Schleife zurückgeht, liegt der fundamentale Gedanke tatsächlich darin, wie wir die Problematik in mentaler Hinsicht einrahmen, um am Ende wieder bei dem Problem anzukommen, das wir zu lösen versuchen. Joannes, ich komme zuerst zu Ihnen und dann zu Eric für einen Kommentar.

Joannes, ich habe dies im Hintergrund angesprochen, weil mich etwas, das Eric vorhin über Capex vs. Opex sagte, an einen Vortrag erinnerte, den Sie über produktorientierte Lieferung für supply chain gehalten haben, in dem Sie das Argument vorbrachten, dass supply chain nicht als Opex-supply chain betrachtet werden sollte. Es sollte als Capex behandelt und als Vermögenswert betrachtet werden, und mir fällt ein, dass die einfache Darstellung dieses Problems – also es nicht als supply chain und all seine damit verbundenen Kosten zu behandeln wie, nun ja, einfach Kekse oder Stifte, also Dinge, die ich brauche, um den Tag zu überstehen – und es stattdessen mehr als einen Vermögenswert zu behandeln, der skaliert und im Wert zunimmt, ein hilfreicherer Ansatz sein könnte, um die Diskussion überhaupt zu beginnen, sei es bei der Einstellung von Mitarbeitern oder der Beschaffung von Software. Könnten Sie daher vielleicht etwas mehr über diese Unterscheidung ausführen?

Joannes Vermorel: Ja, ich meine, das ist meine persönliche Auffassung. Wenn ich mir Büroangestelltenjobs anschaue – sofern nicht etwas wirklich Besonderes daran ist – denke ich, dass es einfach etwas ist, wofür das Unternehmen zahlen muss, um eine bestimmte Leistung in Form von Informationsverarbeitung zu erhalten. Ein Büroangestellter nimmt im Grunde Informationen auf und produziert daraus Informationen, die viele Formen annehmen können. Aber viele Leute, vor allem im Back Office – das machen sie in großen Unternehmen – in supply chain zum Beispiel gibt es Mitarbeiter, die die Lagerbestände aus ihrem ERP abrufen und zusätzlich viele Indikatoren der jüngsten Verkäufe und so weiter, und was entscheiden sie dann? Sie entscheiden für jede einzelne SKU, storage keeping unit: “Muss ich neu bestellen, ja oder nein?” Ich muss tausend SKUs verwalten. Die Organisation ist so aufgeteilt, dass ein supply and demand planner – sagen wir, für 1.000 SKUs – zuständig ist. Wir haben insgesamt 80.000 SKUs, also 80 supply and demand planners, und jeder von ihnen geht jeden Tag 1.000 SKUs durch und gibt die replenishment Bestellung für den Tag ab. Viele Unternehmen sind genau so organisiert.

Also, meiner Ansicht nach sind die Mitarbeiter, wenn man an seine supply chain practice denkt, reine Opex-Kosten. Man muss diese Gehälter jeden Tag zahlen, damit das Unternehmen weiterläuft. Wenn man aufhört, diesen Mitarbeitern zu zahlen, arbeiten sie nicht mehr, das Unternehmen stoppt, der Warenfluss kommt zum Erliegen. Wenn man der Herangehensweise von Lokad folgt, würde man sagen: “Nein, wir sollten die supply chain practice als etwas betrachten, das Capex ist. Wir haben Leute, die Software entwickeln, auf die eine oder andere Weise. Es gibt viele Wege; Low-Code, man muss nicht unbedingt coden, aber man entwickelt Software, die diese Auffüllungsentscheidungen automatisch generiert.”

Und wenn Sie dann einer einzelnen Person mehr bezahlen müssen, geschieht dies zur Verbesserung des Systems. In diesem Fall ist Ihre Investition Capex. Sie haben dieses Softwarestück, das automatisch läuft, und Sie haben die Opex, aber es gilt nur die Software, daher sind die Ausgaben sehr gering. Und wenn Sie Geld für Menschen ausgeben, dann zur Verbesserung des Systems, dann ist es sehr kapitalintensiv. Es baut sich auf; es ist so, wie ein Vermögenswert sein sollte. Ja, es wird zu einem Vermögenswert. Ihre Investition in Menschen wird also zu einem Vermögenswert; das Ergebnis dieser Menschen ist ein greifbarer Vermögenswert für Ihr Unternehmen, der zufälligerweise dieses Entscheidungsfindungssystem ist.

Was ich bei den modernen digitalen Transformationen sehe, ist, dass sie äußerst zahm erscheinen, insofern als dass es Unmengen an Jobs gibt, die reine Opex-Bürojobs sind und zu Capex werden sollten. Wenn Menschen eine Stunde arbeiten, liefern sie etwas, das aufbaut, etwas, das einen Vermögenswert irgendeiner Art schafft – wahrscheinlich Software, aber es können auch andere Dinge sein, die für das Unternehmen wertvoll sind, unabhängig von der fortlaufenden Arbeit der Mitarbeiter. Es mag ein wenig seltsam klingen, aber es ist, als würden diese Menschen die Maschine konstruieren, und dann kann man die Maschine unendlich am Laufen halten. Ich vereinfache natürlich; diese Maschinen brauchen Wartung und dergleichen, aber die meisten digitalen Transformationen, die ich sehe, sind äußerst zahm, weil sie sich lediglich auf diese als Opex betrachteten Mitarbeiter konzentrieren, also reine Verbrauchsgüter. Ich muss diese Mitarbeiter immer und immer wieder einsetzen.

Ich spreche von rein informatorischen Aufgaben und nicht vom Burgerwenden in einem Restaurant. Dafür braucht man Hände. Wir haben noch keine Roboter, die fähig sind, Burger zu wenden. Aber ich spreche von allem, was einem Büroangestellten-Back-Office-Job ähnelt. Für mich behandeln die meisten digitalen Transformationen kaum die Tatsache, dass diese Aufgaben größtenteils wieder komplett robotisiert werden sollten, im Back Office, sodass wir nicht einmal direkt vor den Kunden stehen. Es handelt sich um reine interne Beschäftigungsarbeit, und doch kann dies bei vielen großen Unternehmen leicht zwei Drittel der Büroarbeitskräfte im Back Office ausmachen. Sehr häufig stelle ich fest, dass diese digitalen Transformationen nicht einmal annähernd die enorme Menge an Opex angehen, die in Capex umgewandelt werden sollte, aber das ist eine sehr persönliche Auffassung.

Eric Kimberling: Sie sprechen einen wirklich interessanten Punkt an und, denke ich, eine größere Herausforderung in der Tech-Branche, im Bereich der Enterprise-Technologie im Allgemeinen. Sie haben viel über Capex und Opex sowie darüber gesprochen, IT als Vermögenswert zu behandeln, aber wenn man sich anschaut, wohin die Technologielieferanten steuern, dann bewegen sie sich auf ein Modell zu, bei dem es nicht als Vermögenswert für ihre Kunden gilt, sondern als Vermögenswert für den Anbieter. Und das war schon immer so, offensichtlich; es ist ihr Produkt, ihr geistiges Eigentum. Aber was passiert, ist, dass wir von On-Premise – wo man investiert, eine Kapitalinvestition tätigt, die Software an seine Prozesse anpasst und so weiter – wegkommen, sodass daraus ein Vermögenswert wird, den man abschreibt, und es wird ganz anders betrachtet als jetzt, wo wir alles in die Cloud verlagern. Alle unsere Daten befinden sich in der Cloud. Jetzt wechselt es von Capex zu Opex, und es ist nicht nur eine buchhalterische Entscheidung, ob es Capex oder Opex ist.

Es ist ein Mentalitätswandel, denn was nun passiert, ist – wie zum Beispiel bei KI – dass diese großen Technologielieferanten sagen: “Hey, wir haben diese KI-Technologie, die Ihrer Organisation einen großartigen Mehrwert liefern kann.” Und das mag stimmen, aber was dabei geschieht, ist, dass wir unsere Daten, unser geistiges Eigentum innerhalb des Unternehmens, nutzen, um diese KI-Modelle zu trainieren, die wiederum von anderen Wettbewerbern und anderen Firmen verwendet werden. Nun verlagert sich die Macht vom Kunden hin zum Anbieter, weil jetzt die Anbieter nicht die Daten besitzen, sondern die KI und die Technologie, die Ihre Daten nutzt, um diese zu trainieren und damit ein besseres KI-Tool zu werden, das an andere Unternehmen verkauft werden kann.

Das ist also wichtig. Es ist wirklich wichtig, darüber nachzudenken und die größere Frage zu stellen: Was ist IT für uns? Ist es eine Ware, die wir einfach von der Bilanz bekommen wollen, weil wir uns nicht damit beschäftigen möchten? Vielleicht. Das mag für einige Organisationen in Ordnung sein. Aber Sie erwähnten Amazon und Spotify. Ich garantiere, dass Amazon und Spotify IT nicht nur als eine Ware ansehen, die jemand anderes verwalten könnte. Es ist ein signifikanter Wettbewerbsvorteil, und wir alle müssen nicht danach streben, Amazon oder Spotify zu sein, aber wir können den Anspruch erheben: “Wenn unsere Wettbewerbskraft darin liegt, dass wir eine wirklich effiziente supply chain haben, können wir Produkte schneller an Kunden liefern als jeder andere, und wir können unsere Produkte schnell anpassen und schneller zu unseren Kunden bringen. Okay, das ist Ihr Wettbewerbsvorteil. Jetzt bauen wir eine Technologie, die einzigartig für Sie ist, damit sich dieser Wettbewerbsvorteil wirklich nur schwer replizieren lässt. Wenn ich einfach eine Cloud-Lösung nehme, die jeder kaufen kann, dann habe ich meinen Vorteil verloren.”

Diese gesamte Bewegung hin zur Cloud-Standardisierung von Prozessen und zur Nutzung von Daten, um KI-Modelle zugunsten anderer zu trainieren, verändert sich. Ich denke, es ist ein sehr gefährlicher Trend, der in den kommenden Jahren bei den Organisationen für viel Reue sorgen wird. Daher halte ich es für wichtig, innezuhalten und nachzudenken. Wenn wir wollen, dass IT ein strategischer Vermögenswert ist, der uns differenziert, dann behandeln wir das Projekt auch so. Das bedeutet wahrscheinlich, dass wir nicht auf eine standardfertige Cloud-Technologie setzen. Vielleicht gehen wir stattdessen auf eine maßgeschneiderte Lösung, auch wenn das ein schlechtes Wort ist und man nicht über Anpassungen oder Custom Development sprechen sollte. Das könnte die richtige Antwort für Sie sein, wenn Sie IT als strategischen Vorteil betrachten.

Joannes Vermorel: Vorteil, ja, und ich möchte erneut darauf hinweisen, dass viele Anbieter absolut schlechte Anreize haben. Erneut berechnet die überwiegende Mehrheit der Enterprise-Softwareanbieter pro Nutzerplatz. Wenn also pro Platz abgerechnet wird, sucht man definitiv nicht nach Produktivitätssteigerungen. Wenn Sie Ihre Software weniger effizient oder produktiv machen können, dann haben Sie mehr Nutzerplätze.

Sehen Sie, natürlich sind Enterprise-Softwareanbieter nicht böse. Die meisten Mitarbeiter sind einfach gute Menschen, genau wie 90 % der Bevölkerung. Sie versuchen nicht, ihr Produkt absichtlich zu verschlechtern, nur um mehr Nutzerplätze zu bekommen, aber dennoch ist die Macht der Anreize von enormer Bedeutung.

Das bedeutet beispielsweise, wenn es einen Bereich beim Softwareanbieter gibt, der eine Menge Menschen erfordert, die die Software bedienen, dann fließt das in den Umsatz ein… Wenn der CEO des Softwareunternehmens seine eigenen Verkaufszahlen betrachtet, sagt er: “Oh, schau, da gibt es so viel Schwung.” Ja, ja, denn in diesem Bereich brauchen wir so viele Menschen, die mit der Software interagieren – und das treibt den Umsatz.

Und plötzlich wird es sehr kompliziert. Möchten Sie sich als Softwareanbieter wirklich herausfordern, wenn Sie pro Nutzerplatz abrechnen und Ihr nächstes Upgrade vielleicht 90 % Ihrer Plätze eliminieren wird? Es ist – es ist eine sehr, sehr schwierige Frage. Es ist eine sehr schwierige Frage. Übrigens, historisch betrachtet ist das IBM bereits passiert. IBM rechnete in den 80er und 90er Jahren pro MIPS, Millionen Instruktionen pro Sekunde. Und wissen Sie was? Als IBM pro MIPS abrechnete, wurde ihre Software mit jeder Generation offensichtlich langsamer und langsamer.

Eric Kimberling: Ja, ich meine, Sie sprechen ein wirklich – ein weiteres Thema an, über das wir eine ganze Episode sprechen könnten, und das sind nicht übereinstimmende Erwartungen oder widersprüchliche Anreize. Wissen Sie, wenn Ihr Softwareanbieter und Ihr Systemintegrator – es gibt drei Parteien, drei Hauptparteien – und alle drei sehr unterschiedliche, widersprüchliche Anreize haben, dann ist es schwer, das zu überwinden.

Conor Doherty: Entschuldigen Sie die Unterbrechung, aber ich achte auf Erics Zeit. Sie waren so großzügig, dass Sie bei uns geblieben sind, also werde ich – zumindest können wir später darauf zurückkommen und über die Ethik der Handlungen aller sprechen. Aber für heute werde ich zu einem abschließenden Gedanken überleiten. Ich fange wieder mit Ihnen an, Joannes, in einem positiven Ton. Welchen Rat würden Sie Organisationen geben, ungeachtet all dessen, was wir gesagt haben, oder unter Berücksichtigung all dessen, was wir gesagt haben? Welchen Rat würden Sie Organisationen geben, die kurz davor stehen, ihre digitale Transformation zu beginnen?

Joannes Vermorel: Als ein seit vier Jahrzehnten begeisterter Software-Enthusiast – ich war schon vor einiger Zeit ein Enthusiast, wissen Sie, was Software angeht, auch wenn es damals hauptsächlich Videospiele waren, als ich sehr jung war – würde ich sagen, dass es nie eine bessere Zeit gab, in der Softwaretechnologien so vielversprechend waren. Es ist einfach erstaunlich für mich – die deep learning Revolution, ihr Nachfolger mit LLMs und so weiter. Es ist fast magisch, wissen Sie, die Vorstellung, dass man etwas haben kann, das in der Lage ist, natürliche Sprache zu verarbeiten, um viele Dinge zu tun.

Es ist absolut unglaublich, und diese Technologien sind leicht zugänglich. Sie sind nicht unbedingt billig, aber sie sind leicht zugänglich. Ich würde also sagen, es gab nie eine Zeit, in der man mehr von einer digitalen Transformation erwarten konnte. Ich denke, dass diese digitale Transformation das Versprechen birgt, Ihr Unternehmen wirklich in ein völlig anderes Biest zu verwandeln, das Ihren Kunden in so vielen Aspekten viel mehr bietet. Es kann besseren Service für Ihre Kunden, intelligentere Abläufe bedeuten. Was auch immer – ihr Potenzial ist absolut enorm.

Ich würde also sagen, träumen Sie groß und investieren Sie dann sorgfältig und schrittweise in Dinge, die keine Mega-Projekte sind, denn Risiko – das wäre meine Botschaft für die digitale Transformation. Sie müssen sich in die Lage versetzen, schnell zu scheitern, denn als Softwareanbieter kann ich Ihnen sagen, dass wenn Sie einen Kunden fragen: “Können Sie mir eine wirklich schlechte Schätzung dafür geben, was in den nächsten sechs Monaten passieren wird?” – Sechs Monate, das kann ich vielleicht machen. Ja, ein Jahr wird schon knifflig; zwei Jahre sind wirklich knifflig, weil ich Leute rein und raus rotieren kann. Es könnte ein zwei Jahre andauerndes, störendes Projekt sein, was sehr schwierig zu managen ist.

Fünf Jahre – oh Gott, das ist, als würden wir versuchen, den Todesstern zu konstruieren. Meine Ansicht ist also, ja, die digitale Transformation hat ein enormes Potenzial. Das ist hervorragend, es ist nicht so teuer, also sollten Sie es versuchen, anstatt zu denken, wir müssten sicherstellen, dass alles funktioniert. Ich würde sagen, machen Sie das Gegenteil: Beginnen Sie mit kleinen Dingen, setzen Sie sie schnell um und scheitern Sie schnell, damit Sie im Falle eines Scheiterns sofort zugeben können, dass es ein versunkener Kostenfaktor ist, und weitermachen – anstatt immer weiter zu investieren, was genau das Rezept für Enterprise-Softwareanbieter ist, die letztlich dafür sorgen, dass ihre Kunden zehnmal mehr ausgeben als ursprünglich investiert wurde.

Sie müssen in der Lage sein zu sagen: “Nein, wir hören auf. Wir haben es versucht, wir haben es gesehen, wir sind fertig. Wir werden etwas anderes versuchen, denn die Welt ist groß. Wir haben so viel Potenzial; wir müssen uns nicht unbedingt an den ursprünglichen Plan halten. Es ist in Ordnung, wenn eine Initiative nach drei Monaten scheitert. Aber es ist einfach nicht in Ordnung, wenn sie nach drei Jahren scheitert.”

Eric Kimberling: Nachdem Sie bereits Milliarden oder Hunderte von Millionen Dollar ausgegeben haben.

Joannes Vermorel: Ja, ja.

Conor Doherty: Nun, Eric, es ist hier üblich, den Gästen das letzte Wort zu überlassen, also noch einmal dieselbe Frage: Irgendwelche Ratschläge für Menschen oder Unternehmen, die ihre Reise gerade beginnen?

Eric Kimberling: Naja, ich meine, das war ein großartiger Rat, den Sie gerade gegeben haben. Und ich würde vielleicht noch hinzufügen, dass Sie in – in Change Management investieren sollten. Stellen Sie sicher, dass Sie Ihre Zeit in Change Management investieren, um es weniger wahrscheinlich zu machen, dass Sie überhaupt schnell scheitern müssen. Aber ich stimme zu: Man will schnell scheitern, und deshalb denke ich, dass es viel effektiver ist, klein anzufangen, langsam zu starten und dann zu beschleunigen, als zu schnell und zu groß zu starten und später abbremsen zu müssen. Das führt einfach zu vielen Motivationsproblemen, viel Unsicherheit und Zweifeln in der Organisation.

Also, ja, scheitern Sie schnell, aber investieren Sie auch in den organisatorischen Wandel. Und ein weiterer Punkt, den ich anmerken möchte, ist, dass Sie sich zu Beginn Zeit nehmen sollten, denn in den ersten Monaten eines Projekts, bevor Sie überhaupt mit der Implementierung von Technologie beginnen, wird die Richtung festgelegt. Ich meine, Sie setzen die Vision, die Parameter, die Richtung des Projekts. Achten Sie also darauf, diesen Teil richtig hinzubekommen. Wenn Sie Zweifel haben, ob Sie diese Klarheit besitzen, dann nehmen Sie sich die Zeit, es richtig zu machen.

Denn je mehr Zeit Sie zu Beginn investieren, um diesen Teil richtig hinzubekommen, desto schneller wird das Gesamtprojekt voranschreiten. Tatsächlich werden Sie viel schneller implementieren und viel Zeit und Geld sparen, wenn Sie zu Beginn einfach langsamer vorgehen. Sie können später immer noch beschleunigen, aber fangen Sie langsam an. Das wäre mein letzter Abschlusstipp.

Conor Doherty: Ich habe keine weiteren Fragen. Vielen Dank für Ihre Zeit, Eric, das weiß ich sehr zu schätzen.

Eric Kimberling: Tolles Gespräch, hat auch viel Spaß gemacht, ich habe es sehr genossen.

Conor Doherty: Also, Joannes, ich habe nichts weiter zu sagen, außer noch einmal: Vielen Dank für Ihre Zeit, Eric, nochmals. Vielen Dank auch für Ihre, und danke an alle fürs Zuschauen. Wir sehen uns beim nächsten Mal.