Modularisierung in der Supply Chain

00:00:03 Einführung in die Modularisierung in IT und Supply Chains.
00:00:26 Physische Modularität in der Supply Chain.
00:02:31 Monolithische Strukturen früher IT-Systeme.
00:04:08 IT-Kontext monolithischer Systeme.
00:05:31 Auswirkungen des Internets auf modulare Softwareentwicklung.
00:08:02 Probleme bei monolithischen Softwaresystemen.
00:08:48 Ineffizienzen von monolithischen Systemen.
00:11:16 Übergang zu modularen Systemen: Beispiele.
00:13:34 Systemausfälle bei modularen Anwendungen.
00:14:34 Redundanz, Betriebszeit bei modularen Systemen.
00:16:00 Zuverlässigkeit großer Systeme, Softwareprojektfehler.
00:16:50 Beispiel für fehlgeschlagene Softwareumstellung bei Lidl.
00:18:09 Konzept des “Fail fast” in Softwareprojekten.
00:19:30 Verwaltung von Überschneidungen, Bedeutung von “Klebstoff”-Software.
00:22:46 Vermeidung von Softwarekatastrophen.

Zusammenfassung

In der Lokad TV-Episode diskutiert Joannes Vermorel, der Gründer von Lokad, die Bedeutung der Modularisierung in der IT-Infrastruktur von Unternehmen und zieht dabei einen Vergleich zur Anpassungsfähigkeit von Supply Chains. Er verweist auf die monolithischen IT-Systeme der 70er und 80er Jahre, die durch ihre Unflexibilität aufgrund technologischer Einschränkungen gekennzeichnet waren. Selbst mit dem Übergang zu vernetzten Systemen nach dem Aufkommen des Internets betont er die fortlaufende Herausforderung für Unternehmen, ihre IT-Systeme zu modularisieren. Vermorel schlägt Serviceorientierte Architektur (SOA) als mögliche Lösung vor und betont die Notwendigkeit kleinerer, klar definierter Services. Er warnt davor, groß angelegte Projekte anzugehen, und befürwortet einen “Fail fast”-Ansatz, der die Bedeutung des Risikomanagements und einer schnellen Wiederherstellung im Falle von Fehlern hervorhebt.

Erweiterte Zusammenfassung

In der aktuellen Episode von Lokad TV führt Moderator Kieran Chandler ein Gespräch mit Joannes Vermorel, dem Gründer von Lokad, über die Modularisierung in der IT-Infrastruktur von Unternehmen. Vermorel erläutert das Konzept der Modularisierung und zieht vor allem Parallelen zu Supply Chains in der physischen Welt, die er als eine der modularsten Schöpfungen der Menschheit betrachtet.

Er verwendet die Beispiele von LKW, Paletten und Containern, um seine Punkte zur Modularität zu verdeutlichen. Vermorel betont die inhärente Modularität physischer Supply Chains, indem er auf die universelle Anwendbarkeit von Barcodes hinweist, die praktisch überall angebracht werden können.

Obwohl physische Supply Chains eine klare Modularität aufweisen, stellt Vermorel fest, dass die IT-Infrastrukturen von Unternehmen oft eine ähnliche Flexibilität vermissen lassen. Er führt diese fehlende Modularität auf die frühen Phasen der IT-Entwicklung in Unternehmen während der 1970er und 1980er Jahre zurück, als anfängliche IT-Implementierungen und ERP-Systeme aufgrund der technologischen Einschränkungen der Zeit als eigenständige, monolithische Strukturen konzipiert wurden.

Vermorel definiert einen ‘Monolith’ in IT-Begriffen als eine einheitliche Anwendung, die nicht in kleinere Teile aufgeteilt werden kann. Er erklärt, wie dieser monolithische Ansatz im Gegensatz zur Modularität in physischen Supply Chains steht, bei denen verschiedene Komponenten je nach Bedarf kombiniert oder getrennt werden können.

