Software-Design für Supply Chains

00:00:07 Bedeutung von Software-Design in modernen supply chains.
00:01:22 Häufige Probleme im Software-Design im Supply Chain Management.
00:02:37 Herausforderungen von Echtzeit-Softwaresystemen in supply chains.
00:04:55 Wie komplexe Operationen Echtzeitsysteme beeinflussen können.
00:07:13 Echtzeitsysteme, die durch nicht-echtzeitliche Operationen verstopft werden.
00:09:13 Bedeutung von Designentscheidungen und Zeitskalen in Supply Chain Software.
00:12:31 Unterschiede zwischen Single Tenant und Multi Tenant Software.
00:14:11 Herausforderungen bei mehreren Versionen von Software in Single Tenant Anwendungen.
00:15:33 Vorteile von Multi Tenant Software und der Wechsel zu SaaS-Modellen.
00:17:56 Bedeutung des Verständnisses grundlegender Annahmen im Software-Design für supply chain Praktiker.
00:19:18 Grundlegende Designannahmen von Lokad, einschließlich Batch-Verarbeitungsmodus und Multi-Tenancy.
00:21:35 Abschließende Gedanken zum Verständnis von Entscheidungen in der Software und deren Auswirkungen auf zukünftige Operationen.
00:23:36 Abschließende Gedanken.

Zusammenfassung

In einem Interview mit Joannes Vermorel, dem Gründer von Lokad, wird der Einfluss des Software-Designs auf supply chain optimization diskutiert. Herausforderungen entstehen oft durch Designprobleme statt durch Bugs oder Abstürze, die die Software langsam, unintuitiv und schwer konfigurierbar machen können. Die Verarbeitung von Echtzeitdaten ist ein zentrales Merkmal, das Operationen beeinflussen kann. Allerdings kann die Fokussierung auf schnelle, einfache Operationen komplexe Prozesse wie Prognosen oder netzwerkweite Analysen behindern. Es ist entscheidend, die Annahmen des Software-Designs zu verstehen, um Probleme infolge von Unstimmigkeiten zwischen dem Design der Software und der beabsichtigten Nutzung durch ein Unternehmen zu vermeiden.

Erweiterte Zusammenfassung

In diesem Interview diskutiert der Moderator Kieran Chandler mit Joannes Vermorel, dem Gründer von Lokad, den Einfluss des Software-Designs auf Unternehmensabläufe, insbesondere im Kontext der supply chain optimization. Vermorel betont die Bedeutung des Software-Designs in modern supply chains, die auf mehreren Softwareebenen basieren, wie ERPs, MRPs, WMSs, OMSs und EDIs, um effizient zu funktionieren.

Die Herausforderungen, denen sich Lokads Kunden stellen müssen, resultieren oft aus Problemen mit dem Design ihrer Software, statt aus offensichtlichen Fehlern oder Abstürzen. Diese Designprobleme können die Software träge, unintuitiv, langsam und schwer konfigurierbar machen. Wie Vermorel erklärt, entstehen diese Probleme häufig aus einem Missverhältnis zwischen den grundlegenden Designentscheidungen, die für die Software getroffen wurden, und der tatsächlichen Realität des supply chain, für die sie bestimmt ist.

Ein zentrales Merkmal der Softwarearchitektur, das supply chain Operationen beeinflussen kann, ist die Fähigkeit, Echtzeitdaten zu verarbeiten. Vermorel weist darauf hin, dass, während eine echte Echtzeit-Datenverarbeitung aufgrund der endlichen Lichtgeschwindigkeit nicht möglich ist, viele supply chain software Systeme darauf ausgelegt sind, eine Annäherung an die Echtzeit-Datenverarbeitung zu ermöglichen. Zum Beispiel wird, wenn ein Artikel aus einem Regal entnommen wird, der stock level sofort dekrementiert. Dieser Echtzeit-Ansatz kann jedoch unbeabsichtigte Konsequenzen haben.

