00:15 Einführung
02:28 Smarter Kühlschrank
05:28 Survivorship-Bias
07:28 Die Geschichte bisher
08:46 Über Tabus (Zusammenfassung)
12:06 Ablehnungsheuristiken (Zusammenfassung)
13:34 Niedrigwertiges positives Wissen
15:27 Software-Antipatterns, 1/2
20:11 Software-Antipatterns, 2/2
25:34 Supply Chain-Antipatterns
27:00 Nackte Prognosen
32:36 Das 100%-Serviceniveau
37:06 Die Jedi-Initiation
44:31 Der nicht-euklidische Horror
51:45 Advokat des Teufels
57:35 Zusammenfassung, negatives Wissen für supply chain
01:01:04 Fazit
01:02:45 Bevorstehende Vorlesung und Fragen aus dem Publikum
Beschreibung
Antipatterns sind die Stereotypen von Lösungen, die gut aussehen, aber in der Praxis nicht funktionieren. Die systematische Untersuchung von Antipatterns wurde in den späten 1990er Jahren im Bereich der Softwaretechnik maßgeblich vorangetrieben. Wenn anwendbar, sind Antipatterns den rohen negativen Ergebnissen überlegen, da sie leichter zu merken und zu analysieren sind. Die Perspektive der Antipatterns ist von größter Bedeutung für supply chain und sollte als einer der Pfeiler seines negativen Wissens betrachtet werden.
Volles Transkript
Hallo zusammen, willkommen zu dieser Reihe von supply chain Vorlesungen. Ich bin Joannes Vermorel und heute präsentiere ich negatives Wissen in supply chain. Für diejenigen unter euch, die die Vorlesung live verfolgen, könnt ihr jederzeit über den YouTube-Chat Fragen stellen. Ich werde den Chat während der Vorlesung nicht lesen; jedoch komme ich am Ende der Vorlesung für die Q&A-Session darauf zurück.
Heute geht es darum, was ein Unternehmen tatsächlich gewinnt, wenn es einen erfahrenen supply chain Direktor einstellt, der vielleicht zwei oder drei Jahrzehnte Erfahrung hat. Wonach sucht das Unternehmen, und könnten wir – wenn auch nur in geringem Maße – den Erwerb dieser Erfahrung in viel kürzerer Zeit reproduzieren? Genau darum geht es beim negativen Wissen.
Wenn wir eine sehr erfahrene Person betrachten, jemanden, der seit zwei Jahrzehnten in einem Bereich arbeitet, erwarten wir dann wirklich, dass diese Person Lösungen, Prozesse oder Technologien repliziert, die sie vor ein oder zwei Jahrzehnten in anderen Unternehmen implementiert hat? Wahrscheinlich nicht. Auch wenn es in Einzelfällen passieren könnte, vermute ich, dass das in der Regel höchstens ein Randphänomen darstellt.
Wenn man nach einer sehr erfahrenen Person sucht, besteht das Ziel nicht unbedingt darin, Dinge so zu replizieren, wie sie in der Vergangenheit durchgeführt wurden. Der entscheidende Wert, den man erwerben möchte, liegt darin, jemanden zu haben, der weiß, wie man allerlei Fehler vermeidet und die Erfahrung besitzt, sicherzustellen, dass zahlreiche sehr naive und schlechte Ideen in Ihrem Unternehmen nicht umgesetzt werden. Es gibt das Sprichwort, dass in der Theorie alles dasselbe ist wie in der Praxis, in der Praxis jedoch nicht. Genau darin liegt der Kern des negativen Wissens.
Mein Vorschlag an Sie ist, dass schlechte Geschäftsideen allgegenwärtig sind. Mit schlecht meine ich Ideen, die, wenn sie umgesetzt werden, sich als völlig unrentabel für das Unternehmen erweisen würden. Zur Veranschaulichung habe ich soeben die Suchanfrage “smarte Kühlschränke” in die Google Patents-Suchmaschine eingegeben. Google Patents ist eine spezialisierte Suchmaschine von Google, mit der Sie in einer Patentdatenbank suchen können. Und siehe da, wir erhalten 130.000 Treffer von Patenten, die für smart fridges angemeldet wurden.
Nehmen Sie diese Zahl mit Vorsicht, da es wahrscheinlich viele Duplikate gibt. Ein flüchtiger Blick auf die Ergebnisse zeigt jedoch sehr deutlich, dass wir Hunderte, wenn nicht gar Tausende von Unternehmen haben, die in den letzten Jahrzehnten extra Forschung und Entwicklung betrieben haben, um ein Patent für smarte Kühlschränke anzumelden. Wenn man sich die Art der in diesen Patenten gefundenen Ideen ansieht, wird man erkennen, dass es immer eine Kombination aus diesem allgegenwärtigen Haushaltsgerät, einem Kühlschrank, und dem Hinzufügen von etwas, wie billiger Elektronik, ist. Wir kombinieren beides, und voilà, wir haben irgendeine Art von Lösung.
Für welche Art von Problem allerdings? Es ist sehr unklar. Um Ihnen den Kern der meisten Patente zu verdeutlichen: Es handelt sich um eine Idee, bei der, wenn Sie einen Kühlschrank mit Sensoren haben, der Kühlschrank selbst erkennt, dass Ihnen die Milch ausgeht, und automatisch eine Nachbestellung für Sie aufgibt. Wir befinden uns im Jahr 2021, und nach meinem besten Wissen existieren smarte Kühlschränke nicht. Es ist nicht so, dass sie technisch nicht machbar wären – das sind sie sehr wohl. Es gibt schlicht und ergreifend keinen Markt dafür. Somit haben wir eine gewaltige Anzahl an Lösungen auf dem Markt, die noch ein Problem suchen. In den letzten zwei Jahrzehnten glaube ich, dass ich durchschnittlich zweimal im Jahr ein Startup gesehen habe, das irgendeinen smarten Kühlschrank bewirbt. Interessanterweise habe ich von keinem dieser Startups eine Rückmeldung erhalten. Ich habe das nicht wirklich verfolgt, aber ich vermute fest, dass jedes einzelne Startup, das in den letzten zwei Jahrzehnten einen smarten Kühlschrank beworben hat, gescheitert ist. Dennoch, auch wenn die Idee sehr weit verbreitet und populär ist, wie die tausenden Patente zeigen, haben sich die Konsequenzen dieser Ideen, die schlecht sind, weil vermutlich die meisten dieser Startups einfach bankrottgingen, nicht durchgesetzt.
Hier sehen wir etwas sehr Interessantes: Durch Erfahrung erhält man Zugang zu einer Art von Wissen, das Beobachtern am Markt nicht sofort zugänglich ist. Man kann die dunkle Seite erkennen, also die Dinge, die fehlen, die Dinge, die versprochen und propagiert wurden, sich aber als nicht sehr erfolgreich erwiesen haben.
Es gibt ein sehr bemerkenswertes historisches Beispiel aus dem Zweiten Weltkrieg. Die US-Armee führte eine Untersuchung an Flugzeugen durch, die zur Basis zurückkehrten, um die Positionen der Einschläge von Kugeln an den Flugzeugen zu erfassen. Was Sie auf dem Bildschirm sehen, war im Wesentlichen die Sammlung der Positionen der Kugeln, wie sie an den aus den Schlachtfeldern zur Basis zurückkehrenden Flugzeugen beobachtet wurden. Zunächst gingen die Offiziere der Armee davon aus, dass an den am stärksten getroffenen Bereichen Panzerplatten angebracht werden müssten, also in den Bereichen, die offensichtlich dem stärksten Beschuss während der Schlacht ausgesetzt waren.
Dann sagte ein anderer Herr, Abraham Wald: Nein, das ist genau das Gegenteil. Das Problem ist, was Sie sehen, sind die Flugzeuge, die es geschafft haben, zur Basis zurückzukehren. Was Sie nicht sehen, ist, dass in allen Bereichen, in denen keine Kugelspuren erkennbar sind, höchstwahrscheinlich ein Kugelschlag in diesem Bereich tödlich für das Flugzeug, die Besatzung oder beides war. Wenn man also Panzerplatten anbringen muss, dann genau in allen Bereichen, in denen man keine mit Kugelspuren zurückkehrenden Flugzeuge sieht. Diese Bereiche müssen geschützt werden.
Was Abraham darauf hinwies, war ein Phänomen, das als Survivorship Bias bekannt ist, bei dem man im Wesentlichen nur die Überlebenden sieht und nicht alle Flugzeuge, die es nicht zur Basis zurückschafften. Die Idee des negativen Wissens ist genau so: Man nimmt dieses fotografische Bild und das Negative, und es ist genau das, was Ihre Aufmerksamkeit erregen sollte, weil dort das wirklich Schlechte passiert. Das ist, würde ich sagen, das Wesentliche des negativen Wissens.
Dies ist die vierte Vorlesung in meiner Vorlesungsreihe, die erste Vorlesung des zweiten Kapitels. Im ersten Kapitel des Prologs habe ich meine Ansichten zu supply chain präsentiert, sowohl das Studienfeld als auch die praktische Anwendung. Was wir gesehen haben, ist, dass supply chain im Wesentlichen eine Ansammlung von wicked problems ist, im Gegensatz zu tame problems. Wicked problems sind sehr schwer anzugehen, da sie sich weder für einfache Studien noch für einfache Praxis eignen. Grundsätzlich gibt es bei wicked problems etwas Widriges im Hinblick auf Studium und Praxis. Deshalb ist das zweite Kapitel Methodologien gewidmet.
In der vorliegenden Vorlesung verfolgen wir einen qualitativen Ansatz, so wie wir es bereits bei der supply chain persona getan haben, welche die allererste Vorlesung in diesem Kapitel war. Wir werden auf die Art qualitativer Ansätze eingehen, mit denen wir Verbesserungen für supply chains auf kontrollierte, verlässliche und potenziell letztlich messbare Weise erzielen können.
Zusammenfassung: Obwohl diese Vorlesung dem negativen Wissen gewidmet ist, ist dies nicht das erste Mal in dieser Vorlesungsreihe, dass ich Elemente anspreche, die als Bruchstücke negativen Wissens qualifizieren würden. Während der ersten Vorlesung dieses zweiten Kapitels über supply chain personas habe ich meine Ansichten zu Fallstudien präsentiert. Ich sagte, dass positive Fallstudien, also Fallstudien, die positive Ergebnisse im Zusammenhang mit einer interessanten Lösung präsentieren, mit massiven Interessenkonflikten einhergehen, die im Wesentlichen jegliches Vertrauen in die Gültigkeit der Ergebnisse untergraben. Andererseits erklärte ich, dass negative Fallstudien in Ordnung sind, da diese Interessenkonflikte, obwohl sie vorhanden sein können, wesentlich weniger intensiv sind.
In dieser Vorlesung über supply chain personas stellte ich eine fantastische negative Fallstudie vor, “The Last Days of Target Canada” von Joe Castaldo, die einen versagenden supply chain in epischem Ausmaß beschrieb, der letztlich zum Bankrott von Target Canada führte. Dies ist eine Art negatives Wissen, bei dem das Untersuchungsobjekt buchstäblich Dinge sind, die nicht funktionierten, im Gegensatz zu dem, was wir tun können, um etwas zu haben, das tatsächlich funktioniert.
Könnten wir nun negative Fallstudien als eine grundlegende Praxis für unser negatives Wissen in supply chain nutzen? Ich würde sagen, meist nicht, und zwar aus zwei sehr unterschiedlichen Gründen. Der erste Grund ist einfach, dass negative Fallstudien extrem selten sind. Ich vermute, nur als Schätzung, dass es tatsächlich mehr als 100-mal so viele Patente auf smart fridges gibt, die völlig nutzlos sind, als es negative Fallstudien über supply chains gibt. Wir haben also ein sehr praktisches Problem: Obwohl diese negativen Fallstudien von großer Relevanz und von hohem wissenschaftlichem Interesse sind, sind sie schlichtweg extrem selten. Es gibt so wenige davon, dass es sehr schwierig ist, dieses Material als Grundlage für unser negatives Wissen in supply chain zu nutzen.
Das zweite Problem ist die Verständlichkeit. Diese negativen Fallstudien, wie der fantastische Artikel “The Last Days of Target Canada”, zeigen, dass gleichzeitig Dutzende von Problemen ablaufen und all diese Probleme miteinander verstrickt sind, was letztlich zu einem epischen Scheitern führt. Das Problem ist, dass diese Fallstudien buchstäblich das reale Leben widerspiegeln und diese Ereignisse sehr komplex sind. Es ist schwierig, über diese Fallstudien zu kommunizieren und sie zu analysieren, weil Details eine Rolle spielen und sie sehr dicht sind. Es gibt ein noch alltäglicheres Problem: Wie vermittelt man das einem größeren Publikum?
In meiner letzten Vorlesung über experimentelle Optimierung sahen wir auch eine andere Art von negativem Wissen: Ablehnungsheuristiken. Dabei handelt es sich im Wesentlichen um einfache Tricks, die angewendet werden können, wenn ein quantitativer Lösungsvorschlag als potenzieller Kandidat für die Verbesserung Ihrer supply chain vorgelegt wird. Sie können eine Reihe von Heuristiken oder einfachen Regeln verwenden, um Lösungen auszuschließen, die mit sehr hoher Wahrscheinlichkeit einfach nicht funktionieren werden. Allerdings haben wir hier ein Skalierbarkeitsproblem. Diese Heuristiken funktionieren nur, weil sie obskur sind. Wenn sie in supply chain circles bekannt würden, würden sowohl wissenschaftliche Arbeiten als auch supply chain software ihren Diskurs anpassen und ändern, was die Situation noch verwirrender machen würde. Diese Heuristiken sind sehr effizient, aber wenn sie populär würden, würden sie zwar ihre Gültigkeit behalten, jedoch an Effizienz als Filter verlieren, einfach weil die Menschen darauf achten würden, Wege um diese Heuristiken herum zu arbeiten.
Deshalb können diese Heuristiken, obwohl sie sehr interessant sind, nicht als Grundlage für unser negatives Wissen dienen, das wir für supply chain etablieren möchten.
Außerdem sollten wir negatives Wissen nicht mit niedrigwertigem positivem Wissen verwechseln. Der Unterschied liegt wirklich in der Intention. Zum Beispiel besteht die Absicht von safety stocks darin, Unternehmen einen kontrollierten Weg zu bieten, die Servicequalität, die sie erhalten, zu steuern. Die Absicht ist positiv; es handelt sich um eine Lösung für etwas, das funktionieren sollte. In Wirklichkeit basiert das Safety-Stock-Modell jedoch auf völlig missbräuchlichen Annahmen: future demand und lead times werden als normalverteilt angenommen, obwohl diese Annahmen faktisch falsch sind. Ich habe noch nie supply chain Datensätze beobachtet, in denen entweder die Nachfrage oder die Durchlaufzeiten normalverteilt waren. Die interessierenden Verteilungen sind tatsächlich zipf-verteilt, wie ich in meinen vorherigen Vorlesungen über die quantitative Prinzipien für supply chain angesprochen habe. Aus einer sachgerechten Perspektive ist Safety Stock widerlegt, aber trotzdem ist Safety Stock definitiv im Bereich des positiven Wissens verankert, wenn auch möglicherweise als äußerst niedrigwertiges positives Wissen betrachtet werden kann.
In dieser Vorlesung werden wir nicht die Zeit haben, auf alle Elemente einzugehen, die aus meiner Sicht als äußerst niedrigwertiges positives Wissen gelten, aber ich würde mich freuen, wenn einige Leute mir während der Q&A-Session Fragen zu diesen Elementen stellen möchten.
Wenn es um tatsächliches negatives Wissen von praktischem Interesse geht, gibt es ein Buch namens “Anti-Patterns: Refactoring Software, Architectures, and Projects in Crisis”, das ein Meilenstein in der Geschichte des Software Engineerings ist. Veröffentlicht im Jahr 1998, beginnt dieses Buch mit der beiläufigen Beobachtung, dass in der Softwarebranche, wenn gute Ideen existieren und Projekte von diesen Ideen profitieren, die Softwareanbieter beobachten müssen, wie diese guten Ideen vom Erfolg des Projekts verzehrt werden. Die Autoren stellen in Frage, ob eine gute Idee auch nach der Umsetzung des Produkts weiterhin eine gute Praxis darstellt – und im Grunde lautet die Antwort nein. Es gibt einen First-Mover-Vorteil, der sehr spezifisch für die Softwarebranche ist, und infolgedessen haben wir ein Problem. So gut wie jede Regel, die man verwenden würde, um den Erfolg von irgendetwas in der Softwarebranche vorherzusagen, ist sich selbst widersprechend, da die allerbesten Ansätze dazu neigen, von dem Erfolg, den sie erzeugen, aufgezehrt zu werden. Die Autoren von “Anti-Patterns” stellten fest, dass es ihrer Ansicht nach nahezu unmöglich ist, den Erfolg einer Softwareinitiative zu garantieren. Gleichzeitig bemerkten sie aber auch, dass die Situation bei Misserfolgen sehr asymmetrisch ist. Sie bemerkten, dass es möglich ist, mit sehr hoher Zuversicht (manchmal fast mit Gewissheit) vorherzusagen, dass ein bestimmtes Projekt kurz vor dem Scheitern steht. Dies ist sehr interessant, denn man kann Erfolg nicht garantieren, aber man kann so etwas wie eine Wissenschaft haben, die Misserfolg garantiert. Noch besser: Dieses Wissen um Elemente, die Misserfolg garantieren, scheint über die Zeit hinweg außerordentlich stabil und weitgehend unabhängig von den technischen Details des Unternehmens oder des betrachteten Sektors zu sein.
Wenn wir zur ursprünglichen Idee des smarten Kühlschranks zurückkehren, sehen wir, dass all diese Patente zu smarten Kühlschränken unglaublich vielfältig in den vorgestellten Lösungen sind. Es stellt sich jedoch heraus, dass all diese Patente zu geschäftlichen Fehlschlägen führen, weil sie alle unter dasselbe Motto fallen: eine Lösung, die nach einem Problem sucht. Die Kombination eines allgegenwärtigen Geräts mit preiswerter Elektronik schafft zwar eine Lösung, aber ist das wirklich sinnvoll? In diesem Fall fast nie.
Die Autoren von “Anti-Patterns” begannen ihre Reise, indem sie die Ursachen von Softwarefehlern untersuchten und die sieben Todsünden des Software Engineerings identifizierten, nämlich Eile, Apathie, Engstirnigkeit, Gier, Ignoranz, Stolz und Neid. Diese Probleme sind unabhängig vom Kontext und den beteiligten Technologien, da sie Invarianten der menschlichen Natur selbst darstellen. Wenn man einen Supply Chain Director mit zwei Jahrzehnten Erfahrung sucht, wird es jemand sein, der schlichtweg länger gelebt hat und die meisten Probleme, die auftreten, wenn echte Menschen beteiligt sind – mit allerlei Mängeln – verinnerlicht hat.
Die Idee der Autoren ist, dass es gut ist, dieses Wissen zu formalisieren, um es verdaulicher und verständlicher zu machen, sodass es leichter fällt, über diese Probleme zu kommunizieren und nachzudenken. Das ist das Wesen von Anti-Patterns – ein Format, um Brocken negativen Wissens festzuhalten.
In ihrem Buch stellen die Autoren eine Vorlage für ein Anti-Pattern vor, die mit einem einprägsamen Namen beginnt. Man muss den Maßstab charakterisieren – sei es auf Quellcode-, Softwarearchitektur-, Unternehmens- oder Industrieebene. Es gilt, die tatsächlichen Ursachen und die typischerweise damit verbundenen Konsequenzen zu identifizieren. Ebenso will man die wirkenden Kräfte, die Symptome und die unbeabsichtigten Folgen charakterisieren, die man nicht erwartet und die den erwarteten Nutzen der ursprünglichen Lösung vollständig untergraben.
Die Autoren argumentieren, dass man anekdotische Beweise präsentieren muss, und genau deshalb verwenden sie fiktive Unternehmen in ihren Anti-Patterns. Dies geschieht, um die Tabus zu umgehen, die mit der Diskussion über reale Unternehmen und reale Personen verbunden sind – etwas, das eine offene, ehrliche Kommunikation behindern könnte. Die Anti-Pattern-Vorlage muss mit einer refaktorierten Lösung enden, also einem Weg, eine im Wesentlichen fehlgeleitete Lösung in eine Variante zu transformieren, die in der realen Welt tatsächlich funktioniert und bei der die unbeabsichtigten Folgen abgemildert und idealerweise beseitigt werden.
Diese Vorlesung handelt nicht von supply chain Anti-Patterns, sondern soll lediglich zwei Beispiele von Software-Anti-Patterns veranschaulichen, von denen Sie vielleicht schon gehört haben – das erste ist der Golden Hammer. Der Golden Hammer steht für die Idee, dass, wenn man einen goldenen Hammer in der Hand hat, alles andere wie ein Nagel erscheint. Dieses Anti-Pattern besagt im Wesentlichen, dass, wenn man einen Java-Programmierer fragt, wie er ein neues Problem angehen würde, er wahrscheinlich vorschlagen wird, ein Programm in Java zu schreiben, um dieses Problem zu lösen. Wird derselben Person ein weiteres Problem präsentiert, so würde sie sagen, dass auch dieses Problem mit einem Java-Programm gelöst werden könne. Bei der Präsentation von 20 verschiedenen Problemen lautet jedes Mal die Antwort: “Ich glaube, ein Java-Programm würde vollkommen ausreichen.” Dies ist ein massiver Bias, bei dem Menschen mit Erfahrung in einer bestimmten Technologie dazu neigen, ihr technisches Wissen zur Lösung neuer Probleme wiederzuverwenden, anstatt zu prüfen, ob dieses Wissen tatsächlich technisch relevant für das neue Problem ist. Intellektuell ist es deutlich einfacher, standardmäßig auf das zurückzugreifen, was man bereits kennt.
Ein weiteres ist Analysis Paralysis. In der Welt der Software gibt es viele Situationen, in denen die Möglichkeiten endlos scheinen, und es ist verlockend zu sagen: “Anstatt 20 verschiedene Ansätze auszuprobieren, die scheitern werden, sollten wir uns intensiv mit dem Design befassen, und sobald wir absolut sicher sind, dass wir die richtige Lösung im Kopf haben, werden wir die Umsetzung starten.” Leider ist dies sehr schwer umzusetzen und führt meist zu einer Analyse-Paralyse, bei der mehr Zeit und Aufwand darauf verwendet wird, unzählige potenzielle Optionen zu erwägen, statt einfach eine Lösung auszuprobieren und zu sehen, ob sie funktioniert.
Nun, offensichtlich haben wir bereits besprochen, dass es in diesem Buch um Software-Anti-Patterns ging, und ich glaube, dass das Software Engineering viele Ähnlichkeiten mit den Problemen aufweist, denen wir in der supply chain begegnen – insbesondere in der supply chain Optimierung. Beide Bereiche sind im Wesentlichen Ansammlungen von wicked problems, und die moderne supply chain dreht sich stark darum, ein Software-Produkt zu liefern. Es gibt also ein gewisses Maß an Überschneidungen zwischen supply chain Problemen und Software Engineering Problemen, doch diese beiden Bereiche sind keineswegs meilenweit voneinander entfernt.
Hier werde ich fünf supply chain Anti-Patterns vorstellen, die in schriftlicher Form auf der Lokad-Website zu finden sind, wobei für Interessierte eine ausführlichere Präsentation verfügbar ist.
Das erste ist Naked Forecast. Inspiriert von der Kurzgeschichte “Des Kaisers neue Kleider” von Hans Christian Andersen handelt es sich um ein Unternehmen, das eine laufende Initiative zur Verbesserung der Prognosegenauigkeit verfolgt. Zu den Symptomen gehören lang andauernde Prognosen, über die sich alle beschweren – Produktion, Marketing, Vertrieb, Einkauf und sogar supply chain, wobei die Forecasting-Abteilung typischerweise Teil der supply chain ist. In den letzten ein bis zwei Jahrzehnten gab es zahlreiche Versuche, die Genauigkeit der Prognose zu verbessern, doch scheint es, dass egal wie viel Aufwand betrieben wird, immer eine endlose Reihe von Ausreden von den Verantwortlichen vorliegt, um die mangelhafte Genauigkeit zu rechtfertigen.
Das Problem ist, dass es eine weitere Initiative gibt, deren Ziel es ist, die Prognosegenauigkeit in Ordnung zu bringen – also dieses ungenaue Prognoseproblem ein für alle Mal zu beheben. Das ist das Naked Forecast Anti-Pattern in Aktion. Die unbeabsichtigten Folgen davon sind erstens, dass dadurch nicht wesentlich genauere Prognosen erzielt werden. Zweitens führt eine weitere Initiative lediglich dazu, dass sich eine noch byzantinere Organisation entwickelt, in der eine anfänglich kleine Praxis zur Erstellung der Prognose immer komplexer wird, weil immer mehr Menschen in die Erstellung dieser Prognosen involviert werden. Letztlich endet man mit etwas, das nach wie vor ebenso ungenau ist wie zuvor, sich aber von etwas Bescheidenem und Ungenaurem in eine ausufernde Bürokratie verwandelt hat.
Ich glaube, dass die Wurzel des Problems in dem liegt, was ich naiven Rationalismus oder die Illusion der Wissenschaft nenne. Wenn diese Initiative startet, präsentiert sich das Problem, als wäre es vollkommen objektiv: “Wir werden Prognosen anhand eines festgelegten Metrik, sagen wir des mittleren absoluten Fehlers, erstellen.” Alles erscheint sehr geradlinig und mit einem klar definierten Problem. Das Problem ist jedoch, dass dies alles sehr naiv ist, denn es besteht keine direkte Korrelation zwischen der Prognosegenauigkeit und der Rentabilität des Unternehmens. Man sollte vielmehr nach Wegen suchen, die Rentabilität des Unternehmens zu verbessern, also in Begriffen von Dollar oder Euro des Fehlers und nicht in prozentualen Fehlern denken.
Grundsätzlich liegt das Problem darin, dass diese Prognosen isoliert erstellt werden und kein Feedback aus dem realen Geschäft erhalten. Die Prognosegenauigkeit ist lediglich ein numerischer Artefakt; sie stellt keinen echten, greifbaren Return on Investment für das Unternehmen dar. Als kleines anekdotisches Beispiel: Wenn ich jedes Mal, wenn ich am Telefon mit einem supply chain director sprach, der mir mitteilte, dass sie eine neue Initiative zur Verbesserung der Prognosegenauigkeit starten, einen zusätzlichen Scheck über tausend Dollar erhalten hätte, wäre ich ein noch reicherer Mann.
Die Quintessenz ist, dass, was die refaktorierte Lösung betrifft, solange die Prognosen nackt bleiben, es nicht funktionieren wird. Man muss ihnen quasi Kleidung anziehen – und diese Kleidung sind Entscheidungen. Wie wir in der vorangegangenen Vorlesung zur experimentellen Optimierung erörtert haben: Wenn die Prognosen nicht direkt mit realen, greifbaren Entscheidungen verknüpft sind – wie zum Beispiel wie viel eingekauft werden soll, wie viel produziert werden soll oder ob Preise angehoben oder gesenkt werden sollen – erhält man nie das echte Feedback, das zählt. Das echte Feedback, das zählt, ist nicht der Back-Test-KPI der Messung; es sind diese Entscheidungen. Folglich besteht die refaktorierte Lösung zur Bekämpfung des Naked Forecast Anti-Patterns im Wesentlichen darin, zu entscheiden, dass dieselben Personen, die die Prognose erstellen, auch mit den Konsequenzen dieser Prognosen leben müssen, wenn es um die tatsächlichen supply chain decisions geht, die daraus umgesetzt werden.
Das Zweite wäre der Mythos des 100% Service Level. Die Situation beginnt typischerweise so, dass sich der Vorstand trifft und irgendwo in der Presse oder in den sozialen Netzwerken laute Beschwerden über die Servicequalität zu hören sind. Es sieht schlecht für das Unternehmen aus, da der Eindruck entsteht, dass es seine Versprechen nicht einhält. Der Vorstand setzt den CEO enorm unter Druck, etwas gegen diese Problematik der Servicequalität zu unternehmen, was sich negativ auf Marke, Image und potenziell auf das Wachstum des Unternehmens auswirkt. Der CEO erklärt: “Wir müssen diesen endlosen Kreislauf von Problemen mit der Servicequalität wirklich beenden.” Daraufhin wendet sich der CEO an den VP of Supply Chain und bittet diesen, etwas gegen die Probleme mit der Servicequalität zu unternehmen. Der VP of Supply Chain fordert im Gegenzug vom Supply Chain Director dasselbe, und dieser wendet sich an den Supply Chain Manager, um das Problem in Angriff zu nehmen. Der Supply Chain Manager stellt daraufhin das Service Level auf einen sehr hohen Wert ein, nahezu 100%.
Und siehe da: Selbst wenn man kurzfristig nur geringfügig höhere Service Levels erzielt, kehren die Probleme mit der Servicequalität sehr bald zurück. Diese höheren Service Levels sind nicht nachhaltig, und man endet mit Bestandschwankungen, unnötig hohem Inventarbestand und – obwohl die Absicht bestand, das Service Level zu erhöhen – erhält man häufig nach sechs oder zwölf Monaten wieder niedrigere Service Levels.
Die Ursache liegt hier nicht nur in Unwissenheit, sondern auch im Wunschdenken. Mathematisch gesprochen, bedeutet ein 100% service level, dass unendlich viel Inventar vorhanden sein muss, was technisch nicht möglich ist. Es herrscht das kraftvolle Wunschdenken, dass man dieses Problem vollständig in den Griff bekommen könne, obwohl dies unmöglich ist. Bestenfalls lassen sich die Probleme mit der Servicequalität mildern; sie lassen sich jedoch niemals vollständig beseitigen.
Anekdotisch habe ich erlebt, dass viele Unternehmen am meisten zu kämpfen haben, weil sie diese Denkweise des mythischen Ziels eines 100% service level verinnerlicht haben. Wenn Ihr Unternehmen nicht bereit ist zu akzeptieren, dass bei einigen Produkten (nicht bei allen oder den wichtigsten) die Service Levels absichtlich niedriger angesetzt werden, dann steuern Sie auf große Schwierigkeiten zu. Der einzige Weg, die Servicequalität tatsächlich zu verbessern, besteht darin, zunächst zu akzeptieren, dass, wenn man versucht, sich auf alles zu konzentrieren, das gleichbedeutend damit ist, dass man sich effektiv auf nichts konzentriert. Solange Sie nicht bereit sind, zu akzeptieren, dass bei einigen SKUs absichtlich ein niedrigerer Service Level als akzeptables Ergebnis in Kauf genommen wird, werden Sie die Gesamtqualität des Service nicht verbessern können.
Im Hinblick auf refaktorisierte Lösungen lautet die Antwort: wirtschaftliche Treiber. Das ist ein Punkt, den ich in der zweiten Vorlesung des allerersten Kapitels vorgestellt habe – der Vision für die Quantitative Supply Chain. Die wirtschaftlichen Treiber machen deutlich, dass es Kosten für stockouts und für die carrying cost gibt und dass ein Gleichgewicht gefunden werden muss. Man kann nicht einfach auf einen 100% service level drängen, da dies aus wirtschaftlicher Sicht völlig unausgewogen ist – es ist nicht nachhaltig. Der Versuch, in diese Richtung zu drängen, ist sehr fehlgeleitet, da er dem Unternehmen nur schaden wird. Die Lösung besteht darin, einen gesunden Anteil wirtschaftlicher Treiber in Ihre supply chain Praxis einzubringen.
Nun zeigt sich das dritte Anti-Pattern, Jedi Initiation, wenn das Top-Management vieler großer Unternehmen ständig unter Druck der Medien steht, bedingt durch den unaufhörlichen Strom von Schlagwörtern, die an sie herangetragen werden. Diese Schlagwörter umfassen künstliche Intelligenz, Blockchain, cloud computing, Big Data, IoT usw. Influencer sagen ihnen, dass, wenn sich ihr Unternehmen nicht an diese Trends anpasst, es obsolet wird. Es herrscht eine ständige Angst, etwas zu verpassen – eine Angst, die als mächtige Kraft wirkt und das Top-Management der meisten großen Unternehmen, die große supply chains betreiben, kontinuierlich unter Druck setzt.
Die Symptome der Jedi-Initiation können beobachtet werden, wenn Ihr Unternehmen eine Abteilung mit jungen, begeisterten Ingenieuren hat, die Schlagwörter in ihren Jobtiteln tragen, wie etwa Forscher für künstliche Intelligenz, Blockchain-Ingenieure oder data scientists. Das Motto lautet „die Macht meistern“, wobei die Macht das Schlagwort des jeweiligen Moments ist. Das Management nimmt – man könnte sagen – junge oder unerfahrene Leute und weist sie an, etwas Großartiges für das Unternehmen zu leisten, ohne sich in die technischen Aspekte dieser Konzepte einzumischen.
Was passiert, ist, dass diese Teams interessante Prototypen erstellen, die letztlich keinen echten Mehrwert für das Unternehmen liefern. Infolgedessen bleiben, obwohl man anfänglich davon ausging, dass das Unternehmen gemäß dem Schlagwort des Tages revolutioniert würde, die veralteten Praktiken und Technologien vorherrschend – unverändert durch das Schlagwort oder das extra dafür gebildete Team.
Anhand von Anekdoten lässt sich feststellen, dass heutzutage, im Jahr 2021, die überwiegende Mehrheit der Unternehmen mit einem data science team genau null Rendite auf ihre Investition erzielt. Das data science team erstellt schicke Python-Prototypen mithilfe von Open-Source-Bibliotheken, die sehr cool sind, aber in Bezug auf den praktischen Return on Investment für den Großteil des Marktes ist das exakt null. Genau auf dieses Muster der Jedi-Initiation hereinfallen die obersten Manager: Sie lesen in der Presse, dass data science der neue Trend sei, und stellen deshalb ein data science team ein. Als kleines anekdotisches Beispiel stelle ich fest, dass diese Teams nicht nur ziemlich jung und unerfahren sind, sondern auch im Laufe der Zeit so bleiben. Das liegt daran, dass die Fluktuation sehr hoch ist. Man kann ein Unternehmen haben, das sehr solide und robust ist, bei dem die durchschnittliche Betriebszugehörigkeit typischerweise fünf bis zehn Jahre beträgt – außer im data science team, wo die Mitarbeiter im Durchschnitt 18 Monate bleiben. Ein Grund, warum aus diesen Teams nichts Wertvolles hervorgeht, besteht darin, dass die Leute hereinkommen, ein paar Prototypen erstellen und dann wieder gehen. Für das Unternehmen erfolgt keine Kapitalisierung, und es gelingt niemals, das Unternehmen wirklich zu transformieren.
Was die Umstrukturierung dieser Lösung angeht, so gibt es zunächst keinen Weg darum herum, als Vorbild voranzugehen. Wenn Sie tatsächlich data science betreiben wollen, dann muss das Top-Management über umfassende Kenntnisse in data science verfügen. Zum Beispiel hat Jeff Bezos seine Vertrautheit mit den modernsten Techniken des maschinellen Lernens seiner Zeit gezeigt. Amazon kann mit maschinellem Lernen sehr erfolgreich sein, aber das geschieht, weil das Top-Management die Details genau kennt. Als Vorbild voranzugehen ist unerlässlich.
Zweitens müssen Sie sicherstellen, dass Sie, wenn Sie diese jungen, begeisterten und potenziell talentierten Ingenieure einstellen, sie mit realen Problemen konfrontieren – und nicht mit Meta-Problemen. Es muss einen Bezug zur Realität haben. Dies knüpft an meine vorige Vorlesung über empirische, experimentelle Optimierung an. Wenn Sie einen data scientist einstellen, um eine Kundensegmentierung oder eine bessere ABC analysis für Ihr Unternehmen durchzuführen, handelt es sich dabei nicht um reale Probleme. Es sind nur erfundene Zahlen. Wenn Sie diese Personen einstellen und sie mit der eigentlichen Nachschubsteuerung betrauen sowie sie für die genauen Mengen verantwortlich machen, die von einer Reihe von Lieferanten nachgefüllt werden sollen, dann ist das sehr real. Genau aus diesem Grund hat Lokad vor einem Jahrzehnt intern von data scientists zu Supply Chain Scientists gewechselt. Ziel war es, ein völlig anderes Engagement zu erreichen und sich von diesem Jedi-Initiation-Antimuster zu lösen.
Der nicht-euklidische Horror. In diesem Zusammenhang haben Sie ein Unternehmen, das eine große supply chain betreibt, und die IT-Landschaft ist sehr komplex. Es gibt mehrere Stücke von Unternehmenssoftware, wie ERP, WMS und EDI, die für sich genommen komplex sind. Dann gibt es den ganzen Klebstoff, der diese Dinge miteinander verbindet, und das Gesamtbild ist überwältigend komplex. Wie wissen Sie also, dass Sie sich tatsächlich in einem Unternehmen befinden, das mit einer nicht akklimatisierten Lösung konfrontiert ist? Was sind die Symptome? Die Symptome sind, dass jeder im Unternehmen das Gefühl hat, dass in der IT-Abteilung eine weit verbreitete Inkompetenz herrscht. Die IT-Mitarbeiter wirken überfordert und scheinen nicht zu verstehen, was in dem System vor sich geht, das sie verwalten und betreiben sollen. Ein weiteres Symptom ist, dass Sie täglich IT-Probleme sehen, die die Produktion beeinträchtigen. Dies sind die wesentlichen Symptome der nicht akklimatisierten Lösung.
Die Folge einer nicht akklimatisierten IT-Landschaft ist, dass Änderungen, die im Unternehmen vorgenommen werden müssen – und wenn es im Unternehmen zu einer Änderung kommt, muss auch an den IT-Systemen etwas geändert werden – sehr langsam vonstattengehen. Moderne supply chains werden stark von ihren Softwarekomponenten angetrieben. All diese Änderungen erfolgen sehr langsam, und es ist stets ein mühsamer Prozess, bei dem selbst kleine Änderungen ewig dauern. Wann immer es irgendeinen Grad an Veränderung gibt, gibt es in der Regel eine Menge Rückschritte. Wie man so sagt: Zwei Schritte vorwärts und drei Schritte zurück, dann wieder zwei Schritte vorwärts und ein Schritt zurück. Die Veränderung erfolgt nicht nur langsam, sondern geht auch mit einem stetigen Strom von Rückschritten einher. Die Situation verbessert sich im Laufe der Zeit kaum; bestenfalls stagniert sie.
Was die Ursachen betrifft, so interessiert sich das Management nicht wirklich für das Kleingedruckte, und auch das nicht-IT-Management kümmert sich kaum um all diese IT-Systeme. Das führt zu einem Ansatz, den ich Inkrementalismus nenne, bei dem jegliche Änderung, die im IT-System des Unternehmens vorgenommen werden soll, beispielsweise von den supply chains gefordert wird. Wann immer eine Änderung notwendig ist, sagt das Management stets: “Bitte wählen Sie den einfachsten Weg, den Weg, der den geringsten Aufwand und die wenigste Zeit erfordert, damit wir dies so schnell wie möglich umgesetzt sehen können.” Darum geht es beim Inkrementalismus.
Ich glaube, dass Inkrementalismus eine sehr gefährliche Ursache ist. Das Problem beim Inkrementalismus besteht darin, dass es buchstäblich ein Tod durch tausend Schnitte ist. Jede einzelne Änderung, die am System vorgenommen wird, macht es ein wenig komplexer, ein wenig unübersichtlicher und ein wenig schwerer zu testen. Obwohl jede einzelne Änderung für sich genommen unbedeutend ist, führt das tägliche Anhäufen von Dutzenden von Änderungen an den IT-Systemen über ein Jahrzehnt hinweg zu einem Ozean der Komplexität. Jede Änderung hat das System komplexer gemacht, und das Gesamtbild ist völlig verloren gegangen. Überspulen Sie ein Jahrzehnt, und Sie landen bei einem massiven, verworrenen System, das wahnsinnig wirkt.
Als kleines anekdotisches Beispiel kann man sehen, dass es immer noch sehr große E-Commerce-Unternehmen gibt, bei denen man als Verbraucher routinemäßig Ausfallzeiten beobachten kann. Solche Dinge sollten niemals passieren. Als E-Commerce-Unternehmen im Jahr 2021 sollte Ihre Betriebszeit so sein, dass nur etwa 10 Minuten Ausfallzeit pro Jahr zulässig sind. Jede einzelne Sekunde Ausfallzeit ist eine verlorene Chance. Die Gestaltung von Warenkorbsystemen im Jahr 2021 ist keine Raketenwissenschaft mehr; es ist tatsächlich sehr einfache Software, was Unternehmenssoftware betrifft. Es gibt keinen Grund, nicht etwas zu haben, das immer läuft. Die Realität ist jedoch, dass, wenn Sie beobachten, dass der E-Commerce ausfällt, in der Regel nicht der Warenkorb versagt, sondern eine nicht akklimatisierte Lösung direkt hinter dem E-Commerce sitzt. Dass der E-Commerce ausfällt, spiegelt lediglich ein Problem wider, das irgendwo in der IT-Landschaft aufgetreten ist.
Wenn wir die nicht akklimatisierte Lösung umgestalten wollen, sollten wir aufhören, nach der einfachsten Lösung für Veränderungen zu suchen. Wir müssen nicht an eine leichte Lösung denken, sondern an eine einfache Lösung. Eine einfache Lösung unterscheidet sich von der leichten Lösung in einem entscheidenden Punkt: Sie macht die gesamte Landschaft ein wenig ordentlicher und vernünftiger, was es erleichtert, später weitere Änderungen vorzunehmen. Man könnte sagen: “Aber es ist nur eine rein technische Angelegenheit, also ist das die Aufgabe der IT.” Ich würde sagen: Nein, absolut nicht. Es ist vielmehr ein supply chain Problem. Die Einführung einer einfachen Lösung ist nicht eine Frage einer einfachen Lösung aus IT-Sicht; es ist eine Frage einer einfachen Lösung aus supply chain Perspektive.
Die Einfachheit der Lösung und ihr beabsichtigtes Ziel, spätere Änderungen leichter umsetzbar zu machen, hängt von Ihrer Roadmap ab. Welche zukünftigen Änderungen möchten Sie in Ihre IT-Landschaft einführen? Die IT-Abteilung hat nicht die Zeit, supply chain Experte zu sein und genau zu wissen, wohin Sie das Unternehmen in Bezug auf die supply chain Ausführung in einem Jahrzehnt lenken wollen. Es muss das supply chain management sein, das diese Vision hat und die Entwicklung – möglicherweise mit Unterstützung der IT – in eine Richtung lenkt, in der Änderungen im Laufe der Zeit immer leichter umgesetzt werden können.
Schließlich, als letztes Antimuster für heute, der Advocatus Diaboli. Der Kontext ist typischerweise ein großes Unternehmen, das erhebliche supply chain Probleme hatte und sich für einen großen Anbieter entschieden hat, wobei viel Geld auf den Tisch gelegt wurde. Die Initiative wird gestartet, und wenige Monate später, typischerweise etwa sechs Monate, hat der Anbieter sehr wenig vorzuweisen. Es wurde viel Geld in den Anbieter investiert, und es gibt sehr wenig, was man vorzeigen kann. Übrigens, im Jahr 2021 sind sechs Monate eine lange Zeit. Wenn Sie eine Softwareinitiative haben, die in sechs Monaten keine greifbaren, produktionsreifen Ergebnisse liefert, sollten Sie sehr besorgt sein, denn nach meiner Erfahrung – wenn Sie in sechs Monaten keine greifbaren Ergebnisse liefern können, ist die Initiative höchstwahrscheinlich zum Scheitern verurteilt und Sie werden niemals eine positive Kapitalrendite für das Unternehmen erzielen.
Es kommt dazu, dass das Management sieht, wie sich das Projekt verzögert, und es gibt sehr wenig vorzuweisen. Das Top-Management, anstatt gegenüber dem Tech-Anbieter zunehmend aggressiv zu werden und an der Spitze des Anbieters zu stehen, wechselt plötzlich die Seiten und verteidigt den Anbieter energisch. Das ist sehr rätselhaft. Sie starten eine große Initiative, geben einer anderen Firma viel Geld, und die Initiative schreitet voran – aber schlecht und mit wenig Ergebnissen. Anstatt klarzustellen, dass die Initiative tatsächlich scheitert, verdoppelt das Management seinen Einsatz und beginnt, den Anbieter zu verteidigen, was sehr merkwürdig ist. Es ist, als ob eine Art Stockholm-Syndrom im Spiel wäre, bei dem Ihnen zwar Schaden zugefügt wird, Sie diese Personen aber irgendwann zu mögen beginnen, wenn der Schaden groß genug ist.
Das Management und die Initiative selbst werden zu groß, um scheitern zu können, und infolgedessen wird eine Menge Geld verschwendet und es gehen massenhaft Chancen verloren – vor allem was die Zeit betrifft. Während die Initiative voranschreitet, geht Geld verloren, aber noch wichtiger: Zeit geht verloren – sechs Monate, ein Jahr, zwei Jahre. Der eigentliche Kostenfaktor ist die Zeit. Als eine Art anekdotischer Beleg für solche Fälle liest man sehr regelmäßig in der Presse, dass es bei ERP-Implementierungen zu Fehlschlägen im epischen Ausmaß kommt – Projekte, die fast ein Jahrzehnt oder manchmal fünf bis zehn Jahre andauern. Man fragt sich: Wie kann es ein fünfjähriges Projekt geben? Die Antwort lautet: Die Leute investieren ständig weiter in dieses Projekt, und es dauert buchstäblich Jahre und Jahre, bis man endlich zugibt, dass es ein kompletter Misserfolg war und niemals funktionieren würde.
Ein weiteres kleines Beispiel anekdotischer Evidenz ist, dass – wenn man intern Zeuge dieser mehrjährigen, epischen, gescheiterten ERP-Implementierungen wurde – häufig das Projekt eingestellt wird, nicht weil man sich einig ist, dass der Anbieter tatsächlich versagt hat. Vielmehr wird es so gehandhabt, dass irgendwann das obere Management, das ursprünglich an der Entscheidung beteiligt war, den Anbieter hinzuzuziehen, einfach zu anderen Unternehmen wechselt. Wenn im Grunde all jene Personen, die zunächst Teil der Entscheidung waren, den großen Anbieter einzubringen, das Unternehmen verlassen haben, stimmen die übrigen Leute, die sich diesem speziellen Anbieter nicht so verbunden fühlen, kollektiv darin überein, das Projekt einzustellen und es dabei zu belassen.
Was eine umgestaltete Lösung betrifft, glaube ich, dass Unternehmen toleranter gegenüber Misserfolgen sein müssen. Man muss hart mit Problemen, aber nachsichtig mit Menschen umgehen. Wenn Sie eine Kultur pflegen, in der Sie Sätze wie „Wir müssen es gleich beim ersten Mal richtig machen“ verwenden, ist das sehr schädlich, denn es bedeutet, dass Sie nicht weniger Misserfolge haben werden. Es ist ein Missverständnis des menschlichen Geistes und der menschlichen Natur zu glauben, dass, wenn man eine Kultur hat, die Misserfolge toleriert, tatsächlich mehr Misserfolge entstehen. Ja, es treten etwas mehr kleine Misserfolge auf, aber letztlich sorgt das dafür, dass die Menschen eher dazu neigen, Fehler zu erkennen und weiterzumachen. Umgekehrt führt eine Kultur des „Es muss gleich beim ersten Mal richtig sein“ dazu, dass im Grunde niemand sein Gesicht verlieren kann. Selbst wenn etwas völlig dysfunktional ist, besteht der Überlebensinstinkt der Beteiligten darin, sich noch intensiver in das, was nicht funktioniert, zu verbeißen – nur um ihr Gesicht zu wahren und möglicherweise zu einem anderen Unternehmen zu wechseln, damit sie sich nicht den Konsequenzen ihrer Fehler stellen müssen.
Um es zusammenzufassen: Es gibt positives Wissen versus negatives Wissen. Positives Wissen dreht sich im Wesentlichen darum, Probleme zu lösen; es ist eine Art Doktorandenintelligenz, eine Problemlösungskompetenz, bei der wir Rätsel haben und von einer Lösung zu einer besseren Lösung fortschreiten können. Es ist möglich zu beurteilen, dass eine Lösung besser ist als die andere, und der Höhepunkt dieser Denkweise besteht darin, eine optimale Lösung zu erreichen. Doch was die Menschen zu suchen glauben – optimale Lösungen, die vollkommen gültig und unsterblich sind – was sie stattdessen erhalten, sind sehr ephemere Lösungen.
Als Beispiel: Während der gesamten Lebensdauer von Lokad, meines Unternehmens, haben wir sechs Generationen von Prognose-Engines durchlaufen. Das positive Wissen ist insofern ephem, als dass dieses Wissen, diese Lösung, in Gefahr gerät, sobald etwas Besseres auftaucht – und man dieses Wissensfragment einfach verwirft. Bei Lokad haben wir seit unserem allerersten Beginn im Jahr 2008 die mühsame Übung durchlaufen, unsere eigene Prognosetechnologie von Grund auf neu zu schreiben. Deshalb sage ich, dass positives Wissen sehr flüchtig ist, weil es schnell obsolet wird, sobald neue, bessere Lösungen erscheinen.
Im Gegensatz dazu eröffnet negatives Wissen eine völlig andere Perspektive. Man denkt in Bezug auf absurde Fehltritte, und die Art von Intelligenz, die man erfassen möchte, ist die von Straßenschlauheit – die Art, die einem hilft, in einer gefährlichen Straße in der Nacht zu überleben. Dabei geht es weniger um Rätsel oder um Dinge, die sehr komplex zu verstehen sind und Transfer erfordern, sondern vielmehr um das, was man nicht weiß oder um Tabus. Es geht nicht darum, was fehlt, sondern darum, was einem nicht gesagt wird oder worüber die Leute sogar lügen, nur um ihr Gesicht zu wahren. Negatives Wissen bedeutet, gegen all diese Tabus anzukämpfen, die einen daran hindern, die Realität so zu sehen, wie sie ist.
Mit negativem Wissen ist die Denkweise nicht auf Fortschritt ausgerichtet; es ist eine Überlebensmentalität. Man will einfach überleben, um an einem anderen Tag weiterkämpfen zu können. Das ist eine völlig andere Perspektive, und genau so etwas suchen Unternehmen instinktiv, wenn sie einen sehr erfahrenen supply chain Director einstellen.
Abschließend würde ich sagen, dass negatives Wissen für alle schwierigen Probleme von größter Relevanz ist, wobei supply chain nur der Interessenschwerpunkt dieser Vorlesung ist, aber es ist nicht der einzige Bereich, in dem negatives Wissen angewendet werden kann.
Supply chain Anti-Patterns sind nur einige Beispiele, aber ich bin mir ziemlich sicher, dass Dutzende weitere identifiziert werden könnten, um die Probleme zu erfassen, die in realen supply chains immer wieder auftreten. Wir können nicht hoffen, alles durch Anti-Patterns abzubilden, aber ich glaube, dass wir einen ansehnlichen Teil erfassen können. Nachdem ich ein Buch über Software-Anti-Patterns gelesen hatte, war meine subjektive Meinung, dass ich in nur 200 Seiten das Äquivalent von fünf Jahren Erfahrung in der Softwareentwicklung gewonnen hatte. Meine Hoffnung ist, dass wir bei einer Sammlung von supply chain Anti-Patterns diesen Effekt ebenfalls replizieren können, sodass jemand in wesentlich kürzerer Zeit, vielleicht nur ein paar Wochen, etwa fünf Jahre an Erfahrung erwerben könnte.
Das war’s für diese Vorlesung. Die nächste Vorlesung wird sich mit der Lieferantenbewertung beschäftigen, was ein sehr interessantes Problem ist. Moderne supply chains leben oder sterben durch die Softwareprodukte, die sie unterstützen, und die Frage ist, wie wir über diese Softwareprodukte nachdenken und wie wir die richtigen Produkte und Anbieter auswählen. Trotz meines anteiligen Interessenkonflikts ist es ein interessantes Problem, und die Frage ist, wie wir eine Methodik entwickeln können, bei der selbst wenn alle Menschen Vorurteile haben, wir dennoch unvoreingenommene Ergebnisse erzielen können.
Nun werde ich die Fragen beantworten.
Question: What constitutes a good forecast in a probabilistic optimization setting, and how to measure the quality? Is there a role for manual enrichments?
Eine gute probabilistische Prognose verfügt über Kennzahlen zur probabilistischen Genauigkeit, aber das ist wahrscheinlich nicht das, worauf Sie achten. Im Rahmen einer experimentellen Optimierungsinitiative möchten Sie optimieren. Kennzahlen wie cross-entropy oder Likelihood gelten für probabilistische Prognosen. Noch wichtiger ist, dass es Dinge geben wird, die Sie allmählich entdecken, wenn Sie verrückte Entscheidungen identifizieren. Die Prognose ist nur ein Mittel zum Zweck, nämlich der Entscheidung. Sie müssen auf die Entscheidungen achten. Wir haben dies in der vorherigen Vorlesung über experimentelle Optimierung kurz angeschnitten. Der Prozess ist derselbe wie bei klassischen oder probabilistischen Prognosen. Wenn Sie reale Beispiele für probabilistische Prognosen wünschen, wird dies in den folgenden Vorlesungen ausführlich behandelt. Es tut mir leid, dass ich bei der Beantwortung dieser Frage etwas abschweife.
Question: What do you think of using AI (Appreciative Inquiry) to support your AI (Artificial Intelligence)? What techniques will you use to logically find out large data sets, and why are conversion rates decreasing despite good overall performance? What to tackle causing the activity?
AI, als Ansammlung von Algorithmen, basiert derzeit in erster Linie auf deep learning. Deep learning ist eine Sammlung von Techniken, die sehr gut in der Lage sind, mit hochgradig unstrukturierten Daten umzugehen. Die Frage, die Sie sich wirklich stellen sollten, ist, wie Sie das mit der Realität verbinden. In supply chain neigen die Daten dazu, sehr spärlich zu sein. Die meisten Produkte in einem beliebigen Geschäft werden an weniger als einer Einheit pro Tag verkauft. Große Datensätze sind insgesamt nur groß, wenn man ein sehr großes Unternehmen mit tonnenweise Transaktionen betrachtet. Betrachtet man die Granularitäten, die wirklich zählen, hat man nicht so viele Daten.
Appreciative Inquiry, was methodische Ansätze betrifft, bezieht sich im Wesentlichen auf die in der vorherigen Vorlesung diskutierte experimentelle Optimierung.
Question: Many managers don’t understand the power of data science, and giving fictitious problems for them is a safe path. If they don’t want to dig into learning about data science, what is an alternative way to make them believe in data science and decision-first approaches? How to start small and roll out big?
Zunächst, wenn Sie Menschen haben, die nicht an eine bestimmte Technologie glauben, ist das vollkommen in Ordnung. Nehmen Sie zum Beispiel Warren Buffett. Er ist ein sehr reicher Investor, der sein Leben damit verbracht hat, in Unternehmen zu investieren, die er versteht. Er investiert in Unternehmen mit einfachen Geschäftsmodellen, wie Eisenbahntransportunternehmen oder Möbelvermietungsfirmen. Warren Buffett sagte: “I’m not interested in understanding all those technologies.” Zum Beispiel, als man ihn fragte, warum er nicht in Google investierte, antwortete Buffett: “I don’t understand anything about what Google is doing, so while it may be a good investment, I’m not smart enough for that. I’m just going to invest in companies that I understand.”
Mein Punkt ist, dass es für das Management eine völlige Illusion ist, sich in Bereiche zu wagen, die man nicht versteht. Irgendwann, wenn man nicht bereit ist, die nötige Anstrengung zu unternehmen, wird es einfach nicht funktionieren. Das ist das Jedi-Anti-Pattern, das hier am Werk ist – das Management ist nicht bereit, jegliche Mühe auf sich zu nehmen, und sie denken, dass das Einstellen von smarten, jungen, intelligenten Ingenieuren den Trick schon erledigt. Wäre das der Fall, hätte Amazon nicht den Erfolg gehabt, den es hatte. Wäre es einem traditionellen retail chain Unternehmen möglich, einfach ein paar Ingenieure einzustellen, um eine E-Commerce-Website zu starten und mit Amazon zu konkurrieren, hätten das alle getan. Bis etwa 2005 verfügten diese Unternehmen über deutlich mehr Ingenieurressourcen und -fähigkeiten als Amazon selbst.
Das Problem ist, dass es eine Illusion ist, und genau darum geht es beim negativen Wissen – es wirft ein Licht auf die Art von Problemen, die allgegenwärtig sind. Deshalb braucht man einen eingängigen Titel, um das Problem den Managern zu kommunizieren. Man sollte sich auch nicht davor scheuen, Neues zu lernen. Wenn man wirklich den guten Teil der neuen Technologie übernimmt, ist es meist gar nicht so kompliziert. Nicht alles ist super technisch; viele Teile ließen sich erklären. Zum Beispiel könnten selbst angeblich hochentwickelte Blockchain-Technologien – die Hälfte davon – einem Zehnjährigen erklärt werden. Viele der dahinterstehenden Ideen sind tatsächlich recht simpel. Es gibt Unmengen an zufälligen mathematischen technischen Feinheiten, die sehr schwierig sind, aber das ist nicht das Wesentliche des Problems.
Meine Antwort an Sie wäre also: Wenn das Management an Märchen glauben will, gibt es in dieser Situation nicht viel, das man tun kann. Wenn das Management bereit ist, in Data Science zu investieren, sollte es auch bereit sein, ein wenig Zeit zu investieren, um zu verstehen, worum es bei Data Science geht. Andernfalls ist es einfach wahnhaft.
Das war’s für heute. Vielen Dank, und die nächste Vorlesung findet am gleichen Tag, Mittwoch, in zwei Wochen zur gleichen Zeit statt. Bis dann.
References
- ‘‘AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis’’. y William J. Brown, Raphael C. Malveau, Hays W. “Skip” McCormick, Thomas J. Mowbray, 1998