Trotz ihrer Komplexität erklärt Vermorel, dass die frühen Großrechner von Natur aus kohärent waren, da sie als eine Einheit mit zentralisierten Operationen fungierten. Er weist darauf hin, wie diese Form des Systemdesigns für die aktuelle Generation, die an verteilte Systeme und netzbasierte Anwendungen gewöhnt ist, veraltet zu sein scheint und im Laufe der Jahre eine bedeutende Veränderung in der Entwicklung der IT-Infrastruktur darstellt.

Vermorel weist darauf hin, dass sich die Landschaft mit dem Aufkommen des Internets Ende der 90er Jahre zu ändern begann, was zur Entwicklung von Software mit isolierten Teilen führte, die durch ein Netzwerk verbunden sind. Er bemerkt jedoch, dass viele Unternehmen trotz des theoretisch verstandenen Werts modularer IT-Systeme immer noch Schwierigkeiten mit der Modularisierung haben.

Er erklärt, wie viele Anbieter diese alten monolithischen Architekturen an Cloud- und Software-as-a-Service (SaaS)-Modelle angepasst haben, was zu Systemen führt, die eine verbesserte Wartung bieten, aber die Modularität nicht verbessern. Er sagt, dass dieser Mangel an Modularität Unternehmen daran hindert, bestimmte Funktionen zu isolieren und zu ändern.

Um dieses Problem zu überwinden, schlägt Vermorel eine serviceorientierte Architektur (SOA) vor, einen Ansatz, der Fähigkeiten in kleinere, klar definierte “Chunks” aufteilt. Er verweist auf Amazon als Beispiel für ein Unternehmen, das frühzeitig diesen modularen Ansatz erfolgreich umgesetzt hat.

Er plädiert für eine serviceorientierte Architektur mit APIs, die es ermöglichen, Daten über verschiedene Abteilungen eines Unternehmens exportieren und nutzen zu können. Obwohl er anerkennt, dass ein dezentraler Ansatz im Vergleich zu einem monolithischen System ein höheres Potenzial für Fehlerstellen bietet, argumentiert Vermorel, dass diese Herausforderungen durch Redundanz und hochwertige Ingenieurskunst gemildert werden können.

Vermorel schätzt, dass zwischen einem Drittel und der Hälfte aller IT-Projekte in der Supply Chain scheitern. Er verweist auf den Fall von Lidl in Deutschland, das eine halbe Milliarde Euro bei einer gescheiterten SAP-Umstellung verloren hat. Er argumentiert, dass der Wechsel von kleinen Anbietern zu großen Anbietern die Ausfallraten nur geringfügig reduziert, aber nicht beseitigt.

In Bezug auf das Management mehrerer Anwendungen schlägt Vermorel vor, Anwendungen mit einem engen Anwendungsbereich zu wählen, um Überlappungen zu minimieren, und rät davon ab, große Frameworks von Anbietern zu kaufen. Um mehrere Apps effektiv zu verwalten, sollten Unternehmen laut ihm internes “Klebstoff” entwickeln, der diese Anwendungen zusammenbindet und durch eine serviceorientierte Architektur erleichtert wird.

Schließlich gibt Vermorel Ratschläge, wie man Katastrophen wie die gescheiterte SAP-Umstellung von Lidl verhindern kann. Er betont das Denken in Bezug auf Risikomanagement und die Annahme eines “Fail-Fast”-Ansatzes. Er rät davon ab, im Projektmanagement Wunschdenken zu betreiben, und unterstreicht die Bedeutung der Planung für mögliche Ausfälle und der Suche nach Möglichkeiten zur schnellen Wiederherstellung.

Vollständiges Transkript

Kieran Chandler: Hallo und herzlich willkommen zu einer weiteren Folge von Lokad TV. Diese Woche werden wir über Modularisierung sprechen, den Prozess der Unterteilung der Computerprozesse unseres Unternehmens von einem eigenständigen System in eine Reihe von Unterprogrammen oder sogar Apps. Wie immer bin ich mit Joannes Vermorel zusammen. Also, Joannes, von welchen Geschäftsprozessen sprechen wir heute, die wir modularer gestalten möchten?