Wenn Software für schnelle, einfache Operationen konzipiert wird, wird es schwierig, komplexere Operationen wie Prognosen oder netzwerkweite Analysen durchzuführen. Diese komplexen Operationen erfordern ein anspruchsvolleres Maß an Datenverarbeitung, was in einem System, das für Echtzeit-Updates im kleinen Maßstab optimiert ist, möglicherweise nicht machbar ist.

Joannes Vermorel betont die entscheidende Bedeutung des Software-Designs in der supply chain optimization. Die Herausforderungen, denen sich Lokads Kunden stellen müssen, resultieren oft aus Designproblemen, die die Software langsam, unintuitiv und schwer konfigurierbar machen, bedingt durch ein Missverhältnis zwischen den grundlegenden Designentscheidungen der Software und der tatsächlichen Realität des supply chain. Die Fähigkeit, Echtzeitdaten zu verarbeiten, ist ein zentrales Merkmal der Softwarearchitektur, das supply chain Operationen beeinflussen kann. Wenn Software jedoch für schnelle, einfache Operationen ausgelegt ist, wird es schwierig, komplexere Operationen wie Prognosen oder netzwerkweite Analysen durchzuführen, die ein anspruchsvolleres Maß an Datenverarbeitung erfordern.

Vermorel erklärt, dass die Probleme, mit denen supply chain Praktiker bei der Nutzung solcher Software konfrontiert sind, nicht immer offensichtlich sind, da sie sich oft als eine langsame Ansammlung von Problemen manifestieren, die er als “death by a thousand cuts” bezeichnet.

Ein zentrales Problem ist die Notwendigkeit von Echtzeit-Funktionalität in bestimmten scenarios, wie zum Beispiel beim Scannen von Artikeln auf einem Hochgeschwindigkeits-Förderband. Wenn nicht-echtzeitliche Operationen in das System eingeführt werden, kann die Gesamtleistung negativ beeinflusst werden, was zu Verlangsamungen und Verzögerungen führt. Dies kann zu erhöhter Frustration bei den Nutzern und zu geringerer Effizienz führen.

Vermorel hebt die Bedeutung hervor, die richtigen grundlegenden Designentscheidungen zu treffen, die eng mit den Problemen, die die Software zu lösen versucht, abgestimmt sein sollten. Im Kontext von supply chain software werden verschiedene grundlegende Annahmen getroffen, und wenn diese nicht erfüllt werden, können im Laufe der Zeit Probleme auftreten.

Der Zeithorizont, in dem die Software operiert, ist ein entscheidender Faktor. Vermorel beschreibt die verschiedenen Arten von Software, die für unterschiedliche Zeitskalen benötigt werden – von Reaktionszeiten unter einer Millisekunde für den Betrieb von Förderbändern bis hin zu langfristiger Planung, die Entscheidungen über den Standort von Fabriken über Jahre oder gar Jahrzehnte umfasst. Jede Größenordnungserhöhung im Zeithorizont erfordert eine andere Art von Software mit einzigartigen Fähigkeiten.

Bei Lokad liegt der Fokus typischerweise auf Zeitskalen von einem Tag bis zu einem Jahr, was einen anderen Ansatz im Software-Design erfordert. Vermorel geht auch auf die Unterschiede zwischen Single Tenant und Multi Tenant Software ein, was für Softwareentwickler von entscheidender Bedeutung ist, auch wenn es den meisten Unternehmen weniger geläufig ist.

Es werden die Unterschiede zwischen Multi Tenant und Single Tenant Software, die Vorteile des SaaS-Modells und die grundlegenden Annahmen, die das Software-Design von Lokad geprägt haben, diskutiert.

