00:00:00 Einführung in das Interview
00:00:47 Paul Jans Hintergrund und Lehrerfahrung
00:02:16 Die Rolle von Daten im supply chain und im Unterricht
00:04:00 Zusammenarbeit mit Lokad und deren Auswirkungen
00:06:20 Praktische Herausforderungen im supply chain und Unterrichtshürden
00:10:49 Erklärung der “wicked problems” im supply chain
00:14:37 Auswirkungen der Unternehmenskommunikation auf die Produktwahrnehmung
00:16:11 Kontinuierliche Datenanalyse und Excels Grenzen
00:19:11 Umgang mit relationalen Daten und Excels Schwächen
00:21:49 Übergang zu SQL für die Datenverarbeitung
00:24:11 Vorteile der Einführung von Lokad für Studierende
00:26:33 Unterrichtskosten im supply chain
00:29:13 Einsatz von Envision und Kritik an Unternehmenssoftware
00:32:24 Lösungsorientiertes Denken und Tool-Grenzen
00:35:16 Bessere Tools für bessere supply chain Lösungen
00:37:57 Joannes Vermorels Unterrichtserfahrung und Philosophie
00:41:15 Grundlegende Datenstrukturen und Prognosegrenzen
00:45:31 Visuelle Lehrmethoden und starke Annahmen
00:48:32 Notwendigkeit von Disruption in der supply chain Branche
00:51:12 Der supply chain als Sammlung von “wicked problems”
00:54:24 Annähernd korrekte Ergebnisse im supply chain
00:57:55 Lehren von “wicked problems” im supply chain
01:00:47 Abschließende Worte und die Bedeutung von Investitionen aus dem privaten Sektor
01:03:24 Überwinden der Angst vor Statistik und abschließende Bemerkungen
Zusammenfassung
Conor Doherty, Moderator von Lokad TV, führte kürzlich ein Gespräch mit Joannes Vermorel, Gründer von Lokad, und Paul Jan, einem supply chain Professor an der University of Toronto. Das Gespräch drehte sich um das sich entwickelnde Gebiet des supply chain management, die Rolle von Daten und die Bedeutung von Bildung. Vermorel führte das Konzept der “wicked problems” in supply chain ein, hob die Grenzen von Excel hervor und betonte die Notwendigkeit von Tools wie SQL Server. Jan berichtete von seinen Erfahrungen beim Übergang von Excel zu programmatischeren Optionen und lobte Lokads Tool Envision. Beide betonten die Notwendigkeit einer Branchen Disruption und die Bedeutung von Bildung im supply chain management.
Erweiterte Zusammenfassung
In einem kürzlichen Interview führte Conor Doherty, der Moderator, ein zum Nachdenken anregendes Gespräch mit Joannes Vermorel, dem Gründer von Lokad, und Paul Jan, einem Associate Professor of Operations and Supply Chain Management an der Rotman School of Management. Das Gespräch drehte sich um die sich wandelnde Landschaft des supply chain management, die Rolle von Daten und die Bedeutung von Bildung in diesem Bereich.
Paul Jan, mit seiner umfangreichen Erfahrung in der Beratung und in der US-Unternehmenswelt, unterrichtet seit etwa vier Jahren Kurse in Operations- und supply chain Analytik an der University of Toronto. Seine Kurse, die eine grundlegende Klasse in Operations und supply chain management sowie eine Klasse in Zusammenarbeit mit Lokad umfassen, zielen darauf ab, die Lücke zwischen Theorie und Praxis zu schließen. Jan räumt ein, dass, obwohl Daten in der Branche an Bedeutung gewonnen haben, den Studierenden oft das Vertrauen fehlt, das Gelernte in der realen Welt anzuwenden. Hier kommt die Zusammenarbeit mit Lokad ins Spiel, die ein fertiges Umfeld bietet, in dem Studierende supply chain Aufgaben bearbeiten können, sodass sie sich auf die Aspekte des supply chain konzentrieren können, statt auf die technischen Details der Einrichtung einer Coding-Umgebung.
Vermorel führte das Konzept der “wicked problems” in supply chain ein, also Probleme, die sich einer direkten, oberflächlichen Analyse entziehen und eine Entdeckungsreise erfordern. Er hob die Beschränkungen von Excel im Umgang mit modernen supply chain Daten hervor und stellte fest, dass es nicht in dem Maße skaliert, wie es die heutigen supply chains erfordern. Vermorel schlug vor, dass Microsofts Antwort auf dieses Problem SQL Server und andere Werkzeuge sind, die relationale Daten verarbeiten. Er erwähnte auch, dass Lokads Playground darauf abzielt, Studierenden die Realität relationaler Daten näherzubringen.
Jan teilte seine Erfahrungen beim Übergang von Excel zu programmatischeren Optionen und stimmte Vermorels Einschätzungen zu Excels Begrenzungen zu. Er erwähnte, dass er in einem seiner Projekte SQL erlernt habe und schätzte dessen Fähigkeit, Daten zu verarbeiten und zu vereinfachen. Jan lobte auch Envision, Lokads Tool, für seine Einfachheit und Benutzerfreundlichkeit, die dazu beigetragen haben, den Prozess der Anpassung von Annahmen zu vereinfachen und Fehler, die in Excel auftreten könnten, zu reduzieren.
Das Gespräch verlagerte sich dann auf die erforderliche Denkweise zur Nutzung dieser Tools und darauf, ob Konzepte wie Opportunitätskosten im Unterricht vermittelt werden. Jan antwortete, dass, obwohl das Konzept der Opportunitätskosten nicht eindeutig sei, Studierende mit einer ökonomischen Ausbildung es verstehen können. Er verwies auf eine Lücke zwischen dem, was Führungskräfte und operative Mitarbeiter verstehen und beachten, wobei erstere sich auf finanzielle Ergebnisse konzentrieren und letztere auf traditionelle Kennzahlen.
Vermorel stimmte Jans Ausführungen zu und erörterte die Beschränkungen des Denkens innerhalb des Excel-Paradigmas. Er erklärte, dass wenn Excel das einzige Werkzeug ist, an das man denken kann, dies die Vorstellungskraft hinsichtlich möglicher Lösungen einschränkt. Vermorel kritisierte die Auffassung, dass sich digitale Technologien ständig verändern und Wissen in diesem Bereich wegwerfbar sei. Er argumentierte, dass viele grundlegende Themen, wie relationale Datenstrukturen und grundlegende Datentypen, sich im Laufe der Zeit kaum ändern werden.
Das Interview endete damit, dass Vermorel und Jan die Notwendigkeit von Disruption in der Branche und die Bedeutung von Bildung im supply chain management betonten. Vermorel erklärte, dass supply chain management aufgrund der vernetzten Natur moderner Unternehmen eine Reihe komplexer Probleme mit sich bringt. Er sprach sich für den Einsatz von Paradigmen und Tools aus, die diese komplexen Probleme bewältigen können, anstatt nach exakten Lösungen zu suchen, die möglicherweise falsch sein könnten. Jan hingegen beschrieb seinen Lehransatz als sowohl schrittweise als auch disruptiv, indem er mit traditionellen Theorien begann, bevor er reale Komplexitäten durch Zusammenarbeit mit Unternehmen wie Lokad einführte. Er räumte ein, dass es schwierig sei, über “wicked problems” zu unterrichten, die komplex sind und von den Handlungen anderer abhängen.
Vollständiges Transkript
Conor Doherty: Willkommen zurück bei Lokad TV. Die Fähigkeiten, die erforderlich sind, um im supply chain erfolgreich zu sein, haben sich in den letzten 20 Jahren dramatisch entwickelt und werden es auch in absehbarer Zeit bleiben. All dies ist selbstverständlich für die heutigen Gäste nichts Neues. Wir haben heute jemanden, der uns aus der Ferne von der Rotman School of Management beitritt, den Associate Professor of Operations and Supply Chain Management, Paul Jan. Paul, willkommen bei Lokad. Danke für die Einladung. Es freut mich, hier zu sein.
Conor Doherty: Nun Paul, ich sagte, willkommen bei Lokad, was ein leicht irreführender Name ist. Ich meine, wir sind bereits sehr vertraut miteinander. Du hast schon länger mit uns zusammengearbeitet und uns tatsächlich in den neuen Büros in Paris besucht. Aber für diejenigen, die deine Arbeit nicht kennen, könntest du eine Einführung geben und deinen Hintergrund beschreiben, bitte?
Paul Jan: Danke für die Einladung. Mein Name ist Paul Jan. Ich bin derzeit Professor an der University of Toronto und unterrichte Kurse in Operations und supply chain Analytik. Ich komme aus der Industrie und habe umfangreiche Erfahrungen in der Beratung sowie in der US-Unternehmenswelt gesammelt. In den letzten rund 15 Jahren war ich sowohl in der Industrie als auch in der Beratung tätig, und jetzt unterrichte ich und teile mein Wissen und meine Erfahrungen mit allen Studierenden hier an der UofT.
Conor Doherty: Und wie lange unterrichtest du schon an der Rotman School of Management?
Paul Jan: Ich bin seit etwa vier Jahren an Rotman, und davor war ich an der University of California, Irvine. Insgesamt unterrichte ich also seit ungefähr sieben Jahren.
Conor Doherty: Und wie haben sich die Kurse im supply chain in diesem kurzen Zeitraum entwickelt?
Paul Jan: Hier an Rotman unterrichte ich eine grundlegende Klasse, die eine Einführung in Operations und supply chain management bietet. Dort lernen Studierende die grundlegenden Theorien, Anwendungen und einige der Praktiken. Außerdem unterrichte ich eine weitere Klasse in Zusammenarbeit mit Lokad, um diese Theorien und Praktiken in die Praxis umzusetzen. Im Laufe der Jahre gibt es immer mehr Daten aus dem ERP eines Unternehmens, und selbst mittelständische bis kleinere Unternehmen verfügen über irgendein System zur Datenerfassung oder ein ERP-System. Somit sind Daten prominenter geworden, und den Studierenden fehlt es, wie ich beobachtet habe, oft an Selbstvertrauen und Erfahrung, das im Studium Erlernte in der realen Welt anzuwenden.
Conor Doherty: Nun, und Joannes, ich komme gleich zu dir, aber ich möchte darauf noch eingehen, da du umfangreiche Erfahrungen im privaten Sektor hast. Wenn du die grundlegenden Theorien auswählst, die den Studierenden vermittelt werden, wie viel davon ist traditionelles supply chain Wissen und wie viel wird durch deine umfangreiche Erfahrung beeinflusst?
Paul Jan: In der grundlegenden Klasse, die ich unterrichte, habe ich wenig Spielraum, um abzuweichen. Ich muss einem Lehrplan und den Anforderungen der Universität und der Abteilung folgen. Daher sind die meisten Inhalte die traditionellen Theorien und Modelle, die ein Studierender erlernen wird. Was ich mache, ist, diese mit Anekdoten und Geschichten zu ergänzen oder mit Hinweisen, worauf man achten sollte, wenn sie in die Arbeitswelt eintreten. Aber als Vorgabe der Schule bildet die Grundlage die traditionellen Theorien, die in dieser Klasse gelehrt werden. In der anderen, in der Zusammenarbeit mit Lokad, habe ich den Freiraum, den Unterricht aus der Perspektive eines Praktikers zu gestalten. So geht es darum, sich der Realitäten bewusst zu sein, der finanziellen Kennzahlen, was aus finanzieller Sicht von den traditionellen Theorien nicht abgedeckt wird. In der Praxis werden jedoch Führungskräfte den finanziellen Einfluss von XYZ betrachten. Das ist der Unterschied zwischen den beiden Ansätzen und wie ich meine Erfahrung in diesen verschiedenen Klassen einbringe.
Conor Doherty: Nun, danke, Paul. Und jetzt, Joannes, zu dir: Könntest du beschreiben, inwiefern die Zusammenarbeit mit Paul Teil von Lokads umfassender Bildungsinitiative ist?
Joannes Vermorel: Ja, bei Lokad haben wir vor etwa einem Jahr eine Initiative gestartet, um unseren technologischen Stack breiter zugänglich zu machen. Lokad wird normalerweise als eine Enterprise-Software angeboten, die nur unseren VIP-Potenzialkunden und -Klienten zugänglich ist. Was wir getan haben, ist, dies als einen sogenannten Playground neu zu verpacken, eine leicht vereinfachte Version von Lokad, die unter tr.lo.com zugänglich ist. Dadurch erhält man Zugang zu einer Coding-Umgebung, die von Envision unterstützt wird, sowie zu einem kleinen Dateisystem. Für Bildungszwecke ist die Idee, eine Reihe von Workshops anzubieten, in denen Studierende einen Datensatz bearbeiten können, der eine vereinfachte Version dessen ist, was in realen Setups zu finden ist, aber dennoch ziemlich repräsentativ bleibt. Wir wollten die Aufgabe nicht zu einfach und zu theoretisch gestalten. Die Idee ist, ein fertiges Umfeld bereitzustellen, in dem der Studierende direkt mit einem Datensatz und einer kleinen Herausforderung im Rahmen einer supply chain Aufgabe starten kann, die auf diesem Datensatz ausgeführt werden muss. Dies spiegelt die Art von Herausforderungen wider, mit denen man es zu tun bekommt, wenn man ein Unternehmen betritt, in dem es Probleme mit Lieferanten gibt. Man muss analysieren und herausfinden, welche Lieferanten nicht in der Lage sind, pünktlich und vollständig zu liefern, oder man möchte die Nachfrage prognostizieren oder eine andere dieser supply chain-analytischen Aufgaben durchführen. Die Idee ist, dass Lokad ein Umfeld bereitstellen wollte, um dies zu ermöglichen. Der Grund dafür ist, dass Studierende, die supply chain Materialien studieren, keine Softwareingenieure sind. Wenn man also einen Klassenraum voller zukünftiger Softwareingenieure darum bitten würde, könnten diese die Zeit nutzen, um eine Python-Umgebung einzurichten, ihre eigene Daten-Pipeline sowie Parsing-Logik und dergleichen zu erstellen, sodass sie tatsächlich an einem Datensatz mit Open-Source-Technologien arbeiten können. Das Problem ist, dass man unter Berücksichtigung des Zeitrahmens, den wir für Studierende haben, die keine Softwareingenieure, sondern supply chain Ingenieure oder zukünftige supply chain Ingenieure sind, ein fertiges Umfeld benötigt, das primär auf supply chain ausgerichtet ist und nicht auf die Feinheiten, wie man eine CSV-Datei in Python parst. So etwas muss also vorgefertigt sein, und genau das können wir mit diesem Umfeld leisten. Wir teilen ein Umfeld, in dem die Daten bereits vorbereitet sind, das Skript, das die Daten einliest, bereits geschrieben ist, sodass sie direkt in den Kern des Problems einsteigen können, nämlich herauszufinden, was man mit einem supply chain, mit einem Lieferanten, mit der Nachfrage tun soll, und supply chain-Überlegungen mithilfe eines programmatischen Tools anzuwenden. Unser Ziel ist es, dass jene Curricula, die typischerweise sehr leichtgewichtig in Bezug auf technische Tools sind, fortgeschrittene Dinge tun können, ohne dabei völlig in rein technischen Details zu versinken. Kurzum: Wir stellen ein Umfeld bereit, das problemlos in 5,000 Zeilen Python-Code repliziert werden könnte. Das ist durchaus machbar, aber das Problem ist, dass, wenn man das tut, man plötzlich nicht mehr erwarten kann, in einer drei Stunden andauernden Arbeitssitzung mit seinen supply chain Studierenden fruchtbare Ergebnisse zu erzielen. Man würde eine dreistündige reine Coding-Session abhalten, in der man lediglich herausfindet, wie man eine CSV-Datei parst, was aus supply chain Sicht nicht sehr interessant ist.
Conor Doherty: Und Paul, nur eine Anschlussfrage dazu: Wie herausfordernd sind diese ingenieurtechnischen Fähigkeiten wie Programmieren für den durchschnittlichen Studierenden auf Grundlagenebene im supply chain?
Paul Jan: Ich kann dir ein Beispiel aus der Praxis geben, bei dem wir vor ein paar Wochen hier das Semester begonnen haben. Ich würde sagen, dass etwa 20% dieser neuen Klasse irgendeine Art von Vorerfahrung im Programmieren haben, aber dabei haben sie beispielsweise schon einmal Python in einem Unterrichtsumfeld belegt. Der Großteil hat das nicht. Wenn sie also kommen, denke ich, sind sie begeistert, weil sie erkennen, dass dies eine Fähigkeit ist, die ihnen in Zukunft zugutekommen wird, da es viel mehr Daten gibt und Excel einfach umständlich ist, wenn es darum geht, solch große Datenmengen zu analysieren. Programmieren hilft dabei, diesen Prozess zu vereinfachen. Aber gleichzeitig haben sie auch ein wenig Angst, sind besorgt, weil sie nicht die nötige Erfahrung haben. Es ist jetzt eine sehr wichtige Fähigkeit, aber es fehlt auch in der Ausbildung der Wirtschaftsstudenten, nicht nur im Bereich supply chain, sondern bei Wirtschaftsstudenten im Allgemeinen.
Conor Doherty: Nun, danke. Und das geht eigentlich nahtlos über. Joannes, etwas, auf das ich schon lange gewartet habe zu fragen. In der Vergangenheit hast du in deinen Vorlesungen supply chain Probleme als wicked problems beschrieben. Also, zwei Teile dieser Frage: Erstens, was genau meinst du mit wicked problems im supply chain? Und zweitens, basierend auf dem, was Paul gerade gesagt hat, warum sind Werkzeuge wie Excel einfach nicht dafür ausgerüstet, diese wicked problems zu bewältigen?
Joannes Vermorel: Das Konzept eines wicked problem stammt nicht von mir. Es handelt sich im Wesentlichen um Probleme, die einer direkten, erstklassigen Analyse trotzen. Es ist etwas, bei dem es einer Reise bedarf, auf der du letztlich das Problem selbst entdeckst.
Ein Beispiel dafür ist: Was macht eine gute Anzeige aus? Wenn ich dich bitte, die Oberfläche einer geometrischen Form in Quadratzoll oder Quadratzentimetern zu berechnen, könnte die Form sehr kompliziert sein, sodass die Berechnung schwierig ist, aber es ist ein abgeschlossenes Problem. Es gibt eine analytische Lösung, die dir entweder die exakte Antwort oder eine sehr gute Annäherung liefert.
Aber wenn ich dich frage, was eine gute Anzeige ausmacht, hängt die Antwort wirklich davon ab, und es kommt auch darauf an, was deine Konkurrenten tun. Zum Beispiel, wenn du eine fantastische Anzeige erstellst, diese aber so sehr von deinen Konkurrenten kopiert wird, dass deine Anzeige, die brillant war, nun nicht mehr von der Konkurrenz zu unterscheiden ist – sie war eine sehr gute Anzeige, wurde aber zu einer schlechten Anzeige, einfach weil sie von allen kopiert wurde.
Das ist die Art von wickedness. Die Antwort, die du gibst, kann potenziell die Antwort selbst zunichtemachen. Es ist irgendwie seltsam. Ich gebe eine sehr gute Antwort, und weil es eine sehr gute Antwort ist, wird sie kopiert, und weil sie kopiert wird, wird sie zu einer schlechten Antwort. Das ist eine Art wicked problem.
Supply chain ist voll von wicked problems. Du entscheidest dich, irgendwo ein Distributionszentrum zu errichten, um jemanden zu übertreffen. Genau so etwas.
Also, die Dinge sind nicht stabil. Eine Antwort ist nicht stabil. Diese wicked problems sind Probleme, die wettbewerbsorientiert sind. Es gibt Menschen, die auf das reagieren, was du tust. Dies ist nicht wie das Problem, die Oberfläche einer geometrischen Form zu berechnen, bei dem die Antwort nicht davon abhängt, was der Rest des Universums tut oder was andere entscheiden. Dieses Problem ist gut isoliert.
Und dann gibt es auch Probleme, bei denen du dir nicht einmal sicher bist, ob du das Problem überhaupt richtig umschreibst. Was bedeutet quality of service? Ja, wir können sagen, dass quality of service darauf abzielt, das service level zu erhöhen, aber in Wirklichkeit liegt quality of service im Auge des Kunden – was bedeutet das überhaupt? Es ist eine sehr schwierige Frage.
Für manche Menschen mag es in Ordnung sein, wenn es Ersatzprodukte gibt. Sie erwarten nicht, dass dieses eine Produkt verfügbar ist. Vielleicht, wenn es Ersatzprodukte gibt, ist das in Ordnung. Andere könnten widersprechen. Sie haben möglicherweise eine sehr enge Vorstellung davon, was sie tatsächlich benötigen, und sagen: “Ich will genau diesen Barcode, sonst funktioniert es nicht.”
Und dann, abhängig von der Kommunikation des Unternehmens, der übergeordneten Kommunikation, könntest du tatsächlich verstärken oder abschwächen, ob die Leute andere Produkte als Ersatz ansehen oder nicht. Wenn du eine Kommunikation hast, die besagt, dass dieses Produkt völlig einzigartig ist und es überhaupt keinen Ersatz gibt, dann wundere dich nicht, wenn die Leute nicht einmal bereit sind, andere Produkte von dir als Ersatz zu akzeptieren, weil das deine Kommunikation ist. Das mag im Wettbewerb gut sein, kann aber schwieriger sein, wenn du die Leute davon überzeugen willst, Alternativen anzunehmen.
Die Situationen sind unglaublich vielfältig. Also, das Fazit bezüglich dieser wicked problems – und das ist eine typische Denkweise von Lokad – ist, dass es meist besser ist, das Problem mit Daten iterativ anzugehen, anstatt ohne Daten zu arbeiten.
Egal, welche Frage gestellt wird, wie zum Beispiel “Ist das eine gute Anzeige?”, ist es einfacher, diese Frage zu beantworten, wenn du die Verkaufszahlen messen und ein wenig mit deinen Werbeausgaben korrelieren kannst. Das bedeutet nicht, dass damit die Frage vollständig gelöst wird, aber du wirst besser informiert sein, als wenn du versuchst, diese Frage ohne Daten zu beantworten.
Normalerweise, selbst wenn du es mit einem wicked problem zu tun hast, hilft es, Daten zur Verfügung zu haben. Das Problem ist, dass du aufgrund der wicked Natur deine Stellung bezüglich der Analytik und Verarbeitung immer wieder überdenken musst, was bedeutet, dass es keine Patentlösung gibt. Du wirst die Daten verarbeiten, dann nachdenken und eventuell eine leicht abgewandelte Frage stellen, abhängig davon, was passiert.
Also, bei wicked problems kommen wir ins Spiel. Wenn du vor einem wicked problem stehst, ist es gut, Daten zu haben, weil sie dich besser informieren – was im Allgemeinen vorteilhaft ist. Aber es bedeutet auch, dass du deine Analyse von Zeit zu Zeit wiederholen musst, da es keine endgültige Antwort gibt.
Excel ist in dieser Hinsicht gut. Excel erlaubt es dir, deine Analyse so oft zu überarbeiten, wie du möchtest. Das Problem ist, dass Excel nicht in dem Maße skaliert, wie es moderne supply chains erfordern. Heutzutage sprechen wir von zehntausenden Produkten, Millionen von Transaktionen, einer Menge transaktionaler Daten. Excel ist dafür schlichtweg nicht geeignet.
Die zentrale Herausforderung besteht darin, dass moderne supply chain Daten das, was vernünftigerweise in Excel Platz finden würde, bei Weitem überschreiten – und zwar in zweierlei Hinsicht. Zum einen überschreiten sie die Anzahl der Zeilen. Excel ist auf eine Million Zeilen begrenzt. Aber das ist nicht wirklich das Hauptproblem. Theoretisch könnte Microsoft Excel ein wenig umgestalten und auf 100 Millionen Zeilen erweitern. Das ist nicht unmöglich, und tatsächlich gibt es ein paar Konkurrenten von Excel, die das können.
Aber wenn wir sagen, dass eine moderne supply chain die Grenzen sprengt, dann meinen wir, dass Excel grundsätzlich eine Ein-Tabelle-auf-einmal-Mentalität hat. Es geht davon aus, dass Daten wie in einer flachen, einzigen Tabelle vorliegen. Dabei ist die Realität, dass die transaktionalen Daten, wie sie in einer supply chain zu finden sind, aus mehreren Tabellen bestehen. Du hast eine Tabelle für Lieferanten, eine Tabelle für Transaktionen, eine Tabelle für Kunden, eine Tabelle für Produkte, eine Tabelle für Farben oder Formen oder was auch immer.
So landest du sehr häufig bei mindestens einem halben Dutzend Tabellen. Und was dir fehlt, ist etwas wie eine relationale Algebra, die im Kern deiner transaktionalen Daten steht. Deine Daten in der supply chain sind transaktional und relational. Du hast so etwa ein halbes Dutzend Tabellen, und genau da funktioniert Excel wirklich nicht.
Nicht nur hast du diese Begrenzung bei der Anzahl der Zeilen – was theoretisch behoben werden könnte – sondern grundsätzlich hast du das Problem, dass du in Bezug auf Semantik eingeschränkt bist. Excel bietet dir diese Mehr-Tabellen-Funktionalität nicht.
Und übrigens liegt das daran, dass Microsoft sich nicht wirklich darum bemüht, dieses Limit von 1 Million zu erweitern. Die Leute bei Microsoft wissen – und das schon seit langem – dass selbst wenn sie auf 100 Millionen Zeilen erweitern könnten, der nächste Schritt lauten würde: “Oh, wir brauchen mehrere Tabellen”, und dann würde es mit Excel nicht sehr gut funktionieren.
Deshalb lautete die Antwort von Microsoft: “Wenn du relationale Daten möchtest, hast du SQL Server, oder du hast Werkzeuge, die relationale Daten als erstklassige Bürger behandeln”, anstatt zu versuchen, das in eine Tabellenkalkulation zu pressen. Übrigens ist das auch etwas, das wir mit diesem Playground anstreben – den Studierenden diese Realität relationaler Daten näherzubringen, indem wir eine Sprache anbieten, in der relationale Daten als erstklassige Bürger gelten.
Denn daran glaube ich, dass sich nichts ändern wird. In vierzig Jahren werden ERPs immer noch Tabellen und Spalten haben. Dieses System wurde vor vier Jahrzehnten etabliert und ist seit mehr als vier Jahrzehnten ein sehr stabiler Aspekt der digitalen supply chain.
Conor Doherty: Paul, ein interessanter Punkt zur Vertiefung, denn du hast einen umfangreichen Hintergrund im privaten Sektor und wurdest in diesem Bereich formell ausgebildet. Als du anfingst und deine Erfahrungen entwickelteest, nehme ich an, dass du mit Excel gearbeitet hast. Und falls ja, wann hast du gesagt: “Ich muss reichhaltigere, programmatischere Optionen in Betracht ziehen”? Also, was führte zu der Abkehr von Excel?
Paul Jan: Die Abkehr ist das, worauf Joannes angedeutet hat. Excel ist großartig, weißt du, es ist eine Art Ein-Tabelle-auf-einmal, und es ist sehr umständlich, all diese Tabellen oder Arbeitsblätter in Excel zu verknüpfen. Und selbst wenn du darin erfolgreich bist, ist es auch eine sehr zeitaufwändige Aufgabe, wenn du deine Annahmen und Variablen ändern musst, um alle vorgenommenen Änderungen in Excel zu überprüfen.
Du stößt oft auf Fehler. Fast immer machst du am Ende Fehler, weil du vergessen hast, diese Variable oder diese Annahme zu ändern, was dazu führte, dass das Endergebnis etwas anders aussieht. Ich denke also, es war vielleicht ein paar Jahre, in denen ich die Gelegenheit hatte, SQL zu lernen. Ich kannte SQL vorher nicht, aber ich habe SQL in einem der Projekte gelernt und habe die Sprache wirklich zu schätzen gelernt – sowie die Möglichkeit, mit der du zumindest den ersten Teil, also das Finden der deskriptiven Daten und das Aufspüren von Anomalien in den Daten, verarbeiten und vereinfachen kannst.
Das vereinfacht zumindest den ersten Teil, nämlich das Ermitteln der deskriptiven Daten und das Aufspüren von Anomalien in den Daten. Die Gewährleistung, dass die Daten sauber sind, und das Finden von Wegen, verschiedene Datenquellen zu integrieren, hat die Dinge erheblich vereinfacht. Genau dann habe ich wirklich den Übergang vollzogen. Damals wurde SQL zu meinem bevorzugten analytischen Werkzeug, um die Daten vorzubereiten, um zu verstehen, wie die Daten aussehen und ob es irgendwelche Anomalien gibt. Danach führte ich die erste deskriptive Analyse durch, während Excel eher für die einfache Visualisierung genutzt wurde. Sobald das abgeschlossen war, visualisierten wir es leichter mit Excel, indem wir Diagramme und Grafiken erstellten.
Ich möchte noch ergänzen, was Joannes in Bezug auf die Entdeckung von Lokad erwähnt hat. Ich habe Lokad ebenfalls vor ein paar Jahren entdeckt, aber ich habe nicht eine ähnliche Initiative ergriffen wie letztes Jahr, um dies den Studierenden vorzustellen. Ich hatte ehrlich gesagt Angst, dass der Programmieraspekt die Studierenden davon abhalten würde, das Tool zu nutzen und Freude am Unterricht zu haben oder daraus zu lernen. Aber ich muss sagen, ich lag falsch. Angesichts der letzten Monate unserer Zusammenarbeit habe ich festgestellt, dass Envision ein sehr leicht verständliches Tool ist. Selbst mit meinem Hintergrund in Programmierung und Datenbanken ist es sehr einfach zu verstehen, und ich denke, es ist auch für Studierende einfacher zu verstehen, weil der Code gewissermaßen wie eine Laien-Sprache gelesen werden kann.
Es ist anders als beispielsweise Python und andere, bei denen manche Dinge nicht so viel Sinn ergeben und sie ohne die Erklärung des Programmierers nicht nahtlos aufeinanderfolgen. Bisher war es eine sehr hilfreiche Übung, dies einzuführen. Es hat den Prozess der Anpassung von Annahmen – Dinge, die wir möglicherweise in den Daten nicht berücksichtigt haben – erheblich vereinfacht, indem man diese im Code selbst aktualisiert und dann im dashboard für die Studierenden sichtbar macht.
Ich nenne das immer noch ein Einstiegsniveau. Für die Studierenden geht es darum, aus einer übergeordneten, Top-down-Perspektive zu verstehen, was ein Unternehmen tut und wie es das tut – anhand der deskriptiven Daten, wie der Anzahl der Kunden, den höchsten Umsätzen, dem ABC-Trend ihres Produkts. Von dort aus können sie verstehen, wie sie die supply chains aufbauen, und dann gehen wir tiefer in ihre supply chain hinein. So hat dieses Programm, diese Programmiererfahrung mit Envision, in dieser Hinsicht wirklich dramatisch geholfen und auch die Fehler reduziert, die wir in Excel machen könnten.
Conor Doherty: Ich werde erst mit dir, Paul, und dann mit Joannes weitermachen. Also, willkommen – es ist eine philosophische Frage, die dir gefallen wird. Mir fällt auf, dass wir über die Werkzeuge gesprochen haben, also Envision ist das Werkzeug, aber die Nutzung von Werkzeugen geht mit einer bestimmten Denkweise einher. Wie du gerade angedeutet hast, basiert ein wesentlicher Bestandteil dessen, was Lokad mit Envision macht, darauf, supply chain Probleme aus einer rein finanziellen Perspektive zu betrachten und Dollar oder Euro an Fehlern zu reduzieren. Das ist wohl eine Mischung aus Ökonomie, aber auch ein wenig philosophisch, im Hinblick darauf, dass wenn ich dies tue, ich das nicht tun kann – Opportunitätskosten.
In Bezug auf diese Denkweise, also das Verständnis, wie man diese Werkzeuge nutzt: Ist das etwas, das du auch im Unterricht vermitteln musst, oder verstehen die Studierenden das automatisch, wie in “Oh ja, Opportunitätskosten – ich nutze einfach dieses Werkzeug”, und das ist ihnen sofort klar?
Paul Jan: Ich würde nicht sagen, dass es ganz offensichtlich ist, aber die Studierenden haben eine Ausbildung in Ökonomie erhalten, sodass sie den Trade-off, die Opportunitätskosten, verstehen. Sogar in der grundlegenden supply chain- oder Operations-Klasse, die ich hier unterrichte, führen wir die Studierenden in Überschusskosten, Restwertkosten und die verschiedenen Kosten ein, die mit der Entscheidung verbunden sein können, wie viel Inventar man lagern soll und wann. Diese sind verständlich und nachvollziehbar für die Studierenden, sobald du ihnen erklärst, dass die Art und Weise, wie wir diese finanzielle Basislinie ermitteln, auf ABC basiert.
In der Praxis sind diese finanziellen Basislinien das, was wir auch versuchen, für Führungskräfte in sämtlichen Beratungsprojekten zu quantifizieren. Führungskräfte verstehen, dass wenn du ihnen sagst, dies sind deine Kosten in Dollar oder verpasste Chancen in Dollar. Aber für die supply chain-Leute – oder Operations-Leute – würde ich sagen, werden sie meist von den traditionellen Kennzahlen getrieben, den Umschlagshäufigkeiten, forecast accuracy. Sie verstehen es, aber sie achten mehr darauf. Es besteht also eine gewisse Lücke zwischen dem, was Führungskräfte verstehen, und dem, was die operativen Mitarbeiter – oder zumindest das, was ihnen beigebracht oder angewiesen wird – zu befolgen haben. Aus studentischer Sicht ist es keine schwierige Aufgabe, diese Konzepte einzuführen oder zu erklären. " Conor Doherty: Danke, Paul. Und Joannes, zurück zu dir. Also, noch einmal – aufbauend auf dem, was gerade gesagt wurde – verstehe ich vollkommen, warum Dinge wie Python, SQL und natürlich Envision, unsere domänenspezifische Sprache, neuen supply chain Praktikern fremd sein können. Aber das Konzept knapper Ressourcen und alternativer Verwendungen – das Fundament der Wirtschaftswissenschaften – ist über ein Jahrhundert alt. Warum sollte also dieser Aspekt der wirtschaftlichen Denkweise in supply chain Kreisen so anders sein als, wie Paul gerade beschrieb, in dem, was im Klassenzimmer intuitiv verstanden wird?
Joannes Vermorel: Ich möchte zunächst auf Pauls Bemerkung eingehen. Als du sagtest, du seist besorgt, Envision zu benutzen, denke ich, dass du recht hattest. Nur zur Information für das Publikum: Ich bin persönlich der Überzeugung, dass der Großteil der enterprise software kompletter Mist ist, buchstäblich kompletter Mist. Und beim Kauf von Software – ich schaue gerade euch an – ist es verständlicherweise eine sehr vernünftige Annahme, von vornherein davon auszugehen, dass sie reiner Mist sein wird, und man dann angenehm überrascht ist, wenn dem nicht so ist. Aber ich halte es für eine angemessene Annahme. Ich bin fest davon überzeugt, dass Envision nicht in dieses Lager gehört – wir haben gute Arbeit geleistet. Doch wieder: Es ist naturgemäß zu erwarten, dass enterprise software sehr niedrige Qualität aufweist, besonders im Vergleich zu populären Open-Source-Projekten. Das ist eine faire und sehr rationale Annahme, die man bezüglich der anwendungsbezogenen Landschaft treffen kann.
Nun, das Besondere an dieser Denkweise in finanziellen Belangen – und als Paul übrigens ABC meinte als Activity-Based Costing, nicht ABC analysis – ist, dass es sehr schwierig ist, über Probleme nachzudenken, wenn man sich die Lösung nicht vorstellen kann. Wenn Leute sagen, dass man in Begriffen von Genauigkeit oder Servicegrad denken will, handelt es sich um sehr klassische Kennzahlen. Wenn alles, was man hat, eine Excel-Tabelle ist, dann ist das im Grunde schon alles, was man implementieren kann. Wenn man also nur in Tabellen denken kann, hat man Schwierigkeiten, diese Ansätze zu verfolgen, denn es verlangt, dass man sich zuerst Probleme überlegt. Wie soll ich all das in Dollar umwandeln, während es dir extrem schwerfällt, über die Lösung nachzudenken?
Oft denken Menschen zuerst an die Lösung und erst danach an das Problem. Es ist unglaublich schwer, ein Problem zu formulieren, ohne vorher eine Lösung im Kopf zu haben. Man stößt zunächst auf eine ungefähre Lösung und dann, wenn man jemand anderem erklären möchte, was man getan hat, erfindet man das passende Problem zu dieser Lösung. Menschen stellen sich instinktiv zuerst die Lösung vor und erfinden dann, um darüber kommunizieren zu können, das Problem.
Deine Fähigkeit, Lösungen zu erdenken, hängt von den Werkzeugen ab, die dir im Kopf zur Verfügung stehen. Wenn du Excel im Kopf hast, dann sind alle Lösungen, an die du denken kannst, jene, die in Excel funktionieren. Das beschränkt dich auf das Paradigma der Genauigkeit und des Servicegrads, da dies Arten von Aufgaben sind, die du in Excel umsetzen kannst.
Deshalb ist es in Grundlagenkursen so wichtig, dass Studierende mit besseren Werkzeugen vertraut gemacht werden, mit denen sie beispielsweise mit Tabellen, Spalten und Konzepten wie SQL denken können. Das Problem ist nicht SQL an sich, sondern das Paradigma, das SQL vermittelt – Tabellen, Filter, Aggregationen, Spalten, Datentypen wie Strings versus Zahlen, Booleans. Diese Dinge sind sehr wichtig, und plötzlich, wenn du dieses Paradigma beherrschst, kannst du an elaboriertere Lösungsklassen denken.
Um über finanzielle Indikatoren nachzudenken, musst du die Lagerkosten berücksichtigen – dafür benötigst du eine weitere Tabelle, die Annahmen zu den Lagerkosten liefert. Du musst die Kosten eines Lagerfehlbestands einbeziehen, also muss diese Information an anderer Stelle vorhanden sein. Es ist nicht so, dass Menschen traditionell unfähig sind, über Lagerkosten oder Versicherungskosten nachzudenken – sie wissen es. Aber wenn es um das Vorstellen einer Lösung geht und Excel alles ist, was ihnen einfällt, fällt es ihnen sehr schwer, sich eine Tabelle vorzustellen, in die all diese 20 verschiedenen Faktoren eingepflegt werden können.
Aber wenn du mit relationalen Daten denken kannst, hast du plötzlich die Werkzeuge, mit denen du denken kannst: “Okay, ich werde all diese Kosten mit so vielen Tabellen eingeben, wie es nötig ist.” Und konzeptionell – wenn diese Kosten für sich genommen einfach sind – ist es einfach eine Frage des Aggregierens all dessen.
Das ist eine lange Erklärung, aber auch der Grund, warum das traditionelle supply chain management so zögerlich agiert. Ihnen bot sich schlichtweg nicht die Möglichkeit, diese Art von Ausbildung zu erhalten, bei der sie wirklich mit moderneren Werkzeugen denken können.
Paul Jan: Ich stimme Joannes’ Einschätzung voll und ganz zu. Wenn wir in den supply chain Operationen eines Unternehmens eine Kompetenzbewertung durchführen würden, würde ich sagen, dass eine große Lücke im Verständnis dessen existiert, worüber wir gerade gesprochen haben. Das ist wirklich die Herausforderung, diese nächste Generation junger Fachleute dahingehend zu bilden, dass sie anders denken und innovativ sein können.
Joannes Vermorel: Ich unterrichte seit sieben Jahren – allerdings nicht im Bereich supply chain, sondern im verteilten Rechnen und Software Engineering. Meine Philosophie, als ich am Eon Normal Superior in Paris unterrichtete, wo ich völlige Freiheit hatte, zu entscheiden, was ich lehre, war, mich auf Themen zu konzentrieren, die auch in vier Jahrzehnten noch relevant sein würden.
Meine größte Angst war es, etwas zu lehren, das nur ein kurzlebiger Trend ist, etwas, von dem man fünf Jahre später merkt, dass es nur eine Feinheit war und dann einfach verschwindet. Deshalb fragte ich mich immer: Ist das etwas, das die Zeit überdauern wird? Hat es in 40 Jahren noch eine sehr gute Chance, von Bedeutung zu sein?
Beispielsweise wurde SQL seit 1989 als Standard etabliert. Es hat sich weiterentwickelt, aber der Großteil davon hat sich seitdem nicht verändert. Das zugrunde liegende Modell – die relationalen Daten – hat sich seit den späten 70er-Jahren nicht geändert. Es hat sich als unglaublich erfolgreich erwiesen, da praktisch 99 % des ERP-Marktes dieses relationale Datenformat in irgendeiner Form verwenden.
Die Menschen haben den Eindruck, dass sich digitale Technologien ständig verändern, dass man etwas lernen muss und in zwei Jahren ist es schon wieder veraltet. Ich glaube, das ist ein Problem, weil es den Eindruck vermittelt, dass dieses Wissen austauschbar ist. Es vermittelt auch dem Management den falschen Eindruck, dass sie das umgehen können und es ihnen egal ist, weil es in zwei Jahren ohnehin etwas anderes sein wird.
Wenn es richtig gemacht wird, haben wir viele Themen, die fundamental sind. Die relationale Datenstruktur wäre eines davon. Die grundlegenden Datentypen – Text, Booleans, Zahlen – waren bereits Ende der 70er so. Sogar Python 3, die neueste Version, hat das immer noch im Kern. Es ist etwas, das sich in den nächsten vier Jahrzehnten höchstwahrscheinlich nicht ändern wird.
Ähnlich verhält es sich beim Forecasting, also der Frage, wie man über die Zukunft nachdenkt, time series: Was sind die Einschränkungen von Zeitreihen, was liefert eine Zeitreihenprognose, was nicht, was per Design nicht möglich ist – daran wird sich auch nichts ändern. Die grundlegendste Art der Prognose in vier Jahrzehnten wird immer noch eine Zeitreihenprognose pro Tag, Woche oder Monat sein, und die Einschränkungen einer solchen Prognose bleiben dieselben.
Wenn ich Forecasting lehren müsste, würde ich mich statt darauf zu fokussieren, welches das beste Zeitreihenprognosemodell ist – was sich verändern wird – auf die eingebauten Annahmen konzentrieren, die mit der Zeitreihenprognose verbunden sind, darauf, was sie dir liefert und was nicht, sowie auf die gefährlichen Einschränkungen und wie man über Unsicherheit nachdenkt.
Ich verstehe, dass das eine sehr große Herausforderung ist. Die meisten Universitätsprofessoren hatten nicht den Luxus, den ich hatte, bei dem der Verwaltung völlig gleichgültig war, was ich tatsächlich unterrichte.
Conor Doherty: Paul, wenn du in der Klasse Nachfrageprognosen behandelst, gehst du dabei auch auf Wahrscheinlichkeitsverteilungen ein, um die Unsicherheit der Zukunft zu verstehen?
Paul Jan: Im Grundlagenkurs sprechen wir darüber, und auch im Demand Management, Forecasting und inventory management. Aber wir nehmen an, dass die Variabilitäten und Unsicherheiten der Normalverteilung folgen, was das Lehren erheblich erleichtert.
Allerdings, wenn man den probabilistischen Ansatz anwendet, der die Wahrscheinlichkeit von Schwankungen bei einem Produkt betrachtet, kann man das grafisch darstellen. Menschen sind visuell, sodass sie verstehen können, warum sich ein Produkt anders verhält als ein anderes.
Dieses Semester überlege ich, Inhalte aus dem fortgeschrittenen Kurs in den Grundlagenkurs zu bringen, um Unsicherheiten und Schwankungen auf eine visuellere Weise zu erklären.
Joannes Vermorel: Es ist in Ordnung, starke Annahmen zu Lehrzwecken zu treffen. Ich erinnere mich, dass ein Physikdozent an der Universität Berechnungen vereinfachte, indem er annahm, eine Kuh sei eine Kugel. Offensichtlich ist eine Kuh keine Kugel, aber um der Übung willen ist es vernünftig, den Studierenden zu erlauben, eine vereinfachte Berechnung durchzuführen. Das hilft ihnen, mit den Konzepten zu experimentieren, ohne sich in den Details der Berechnung zu verlieren.
Allerdings treffen im supply chain Bereich die Leute gleichartige Annahmen, wie etwa, dass die Nachfrage normalverteilt ist. Dies ist eine Lehrannahme, die in der realen Welt nicht standhält. Dennoch kodieren Anbieter von enterprise software diese Annahmen fest in ihre Software. Das ist Wahnsinn. Es ist, als würde General Motors Annahmen über Kugeln und Passagiere in ihren Autos hartkodieren. Die Leute würden das für verrückt halten. Das sollte man nicht für ein echtes Auto tun, das in der realen Welt unterwegs ist.
Doch seltsamerweise sagen supply chain software Anbieter, dass es kein Problem sei, diese Annahmen in ihre Software einzucodieren. Das ist meine Reaktion auf den Status quo in dieser Branche, den ich ein wenig verrückt finde. Es besteht ein Bedarf an Disruption. Aus irgendeinem seltsamen Grund scheint es, dass supply chain software Anbieter diese verrückten, lehrzweckbedingten Annahmen direkt in ihre Software übertragen.
Aber vielleicht ist es nicht fair, das von Professoren zu verlangen. Vielleicht sind es selbst die Anbieter von supply chain enterprise software, die sich mit der Realität auseinandersetzen müssen.
Conor Doherty: Das wollte ich gerade fragen. Aus Pauls Perspektive an der Rotman School of Management ist es seine Verantwortung, diese Konzepte zu lehren. Aber für Lokad, einen supply chain software Anbieter, warum ist Bildung so wichtig? Warum legt ihr so großen Fokus darauf?
Joannes Vermorel: Supply chain ist eine Ansammlung von wicked problems, weil wir alle Kräfte eines Unternehmens zusammenführen. Per Definition hält die supply chain das Unternehmen zusammen – das heißt, wir bringen Vertrieb, Produktion, Transport, Marketing, Finanzen, alles zusammen. Das ist keine einfache Aufgabe. Moderne Unternehmen agieren in vielen Ländern, sodass es nicht nur Konflikte zwischen Vertrieb und Marketing gibt, sondern auch zwischen Frankreich, Italien und Spanien.
Supply chain besteht aus einer Reihe von wicked problems – sei es durch ihr Design oder durch die Natur der supply chain, die viele widersprüchliche Interessen innerhalb und außerhalb des Unternehmens verbindet. Wir müssen in Begriffen von Paradigmen und Werkzeugen denken, die es uns ermöglichen, diese wicked problems auch annähernd zu erfassen. Anstatt nach dem annähernd Richtigen zu streben, gehen die Leute für das exakt Falsche und verdoppeln es mit vielen numerical recipes, die weitaus präziser sind, als sie sein sollten.
Conor Doherty: Wir kommen langsam zum Ende, aber ich möchte es wieder an dich zurückgeben. Joannes’ Vorstellung von supply chain erscheint mir zutiefst philosophisch. Wenn wir von Problemen erster und zweiter Ordnung sprechen, ist es fast wie bei Wittgenstein. Mich interessiert: Verfolgst du einen ähnlich tief philosophischen Ansatz in Bezug auf supply chain? Lässt es die Verwaltung überhaupt zu? Müssen wir am ersten Tag die ganze Sphäre der supply chain-Philosophien neu überdenken? Sagst du den Studierenden, dass wir das Rad komplett neu erfinden müssen, oder ist das eher ein gradueller Prozess?
Paul Jan: Es ist graduell und gleichzeitig disruptiv. An der Universität beginnen die Studierenden mit den Grundlagen, dann folgt ein Kurs im mittleren Bereich des supply operation management, und anschließend kommen sie zu einem fortgeschritteneren Kurs, den ich dieses Semester in Zusammenarbeit mit Lokad unterrichte. Sie lernen nach und nach traditionelle Theorien und Anwendungen. Aber dann kommt die Disruption, wenn – zumindest nach meiner Erfahrung – ich den Studierenden die Wickedness in der supply chain nicht vermitteln kann, ohne dass sie sie selbst erleben. Deshalb arbeiten wir mit einem Unternehmen zusammen. Wir bearbeiten echte Daten und denken mit einem Tool. Sie sehen die Wickedness, die Unsicherheit und erkennen, dass die Dinge, die sie in den ein oder zwei vorangegangenen Kursen gelernt haben, nicht sofort anwendbar sind. Man kann es tun, aber es könnte einfach keinen Sinn ergeben.
Es ist also eine philosophische Frage. Und übrigens, dies ist ein offenes Problem. Wenn man sich die Wikipedia-Seite zu wicked problems ansieht, wird klar, dass alle Disziplinen, die mit solch einer Problematik konfrontiert sind – bei der eine gute oder schlechte Antwort auf eine Problemstellung davon abhängt, was andere tun – unglaublich schwer zu lehren sind. Das ist nicht spezifisch für supply chain; es gibt auch andere Bereiche, in denen es einfach unglaublich schwierig ist.
Joannes Vermorel: Es gibt sogar Bereiche, in denen – zum Beispiel, als wir kürzlich einen Gast hatten, der über den Handel an öffentlichen Märkten sprach – wenn du verrätst, wie du es machst, untergräbst du deine eigene Lösung und Einnahmequelle. Daher ist Geheimhaltung in solchen Dingen von größter Bedeutung. Wenn du etwas verstehst, solltest du beruflich nicht darüber sprechen, denn wenn du es tust, werden die Leute das gegen dich verwenden.
Aber meiner Meinung nach wird Lokad weiter daran arbeiten. Wir werden weiterhin die guten Universitäten unterstützen, die – wie die University of Toronto – in diese Richtung gehen. Wir erwarten keine vollständige Lösung, aber jeder Schritt in diese Richtung ist bereits etwas Besseres, als so zu tun, als ob das Problem gar nicht existieren würde.
Conor Doherty: Genau, annähernd korrekt. Nun, Paul, es ist hier üblich, dem Gast das letzte Wort zu überlassen. Möchtest du den Leuten etwas mitteilen oder deinen Studenten einen Rat für die Prüfungen geben?
Paul Jan: Noch keinen Rat zu den Prüfungen, aber ich möchte auf Joannes’ Kommentar zurückkommen, warum der private Sektor in Bildung investiert. Ihr investiert in Vorlesungen, Artikel und Blogs, und das weiß ich zu schätzen. Viele dieser Studenten wenden sich nach ihrem Abschluss an Anbieter, Lieferanten und Websites, um Informationen zu finden oder zu verstehen, was supply chain management ist – oder um ihr Wissen aufzufrischen.
Zum Beispiel ist Statistik ein sehr angsteinflößendes Fach für Studierende. Daher macht es die Sache viel einfacher, nicht einfach anzunehmen, dass alles normal ist, weil das diese Angst nimmt. Aber wenn Sie einen echten Hintergrund haben, um unterschiedliche Verhaltensweisen zu untermauern, dann könnten sie eher bereit sein, zu lernen, diese Angst zu überwinden. Nach der Universität wird Ihre Information für sie zugänglicher, sodass sie eine Verstärkung darstellt, um uns aus der Denkweise zu bringen, dass wir dieselbe Lösung für all die unterschiedlichen komplexen Probleme anwenden können.
Conor Doherty: Perfekt. In diesem Zusammenhang habe ich eigentlich keine weiteren Fragen. Joannes, danke für deine Zeit.
Joannes Vermorel: Vielen Dank für deine Zeit und für die anhaltende Zusammenarbeit.
Conor Doherty: Und vielen Dank an alle fürs Zuschauen. Wir sehen uns beim nächsten Mal.