Joannes Vermorel: Heute konzentrieren wir uns besonders auf die IT-Infrastruktur und die Anwendungsumgebung Ihres Unternehmens. Modularisierung ist interessant. Wenn man an die physische Welt denkt, ist es offensichtlich, dass Supply Chains unglaublich modular sind. Sie sind wahrscheinlich das modularste, was jemals von der Menschheit erfunden wurde. Mit modular meine ich, dass Sie, wenn Sie Waren auf Straßen transportieren möchten, Lastwagen verwenden können. Lastwagen sind unglaublich modular, weil Sie praktisch alles, was die Kapazität eines Lastwagens nicht überschreitet, darin transportieren können, und ein Lastwagen kann auf jeder Straße fahren, von überall nach überall. Wenn Sie zusätzliche Lastwagen benötigen, könnten Sie praktisch jeden Lastwagentyp verwenden, und sie können die Transportkapazität Ihrer Supply Chain erhöhen.

Das Gleiche gilt für Paletten und Container. Sie können praktisch alles auf eine Palette oder in einen Container legen, solange es die Kapazität nicht überschreitet. Ein Container ist äußerst modular. Sie können ihn von einem Frachtschiff auf einen Lastwagen bewegen. All diese Teile sind unglaublich modular. Sie können praktisch auf alles, was nicht zu klein ist, einen Barcode setzen. Es ist eine unglaublich moderne Erfindung. Wenn Sie etwas wie einen Diamanten haben, würden Sie ihn wahrscheinlich in eine Schachtel legen und dann den Barcode oben auf die Schachtel setzen. Sie können all diese einfachen Elemente nach Belieben kombinieren, nahezu unendlich. Es ist sehr Lego-ähnlich; einfache Teile, die Sie auf unglaublich vielfältige Weise kombinieren können. Das ist die physische Supply Chain, die unglaublich modular ist.

Interessanterweise ist jedoch, wenn wir in die IT-Welt wechseln, die Perspektive völlig anders und die Modularisierung geht häufig verloren. Ich glaube, dass der Ursprung davon in den frühen 70er oder 80er Jahren liegt, als Unternehmen ihre ersten Computersysteme und ihre ersten ERP-Implementierungen hatten.

Kieran Chandler: Also, was du sagst, ist, dass diese anfänglichen Implementierungen, diese anfänglichen IT-Systeme, weil sie sehr stark auf einen einzigen Ansatz ausgerichtet waren, immer noch das sind, was wir heute verwenden. Ist das das, was du sagst?

Joannes Vermorel: Ja, in der Tat. Wenn man an die IT oder Software der 70er, 80er oder sogar der frühen 90er Jahre zurückdenkt, war alles, was über das Netzwerk gemacht wurde, wie Raketenwissenschaft. Es war möglich, aber es war ein Albtraum für die Ingenieure. Es war viel einfacher zu sagen, wir nehmen eine große Maschine, idealerweise einen IBM-Großrechner aus dieser Zeit, und legen die gesamte Logik auf diese Maschine. Dann verwendet jeder ein Terminal, das mit dieser Maschine verbunden ist, und die gesamte Logik läuft in einem Monolithen auf dieser Maschine.

Kieran Chandler: Was meinst du also mit Monolith?

Joannes Vermorel: Mit einem Monolith meine ich, dass es sich um eine App handelt, die als Ganzes betrachtet wird. Sie kann nicht auseinander genommen werden. Sie muss zusammen sein oder es ist nichts.

Kieran Chandler: Ich fürchte, ich bin ein bisschen ein Millennial, also könnte diese Art von Idee ein wenig vor meiner Zeit liegen. Aber im Grunde genommen sagen wir, dass alles mit einer einzigen Maschine verbunden ist, richtig? Und dann verbinden wir uns alle und arbeiten von dort aus?