Vermorel erklärt, dass Multi Tenant Software mehrere Kunden mit derselben Software bedient, während Single Tenant Software jedem Kunden eine eigene, angepasste Version bereitstellt. Lokad ist Multi Tenant, mit einer Codebasis, die wöchentlich aktualisiert wird. Dieser Ansatz hat mehrere Vorteile, darunter vereinfachte Versionierung und geringere Sicherheitsprobleme. Vermorel stellt dies der Single Tenant Software gegenüber, die eine kundenspezifische Anpassung ermöglicht, aber die Verwaltung mehrerer Versionen erfordert, was zu betrieblichen Herausforderungen führt.

Er stellt fest, dass in den letzten zehn Jahren viele seriöse Softwareunternehmen auf Multi-Tenancy umgestellt haben. Für Web-Apps wie Lokad ist Multi Tenant relativ unkompliziert, aber für Software, die auf Client-Rechnern läuft, kann es komplizierter sein. Eine Lösung für dieses Problem ist die “evergreen”-Strategie, wie sie beispielsweise von Google Chrome und Microsoft Office 365 umgesetzt wird. Diese Anwendungen aktualisieren sich automatisch, ohne dass der Benutzer eingreifen muss, und mildern so die Probleme, die durch mehrere Versionen derselben Software entstehen.

Im Gespräch über Lokads Software-Design betont Vermorel die Wichtigkeit, die grundlegenden Annahmen eines Anbieters zu verstehen. Er warnt vor Anbietern, die behaupten, ihre Software könne alles, und unterstreicht, dass Design immer mit trade-offs verbunden ist – mit sowohl positiven als auch negativen Aspekten. Er ermutigt potenzielle Kunden, Softwareanbieter nach ihren grundlegenden Annahmen zu fragen, und rät dazu, vorsichtig zu sein bei jenen, die nur vage, positive Antworten geben.

Zu Lokads grundlegenden Designannahmen gehört der Batch-Verarbeitungsmodus, den Vermorel erklärt, gewählt zu werden, da er eine bessere Optimierung und Ressourcenverwaltung ermöglicht.

Ein zentrales Prinzip ist es, intelligente Berechnungen über Geschwindigkeit zu priorisieren. Lokad zieht genaue und detaillierte Berechnungen vor, auch wenn diese länger dauern, statt schneller, weniger präziser Berechnungen. Die Software ist für die Batch-Verarbeitung konzipiert statt für Echtzeit, was eine größere Ausdruckskraft und Leistungsfähigkeit in der Analyse ermöglicht.

Eine weitere grundlegende Annahme ist die Bedeutung von Multi-Tenancy und die Nutzung der Möglichkeiten, die Cloud Computing bietet. Lokad setzt auf Scale-Out-Fähigkeiten statt auf Scale-Up, was bedeutet, dass mehrere kleinere Maschinen zur Verarbeitung großer Datenmengen genutzt werden, anstatt sich auf einen einzelnen, leistungsstarken Supercomputer zu verlassen.

Vermorel betont, wie wichtig es für supply chain Praktiker ist, die grundlegenden Designannahmen ihrer Software zu verstehen. Dieses Verständnis hilft, Probleme zu vermeiden, die aus einem Missverhältnis zwischen dem Design der Software und der beabsichtigten Nutzung durch das Unternehmen entstehen. Anbieter mögen behaupten, dass ihre Software vielseitig und für verschiedene Situationen geeignet ist, doch in der Realität können bestimmte Designbeschränkungen ihre Effektivität in einigen Anwendungen beeinträchtigen.

Vollständiges Transkript

Kieran Chandler: Heute werden wir verstehen, wie diese Entscheidungen ein Unternehmen tatsächlich in eine Schublade stecken können und auch einige der grundlegenden Annahmen dahinter kennenlernen. Also, Joannes, wir sprechen ein wenig darüber, wie schlechtes Software-Design ein Unternehmen tatsächlich beeinflussen kann. Was sind einige der Herausforderungen, die du siehst?

