00:00:07 Bedeutung des Softwaredesigns in modernen Supply Chains.
00:01:22 Häufige Probleme im Softwaredesign im Supply Chain Management.
00:02:37 Herausforderungen von Echtzeit-Softwaresystemen in der Supply Chain.
00:04:55 Wie komplexe Operationen Echtzeitsysteme beeinflussen können.
00:07:13 Echtzeitsysteme verstopft durch nicht-echtzeitfähige Operationen.
00:09:13 Bedeutung von Designentscheidungen und Zeitskalen in der 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 Trend zu SaaS-Modellen.
00:17:56 Bedeutung des Verständnisses von Kernannahmen im Softwaredesign für Supply Chain-Experten.
00:19:18 Kernannahmen des Designs von Lokad, einschließlich des Batch-Verarbeitungsmodus und der Multi-Tenancy.
00:21:35 Abschließende Gedanken zum Verständnis von Softwareentscheidungen und deren Auswirkungen auf zukünftige Operationen.
00:23:36 Schlussgedanken.
Zusammenfassung
In einem Interview mit Joannes Vermorel, dem Gründer von Lokad, wird die Auswirkung des Softwaredesigns auf die Optimierung der Supply Chain diskutiert. Herausforderungen entstehen oft durch Designprobleme anstelle von Fehlern oder Abstürzen, die die Software langsam, nicht intuitiv und schwer konfigurierbar machen können. Die Echtzeit-Datenverarbeitung ist ein wichtiges Merkmal, das sich auf die Betriebsabläufe auswirken kann. Es ist jedoch wichtig, sich auf schnelle, einfache Operationen zu konzentrieren, um komplexe Prozesse wie Prognosen oder netzwerkweite Analysen nicht zu behindern. Es ist entscheidend, die Designannahmen der Software zu verstehen, um Probleme zu vermeiden, die durch Unstimmigkeiten zwischen dem Design der Software und der beabsichtigten Verwendung eines Unternehmens entstehen können.
Erweiterte Zusammenfassung
In diesem Interview diskutiert Moderator Kieran Chandler mit Joannes Vermorel, dem Gründer von Lokad, die Auswirkungen des Softwaredesigns auf die Unternehmensabläufe, insbesondere im Kontext der Optimierung der Supply Chain. Vermorel betont die Bedeutung des Softwaredesigns in modernen Supply Chains, die auf mehreren Ebenen von Software wie ERPs, MRPs, WMSs, OMSs und EDIs basieren, um effizient zu funktionieren.
Die Herausforderungen, mit denen die Kunden von Lokad häufig konfrontiert sind, resultieren oft aus Problemen mit dem Design ihrer Software, anstatt offensichtlichen Fehlern oder Abstürzen. Diese Designprobleme können die Software träge, nicht intuitiv, langsam und schwer konfigurierbar machen. Wie Vermorel erklärt, resultieren diese Probleme oft aus einer Diskrepanz zwischen den Kernentscheidungen, die für die Software getroffen wurden, und der tatsächlichen Realität der Supply Chain, für die sie gedacht ist.
Eine der wichtigsten Funktionen der Softwarearchitektur, die sich auf die Betriebsabläufe in der Supply Chain auswirken kann, ist ihre Fähigkeit, Echtzeitdaten zu verarbeiten. Vermorel weist darauf hin, dass zwar eine echte Echtzeitdatenverarbeitung aufgrund der endlichen Lichtgeschwindigkeit nicht möglich ist, viele Supply Chain Software Systeme jedoch darauf ausgelegt sind, eine Echtzeitdatenverarbeitung zu approximieren. Wenn zum Beispiel ein Artikel aus einem Regal entnommen wird, verringert die Software den Lagerbestand sofort. Dieser Echtzeitansatz kann jedoch unerwünschte Konsequenzen haben.
Wenn Software für schnelle, einfache Operationen konzipiert ist, wird es schwierig, komplexere Operationen wie Prognosen oder netzwerkweite Analysen durchzuführen. Diese komplexen Operationen erfordern eine anspruchsvollere Datenverarbeitung, die innerhalb eines Systems, das für Echtzeit-Updates im kleinen Maßstab optimiert ist, möglicherweise nicht realisierbar ist.
Joannes Vermorel betont die entscheidende Bedeutung des Software-Designs für die Optimierung der Supply Chain. Die Herausforderungen, mit denen die Kunden von Lokad häufig konfrontiert sind, resultieren oft aus Designproblemen, die die Software langsam, nicht intuitiv und schwer konfigurierbar machen und auf einer Diskrepanz zwischen den Kernentscheidungen der Software und der tatsächlichen Realität der Supply Chain beruhen. Die Fähigkeit, Echtzeitdaten zu verarbeiten, ist eine wichtige Funktion der Softwarearchitektur, die sich auf die Betriebsabläufe in der Supply Chain auswirken kann. Wenn jedoch Software für schnelle, einfache Operationen konzipiert ist, wird es schwierig, komplexere Operationen wie Prognosen oder netzwerkweite Analysen durchzuführen, die eine anspruchsvollere Datenverarbeitung erfordern.
Vermorel erklärt, dass die Probleme, mit denen Supply Chain-Praktiker bei der Verwendung solcher Software konfrontiert sind, nicht immer offensichtlich sind, da sie sich oft als langsame Ansammlung von Problemen manifestieren, die er als “Tod durch tausend Schnitte” bezeichnet.
Ein zentrales Problem besteht in der Notwendigkeit von Echtzeitfunktionalität in bestimmten Szenarien, wie z.B. dem Scannen von Artikeln auf einem Hochgeschwindigkeits-Förderband. Wenn nicht-Echtzeit-Operationen in das System eingeführt werden, kann dies die Gesamtleistung negativ beeinflussen und zu Verlangsamungen und Verzögerungen führen. Dies kann zu erhöhter Frustration bei den Benutzern und geringerer Effizienz führen.
Vermorel betont die Bedeutung der richtigen Kern-Designentscheidungen, die eng mit den Problemen verbunden sein sollten, die die Software zu lösen versucht. Im Kontext von Supply Chain-Software werden verschiedene Kernannahmen getroffen, und wenn diese nicht erfüllt werden, können Probleme entstehen.
Der Zeithorizont, auf dem die Software arbeitet, ist eine entscheidende Überlegung. Vermorel beschreibt die verschiedenen Arten von Software, die für verschiedene Zeithorizonte benötigt werden, von Reaktionszeiten im Sub-Millisekundenbereich für den Betrieb von Förderbändern bis hin zu langfristiger Planung, die Entscheidungen zur Standortwahl von Fabriken über Jahre oder sogar Jahrzehnte hinweg umfasst. Jede Verzehnfachung des Zeithorizonts erfordert eine andere Art von Software mit einzigartigen Fähigkeiten.
Bei Lokad liegt der Fokus in der Regel auf Zeithorizonten von einem Tag bis zu einem Jahr, was einen anderen Ansatz für das Software-Design erfordert. Vermorel geht auch auf die Unterschiede zwischen Single-Tenant- und Multi-Tenant-Software ein, was für Softwareentwickler eine wichtige Überlegung ist, aber den meisten Unternehmen weniger vertraut ist.
Sie diskutieren die Unterschiede zwischen Multi-Tenant- und Single-Tenant-Software, die Vorteile des SaaS-Modells und die Kernannahmen, die das Software-Design von Lokad geleitet haben.
Vermorel erklärt, dass Multi-Tenant-Software mehrere Kunden mit derselben Software bedient, während Single-Tenant-Software jedem Kunden eine eigene angepasste Version zur Verfügung stellt. Lokad ist Multi-Tenant, mit einer wöchentlich aktualisierten Code-Basis. Dieser Ansatz hat mehrere Vorteile, darunter vereinfachte Versionierung und weniger Sicherheitsprobleme. Vermorel stellt dies dem Single-Tenant-Software gegenüber, die eine kundenspezifische Anpassung ermöglicht, aber die Verwaltung mehrerer Versionen erfordert und zu betrieblichen Herausforderungen führt.
Er stellt fest, dass im Laufe des letzten Jahrzehnts viele seriöse Softwareunternehmen auf Multi-Tenancy umgestiegen sind. Für Webanwendungen wie Lokad ist Multi-Tenant recht einfach, aber für Software, die auf Client-Maschinen arbeitet, kann es komplizierter sein. Eine Lösung für dieses Problem ist die “evergreen” Strategie, wie sie von Google Chrome und Microsoft Office 365 verkörpert wird. Diese Anwendungen aktualisieren sich automatisch, ohne Benutzereingriff, um die Probleme mehrerer Versionen derselben Software zu mildern.
Bei der Diskussion über das Software-Design von Lokad betont Vermorel die Bedeutung des Verständnisses der grundlegenden Annahmen eines Anbieters. Er warnt vor Anbietern, die behaupten, ihre Software könne alles tun, und betont, dass Design eine Frage von Kompromissen ist, mit positiven und negativen Aspekten. Er ermutigt potenzielle Kunden, Softwareanbieter nach ihren grundlegenden Annahmen zu fragen und vorsichtig zu sein bei denen, die nur vage, positive Antworten geben.
Zu den grundlegenden Design-Annahmen von Lokad gehört der Batch-Verarbeitungsmodus, den Vermorel erklärt, weil er eine bessere Optimierung und Ressourcenverwaltung ermöglicht.
Ein weiteres wichtiges Prinzip besteht darin, intelligente Berechnungen gegenüber Geschwindigkeit zu priorisieren. Lokad zieht es vor, genaue und detaillierte Berechnungen zu haben, auch wenn es länger dauert, anstatt schnellere, weniger präzise Berechnungen. Die Software ist für die Stapelverarbeitung konzipiert, nicht für Echtzeit, was eine größere Ausdruckskraft und Leistung bei 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 zielt darauf ab, Scale-Out-Fähigkeiten anstelle von Scale-Up zu nutzen, was bedeutet, dass sie mehrere kleinere Maschinen zur Verarbeitung großer Datenmengen verwenden, anstatt sich auf einen einzigen leistungsstarken Supercomputer zu verlassen.
Vermorel betont die Bedeutung, dass Supply-Chain-Praktiker die grundlegenden Design-Annahmen ihrer Software verstehen. Dieses Verständnis hilft, Probleme zu vermeiden, die sich aus einer Diskrepanz zwischen dem Design der Software und dem beabsichtigten Einsatz des Unternehmens ergeben. Anbieter können behaupten, dass ihre Software vielseitig und für verschiedene Situationen geeignet ist, aber in Wirklichkeit können bestimmte Design-Einschränkungen ihre Wirksamkeit in einigen Anwendungen beeinträchtigen.
Vollständiges Transkript
Kieran Chandler: Heute werden wir verstehen, wie diese Entscheidungen ein Unternehmen tatsächlich einschränken können, und auch einige der grundlegenden Annahmen verstehen, die dahinter liegen. Also, Joannes, wir sprechen ein wenig darüber, wie schlechtes Software-Design ein Unternehmen tatsächlich beeinflussen kann. Welche Herausforderungen sehen Sie?
Joannes Vermorel: Die erste Herausforderung besteht darin, dass das Software-Design für Lieferketten von entscheidender Bedeutung ist. Moderne Lieferketten laufen auf Software. Sie haben LKW, Maschinen, Förderbänder, aber auch große Teile von Software wie Ihr ERP, MRP, WMS, OMS, EDI und so viele Schichten. Moderne Lieferketten funktionieren nicht ohne Software in großen Mengen. Wenn ich mit Kunden von Lokad spreche, kämpfen sie häufig gegen die Anwendungslandschaft der Lieferkette. Es gibt viele softwarebezogene Probleme, aber sie sind nicht unbedingt Fehler oder Abstürze. Designprobleme sind viel weitreichender; sie machen die Dinge träge, nicht intuitiv, langsam und es dauert ewig, das System zu konfigurieren. Wenn Sie eine Ursachenanalyse durchführen möchten, stellen Sie häufig fest, dass die Probleme tatsächlich Designprobleme der Software sind, bei denen grundlegende Entscheidungen über das Design der Software getroffen wurden und es einfach nicht mit der tatsächlichen Realität der betreffenden Lieferkette übereinstimmt.
Kieran Chandler: Was sind also einige Merkmale der Softwarearchitektur, die so wichtig sein können? Welche Herausforderungen haben Sie bei Ihren Kunden gesehen?
Joannes Vermorel: Nehmen wir zum Beispiel Echtzeit. Viele heutige Supply-Chain-Softwarelösungen sind auf Echtzeitbetrieb ausgerichtet. Mit Echtzeit meine ich, dass der Bestand unmittelbar verringert wird, wenn Sie sich entscheiden, eine Einheit aus dem Regal zu entnehmen. Das scheint eine sehr vernünftige Sache zu sein. Sobald Sie jedoch eine solche Software haben, die für Echtzeitbetrieb konzipiert ist, wird jede komplexe Berechnung zu einer großen Herausforderung. Der Grund dafür ist, dass eine Software, die für superschnelle und einfache Operationen ausgelegt ist, Schwierigkeiten hat, komplexe Operationen wie Prognosen oder netzwerkweite Analysen durchzuführen. Wenn Sie also eine moderat komplexe Datenmenge verarbeiten müssen, wird es schwierig.
Kieran Chandler: Und wenn Sie eine große granulare Version haben, verlangsamt dies alle, einschließlich Dingen, die eigentlich superschnell sein sollten, wie das Scannen eines Barcodes und das Ausführen eines Pieptons. Ich habe gescannt, Sie können zum nächsten Artikel übergehen. Wie offensichtlich sind einige dieser Herausforderungen? Man muss mit einem Supply-Chain-Praktiker sympathisieren. Ich meine, es passiert so viel, und mit dieser Software passiert unter der Haube eine Menge. Wie offensichtlich ist es, dass einige dieser Herausforderungen existieren?
Joannes Vermorel: Es ist nicht offensichtlich, weil es normalerweise kein offensichtlicher Fehler ist, bei dem Ihr System abstürzt. Es ist eher wie der Tod durch tausend Schnitte. Lassen Sie mich das verdeutlichen: Sie haben dieses System, das in Echtzeit arbeiten soll. Wenn etwas auf einem Hochgeschwindigkeits-Förderband gescannt wird, sollten Sie in der Lage sein, drei Artikel pro Sekunde zu piepen oder so etwas. Sie sollten wirklich schnell sein und eine Millisekunden-Reaktionszeit haben.
Was passiert nun, wenn gelegentlich eine Berechnung ein paar Sekunden dauert anstatt Millisekunden? Wenn Sie nur eine Operation haben, die gelegentlich ein paar Sekunden dauert, und Ihr Echtzeitsystem gut konzipiert ist, werden wahrscheinlich die meisten anderen Operationen superschnell bleiben, sodass es nicht so sehr schadet. Es sei denn, Sie haben Pech und zur gleichen Zeit haben Sie zehn verschiedene Operationen, die mehrere Sekunden dauern, um berechnet zu werden. Das absorbiert dann zu diesem bestimmten Zeitpunkt alle Rechenressourcen.
Was passiert also ist, dass das System, das in der Lage sein sollte, zu scannen und Ihnen in Millisekunden Feedback zu geben, plötzlich eine Sekunde dauert. Es ist nicht ideal, aber man kann damit leben. Doch gelegentlich haben Sie diese Situation, in der Sie etwas Blitzschnelles erwartet haben, aber plötzlich gibt es zwei oder drei Sekunden Verzögerung. Übrigens kann man das manchmal sogar in lokalen Supermärkten beobachten. Sie haben eine Kasse und das Piepen der Artikel ist sehr flüssig, aber irgendwann piepen sie etwas und dann vergehen drei Sekunden, und dann piepen sie weiter.
Hier haben Sie ein Echtzeitsystem, das in eine nicht-echtzeitfähige Operation verstopft wurde. Ich weiß nicht, was es war, vielleicht ein Windows-Update oder irgendein seltsamer Vorfall, der den Computer verlangsamt hat. Aber in einem Echtzeitsystem dürfen Sie nichts Intelligentes oder Komplexes tun, weil das die superschnellen Operationen beeinträchtigt, die Sie durchführen möchten.
Wenn ich von Tod durch tausend Schnitte spreche, dann deshalb, weil beim ersten Mal, wenn Sie in einem Echtzeitsystem etwas Nicht-Echtzeitfähiges tun, wahrscheinlich nichts Schlimmes passiert. Es ist selten, also ist alles in Ordnung. Aber das Problem ist, dass sich immer mehr nicht-echtzeitfähige Dinge ansammeln, und plötzlich werden diese Probleme, die sehr selten waren, immer häufiger und häufiger, bis sie superhäufig werden. Dann drehen die Leute durch und fragen sich: “Warum funktioniert dieses Förderband nicht schneller? Es könnte doch.”
Die Antwort lautet, dass es eine Maschine gibt, die den Barcode scannen soll, und wir müssen auf die Antwort des Systems warten. Ich habe Situationen gesehen, in denen es eine halbe Minute dauerte, bis das System nach dem Scannen eines Barcodes geantwortet hat. Es ging darum, etwas zu drucken, das auf die Schachtel geklebt werden sollte, aber das Förderband war durch die Geschwindigkeit begrenzt, mit der das System den Druckauftrag an den Drucker senden konnte. Die Leute mussten einfach auf den Drucker warten.
Es gibt viele Designentscheidungen, die richtig getroffen werden müssen, und zwar in einer Weise, die eng mit den Problemen verbunden ist, die Sie lösen möchten.
Kieran Chandler: Welche grundlegenden Annahmen werden in der Supply-Chain-Software getroffen, und welche davon haben Sie beobachtet, dass sie nicht wirklich funktionieren?
Joannes Vermorel: Es gibt viele Möglichkeiten, dies anzugehen. Zunächst sollten Sie den Zeitrahmen betrachten, in dem Sie arbeiten möchten. Wir haben Dinge, die in Echtzeit reagieren müssen, was erforderlich ist, um ein Förderband buchstäblich zu steuern, bis hin zu Entscheidungen, bei denen Sie ein Jahrzehnt im Voraus denken müssen, wie beispielsweise die Standortwahl von Fabriken. Jedes Mal, wenn Sie eine Größenordnung hinzufügen, ändert sich die Software grundlegend.
Kieran Chandler: Können Sie einige Beispiele für verschiedene Zeitskalen und die entsprechenden Arten von Software geben?
Joannes Vermorel: Sicher. Sub-Millisekunden sind eine Art von Software; von 1 bis 10 Millisekunden handelt es sich um eine andere Art von Software; von 10 bis 100 Millisekunden handelt es sich um eine weitere Art von Software, typischerweise ERP-Software mit Reaktionszeiten von 10 bis 100 Millisekunden. Von 100 Millisekunden bis 1 Sekunde erhalten Sie die Art von Dingen, die Sie in einer Webanwendung finden können. Wenn Sie dann von 1 Minute bis 10 Minuten im Voraus denken, sind Sie nicht mehr in Echtzeit, aber Sie können anspruchsvolle Berechnungen durchführen. Zum Beispiel muss eine Navigations-App wie Waze eine Route innerhalb von einer halben Minute bereitstellen, muss aber nicht in Echtzeit sein.
Wenn Sie eine Route für LKW-Lieferungen optimieren, können Sie in der Regel mehrere Minuten benötigen, um die Ergebnisse zu erhalten, da es nicht in Echtzeit sein muss. Bei Lokad konzentrieren wir uns in der Regel auf Zeiträume von 1 Tag bis 1 Jahr. Dies ist der optimale Bereich für uns und bedeutet, dass wir im Wesentlichen alles davor ignorieren können. Wenn wir über ein Jahr hinausgehen, betreten wir den Bereich des Supply-Chain-Designs, das mehr kartenbasiert 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 Sie mit derselben Software bedienen. Wenn Sie wie Lokad Multi-Tenant sind, handelt es sich um dieselbe Software, die alle unsere Kunden bedient. Wir haben immer nur eine Version online bereitgestellt, und wir aktualisieren diese Software wöchentlich. Der andere Weg, der vor dem Aufkommen von SaaS häufiger war, ist Single-Tenant. Bei diesem Ansatz erhält jeder Kunde eine eigene Kopie der Software, was oft zu Anpassungen für große Kunden führt.
Die Bereitstellung der Software bedeutet, dass Sie plötzlich viele Varianten Ihrer Software haben, die gleichzeitig ausgeführt werden, was ein großes operatives Problem darstellt. Denn das bedeutet, dass wenn in einer Version ein Fehler auftritt, Sie diesen in dieser Version beheben müssen, aber sicherstellen müssen, dass der Fehler auch in allen anderen Versionen behoben ist. Übrigens handelt es sich hierbei um ein Problem, bei dem Softwareunternehmen wie Anti-Skaleneffekte auftreten. Je größer Sie sind, desto mehr Probleme haben Sie mit Ihrer Versionsverwaltung. Übrigens hat Oracle zum Beispiel mit der Oracle-Datenbank mit diesem Problem zu kämpfen. Sie haben viele stark angepasste Versionen, die auf Leistung optimiert sind. Ich habe keine geheimen Insiderinformationen, aber aus öffentlichen Informationen kann man sehen, dass sie buchstäblich in einigen mehreren Entwicklungsabteilungen bei Oracle mit der Tatsache zu kämpfen haben, dass sie viele Varianten der Software haben. Oracle verfügt natürlich über viele technische Möglichkeiten, aber dennoch bleibt dies eine große Herausforderung. Daher bietet Single-Tenant die Möglichkeit der kundenspezifischen Anpassung, aber dann müssen Sie sich mit dem kundenspezifischen Overhead befassen. Multi-Tenant bietet Ihnen die Tatsache, dass Sie einen Code-Basis für alle haben, keine Anpassungen, aber im Gegenzug können Sie sich viel schneller weiterentwickeln und haben auch viel weniger Sicherheitsprobleme.
Kieran Chandler: Wenn Sie sagen, dass der Markt sehr stark in Richtung dieses SaaS-Modells geht, warum ist dieses Modell so viel besser? Bietet es dem Unternehmen einen größeren Flexibilitätsgrad?
Joannes Vermorel: Ja, in den letzten zehn Jahren sind praktisch alle ernsthaften Softwareanbieter zu Multi-Tenancy übergegangen, selbst klassische Desktop-Anwendungen. Denn offensichtlich ist es für eine Webanwendung wie Lokad recht einfach, Multi-Tenant zu sein. Sie stellen die Dinge auf Ihren eigenen Systemen neu bereit, und das war’s. Natürlich ist es komplizierter, wenn Sie Software haben, die auf Client-Maschinen ausgeführt wird, wie zum Beispiel Ihren Browser, Internet Explorer oder Google Chrome. Denn Sie haben keine Kontrolle über Ihre Client-Maschinen. Aber raten Sie mal, was Softwareanbieter getan haben? Sie sind zur Evergreen-Strategie übergegangen. Zum Beispiel fragt Google Chrome Sie nicht mehr nach einem Browser-Update. Wenn Google feststellt, dass Ihre Chrome-Version veraltet ist und ersetzt werden muss, aktualisiert Google Ihren Browser aus der Ferne. Natürlich können sie Ihre Software nicht magisch aktualisieren, wenn Sie keine Internetverbindung haben, vorausgesetzt, Sie haben eine Internetverbindung und haben keine speziellen Tricks mit Ihrer Maschine angewendet, um das Upgrade zu verhindern. Das Upgrade erfolgt im Grunde genommen ohne Ihr Zutun. Und wenn Sie sich ansehen, was Microsoft mit Office 365 macht, ist es dasselbe. Früher gab es eine Reihe von Microsoft Office-Versionen, wenn Sie von einer Excel-Version zur nächsten wechselten. Heutzutage geschieht dies auf Abruf, und Microsoft kümmert sich um das Upgrade. Sie haben ein Abonnement, die Software ist auf Ihrem Computer installiert, aber sie kann sich selbst auf die nächste Version aktualisieren. Und wenn Sie es einfach zulassen, es sei denn, Sie deaktivieren Ihre Upgrade-Optionen, aktualisiert Microsoft einfach alle Desktop-Anwendungen, um das Problem vieler Versionen derselben Software zu mildern.
Kieran Chandler: Sprechen wir ein wenig über Lokad. Sie haben gesagt, dass es bestimmte grundlegende Annahmen gibt, die bei der Softwareentwicklung getroffen werden müssen und die sich wirklich auf zukünftige Operationen auswirken können. Welche grundlegenden Annahmen haben Sie hier bei Lokad getroffen?
Joannes Vermorel: Davon gibt es viele, aber bevor ich auf die grundlegenden Annahmen eingehe, möchte ich eine Anmerkung machen. Wenn Sie einen Softwareanbieter treffen,
Kieran Chandler: Der Ihnen sagt, dass meine Software alles kann, wissen Sie. Wir sind in der Lage, alles zu machen, was wir nicht gemacht haben. Sie wissen schon, Softwareannahme. Wenn sie Ihnen nur, kann ich vorschlagen, wenn Sie einen Softwareanbieter für Ihre Supply Chain treffen, fragen Sie sie, was sind die grundlegenden Annahmen? Und wenn sie Ihnen etwas vages sagen wie “wir sind auf Sicherheit ausgelegt”, großartig. “Wir sind auf Geschwindigkeit ausgelegt”, ja, ich auch. “Wir sind auf Kosteneffizienz ausgelegt”, ja. Das sind sozusagen unsere super vagen, absolut positiven Dinge. Aber wenn wir über Design sprechen, ist ein Designstandpunkt ein Kompromiss. Es hat positive Aspekte und negative Aspekte. Wenn Sie also mit dem Softwareanbieter diskutieren können und sie Ihnen nur die positiven Aspekte nennen können, liegt es wahrscheinlich daran, dass sie die Natur des Softwaredesigns überhaupt nicht verstehen. Also, Joannes, welche grundlegenden Designannahmen haben Sie in Lokad eingebaut?
Joannes Vermorel: Die erste war ein Batch-Verarbeitungsmodus. Was bedeutet das? Das bedeutet, dass wir in der Lage sein wollen, Tonnen von großen Datenmengen zu verarbeiten und sehr intelligente Berechnungen durchzuführen. Natürlich möchten wir lieber sehr intelligent sein, anstatt sehr, sehr schnell zu sein, was bedeutet, dass wir für uns Berechnungen haben möchten, die normalerweise innerhalb von Minuten ausgeführt werden, aber die Tatsache, dass sie innerhalb von Sekunden ausgeführt werden können, ist sozusagen ein Bonus. Aber wenn wir es nicht können, ist es nicht so schlimm. Wir ziehen es vor, bessere Zahlen zu haben, auch wenn es etwas Zeit kostet. Übrigens ist es nicht so, dass es unsere Teile gibt, die das betrachten, unsere Raddrehzeit, es ist nur eine Präsentation der Ergebnisse. Also, vielleicht benötigen Sie eine halbe Stunde, um eine massive Berechnung durchzuführen, aber wenn Sie auf diese Ergebnisse zugreifen möchten, muss es in Echtzeit sein, aber es ist vorberechnet. Sie sehen, das war eine grundlegende Designannahme. Keine Echtzeit oder es ist Stapelverarbeitung. Und der Grund dafür ist, dass wir sehr ausdrucksstark und sehr leistungsstark sein wollen und somit so intelligent wie möglich für eine weltweite Analyse sein können. Das ist eine grundlegende Annahme. Eine weitere war, dass wir Multi-Tenancy haben wollten. Heutzutage machen das die meisten Leute, aber es gibt immer noch Unternehmen, insbesondere im Unternehmensbereich, die hinterherhinken. Und ich würde sagen, Multi-Tenancy, das mit allem gemacht wird.
Kieran Chandler: Kannst du den Unterschied zwischen skalierbar und skalierbar machen erklären?
Joannes Vermorel: Die Möglichkeiten, die die Cloud bietet, bedeuten, dass wir skalierbare Fähigkeiten anstelle von Skalierung nach oben haben möchten. Die Frage ist, wenn Sie Terabyte an Daten verarbeiten möchten, können Sie das tun, indem Sie Tonnen von kleinen Maschinen stapeln oder benötigen Sie einen Supercomputer, um dies zu tun?
Kieran Chandler: Was ist also unser Hauptfazit hier heute?
Joannes Vermorel: Unser Hauptfazit ist, dass es in Bezug auf die vorhandenen Daten und die Entscheidungen über Software sehr stark einschränken kann, was Sie in Zukunft tun. Sie müssen also die getroffenen Entscheidungen vollständig verstehen.
Kieran Chandler: Kannst du das näher erläutern?
Joannes Vermorel: Mein Vorschlag wäre, dass Supply-Chain-Praktiker sich mehr der grundlegenden Designannahmen bewusst sein sollten, die ihre eigene Anwendungslandschaft charakterisieren. Sie haben viele Apps und können sie mir ein halbes Dutzend kritischer Codeannahmen nennen, die die Vor- und Nachteile des Produkts erklären. Es mag sich super technisch anhören, aber wenn Sie diese grundlegenden Designannahmen nicht verstehen, werden Sie viel leiden, wenn Sie feststellen, dass Sie versuchen, etwas zu tun, für das dieses Produkt von vornherein nicht geeignet ist. Ich habe häufig viele Unternehmen gesehen, bei denen ihre Probleme buchstäblich aus einer Diskrepanz zwischen dem Design der Software und dem, was sie damit tun möchten, entstehen.
Kieran Chandler: Kannst du ein Beispiel geben?
Joannes Vermorel: Anbieter versuchen sehr zuversichtlich zu sein, wissen Sie, als Anbieter versuchen Sie, Ihre Software zu verkaufen. Sie möchten zuversichtlich auftreten und dem Kunden sagen, dass Ihre Supply-Chain-Software in allen Situationen gut funktionieren wird und dass wir Sie abgedeckt haben. Aber die Realität ist, dass wenn ein Kunde Ihre Software für etwas verwenden möchte, das außerhalb Ihrer Designfähigkeiten liegt, können Sie das nicht einfach mit Klebeband beheben. Sie können nicht einfach eine Funktion hinzufügen. Die Software-Ingenieure auf der Backend-Seite werden Ihnen sagen: “Chef, tut mir leid, wir können das nicht tun. Das wird die Hölle sein.”
Kieran Chandler: Okay, lassen Sie uns das abschließen. Vielen Dank, Joannes. Das war alles für diese Woche. Vielen Dank fürs Zuschauen und bis zum nächsten Mal. Tschüss für jetzt.