Joannes Vermorel: Genau. Mainframes waren relativ komplexe Hardware-Dinge, auch wenn es sich um eine Maschine handelte.

Kieran Chandler: Wir sprechen hauptsächlich von ERPs, das heißt, von Enterprise Resource Management-Systemen. Diese Systeme sind in der Regel so konzipiert, dass sie erweiterbar sind und die Hinzufügung zusätzlicher Funktionen und Features ermöglichen. Sie sind jedoch nicht modular, das heißt, Sie können diese Funktionen nicht voneinander trennen, um sie vollständig isoliert zu halten.

Joannes Vermorel: Das Interessante ist, dass sich wirklich etwas geändert hat, wahrscheinlich das Internet. Ich beziehe mich nicht auf die Erfindung des Internets, sondern darauf, dass in den späten 90er Jahren, als das Internet sehr populär wurde, die Leute begannen, darüber nachzudenken, wie man Software so entwerfen kann, dass man die Teile isoliert nimmt, mit dem Netzwerk in der Mitte. Auf diese Weise ist der Workflow kein Albtraum für die Ingenieure. Vorher war es, wenn man nicht wusste, wie man ein komplexes Softwaresystem aus vielen Teilen erstellt, ein Albtraum für die Ingenieure, ein Netzwerk in der Mitte zu haben. Dieses Know-how, diese Kultur und diese Werkzeuge sind größtenteils als Nebenprodukt der Nutzung des Internets durch die breite Öffentlichkeit entstanden.

Kieran Chandler: Das Internet gibt es schon lange, warum sprechen wir immer noch von Modularisierung? Warum verhalten sich diese Software immer noch sozusagen auf diese Art und Weise?

Joannes Vermorel: Meine Diagnose ist, dass, wenn man sich das durchschnittliche Unternehmen ansieht, das eine komplexe Lieferkette oder eine multinational mit vielen Standorten betreibt, alles Physische unglaublich modular ist. Wenn wir uns jedoch die IT anschauen, ist sie komplett monolithisch. Ich glaube, dass Unternehmen und der Markt im Allgemeinen immer noch Schwierigkeiten haben, den Wert von etwas zu schätzen, das in Bezug auf die IT äußerst modular ist. Physisch ist es ziemlich offensichtlich, und Lieferketten verbessern immer noch ihre Modularität. In Bezug auf die Anwendungslandschaft ist es jedoch abstrakter, schwieriger, die Modularität als solche wahrzunehmen.

Viele Anbieter haben alte monolithische Architekturen genommen, sie leicht auf SaaS und die Cloud aktualisiert, aber nur kopiert und eingefügt. Es handelt sich im Wesentlichen um die gleiche Art von Architektur, die Sie in einem IBM-Großrechner der 90er Jahre hatten, bei dem Sie einfach entschieden haben, dass Sie anstelle einer Maschine im Hauptsitz Ihres Unternehmens, die das System ausführt, es einem Softwareanbieter überlassen, der als SaaS fungiert. Aber wenn der SaaS-Anbieter nur einen Monolithen hat, der auf einer Maschine läuft, die weit entfernt von Ihrem Hauptsitz ist, mit nur etwas Netzwerk und einer Web-Benutzeroberfläche in der Mitte, bringt das in Bezug auf die Modernisierung nichts. Es erleichtert nur die Wartung. Aber wenn Sie die Funktionen auseinandernehmen möchten, stehen Sie immer noch vor einem Monolithen, in dem solche Fähigkeiten nicht möglich sind.

Kieran Chandler: Was ist das Problem mit diesem monolithischen Ansatz? Wie beeinflusst er Unternehmen in der realen Welt?