Joannes Vermorel: Die erste Herausforderung besteht darin, dass Software-Design für supply chains von entscheidender Bedeutung ist. Moderne supply chains laufen auf Software. Es gibt trucks, Maschinen, Förderbänder, aber auch große Software-Bausteine wie dein ERP, MRP, WMS, OMS, EDI und viele weitere Ebenen. Moderne supply chains funktionieren nicht in großem Umfang ohne Software. Wenn ich mit den Kunden von Lokad spreche, haben sie häufig Schwierigkeiten mit der anwendungsspezifischen Landschaft des supply chain. Es gibt viele softwarebezogene Probleme, aber es handelt sich dabei nicht unbedingt um Bugs oder Abstürze. Designprobleme sind weitaus umfassender; sie machen die Dinge träge, unintuitiv, langsam und es dauert ewig, das System zu konfigurieren. Wenn man eine Ursachenanalyse durchführt, stellt man häufig fest, dass es sich tatsächlich um Probleme im Software-Design handelt, bei denen grundlegende Entscheidungen über das Design getroffen wurden und die vollkommen nicht mit der tatsächlichen Realität des betreffenden supply chain übereinstimmen.

Kieran Chandler: Also, was sind einige Merkmale der Architektur der Software, die so wichtig sein können? Was sind einige der Herausforderungen, die du bei deinen Kunden gesehen hast?

Joannes Vermorel: Nehmen wir zum Beispiel Echtzeit. Viele supply chain software heute sind auf Echtzeit-Operationen ausgerichtet. Mit Echtzeit meine ich, dass wenn du dich entscheidest, eine Einheit im Regal auszuwählen, der [stock level] sofort dekrementiert wird. Das erscheint sehr vernünftig. Sobald du jedoch eine Art von Software hast, die für Echtzeit konzipiert ist, wird jede anspruchsvolle Berechnung im Betrieb der Software zur großen Herausforderung. Der Grund ist, dass wenn deine Software für super schnelle, super einfache Operationen entworfen wurde, eine komplexe Operation – wie etwa eine Prognose oder eine netzwerkweite Analyse – zu einer echten Schwierigkeit wird. Das liegt daran, dass deine Software für sehr schnelle, kleine Operationen ausgelegt ist und es schwierig wird, eine mäßig komplexe Datenmenge zu verarbeiten.

Kieran Chandler: Und wenn du eine stark granulare Version hast, wird sie alle verlangsamen, auch Dinge, die super schnell sein sollten, wie das Scannen eines Barcodes und ein Signalton. Ich habe gescannt, du kannst zum nächsten Artikel übergehen. Wie offensichtlich sind einige dieser Herausforderungen? Man muss mit einem supply chain Praktiker mitfühlen. Ich meine, da ist so viel los und hinter der Fassade passiert eine Menge – wie offensichtlich ist es also, dass einige dieser Herausforderungen existieren?

Joannes Vermorel: Es ist nicht offensichtlich, denn in der Regel handelt es sich nicht um einen offensichtlichen Bug, bei dem dein System abstürzt. Es ist eher wie “death by a thousand cuts”. Lass mich das veranschaulichen: Du hast dieses System, das in Echtzeit arbeiten soll. Wenn etwas auf einem Hochgeschwindigkeits-Förderband gescannt wird, solltest du in der Lage sein, etwa drei Artikel pro Sekunde pieppen zu lassen. Du solltest wirklich schnell sein und eine Antwortzeit in Millisekunden haben.

Nun, was passiert, wenn hin und wieder eine Berechnung einfach ein paar Sekunden dauert, statt in Millisekunden? Wenn du nur gelegentlich eine Operation hast, die einige Sekunden benötigt, und dein Echtzeitsystem gut gestaltet ist, bleiben wahrscheinlich die meisten anderen Operationen super schnell, sodass es nicht allzu sehr stört. Außer, du hast nicht so viel Glück und zum gleichen Zeitpunkt laufen etwa zehn verschiedene Operationen, die jeweils mehrere Sekunden zur Berechnung brauchen. Das absorbiert in diesem Moment alle Rechenressourcen.

Was passieren wird, ist, dass das System, das in Millisekunden scannen und Feedback geben sollte, plötzlich eine Sekunde benötigt. Es ist nicht ideal, aber man kommt damit zurecht. Allerdings gibt es hin und wieder Momente, in denen man etwas blitzschnelles erwartet, aber plötzlich zwei oder drei Sekunden Verzögerung auftreten. Übrigens, manchmal sieht man das sogar in lokalen Supermärkten: An der Kasse ist das Piepen der Artikel sehr flüssig, doch dann piept es einmal und es vergehen drei Sekunden, bevor wieder gepiept wird.

Hier hast du ein Echtzeitsystem, das irgendwie in eine nicht-echtzeitliche Operation verstrickt wurde. Ich weiß nicht genau, was es war – vielleicht ein Windows-Update oder irgendein merkwürdiges Ereignis, das die Maschine verlangsamt – aber in einem Echtzeitsystem ist es nicht erlaubt, irgendetwas Komplexes oder “Schlaues” zu tun, da dies die super schnellen Operationen, die du durchführen möchtest, beeinträchtigen würde.

Wenn ich von Tod durch tausend Schnitte spreche, liegt das daran, dass beim ersten Mal, wenn du etwas Nicht-Echtzeitliches in einem Echtzeitsystem machst, wahrscheinlich nichts allzu Schlimmes passiert. Es ist selten, also ist es sozusagen in Ordnung. Aber das Problem ist, dass du immer mehr Nicht-Echtzeitliches anhäufst, und plötzlich werden diese Probleme, die bisher sehr selten auftraten, immer häufiger – bis sie super häufig werden. Dann drehen die Leute völlig durch und rufen: “Warum läuft dieses Förderband nicht schneller? Es könnte!”

Die Antwort ist, dass es eine Maschine gibt, die den Barcode scannen soll, und wir auf die Antwort des Systems warten müssen. Ich habe Situationen erlebt, in denen es eine halbe Minute dauerte, bis das System nach dem Scannen eines Barcodes reagierte. Es ging darum, etwas zu drucken, das auf die Box geklebt werden sollte, aber das Förderband war durch die Geschwindigkeit limitiert, mit der das System den Auftrag an den Drucker liefern konnte, um etwas auf der Box zu drucken. Die Leute mussten einfach darauf warten, dass der Drucker seinen Job erledigt.

Es gibt viele Designentscheidungen, bei denen die Kernentscheidungen genau richtig getroffen werden müssen – in einer Weise, die eng mit den Problemen übereinstimmt, die du zu lösen versuchst.

Kieran Chandler: Was sind die wesentlichen Kernannahmen, die in supply chain software getroffen werden, und welche hast du beobachtet, funktionieren nicht wirklich?

Joannes Vermorel: Es gibt viele Ansätze. Zunächst einmal betrachte den Zeithorizont, in dem du operieren möchtest. Wir haben Dinge, die mit einer Unter-Millisekunden-Reaktionszeit arbeiten müssen – was man praktisch braucht, um ein Förderband anzutreiben – bis hin zu Entscheidungen, bei denen man ein Jahrzehnt vorausdenken muss, wie etwa die Standortwahl von Fabriken. Jedes Mal, wenn du eine Größenordnung hinzufügst, änderst du die Software grundlegend.

Kieran Chandler: Kannst du ein paar Beispiele für unterschiedliche Zeitskalen und die entsprechenden Softwaretypen geben?

Joannes Vermorel: Sicher. Unter-Millisekunden sind eine Art von Software; von 1 bis 10 Millisekunden ist es eine andere Art; von 10 bis 100 Millisekunden wiederum eine andere, typischerweise ERP-Software mit Reaktionszeiten von 10 bis 100 Millisekunden. Von 100 Millisekunden bis zu 1 Sekunde findest du die Art von Software, die man in einer Web-App antrifft. Wenn du dann anfängst, 1 bis 10 Minuten vorauszudenken, bist du nicht mehr in Echtzeit, aber du kannst bereits ausgeklügelte Berechnungen durchführen. Zum Beispiel muss eine Navigations-App wie Waze innerhalb einer halben Minute eine Route liefern, ohne in Echtzeit arbeiten zu müssen.