Joannes Vermorel: Stellen Sie sich das physische Äquivalent von fehlender Modularisierung vor. Stellen Sie sich vor, dass Sie in Ihrer Lieferkette jedes Mal, wenn Sie einen LKW ändern möchten, alle ändern müssen. Wenn Sie zum Beispiel von einem LKW zu einem anderen wechseln, benötigen Sie eine andere Art von Benzin. Also müssten alle Ihre Tankstellen geändert werden, was bedeutet, dass Sie Tanks haben, die Benzin enthalten, für das Sie eine zweite Art von Benzin benötigen. Das wäre immens.

Der Schmerz, sehen Sie, ist vergleichbar mit der Situation in der Software. Wenn Ihnen die Modernisierung fehlt, ist es so, als ob Sie, wenn Sie ein Teil ändern, alle ändern müssen. Wenn Sie einen LKW ändern, müssen Sie Ihre gesamte Flotte ändern. Stellen Sie sich vor, Sie ändern die Regale eines Lagers und Sie müssten alle Regale aller anderen Lager ändern, sonst ist es nicht kompatibel. Dann erkennen Sie, okay, vielleicht kann ich mich entscheiden, meine LKW-Flotte auf Elektro-LKWs umzurüsten, aber das wäre ein massiver strategischer Schritt und sehr kompliziert. Sie würden immer noch lieber etwas relativ Modulares haben, wo Sie Elektro-LKWs und Verbrennungsmotoren-LKWs über einen langen Zeitraum hinweg harmonisch nebeneinander haben können. Wenn Ihnen die Modernisierung fehlt, bedeutet das, dass Sie diese Art des Nebeneinanders nicht haben können. Sie können einige Teile Ihrer Lieferkette nicht ändern, ohne alles zu ändern.

Das häufigste anekdotische Beweismittel für diesen Mangel an Modernisierung ist, dass Unternehmen, um von einem Lager zu einem anderen physisch zu wechseln, dies in etwa einem Tag erledigen könnten, indem sie die Sachen, die in einem Lager auf den Regalen von Lager A liegen, auf die Regale von Lager B verschieben. Aber um die Software zu migrieren, die mit Lager A verbunden war, damit alles weiß, dass sich alle Sachen im System befinden, das Lager B steuert, würde das etwa sechs Monate dauern.

Kieran Chandler: Das ist interessant. Wie machen das große Unternehmen, wenn sie auf diesem monolithischen System existieren? Wie migrieren sie zu einem modularen System?

Joannes Vermorel: Ich denke, wir werden zu einem der Unternehmen zurückkehren, die wir in praktisch jeder einzelnen Episode erwähnt haben, wie Amazon. Sie sind nicht die einzigen, die einen äußerst modularen Ansatz gewählt haben. In Deutschland hat Zalando, wie Sie in den Blogs verfolgen können, jetzt auch einen sehr modularen Ansatz vollständig übernommen, und das Schlüsselwort in der IT dafür, wenn Sie diese Modularität haben möchten, ist wahrscheinlich Serviceorientierte Architektur, SOA.

Serviceorientierte Architektur bedeutet im Grunde genommen, dass Sie Fähigkeiten in Chunks isolieren möchten, die selbst wie kleine Monolithen sind, aber viel kleiner, und dass sie sehr gut abgegrenzt sind, um eine Sache gut zu erledigen. Und Sie verbinden all diese Dinge durch Ihre serviceorientierte Architektur, was bedeutet, dass jeder einzelne Service, im Sinne einer App, die eine Sache gut macht, APIs bereitstellt, damit er sehr einfach in Ihre Anwendungslandschaft integriert werden kann. Es ist so konzipiert, dass es programmgesteuert in jede beliebige Anwendungslandschaft eingebunden werden kann, ohne fast irgendwelche Annahmen darüber zu treffen, was die anderen Teile der Anwendungslandschaft sind.

Jeff Bezos von Amazon hat eine sehr berühmte Mitteilung veröffentlicht, ich glaube, es war 2002, in der er allen seinen Teams sagte, dass jede einzelne Abteilung eine serviceorientierte Architektur mit APIs haben muss, damit die Daten, die Sie in Ihrem Silos haben, exportiert werden können, um in jeder anderen Abteilung im Unternehmen genutzt zu werden, und wir können programmgesteuert mit dem interagieren, was auch immer Sie aufbauen.