Wenn du eine Route für LKW-Lieferungen optimierst, kannst du typischerweise mehrere Minuten benötigen, um das Ergebnis zu erzielen, da es nicht in Echtzeit erfolgen muss. Bei Lokad konzentrieren wir uns in der Regel auf Zeitrahmen von 1 Tag bis 1 Jahr. Das ist unser optimaler Bereich und bedeutet, dass wir alles, was davor liegt, praktisch ignorieren können. Überschreitet man ein Jahr, betritt man den Bereich des supply chain design, der kartenzentrierter ist und das Problem verändert.

Kieran Chandler: Sprechen wir mehr über die Implementierung von Software. Was sind die wesentlichen Unterschiede zwischen Single Tenant- und Multi-Tenant-Software?

Joannes Vermorel: Der Unterschied zwischen single tenant und multi-tenant besteht darin, wie viele Kunden mit derselben Software bedient werden. Wenn du multi-tenant bist, wie Lokad, dann läuft dieselbe Software für all unsere Kunden. Wir haben jederzeit nur eine Version online im Einsatz und aktualisieren diese Software wöchentlich. Der andere Weg, der vor dem Aufkommen von SaaS gebräuchlicher war, ist single tenant. Dieser Ansatz bedeutet, jedem Kunden eine eigene Kopie der Software zur Verfügung zu stellen, was oft zu individuellen Anpassungen für Großkunden führt.

Die Produktion der Software führt dazu, dass du plötzlich viele Varianten deiner Software hast, die gleichzeitig laufen – was ein großes operatives Problem darstellt, da im Falle eines Fehlers in einer Version diese Version behoben werden muss und gleichzeitig sichergestellt werden muss, dass der Fehler auch in allen anderen Versionen behoben wird. Übrigens, dies ist ein Problem, bei dem Softwarefirmen quasi mit Gegen­skalen zu kämpfen haben. Je größer man wird, desto mehr Probleme entstehen durch die Versionsverwaltung. Dieses Problem trifft beispielsweise Oracle sehr hart, etwa bei der Oracle-Datenbank. Sie haben zahlreiche stark angepasste Versionen, die auf Leistung optimiert sind. Ich habe zwar keine geheimen Insiderinformationen, aber aus öffentlichen Quellen sieht man, dass buchstäblich in mehreren Entwicklungsabteilungen bei Oracle damit gerungen wird, dass es viele Varianten der Software gibt. Offensichtlich verfügt Oracle über enorme Engineering-Kapazitäten, aber dennoch bleibt dies eine große Herausforderung. Single tenant bietet die Möglichkeit der kundenspezifischen Anpassung, bringt aber einen hohen Aufwand pro Kunde mit sich. Multi-tenant hingegen ermöglicht dir, eine Codebasis für alle zu nutzen, ohne individuelle Anpassungen – im Gegenzug kannst du viel schneller weiterentwickeln und hast wesentlich weniger Sicherheitsprobleme.

Kieran Chandler: Wenn du sagst, dass sich der Markt stark in Richtung dieses SaaS-Modells bewegt, warum ist dieses Modell so viel besser? Bietet es dem Unternehmen einen größeren Grad an Flexibilität?

Joannes Vermorel: Ja, in den letzten zehn Jahren haben so ziemlich alle seriösen Softwareanbieter auf Multi-Tenancy umgestellt – selbst bei klassischen traditionellen Desktop-Anwendungen. Denn wenn du, wie Lokad, eine Web-App betreibst, ist Multi-Tenancy relativ unkompliziert. Du stellst die Software einfach auf deinen eigenen Systemen neu bereit, und fertig. Offensichtlich wird es komplizierter, wenn die Software auf den Rechnern der Kunden läuft – wie zum Beispiel bei Browsern wie Internet Explorer oder Google Chrome –, weil du keine Kontrolle über die Systeme der Kunden hast. Aber weißt du, was die Softwareanbieter gemacht haben? Sie haben auf die Evergreen-Strategie umgestellt. Beispielsweise fragt Google Chrome nicht mehr, ob du den Browser aktualisieren möchtest. Wenn Google entscheidet, dass deine Chrome-Version veraltet ist und ersetzt werden muss, aktualisiert Google deinen Browser aus der Ferne. Natürlich können sie deine Software beim nächsten Verbindungsaufbau nicht magisch aktualisieren, falls du keine Internetverbindung hast. Aber vorausgesetzt, du bist online und hast nichts unternommen, um das Upgrade zu verhindern, wird das Upgrade im Grunde ohne dein Zutun durchgeführt. Und wenn man sich ansieht, was Microsoft mit Office 365 macht, ist es dasselbe. Früher hattest du eine Reihe von Microsoft Office-Versionen, wenn du von einer Excel-Version zur nächsten gewechselt hast. Heutzutage erfolgt es on-demand, und Microsoft kümmert sich um das Upgrade. Du hast ein Abonnement, die Software ist auf deinem Rechner installiert, und sie kann sich einfach selbst auf die nächste Version aktualisieren. Und wenn du es so belässt – sofern du deine Upgrade-Optionen nicht deaktivierst – aktualisiert Microsoft quasi alle Desktop-Anwendungen, um das Problem der zahlreichen Versionen derselben Software zu umgehen.

Kieran Chandler: Sprechen wir also ein bisschen über Lokad. Du hast gesagt, dass es bestimmte Kernannahmen in der Softwaregestaltung gibt, die zukünftige Abläufe wirklich beeinflussen können. Was waren also die Kernannahmen, die ihr hier bei Lokad getroffen habt?

Joannes Vermorel: Es gibt Unmengen davon, aber bevor ich auf die Kernannahmen eingehe, möchte ich eine Anmerkung machen. Falls du einen Softwareanbieter triffst, der

Kieran Chandler: … der dir dann erzählt: “Unsere Software kann alles, was wir nicht gebaut haben.” Weißt du, so eine Softwareannahme. Wenn sie dir nur vage Aussagen liefern – ich schlage vor, wenn du einen Softwareanbieter für deine supply chain triffst, frage ihn, was die Kernannahmen sind. Und wenn er dir etwas Undurchsichtiges sagt wie: “Wir sind auf Sicherheit ausgelegt,” super. “Wir sind auf Geschwindigkeit ausgelegt,” ja, das auch. “Wir sind auf Kosteneffizienz ausgelegt,” ja. Weißt du, das sind so ziemlich unsere super vagen, absolut positiven Aussagen. Aber wenn es ums Design geht, ist ein Design-Ansatz immer ein Kompromiss. Er hat positive wie negative Aspekte. Wenn du also mit dem Softwareanbieter darüber sprechen kannst und er dir nur die positiven Aspekte präsentiert, versteht er wahrscheinlich nicht einmal die grundlegende Natur der Softwaregestaltung. Also, Joannes, was sind die zentralen Designannahmen, die ihr bei Lokad eingebaut habt?