Kieran Chandler: Das Problem, das ich sehe, ist, dass Sie von vielen kleineren Apps, kleineren Programmen, letztendlich kleineren Unternehmen abhängig werden. Führt das nicht zu viel mehr Single Points of Failure? Während Sie bei einem monolithischen Ansatz ein solides großes Unternehmen haben, ein großes ERP-System, das immer läuft, und Sie mehr Vertrauen darin haben.

Joannes Vermorel: Das stimmt, und in gewissem Maße ist das eine der Herausforderungen eines verteilten Systems. Wenn Ihre Hardware 1% der Zeit ausfällt, dann bedeutet das, wenn Sie einen Großrechner haben.

Kieran Chandler: Sie haben erwähnt, dass die Software drei Mal im Jahr ausfallen kann. Wenn Sie 10 Apps haben, von denen jede eine einprozentige Chance hat, an einem beliebigen Tag auszufallen, bedeutet das, dass etwa alle 10 Tage etwas in Ihrem Netzwerk ausfällt. Das ist in der Tat eine Herausforderung. Welche Lösungen würden Sie für diese Situation vorschlagen?

Joannes Vermorel: Redundanz ist das erste, was mir in den Sinn kommt, aber ich würde gerne die Auswirkungen in Bezug auf verteiltes Computing diskutieren, und vielleicht können wir dann über kleine gegen große Unternehmen und die Unterschiede zwischen Anbietern sprechen. Aus Sicht des verteilten Computings besteht das Ziel darin, sicherzustellen, dass jeder einzelne Block hochgradig redundant ist. Das ist das Wesen des Cloud Computing. Sie möchten stark redundante Software haben, damit Ihre Betriebszeit sehr hoch ist.

Die gute Nachricht ist, dass es aufgrund der kleineren und einfacheren Apps viel einfacher ist, eine sehr hohe Betriebszeit mit einer kleinen einfachen App zu erreichen als mit einer sehr komplexen App. Es gibt viele Komponentendienste im Internet, die buchstäblich immer eingeschaltet sind. Google Mail zum Beispiel ist buchstäblich immer eingeschaltet. Die Website von Yahoo ist im Grunde genommen immer eingeschaltet. Auch Facebook ist immer eingeschaltet. Es ist also möglich, diese “immer eingeschaltet” Eigenschaften für Ihre Apps zu entwickeln, was die Zuverlässigkeit Ihres Systems als Ganzes betrifft.

Kieran Chandler: Was ist mit dem Übergang von einem großen Anbieter zu vielen kleinen Anbietern?

Joannes Vermorel: Die Realität ist, dass die Ausfallraten von Software hoch sind. Die Leute erkennen nicht, dass vielleicht die Hälfte der Zeit Softwareprojekte scheitern. Meine Schätzung wäre, dass zwischen einem Drittel und der Hälfte aller Supply-Chain-IT-Projekte für Unternehmen jeder Größe scheitern. Vor ein paar Wochen hat Lidl in Deutschland etwa eine halbe Milliarde Euro für eine gescheiterte SAP-Migration ausgegeben. Es war ein siebenjähriges Projekt, das in einem Misserfolg endete, und sie haben letztendlich aufgegeben. Aber das ist nicht das einzige Beispiel; das passiert ziemlich häufig.

Große Anbieter haben wahrscheinlich eine bessere Erfolgsquote, aber wenn wir von groben Schätzungen sprechen, gehen wir von einem kleinen Anbieter mit einer Ausfallrate von 50% aus, was ziemlich schlecht ist, zu einem großen Anbieter mit einer Ausfallrate von 30%. Wenn Sie also von einem kleinen zu einem großen Unternehmen wechseln, nimmt Ihr Risiko leicht ab, aber nur geringfügig.

Wenn Sie sich für einen hochmodularen Ansatz entscheiden, werden sicherlich viele Dinge scheitern, aber Sie haben die Möglichkeit, es erneut zu versuchen und zu wiederholen, bis Sie Erfolg haben. Jede Komponente hat eine Chance zu scheitern, aber weil der Umfang einfacher ist, die App selbst kleiner ist, können Sie schnell scheitern und es erneut versuchen.

Das Problem bei der Lidl-Methode ist, dass ich ziemlich sicher bin, dass sie ursprünglich keine siebenjährige Migration geplant hatten. Es war wahrscheinlich eine zweijährige Migration, die sich zu drei, dann vier Jahren entwickelte, und so weiter, weil sie scheiterten, wiederholten und erneut scheiterten. Sieben Jahre später haben sie schließlich beschlossen aufzugeben, wahrscheinlich weil jeder die Hoffnung auf den Erfolg des Projekts verloren hatte.

Kieran Chandler: Wenn wir also übereinstimmen, dass diese Apps, sobald Sie die richtige gefunden haben und vielleicht ein wenig iterieren, zuverlässig sein können… Sie scheinen zu funktionieren und sie scheinen die gleiche Aufgabe wie ein größeres System zu erfüllen. Was ist mit dem Überschneidungsbereich zwischen diesen Apps? Denn oft kann eine App etwas anderes gut machen und es könnte ein wenig Überschneidung und Konflikte innerhalb dieses Systems geben. Wie verwalten Sie das?

Joannes Vermorel: Zunächst einmal, wenn Sie die Zusammensetzung Ihrer Anwendungslandschaft wählen, möchten Sie wirklich Apps mit einem engen Anwendungsbereich wählen. Dieser Ansatz steht im völligen Gegensatz zu dem, was die meisten Angebotsaufforderungen (RFPs) tun. Wenn Unternehmen versuchen, eine Software zu erwerben, gehen sie oft nach einer RFP und wollen alles - alle Funktionen, alle Extras. Aber das ist das Gegenteil von dem, wonach Sie suchen sollten. Sie möchten etwas, das extrem eng ist, damit Sie Ihre Überschneidungen von vornherein minimieren.

Wenn Sie große Frameworks kaufen, ist das ein Rezept für Überschneidungen. Enterprise-Anbieter sind daran interessiert, Ihnen große Frameworks zu verkaufen, weil sie es mit vielen Funktionen erweitern können. Sie verkaufen Ihnen etwas und dann verkaufen sie Ihnen die Add-Ons oben drauf. Also würde ich Leuten, die große Lieferketten betreiben, raten, sehr vorsichtig zu sein, wenn ihnen eine Plattform verkauft wird.

Eine Plattform ist gut, aber zwei Plattformen können ein Albtraum sein. Sobald Sie mehrere Anbieter haben, die Ihnen Plattformen verkaufen, werden Sie mit einer Vielzahl von Überschneidungen enden. Die Lösung besteht darin, die Zusammensetzung Ihrer Komponenten sorgfältig zu wählen.

In Bezug auf die “Verbindung” ist der Ansatz, dass dies typischerweise etwas ist, das Sie intern entwickeln möchten. Das mag gegen die Intuition sprechen, warum Sie überhaupt eine Art von Software intern entwickeln möchten. Die Antwort ist, dass Ihre Anwendungslandschaft als Unternehmen einer bestimmten Größe völlig einzigartig ist.

Selbst wenn Sie alle Standard-Apps verwenden, werden Sie mehrere Apps benötigen. Es gibt keine Möglichkeit, dass Sie heutzutage ein ERP haben können, das E-Mails, Videokonferenzen und dergleichen kann. Sie können nicht jede einzelne Softwarefunktion, die Sie benötigen, in eine App integrieren. Sie werden wahrscheinlich wie alle anderen Microsoft Excel verwenden, also benötigen Sie einen Ort zum Speichern von Dateien und so weiter.