Joannes Vermorel: Die erste Annahme war ein Batch-Verarbeitungsmodus. Was bedeutet das? Es bedeutet, dass wir in der Lage sein wollen, Unmengen an Big Data zu verarbeiten und sehr intelligente Berechnungen durchzuführen. Offensichtlich bevorzugen wir es, sehr schlau zu sein, anstatt extrem schnell – was für uns bedeutet, dass Berechnungen typischerweise innerhalb von Minuten erfolgen, wobei es ein Bonus ist, wenn sie in Sekunden durchgeführt werden können. Aber wenn das nicht möglich ist, ist es nicht so schlimm. Wir ziehen es vor, bessere Ergebnisse zu erzielen, selbst wenn es etwas länger dauert. Übrigens, es liegt nicht daran, dass unsere Komponenten auf diese Radzeit achten – es handelt sich lediglich um die Präsentation der Ergebnisse. Vielleicht benötigst du eine halbe Stunde für eine massive Berechnung, aber wenn du auf die Ergebnisse zugreifen möchtest, muss es in Echtzeit sein – wenn auch vorab berechnet. Siehst du, das war eine zentrale Designannahme: Kein Echtzeitbetrieb, sondern Batch. Und der Grund ist, dass wir sehr ausdrucksstark und leistungsfähig sein wollen, um, würde ich sagen, für eine weltweite Analyse so schlau wie möglich zu sein. Eine weitere Annahme war, dass wir Multi-Tenancy einführen wollten. Heutzutage setzen das zwar die meisten um, aber es gibt immer noch Unternehmen, insbesondere im Enterprise-Bereich, die hinterherhinken. Und ich würde sagen, Multi-Tenancy in vollem Umfang.

Kieran Chandler: Kannst du den Unterschied zwischen scalable und scale out erklären?

Joannes Vermorel: Die Möglichkeiten, die die Cloud bietet, bedeuten, dass wir auf Scale Out setzen wollen, statt auf Scale Up. Die Frage ist: Wenn du Terabytes an Daten verarbeiten möchtest, kannst du das erreichen, indem du viele kleine Maschinen zusammenstellst, oder benötigst du dafür einen Supercomputer?

Kieran Chandler: Was ist also unsere wichtigste Schlussfolgerung heute?

Joannes Vermorel: Unsere wichtigste Schlussfolgerung ist, dass die Daten, die uns zur Verfügung stehen, und die getroffenen Softwareentscheidungen stark beeinflussen können, was du in der Zukunft tust. Daher musst du die Entscheidungen, die du triffst, in vollem Umfang verstehen.

Kieran Chandler: Kannst du das näher erläutern?

Joannes Vermorel: Mein Vorschlag wäre, dass supply chain practitioners sich intensiver mit den grundlegenden Designannahmen auseinandersetzen, die ihre eigene Anwendungslandschaft charakterisieren. Sie besitzen viele Apps – können sie mir etwa ein halbes Dutzend kritische Code-Annahmen nennen, die die Details des Produkts erklären? Es mag super technisch klingen, aber wenn du diese zentralen Designannahmen nicht verstehst, wirst du sehr zu leiden haben, wenn dir klar wird, dass du versuchst, etwas umzusetzen, für das das Produkt von vornherein nicht geeignet ist. Häufig habe ich viele Unternehmen erlebt, deren Probleme buchstäblich aus einer Diskrepanz zwischen dem Softwaredesign und dem resultieren, was sie damit zu erreichen versuchen.

Kieran Chandler: Kannst du ein Beispiel nennen?

Joannes Vermorel: Anbieter versuchen, sehr selbstsicher aufzutreten – schließlich willst du als Anbieter deine Software verkaufen. Du willst selbstbewusst wirken und dem Kunden versichern, dass dein Stück supply chain software in allen Situationen hervorragend funktioniert und dass du alles abdeckst. Aber die Realität ist, dass wenn ein Kunde deine Software für etwas einsetzen möchte, das außerhalb deiner Designfähigkeiten liegt, du das nicht einfach mit Klebeband flicken kannst. Du kannst nicht einfach ein Feature hinzufügen. Die Softwareingenieure im Hintergrund werden dir sagen: “Chef, Sorry, das kriegen wir nicht hin. Das wird ein Desaster.”

Kieran Chandler: Alles klar, fassen wir zusammen. Danke, Joannes. Das war alles für diese Woche. Vielen Dank fürs Einschalten, und wir sehen uns beim nächsten Mal wieder. Tschüss fürs Erste.