Es ist unrealistisch zu sagen, dass wir ein Stück Software haben. Jedes Unternehmen von bedeutender Größe wird sowieso eine Sammlung von Software sein. Das genaue Rezept, also die Liste der Software, die Ihr Unternehmen buchstäblich betreibt, wird sowieso völlig einzigartig für Sie sein. Kein anderes Unternehmen ist genau wie Sie organisiert.

Kieran Chandler: Es ist völlig einzigartig, das ist Ihre DNA. Sie können diesen Klebstoff haben, den Sie intern implementieren. Das ist der ganze Sinn der serviceorientierten Architektur, um diesen Klebstoff so einfach und schlank wie möglich zu implementieren, damit Sie ein sehr schlankes IT-Team haben, das minimale Anstrengungen unternehmen muss. Um diese benutzerdefinierte Software zu entwickeln, die einfach alles miteinander verbindet. Also, um es zusammenzufassen, wenn ich ein CEO bin, wie vermeide ich eine weitere Lidl-artige Katastrophe?

Joannes Vermorel: Zuerst denke ich, es ist wesentlich, an Risiken zu denken, anstatt das Risiko zu minimieren. Die Lidl-artige Katastrophe bestand darin, dass die Leute sagten: “Wir wollen keinerlei Risiko eingehen”, und deshalb entschieden sie sich für den größten Anbieter und versuchten, das Produkt zu bekommen, das alles kann. Im Wesentlichen ist dies der Ansatz, bei dem wir sagen, dass wir etwas wollen, das von Anfang an korrekt ist, und wir möchten etwas einführen, das das gesamte Unternehmen auf einmal aktualisiert. Dies ist die schlechteste Art des Risikomanagements.

Sie müssen genau das Gegenteil denken, nämlich “Wie kann ich etwas haben, das schnell scheitert, wenn es scheitern muss?” Sehen Sie, das Problem mit dem Risiko besteht darin, dass Sie bei einem solchen massiven Projekt über einen langen Zeitraum nicht wissen, ob Sie gescheitert sind oder nicht. Sie möchten etwas haben, das eher “schnell scheitert”, bei dem Sie wissen, ob Sie gescheitert sind und das Scheitern in kleinem Maßstab erfolgt. Und wenn Sie einen Ersatz benötigen, haben Sie einen überschaubaren Umfang und Sie tun dies mit vielen kleinen Teilen.

Also denken Sie daran, das Risiko nicht zu verhindern. Ich sage, dass der Wechsel von einem großen Anbieter zu einem kleinen Anbieter das Risiko von einer 50%igen Ausfallchance auf 50% erhöhen kann. Am Ende, wenn eine 30%ige Ausfallchance bedeutet, dass Ihr Unternehmen bankrott geht oder die Lieferkette zum Stillstand kommt, ist es kein Risiko, das Sie eingehen können. Sie müssen also sowieso auf einen Ausfall vorbereitet sein.

Meine Überlegung ist, dass aufgrund eines hohen Risikograden ein Scheitern unvermeidlich ist. Gehen Sie also direkt auf einen Plan für das Scheitern zu. Versuchen Sie, kleine, schnelle und gut abgegrenzte Fehler zu haben, damit Sie iterieren können, anstatt zu sagen, dass wir beim ersten Mal alles richtig machen werden, was Wunschdenken ist. Dann begeben Sie sich auf eine Reise, die wahrscheinlich sieben Jahre dauern kann, um am Ende eine halbe Milliarde Euro zu verlieren. Das ist die Art von Wunschdenken beim Projektmanagement.

Kieran Chandler: Großartig, das gefällt mir. Der Lokad-Tipp des Tages: Wenn Sie scheitern, dann scheitern Sie schnell. Genial. Das war alles für diese Woche. Wir sind nächste Woche wieder mit einer weiteren Episode zurück. Bis dahin vielen Dank fürs Zuschauen.