Software Engineering für die Supply Chain - Vorlesung 4.6

00:02 Einführung
01:43 Mechanisierung
07:34 Jenseits des Paradoxons
12:14 Der bisherige Verlauf
14:32 Die heutigen Teilmodule
16:24 Anforderungen (Hauptströmung 1/5)
20:12 Design (Hauptströmung 2/5)
25:37 Konstruktion (Hauptströmung 3/5)
30:29 Testen (Hauptströmung 4/5)
34:09 Wartung (Hauptströmung 5/5)
41:12 Identität (Schützengraben 1/8)
46:35 Lebenslauf (Schützengraben 2/8)
51:43 Praktiken (Schützengraben 3/8)
56:47 Bastionen (Schützengraben 4/8)
01:02:00 Code-Schreiber (Schützengraben 5/8)
01:06:23 Schmerztoleranz (Schützengraben 6/8)
01:14:55 Produktivität (Schützengraben 7/8)
01:21:37 Das Unbekannte (Schützengraben 8/8)
01:27:00 Fazit
01:29:55 4.6 Software Engineering für die Supply Chain - Fragen?

Beschreibung

Die Beherrschung von Komplexität und Chaos ist das Fundament des Software Engineerings. Angesichts der Tatsache, dass Lieferketten sowohl komplex als auch chaotisch sind, sollte es nicht überraschen, dass die meisten Probleme mit Unternehmenssoftware, mit denen Lieferketten konfrontiert sind, auf schlechtem Software Engineering beruhen. Numerische Rezepte, die zur Optimierung von Lieferketten verwendet werden, sind Software und unterliegen daher genau demselben Problem. Diese Probleme nehmen mit der Komplexität der numerischen Rezepte selbst zu. Gutes Software Engineering ist für Lieferketten das, was Asepsis für Krankenhäuser ist: Es allein bewirkt nichts - wie die Behandlung von Patienten - aber ohne es fällt alles auseinander.

Vollständiges Transkript

Willkommen zu dieser Reihe von Lieferketten-Vorlesungen. Ich bin Joannes Vermorel und heute werde ich “Software Engineering für die Supply Chain” präsentieren. Software ist das Fundament einer modernen Lieferkettenpraxis, doch die meisten Lieferketten-Lehrbücher unterschätzen die Rolle von Software in der Lieferkette erheblich. Software für die Lieferkette ist nicht nur eine einfache Anforderung wie der Zugang zu Transportmitteln; sie ist viel mehr als das. Aus der Sicht von Lieferketten-Praktikern wird die meiste Arbeit von Software angetrieben, sei es durch Softwarefehler oder die Einschränkungen von Software oder durch softwarebezogene Anliegen.

Software Engineering ist die Disziplin, die sich zum Ziel gesetzt hat, den Menschen dabei zu helfen, bessere Software zu entwickeln, mehr aus der Software herauszuholen, diese Software schneller zu entwickeln und weniger dafür aufzuwenden, um mehr zu erreichen. Das Ziel dieser Vorlesung ist es, zu verstehen, worum es beim Software Engineering geht, und seine herausragende Bedeutung für die Lieferkette zu verstehen. Das Ziel dieser Vorlesung ist auch zu verstehen, was Sie als Lieferketten-Praktiker tun können, um Ihre Lieferkette entweder durch Handlungen oder Untätigkeit zu verhindern, die leider Ihre Software-Projekte behindert haben.

Das 20. Jahrhundert war das Jahrhundert der Mechanisierung der Arbeitskräfte. Große Unternehmen und große Lieferketten, wie wir sie kennen, sind im 20. Jahrhundert entstanden, und der Fortschritt, der durch die Mechanisierung der Arbeitskräfte erzielt wurde, war unglaublich. Im Laufe des letzten Jahrhunderts hat sich die Produktivität für nahezu jede arbeitsintensive Aufgabe, die für die Lieferkette relevant ist, wie Produktion oder Distribution, um das Hundertfache erhöht.

Im Gegensatz dazu glaube ich, dass das 21. Jahrhundert das Jahrhundert der Mechanisierung intellektueller Arbeit ist und sein wird, und dieser Übergang ist sehr schwer zu erfassen. Die Art von Intuition, die wir haben, wenn wir von der Mechanisierung der physischen Arbeitskräfte ausgehen, überträgt sich überhaupt nicht auf die Art von Intuition, die wir haben, wenn wir zur Mechanisierung intellektueller Arbeit übergehen. Ich sage nicht, dass der Übergang weniger dramatisch ist, aber die Realität ist, dass zu diesem Zeitpunkt der Übergang zur Beseitigung der Arbeitskräfte, die sich mit sehr arbeitsintensiven Aufgaben befassen, bereits hinter uns liegt.

Im Jahr 2020 gab es in Frankreich 27 Millionen Menschen mit Bürojobs - im Wesentlichen Büroangestellte - während weniger als eine Million Menschen übrig waren, die Fabrikarbeiter waren. Das Verhältnis beträgt 27 zu 1. Wenn wir uns anschauen, was die Mechanisierung intellektueller Arbeit bedeutet, ist es sehr überraschend und steht auch in engem Zusammenhang mit einem Paradoxon, das als Moravec-Paradoxon bekannt ist.

Hans Moravec, ein Informatiker, bemerkte 1980, dass die Aufgaben, die für den menschlichen Verstand am schwierigsten schienen, wie zum Beispiel das Erlangen des Titels eines Schachgroßmeisters, tatsächlich die Arten von Aufgaben waren, die am einfachsten mit Computern zu bewältigen waren. Im Gegensatz dazu erweisen sich Aufgaben, die für Menschen extrem einfach erscheinen, wie das auf zwei Beinen stehen, als unglaublich herausfordernd für Computer. Das ist das Wesen des Moravec-Paradoxons: Unsere Intuition darüber, was in Bezug auf intellektuelle Aufgaben mit Computern schwer zu erreichen ist, ist sehr irreführend.

Etwas, das das Problem weiter kompliziert, ist, dass plötzlich, wenn wir über die Automatisierung von Büroangestellten sprechen, dies von den Büroangestellten selbst durchgeführt wird. Dies war nicht der Fall bei Fabrikarbeitern; sie waren nicht diejenigen, die entschieden haben, dass die Fabrik weiter mechanisiert wird und ihre Arbeitsplätze beseitigt werden. Doch genau das passiert bei Bürojobs. Somit haben wir eine Herausforderung, bei der der Mechanisierungsprozess nicht nur aufgrund des Moravec-Paradoxons sehr gegenintuitiv ist, sondern auch das Management der Personen, die für die Umsetzung dieser Mechanisierung zuständig sind, nämlich Software-Ingenieure, selbst sehr gegenintuitiv ist. Dies ist wahrscheinlich eine der größten Herausforderungen für die Lieferkette: das Management der Personen, die auf die eine oder andere Weise mit dieser Mechanisierung umgehen werden.

Hier muss ich jedoch darauf hinweisen, dass viele Lieferketten und damit verbundene Unternehmen immer noch fest in einer Denkweise des 20. Jahrhunderts verankert sind, in der Sie die Unternehmenswelt so angehen, als hätten Sie Büroangestellte, die die intellektuelle Arbeit erledigen, und dann kommen sie mit der Lösung oder dem Plan, der an Fabrikarbeiter zur Ausführung übergeben wird. Bei einem Verhältnis von 27 Personen zu einer Person bei Bürojobs im Vergleich zu Fabrikjobs in Frankreich und wahrscheinlich ähnlichen Statistiken in den meisten entwickelten Ländern läuft es jedoch nicht mehr so ab. Es geht buchstäblich darum, Ihre eigene Arbeit zu automatisieren, und das bedeutet, dass in dieser Welt des 21. Jahrhunderts die allerbesten Büroangestellten diejenigen sind, die es ständig schaffen, sich selbst zu automatisieren, sich überflüssig zu machen und dann zu etwas anderem überzugehen. Das ist sehr herausfordernd für viele Unternehmen, die immer noch sehr stark in der Denkweise des 20. Jahrhunderts verwurzelt sind.

Meinungen über den Begriff der Softwaretechnik gehen weit auseinander. Eine der stärksten Kritiken kam von Edsger Dijkstra, einem der Gründungsväter der Informatik. Seiner Ansicht nach ist Softwaretechnik nicht einmal als Disziplin oder Forschungsfeld möglich, und er sagte, dass es im Grunde genommen darauf hinausläuft oder sich zu einer Art “Wie man programmiert, wenn man es nicht kann” -Rezept entwickelt. Die Kritik von Dijkstra, die sehr interessant ist, besagt, dass Softwaretechnik zu einer Art Selbsthilfe-Fiktion wird, die unmöglich erfolgreich sein kann. Tatsächlich ist es, wenn wir vorschlagen, dass das Ziel der Softwaretechnik darin besteht, den Erfolg bei der Erstellung nützlicher, überlegener Software sicherzustellen, größtenteils zum Scheitern verurteilt. Erfolg in der Software ist unglaublich schwierig; er ist genauso schwierig wie Erfolg in der Wissenschaft. Es erfordert einen Funken Genialität, ziemlich viel Glück, und dafür gibt es kein Rezept. Darüber hinaus neigt jeder einzelne Erfolg dazu, die Möglichkeit, die er benötigt hat, um diesen Erfolg zu erzielen, zu verbrauchen, und somit wird das Ganze nicht replizierbar.

Ich bin jedoch anderer Meinung als die Vision, dass die Softwaretechnik zum Scheitern verurteilt ist. Ich glaube, das Hauptproblem besteht darin, den Anspruch der Softwaretechnik zu definieren. Wenn wir beschließen, dass der Anspruch der Softwaretechnik darin besteht, erfolgreich Software zu erstellen, dann ist sie tatsächlich zum Scheitern verurteilt. Wenn wir jedoch die Softwaretechnik als einen engen Teilbereich der experimentellen Psychologie betrachten, glaube ich, dass wir durch diesen Blickwinkel sehr wertvolle und umsetzbare Erkenntnisse gewinnen können, und das ist die Perspektive, die ich heute in diesem Vortrag einnehmen werde. Daher geht es bei der Softwaretechnik um die Softwareingenieure selbst und ihre Interaktionen. Die Konzentration auf Softwareingenieure ist ein guter Ausgangspunkt, da die menschliche Natur im Laufe der Zeit stabil ist, im Gegensatz zur Softwaretechnologie, die sich ständig ändert. Die Natur der Menschen, die mit dieser Technologie kämpfen, ist es nicht; die menschliche Natur ist seit langem sehr stabil.

Wenn wir uns andere Bereiche wie die Wissenschaft ansehen, können wir sehen, dass es sehr fruchtbar sein kann, einen Bereich durch die Linse der Inspektion dessen zu betrachten, was seine Praktiker tun. Zum Beispiel ist es in der Wissenschaft mittlerweile weitgehend anerkannt, dass ein Interessenkonflikt zu schlechter Wissenschaft und einer Verfälschung des Wissens führt. Dieser Punkt wurde bereits in dem Vortrag mit dem Titel “Adversarial Market Research for Enterprise Software” behandelt. Aus dieser Perspektive sehen wir, dass es möglich ist, Erkenntnisse von weitreichender Anwendbarkeit und Relevanz zu gewinnen, wenn wir uns auf die Praktiker selbst konzentrieren. Daher geht es bei der Softwaretechnik um die Menschen, die sich mit Softwaretechnologie befassen, ihre Herausforderungen und ihre Prozesse und nicht so sehr um die Technologie selbst.

Heute ist der sechste Vortrag der vier Kapitel. Dieses Kapitel ist den Hilfswissenschaften der Lieferkette gewidmet. Diese Hilfswissenschaften stellen Elemente dar, die ich für von grundlegender Bedeutung für eine moderne Lieferkettenpraxis halte, aber sie sind streng genommen keine Elemente der Lieferkette. Sie sind eher unterstützende Elemente für Ihre Lieferkettenpraxis.

Bisher haben wir in diesem vierten Kapitel mit der Physik der Berechnung begonnen, die sich mit modernen Computern befasst, und sind dann über eine Leiter der Abstraktionen nach oben gewandert. Wir sind von Computern zu Algorithmen gewechselt, die die winzigsten, kleinsten interessanten Bits in der Software darstellen. Dann sind wir zur mathematischen Optimierung übergegangen, die für die Lieferkette von Interesse ist, aber auch für viele andere relevante Softwareprojekte, wie maschinelles Lernen. Wir haben gesehen, dass mathematische Optimierung direkt für die Lieferkette interessant ist, aber auch direkt für maschinelles Lernen, das wiederum auch für die Lieferkette von Interesse ist.

Was die mathematische Optimierung und das maschinelle Lernen betrifft, so handelt es sich bei den meisten interessanten Konzepten und Paradigmen heutzutage um programmatische Natur. Es handelt sich nicht nur um einfache Algorithmen; es ist etwas unglaublich Ausdrucksstarkes und muss durch die Linse von Programmiersprachen angegangen werden. Deshalb ging es im letzten Vortrag um Sprachen und Compiler.

Heute bewegen wir uns immer noch auf dieser Leiter der Abstraktion nach oben und konzentrieren uns auf die Menschen anstatt auf das, was sie tun. Wir werden uns auf die Softwareingenieure selbst konzentrieren, und das ist der ganze Sinn dieser Software Engineering Analyse.

Heute werde ich speziell zwei Sichtweisen zum Software Engineering präsentieren. Zunächst werde ich die Mainstream-Sichtweise präsentieren, die meiner Meinung nach das Feld dominiert. Leider hat diese Mainstream-Sichtweise Kritik hervorgerufen, wie bereits erwähnt, und es gibt Leute, die Selbsthilfeansätze präsentieren, die einige, einschließlich mir selbst, aus Gründen ablehnen, weil sie keine realistischen Ambitionen für die Disziplin des Software Engineering darstellen. Trotzdem werde ich diese Mainstream-Sichtweise untersuchen, wenn auch nur, weil einige fehlgeleitete Einsichten immer noch unglaublich beliebt sind. Mit diesen fehlgeleiteten Konzepten vertraut zu sein, ist von größter Bedeutung, wenn es darum geht, inkompetente Personen ausfindig zu machen, die Ihre Lieferkette durch ihre Inkompetenz gefährden könnten.

Dann werde ich mich einer Sichtweise aus der Praxis zuwenden, die eine Sammlung von Elementen ist, die in meiner persönlichen Erfahrung als CEO eines Softwareunternehmens verwurzelt sind, das genau im Bereich der Unternehmenssoftware für die Lieferkette tätig ist. Wie wir sehen werden, geht es bei den Erkenntnissen sehr stark um die Menschen und nicht wirklich um die Technologie selbst.

Die Mainstream-Sichtweise des Software Engineering besagt, dass eine Softwareinitiative mit der Erfassung der Anforderungen für die interessierende Software beginnt. Die meisten Softwareinitiativen in großen Unternehmen übernehmen diese Perspektive durch einen Prozess, der in der Regel mit einer Angebotsaufforderung (RFP), einer Angebotsanfrage (RFQ) oder einer Informationsanfrage (RFI) beginnt. Dieser Ansatz stammt aus den Praktiken des 20. Jahrhunderts, die in der Maschinenbau- und Bauindustrie sehr erfolgreich waren. Ich glaube jedoch, dass diese Ansätze zur Erfassung von Anforderungen im Bereich der Software tiefgreifend fehlgeleitet sind.

Bei Software weiß man nicht, was man will; das weiß man einfach nicht. Zu wissen, was man will, ist in der Regel der schwierigste Teil der Software. Wenn wir zum Beispiel ein einfaches Problem wie die Lagerauffüllung betrachten, ist die Problemstellung unglaublich einfach: Zu jedem Zeitpunkt möchte ich die Menge wissen, die ich für jeden einzelnen Lagerhaltungseinheit (SKU) auffüllen oder nachbestellen sollte. Das Problem selbst ist einfach, aber die Definition dessen, was eine gute Menge ist, wird teuflisch komplex und schwierig. Als Faustregel gilt: Die Klärung der Anforderungen ist weitaus schwieriger als das Schreiben der Software selbst.

Es ist nur durch den Abgleich Ihrer Intuition mit dem Feedback der realen Welt möglich, dass die Anforderungen nach und nach entstehen können. Die Anforderungen fallen nicht vom Himmel; sie können nur durch einen ziemlich experimentellen Prozess gewonnen werden, und Sie müssen diese Interaktion mit der realen Welt haben. Die einzige Möglichkeit, diese Interaktion zu haben, besteht jedoch darin, das Softwareprodukt zu haben, da die Erfassung von Anforderungen grundsätzlich ein sehr empirischer und aufkommender Prozess ist. Das Problem ist, dass Sie, wenn Sie mit den Anforderungen fertig sind, die Anforderungen irrelevant werden, denn wenn Sie die Anforderungen haben, bedeutet das, dass Sie bereits das entsprechende Produkt haben, das diese Anforderungen umsetzt. Also, wenn Sie Zugang zu den richtigen Anforderungen haben, haben Sie das Produkt bereits in Produktion, in Betrieb und die Tatsache, dass Sie diese Anforderungen haben, ist irgendwie irrelevant.

Daher ist der Punkt, dass der Prozess mit dem Blick auf die Anforderungen zu beginnen, meiner Meinung nach Wahnsinn ist. Anforderungen sollten wahrscheinlich als späte Dokumentation am Ende kommen, in der Sie alle Hauptgründe dokumentieren, die Sie dazu veranlasst haben, das Produkt so zu implementieren, wie Sie es getan haben, und nicht umgekehrt.

Sobald die Anforderungen festgelegt sind, besagt der klassische Ansatz, dass man mit der Designphase fortfahren muss. Ich stimme zu, dass an einem gewissen Punkt ein gewisses Design erfolgen kann. Die Art des Denkens, das in diese Designphase einfließt, ist jedoch häufig fehlgeleitet. Das Problem besteht darin, die Kosten für Änderungen unter Kontrolle zu halten. Die klassische nicht-softwarebezogene Perspektive auf die Kosten für Änderungen besagt, dass die Kosten im Laufe der Zeit exponentiell steigen. Wenn Sie beispielsweise das Design eines Autos sehr früh ändern, wenn Sie nur mit einer Blaupause arbeiten, sind die Kosten für Änderungen minimal. Wenn Sie jedoch warten, bis Millionen dieser Autos auf den Straßen sind, sind die Kosten für Änderungen unglaublich hoch, da dies eine Rückrufaktion impliziert, die unglaublich teuer sein kann.

Im Gegensatz zur physischen Welt steigen die Kosten für Änderungen in der Softwarewelt nicht natürlicherweise exponentiell an. Die Kostensteigerung kann nicht vollständig gemildert werden; jedoch kann die Kostensteigerung weitgehend verwaltet werden. Tatsächlich steigen die Kosten für Änderungen im Laufe der Zeit, hauptsächlich weil Codebasen tendenziell im Laufe der Zeit wachsen. Ich habe noch nie gesehen, dass der Code einer Unternehmenssoftware von einem Jahr zum nächsten signifikant schrumpft; sie neigen dazu, weiter zu wachsen. Dennoch ist es möglich, die Kosten für Änderungen in gewissem Maße zu verwalten.

Heutzutage wird dieser Aspekt auch in Softwarekreisen immer mehr anerkannt. Übrigens ist dies das Wesentliche der agilen Methodik. Sie haben diese Begriffe vielleicht schon gehört, wenn Leute sagen: “Oh, wir haben diese agile Softwaremethodik.” Eines der größten Ziele der agilen Methodik ist es, die Kosten für Änderungen unter Kontrolle zu bringen. Ich werde heute nicht ins Detail gehen, wie genau die agile Methodik funktioniert, aber ich glaube, dass dieser Ansatz etwas fehlgeleitet ist, wenn es darum geht, wie genau Sie diese Kosten für Änderungen unter Kontrolle bringen.

Ich habe festgestellt, dass die Kosten für Änderungen hauptsächlich von den Entscheidungen herrühren, die über die Software getroffen werden und genauer gesagt davon, dass es sehr schwierig ist, dem Drang, Entscheidungen zu treffen, zu widerstehen. Stellen Sie sich vor, Sie betrachten ein potenzielles zukünftiges Softwareprodukt und es gibt viele Entscheidungen, die getroffen werden müssen. Der frühe Versuch wäre, diese Entscheidungen zu treffen, um zu klären, was Sie vor sich haben. Im Gegenteil, eine sehr gute Designphase, anstatt ein gutes Design, besteht darin, alle Entscheidungen zu verschieben, die nicht unbedingt erforderlich sind, bei denen das Produkt diese Entscheidungen jetzt nicht erfordert. Tatsächlich schwebt die Entscheidung noch in der Luft und kann geändert werden, solange die Entscheidung nicht getroffen wurde und Sie nicht festgestellt haben, dass Sie diesen bestimmten Designansatz oder technologischen Ansatz wählen müssen.

Eine der Möglichkeiten, die Kosten für Änderungen unter Kontrolle zu halten, besteht darin, alle Entscheidungen so weit wie praktisch möglich zu verschieben. Aus Sicht der Supply Chain sieht dies sehr seltsam aus, denn es bedeutet, dass es für alle Personen im Softwareteam und alle Personen, die das Produkt und das Softwareteam beobachten, so aussieht, als ob sie im Dunkeln gehalten werden. Es ist noch schlimmer, denn sie werden absichtlich im Dunkeln gehalten, was sehr verwirrend ist. Dennoch ist es genau das, was geschehen muss, und es muss absichtlich geschehen. Deshalb ist es, gelinde gesagt, beunruhigend.

Wenn vorzeitige Designentscheidungen in dem manchmal fehlgeleiteten Bedürfnis nach Kontrolle verwurzelt sind, hören die Probleme, die mit diesem Bedürfnis nach Kontrolle verbunden sind, nicht auf. Sobald die Designphase abgeschlossen ist, besagt die gängige Sichtweise auf Softwaretechnik, dass wir mit der Erstellung der Software, die auch häufig als Implementierungsphase bezeichnet wird, fortfahren sollten. Die Art und Weise, wie dies typischerweise geschieht, besteht darin, eine Art Wasserfallprojektion vorzustellen, die auch als Gantt-Diagramme bezeichnet wird. Dies ist das, was Sie auf dem Bildschirm sehen können. Ich glaube, dass dieser Ansatz, Gantt-Diagramme und Wasserfälle, unglaublich giftig ist und die Toxizität dieses Ansatzes im Hinblick auf Software nicht unterschätzt werden sollte. Das Problem auf diese Weise anzugehen, bedeutet buchstäblich, Ihre Supply Chain zum Scheitern zu verurteilen, zumindest was ihre Softwareinitiativen betrifft.

Ein viel besserer Weg, das Problem zu verstehen und die Erstellung der Software anzugehen, besteht darin, sie als Lernprozess zu betrachten. Die Erstellung der Software besteht darin, alles zu lernen, was nötig ist, um ein gutes Produkt zu erhalten. Dies ist ein Lernprozess, und all diese erlernten Teile sind ein Nebenprodukt davon, dass die Welt mit der Software interagiert, die aus dem Erstellungsprozess entsteht. Das Hauptproblem bei einer Wasserfallprognose besteht darin, dass Sie projizieren, was Sie gerade entdecken werden. Dies ist per Definition einfach nicht möglich. Was Sie gerade entdecken werden, war bis zu diesem Zeitpunkt unbekannt. Sie können Ihre Entdeckungen nicht vorhersagen. Sie können sie erwarten, aber Sie können nicht die Details dessen planen, was Sie gerade entdecken werden. Sie können Vermutungen haben, aber das ist das Beste, was Sie bekommen können. Die Vorstellung, dass Sie diese vagen Intuitionen in eine präzise Wasserfallprognose umwandeln können, ist wiederum völliger Wahnsinn.

Übrigens erklärt dieses scheinbare Paradoxon über die Erstellung von Software als Lernprozess auch, warum das Reproduzieren eines Softwareprodukts manchmal unglaublich einfach oder unglaublich schwierig sein kann. Wenn ein Team versucht, ein bereits auf dem Markt befindliches Softwareprodukt zu reproduzieren und dieses Team Zugang zu dem Verständnis oder den Erkenntnissen hat, die zur Produktion der Software geführt haben, dann kann das Reproduzieren des Softwareprodukts - das erneute Implementieren oder Neucodieren - in der Regel mit nur einem winzigen Bruchteil der Zeit und des Budgets erfolgen, die für die Erstellung der Software benötigt wurden. Im Gegensatz dazu wird das Team, wenn es keinen Zugang zu diesen hochrangigen Erkenntnissen hat und zum Beispiel nur Zugang zum Quellcode hat, sehr häufig ein Produkt von sehr geringer Qualität erhalten, weil im Wesentlichen alle Lernbestandteile oder Wissenshäppchen verloren gegangen sind. Sie haben nur das äußere Erscheinungsbild des Produkts repliziert.

Aus der Perspektive der Supply Chain besteht die größte Herausforderung hier darin, Ihren Kontrollbedarf bewusst aufzugeben und zu zähmen. Der Wasserfallprozess ist ein Ausdruck eines Unternehmens, das den Prozess kontrollieren möchte. Wenn ich zum Beispiel sage: “Lassen Sie uns dieses Projekt unter Kontrolle bringen”, würde das als etwas sehr Vernünftiges angesehen werden. Warum sollten Sie das Gegenteil tun? Warum würden Sie zum Beispiel sagen: “Lassen Sie uns dieses Projekt völlig außer Kontrolle geraten?” Aber die Realität ist, dass dieses Maß an Kontrolle in Bezug auf Software eine vollständige Täuschung ist und Ihre Fähigkeit, am Ende ein qualitativ hochwertiges Produkt zu liefern, vollständig beeinträchtigt. Den Wunsch nach Kontrolle zu zähmen, ist aus Sicht der Supply Chain wahrscheinlich die größte Herausforderung bei der Erstellung von Software.

Seit dem Aufkommen von Computerprogrammen sind sie von Fehlern und Defekten geplagt. Um diese offensichtlichen Probleme anzugehen, ist die gängige Meinung, dass Tests durchgeführt werden müssen. Tests nehmen viele Formen an. In Bezug auf den Bedarf an Tests stimme ich zu, obwohl dies zu diesem Zeitpunkt sehr vage ist. Einige Tools betonen, dass Tests nach der Erstellung durchgeführt werden müssen, andere betonen, dass Tests während der Erstellung durchgeführt werden müssen, und wieder andere geben an, dass Tests vor der Erstellung durchgeführt werden müssen. Einige Ansätze besagen, dass Tests vor, während und nach der Erstellung der Software durchgeführt werden müssen.

Meine generelle Ansicht zu diesem Problem ist, dass Sie alles tun sollten, um die Rückkopplungsschleife so kurz wie möglich zu halten. Wir haben diesen Punkt in der vorherigen Vorlesung diskutiert: Die Rückkopplungsschleife so kurz wie möglich zu halten, ist von entscheidender Bedeutung, um tatsächlich etwas zu bekommen, das in der realen Welt funktioniert. Daher würde ich in der Regel empfehlen, darauf zu achten, ob das, was Sie in Bezug auf Tests tun, diese Rückkopplungsschleife tatsächlich verkürzt oder nicht. Zum Beispiel würde ich für die meisten Situationen nicht natürlicherweise die testgetriebene Entwicklung empfehlen (eine Methode, die besagt, dass zuerst getestet wird), einfach weil das Testen zuerst für die meisten Situationen nur die Zeit verzögern würde, die benötigt wird, um Feedback zu Ihrem Softwarestück von der Welt im Allgemeinen zu erhalten.

Meine größte Sorge beim Testen ist jedoch eine unerwähnte Einschränkung, etwas, das anscheinend allgemein abgetan wird. Tests können letztendlich nur die Einhaltung der Regeln bewerten, die Sie selbst festgelegt haben. Das Problem ist, dass es in der Software keine harten Einschränkungen gibt. Es gibt keine chemische Möglichkeit, die Angemessenheit Ihres Produkts in Bezug auf das Problem, das Sie lösen möchten, zu bewerten. Dies ist sehr anders als in der physischen Welt. Zum Beispiel gibt es in der Maschinenbau eine kanonische Kriterium: die Maßtoleranz eines Teils. Was auch immer Sie im Maschinenbau entwickeln, die Maßtoleranz wird von vorrangiger Bedeutung sein. Es ist ein offensichtlicher und natürlicher Kandidat. In der Software gibt es jedoch keine solchen natürlichen und offensichtlichen Kandidaten.

Das Problem hier wird zu einer Frage der Angemessenheit. Wenn wir ein Beispiel aus der Supply Chain nehmen, wie zum Beispiel Sicherheitsbestände, ist es völlig unkompliziert, eine automatisierte Test-Suite zu entwerfen, um die Berechnung der Sicherheitsbestände zu validieren. Es ist sehr einfach, diese Art von Testlogik zu implementieren. Dies kann Ihnen jedoch nicht sagen, dass Sicherheitsbestände an sich eine schlechte Idee sind. Sie testen nur das, was Sie wissen.

Wenn wir es mit einer physischen Maschine zu tun haben, erwarten wir Verschleiß und somit erwarten wir eine Art von Wartung, um die Maschine in Betriebszustand zu halten. Warum sollte Software jedoch irgendeine Art von Wartung benötigen, um weiterhin zu funktionieren? Sicherlich müssen wir Computer gelegentlich ersetzen, wenn sie im Laufe der Zeit ausfallen. Dieser Aspekt ist jedoch sehr marginal, und bei Unternehmenssoftware machen die physischen Ausfälle von Maschinen nicht einmal 10% der tatsächlichen Wartungskosten aus. Dies existiert, aber die Auswirkungen dieser Art von Wartung sind äußerst gering.

Dennoch ist die Wartung in der Unternehmenssoftware von vorrangiger Bedeutung. Die Wartungskosten sind enorm. Für viele Anbieter von Unternehmenssoftware machen die Wartungskosten buchstäblich 80% oder mehr der Entwicklungskosten aus. Es stellt sich heraus, dass die Faktoren, die diesen Wartungsbedarf generieren, sehr wenig mit Physik zu tun haben. Der erste Faktor ist die Zahlungsbereitschaft der Kunden selbst. Wenn ein Anbieter mit einer jährlichen Wartungsgebühr von 20% im Vergleich zu dem, was im ersten Jahr für die Einrichtung der Software bezahlt wurde, davonkommen kann, wird der Softwareanbieter das berechnen. Aus Kostensicht wird der Wartungsaufwand durch die Zahlungsbereitschaft der Unternehmenskunden bestimmt.

Der zweite Faktor ist die Art der Wartung, die einfach durchgeführt werden muss, um die Software am Laufen zu halten. Tatsächlich entfernt sich die Umgebung, die das Interessensprodukt umgibt, für jeden einzelnen Tag, der vergeht, von dem Produkt. Das Betriebssystem entwickelt sich weiter, das Datenbanksystem entwickelt sich weiter, und das Gleiche gilt für alle Drittanbieter-Bibliotheken, die von der Software verwendet werden. Kein Softwareprodukt ist eine Insel. Jedes einzelne Softwareprodukt hängt von einer Vielzahl anderer Softwareprodukte ab, und diese anderen Produkte entwickeln sich von selbst weiter. Die Menschen, die diese Softwareprodukte entwickeln, arbeiten weiter daran und verändern sie, während sie an diesen Produkten arbeiten. Es kommt also ein Zeitpunkt, an dem das Produkt einfach aufhört zu funktionieren, weil es eine Inkompatibilität gibt. Sie haben nichts getan außer nicht mit dem Rest des Marktes Schritt zu halten. Der zweite Faktor ist all die Wartung, die durchgeführt werden muss, um die Software am Laufen zu halten und mit dem Rest des Marktes kompatibel zu machen.

Der dritte Faktor ist der Aufwand, der erforderlich ist, um das Produkt nützlich zu halten. Tatsächlich wurde die Software zu einem bestimmten Zeitpunkt entworfen und entwickelt, und jeden einzelnen Tag, der vergeht, entfernt sich die Welt von dem, was zum Zeitpunkt der Entwicklung des Produkts gesehen wurde. Selbst wenn in Bezug auf die Hardwarekompatibilität nichts wirklich kaputt geht, stellt sich heraus, dass sich mit der Zeit die Nützlichkeit des Produkts verringert, weil sich die Welt einfach von den in das Produkt eingebauten Erwartungen entfernt. Wenn Sie die Software nützlich halten möchten, müssen Sie die Software ständig warten.

Aus der Perspektive der Lieferkette ist die Wartung eine große Herausforderung, und wir haben dieses Thema bereits in der vorherigen Vorlesung angesprochen, die sich mit der produktorientierten Lieferung für die Lieferkette befasste. Die Kosten für die Wartung beeinflussen signifikant die kapitalistischen Vorteile, die Sie von Ihrem Softwareprojekt haben können. Idealerweise möchten Sie, dass Ihr Softwareprojekt eine sehr hohe Rendite erzielt, aber um das zu erreichen, müssen Sie sicherstellen, dass Sie nicht mit massiven Wartungskosten enden. Diese Kosten werden den kapitalistischen Gewinn und die Rendite, die Sie aus Ihrer Softwareinvestition erzielen können, vollständig zunichte machen.

Die größte Herausforderung hierbei, wieder aus der Perspektive der Lieferkette, besteht darin, den Wartungsaufwand zu minimieren, indem man sich auf das konzentriert, was sich nicht ändert. Wie ich bereits erwähnt habe, sind die meisten Kosten mit den Dingen verbunden, die entweder im Software-Ökosystem oder in der Welt im Allgemeinen geschehen und sich ändern. Wenn Sie sich jedoch auf die Dinge konzentrieren, die sich nicht ändern, erhalten Sie im Wesentlichen den Großteil Ihrer Software, der nur langsam verfällt, weil sich Ihre Software hauptsächlich mit den Dingen befasst, die sich nicht ändern.

Das Problem besteht darin, dass es einfacher gesagt als getan ist, sich auf das zu konzentrieren, was sich nicht ändert, denn es gibt eine sehr menschliche Kraft, die diesem Vorhaben entgegenwirkt: die Angst, etwas zu verpassen. Wenn Sie sich die Presse, die Medien, Ihre Kollegen usw. ansehen, wird es einen ständigen Strom von Neuheiten, Schlagwörtern geben, und jedes einzelne Schlagwort hat aufgrund der Angst, etwas zu verpassen, den Drang, einfach mitzumachen und nicht zurückgelassen zu werden. Zum Beispiel wären all diese Schlagwörter KI, Blockchain, IoT und all diese Dinge, die sehr präsent sind. Ich glaube, dass diese Schlagwörter in der Lieferkette wirklich eine Ablenkung sind und sie wesentlich zu den Wartungsproblemen beitragen, weil sie von dem ablenken, was sich nicht ändert. Im Gegenteil, wenn Sie anfangen, sich mit diesen Schlagwörtern zu beschäftigen, reiten Sie auf einer Welle und beschäftigen sich genau mit den Dingen, die sich im Laufe der Zeit sehr wahrscheinlich ändern werden, was Ihre Wartungskosten im Laufe der Zeit erhöht.

Jetzt, da wir mit der Mainstream-Sichtweise auf Softwareentwicklung fertig sind, wollen wir uns eine Reihe von persönlichen Erkenntnissen ansehen, die hoffentlich nützlich sind, um Softwareprojekte unter Berücksichtigung der Lieferkette durchzuführen. Eines der häufigsten Probleme beim Umgang mit Softwareentwicklern ist ein Missverständnis über ihre eigene Identität, und ich entlehne diese Idee einem Unternehmer namens Paul Graham. Ein Ingenieur wird zum Beispiel sagen: “Ich bin ein Python-Ingenieur.” Auch wenn es nicht so extrem sein mag, ist es sehr häufig, dass Softwareentwickler ihre eigene Identität durch die Art von Technologien wahrnehmen, die sie beherrschen und die ihren Fähigkeitssatz ausmachen. Diese Verwirrung zwischen ihrer Identität und ihrem aktuellen Fähigkeitssatz wird durch die gängigen Einstellungspraktiken in der IT- und Softwarewelt tendenziell verstärkt. Aus Sicht der Einstellung gibt es viele Unternehmen, die in ihren Stellenanzeigen angeben: “Ich brauche einen Python-Programmierer.” Also gibt es jemanden auf der einen Seite, der denkt: “Ich bin ein Python-Programmierer”, und dann gibt es ein Unternehmen, das eine Stellenanzeige veröffentlicht, in der im Grunde steht: “Ich brauche einen Python-Programmierer.” Plötzlich ist es also nicht nur eine Frage der Wahrnehmung, die richtige Identität zu haben; damit sind finanzielle Belohnungen verbunden, wenn man die richtige Identität, das richtige Label, das richtige Etikett hat, das man sich selbst anheften kann und das einen attraktiver auf dem Markt macht.

Diese identitätsgetriebene Wahrnehmung, bei der Technologien mit sich selbst als Softwareentwickler verbunden werden, führt zu zahlreichen Problemen, die sich auf praktisch jedes einzelne Softwareprojekt auswirken, insbesondere auf Lieferkettensoftwareprojekte. Wenn man mit einer Person interagiert, in der Regel einem Softwareentwickler, der seine Identität stark mit der Technologie verbindet, die in Ihrem Unternehmen vorhanden ist, wird das Problem, dass jede Kritik an der Technologie aus einer persönlichen Perspektive betrachtet wird. Wenn Sie sagen, dass ich ein Python-Programmierer bin und Sie meine Software kritisieren, nehme ich das persönlich. Das Problem ist, dass es sehr schwierig wird, über diese Probleme zu argumentieren, sobald die Leute Kritik an der Technologie als persönliche Kritik auffassen. Diese Softwareentwickler werden leider dazu neigen, alle Rückmeldungen abzuwehren, einfach weil sie sie teilweise als persönliche Kritik sehen.

Umgekehrt, wenn das Unternehmen eine Technologie verwendet, die nicht als Kernidentität des Softwareentwicklers wahrgenommen wird, zum Beispiel wenn Ihr Unternehmen einige Systeme in Java implementiert hat und Sie einen Softwareentwickler haben, der sagt: “Ich bin ein Python-Programmierer”, dann werden alle Probleme durch die Brille wahrgenommen, dass diese Technologie minderwertig ist. Auch hier ist das ein weiteres Problem, bei dem die Kritik und das Feedback als Haltung von “nicht mein Problem; das liegt nur an dieser sehr schlechten Technologie, die hier und jetzt in diesem Unternehmen verwendet wird” abgewehrt werden. In beiden Situationen, ob der Softwareentwickler eine Identität hat, die mit der von Ihnen verwendeten Technologie verbunden ist oder eine Identität hat, die mit einer von Ihnen nicht verwendeten Technologie verbunden ist, entstehen eine ganze Reihe von Problemen und das Feedback wird abgewehrt, anstatt genutzt zu werden, um die Technologie zu verbessern.

Aus Sicht der Lieferkette müssen wir bedenken, dass die Lieferkettenumgebung unglaublich chaotisch ist und daher ständig Probleme auftreten werden. Gerade aufgrund dieses Umgebungschaoes ist es sehr wichtig, Teams von Softwareentwicklern zu haben, die diesen Problemen direkt ins Auge sehen und etwas dagegen unternehmen können, anstatt das Feedback einfach abzuwehren, wenn es auftritt. Es ist entscheidend, Teams zusammenzustellen, die kein Drama aufgrund der Wahrnehmung ihrer Identität über den Lieferkettenchaos hinaus fördern.

Diese Idee erstreckt sich auch auf Softwareentwickler, die oft Technologien wählen, die zu ihrer Identität oder der Identität passen, die sie erlangen möchten. Sie wählen Technologien, um die Fähigkeiten zu erwerben, damit sie ein weiteres Stichwort zu ihrem Lebenslauf hinzufügen können. Diese Herangehensweise führt jedoch dazu, dass Technologien aus Gründen ausgewählt werden, die nichts mit der Lösung der Probleme zu tun haben, mit denen das Unternehmen konfrontiert ist. Dies ist die falsche Perspektive, um zu entscheiden, ob eine Technologie relevant oder angemessen ist, um die spezifischen Probleme der Organisation anzugehen.

Das Erstellen eines Lebenslaufs kann ein starker Anreiz für Softwareentwickler sein, da mit einer Liste von Stichworten finanzielle Vorteile verbunden sind. Die besten Softwareunternehmen sehen oft auf Lebensläufe mit einer langen Liste von Stichworten herab. Als CEO von Lokad werfe ich einen Lebenslauf mit einer halben Seite Stichwörtern direkt weg. Viele Unternehmen, insbesondere mittelmäßige, suchen jedoch aktiv nach Personen mit vielen Stichworten, in der Annahme, dass diese Personen unglaublich vielseitig und agil in der Organisation sein werden. Aus meiner Erfahrung ist dies oft das Gegenteil.

Im Zusammenhang mit Identität und Lebenslaufaufbau ist es wichtig, darauf zu achten, dass Softwarearchitekten nicht zu sehr an einer bestimmten Technologie hängen. Es ist bereits schwierig, Softwareentwickler einzustellen, daher müssen manchmal Kompromisse eingegangen werden. Wenn es jedoch um Softwarearchitekten geht, kann es katastrophal sein, Kompromisse einzugehen, indem Personen ausgewählt werden, die eine emotionale Bindung an eine bestimmte Technologie haben. Diese Personen werden einen großen Einfluss auf Ihr Unternehmen haben.

Dieses Problem der Voreingenommenheit beim Erstellen von Lebensläufen beschränkt sich nicht nur auf Softwareentwickler oder Softwarefachleute. Es tritt auch bei IT-Personal auf. Zum Beispiel habe ich mehrere IT-Direktoren in großen Unternehmen getroffen, die auf SAP umsteigen wollten, obwohl ihr vorhandenes Legacy-ERP perfekt in Ordnung war. Die enormen Kosten, die mit dem Wechsel zu SAP verbunden sind, würden niemals durch die erwarteten Vorteile eines moderneren ERP aufgewogen werden. In diesen Fällen spielte ein irrationaler Verhaltensweisen eine Rolle, bei dem das persönliche Interesse des IT-Direktors, SAP in seinem Lebenslauf einzusetzen, die Interessen des Unternehmens selbst überwog.

Aus Sicht der Lieferkette ist es wichtig, auf diese Interessenkonflikte zu achten. Es erfordert nicht viel Softwarekenntnisse oder Kompetenz, Interessenkonflikte zu erkennen. In anderen Bereichen wie der medizinischen Wissenschaft können sogar Ärzte aufgrund von Interessenkonflikten falsche Medikamente verschreiben, selbst wenn Menschenleben auf dem Spiel stehen. Dies zeigt, dass Interessenkonflikte unglaublich giftig sind. Stellen Sie sich nur vor, wie sich diese Probleme im Supply Chain Management auswirken, wo keine Menschenleben auf dem Spiel stehen und das Hauptanliegen das Geld ist. In diesem Kontext gibt es noch weniger Zurückhaltung, Interessenkonflikte zuzulassen.

Im Gegensatz zur physischen Welt bietet die Softwarewelt nur sehr wenige Einschränkungen, wie man mit Softwareinitiativen und Arbeitsansätzen umgehen soll. Die menschliche Natur mag keine Leere, und Menschen können sich durch einen Mangel an Struktur verunsichert fühlen. Als Ergebnis sind im Laufe der Jahre zahlreiche Praktiken entstanden und werden weiterhin entwickelt. Mit jeder Praxis entsteht eine Vorstellung von Orthodoxie. Einige Beispiele für diese Praktiken sind Extreme Programming, Domain-driven Design, Test-driven Design, Microservices, Scrum und Agile Programming. Es gibt viele Praktiken, und jedes Jahr entstehen neue.

Mit jeder Praxis entsteht eine Vorstellung von Orthodoxie. Sobald Menschen einer Praxis folgen, können sie sich fragen, ob sie den Kernprinzipien treu bleiben. Softwareingenieure sind auch nur Menschen, und Menschen lieben Rituale und Stämme. Eine Praxis vermittelt ein Gefühl der Zugehörigkeit zu einem Stamm mit gemeinsamen Überzeugungen. Deshalb finden Sie auch Meetups, die mit diesen Praktiken verbunden sind und einem sehr menschlichen Bedürfnis gerecht werden.

Es kann schwierig und sogar deprimierend sein, ein Problem anzustarren, unsicher über alles zu sein und fast niemanden zu haben, der sich mit der Bewältigung des Problems identifizieren kann. Das Interessante ist, dass eine Praxis fragwürdig oder leicht irrational sein kann, aber die Vorteile real sein können. Die Werbung für eine Praxis innerhalb und außerhalb Ihres Unternehmens kann die Moral steigern und bei der Einstellung potenzieller Bewerber helfen.

In einem Vorstellungsgespräch, wenn Menschen danach fragen, wie Sie arbeiten, ist es nicht gerade überzeugend zu sagen, dass Sie improvisieren und keine Regeln haben. Es ist effizienter, Vertrauen zu wecken, indem man eine Praxis präsentiert, als ob sie Probleme im Unternehmen lösen würde. Der entscheidende Punkt ist, dass diese Praktiken kurzfristig nicht alle schlecht sind, auch wenn sie größtenteils irrational sind. Das Gefühl der Zugehörigkeit kann vorteilhaft sein. Es wird jedoch giftig, wenn Praktiken zu ernst oder zu lange genommen werden. Eine Praxis kann interessant sein, nur weil sie Sie zwingt, das Problem aus einem anderen Blickwinkel zu betrachten. Aber sobald Sie das Problem aus einem anderen Blickwinkel betrachtet haben, sollten Sie versuchen, noch einen anderen Blickwinkel zu finden. Sie sollten nicht zu lange bei einem Blickwinkel bleiben. Aus Sicht der Lieferkette verdeutlicht dies die radikale Eigenart der Softwarewelt.

Auf dem Fabrikboden bedeutet Exzellenz, immer genau dasselbe zu tun. In der Softwarewelt ist es genau das Gegenteil. Wenn Sie dasselbe tun, ist es ein Rezept für Stagnation und Misserfolg im Laufe der Zeit.

Software ist komplex, und Unternehmenssoftware erst recht. Häufig arbeiten mehrere Ingenieure an einer bestimmten Initiative, was zu einer natürlichen Tendenz zur Spezialisierung führt. Wenn ein Ingenieur an einem bestimmten Teil des Codebase arbeitet, besteht eine natürliche Neigung, dieselbe Person zuzuweisen, wenn neue Aufgaben erfordern, dass dieser Teil des Codebase berührt wird. Die Vorteile sind real, da diese Person bereits mit dem Code vertraut ist und produktiver sein kann.

Das Hauptproblem bei der Spezialisierung besteht darin, dass dies zu einem Gefühl der Eigentümerschaft über Teile des Codebase führen kann, was verschiedene Probleme schafft. Es gibt zwei Arten von Problemen im Zusammenhang mit dieser Eigentümerschaft: der “Truck-Faktor” und Machtspiele. Der Truck-Faktor bezieht sich auf das Risiko, einen Mitarbeiter zu verlieren, der über einzigartiges Wissen oder Fähigkeiten verfügt. Dies kann daran liegen, dass der Mitarbeiter zu einem anderen Unternehmen wechselt oder aus irgendeinem anderen Grund nicht mehr arbeiten kann. Machtspiele können auftreten, wenn ein Mitarbeiter erkennt, dass sein Beitrag für das Unternehmen entscheidend ist und diese Hebelwirkung nutzt, um einen höheren Gehalt oder andere Vorteile zu fordern.

In meiner Erfahrung neigen Softwareingenieure in der Regel nicht dazu, Machtspiele zu spielen, aber diese Probleme können in größeren Unternehmen immer häufiger auftreten. Es gibt viele Software-Engineering-Praktiken, die versuchen, dieses Problem direkt anzugehen, wie zum Beispiel Pair Programming. Die entscheidende Erkenntnis ist jedoch, dass zu viel von einer guten Sache für das Unternehmen giftig sein kann. Das Beste ist, sich dieses Problems bewusst zu sein, anstatt sich nur an einer bestimmten Praxis festzuhalten, die das Problem lösen soll. Dies liegt daran, dass solche Praktiken andere Probleme schaffen, Sie ablenken oder Ihre Aufmerksamkeit auf andere Dinge einschränken können, die Sie noch nicht gesehen haben. Aus softwaretechnischer Sicht ist die entscheidende Lektion hier, dass Kultur das Gegenmittel zu dieser Art von Problemen ist, nicht der Prozess.

Wir stehen vor einer Situation, in der wir einen sehr subtilen Kompromiss zwischen den Produktivitätsgewinnen, die durch die Spezialisierung von Personen in Teilen des Codes erzielt werden, und den Risiken haben, die mit dem Besitz dieser Teile des Codes verbunden sind. Was Sie wollen, ist eine Situation zu schaffen, in der es immer eine gewisse Redundanz in Bezug auf das Wissen über die Codebasis des gesamten Teams gibt, so dass jeder Ingenieur eine Art Überschneidung der Kompetenz hat. Dies ist ein sehr subtiler Kompromiss, den Sie erreichen müssen, wenn Sie irgendeinen Grad an Produktivität aufrechterhalten möchten. Die einzige Möglichkeit, dies tatsächlich in der realen Welt zu tun, besteht darin, eine gut verstandene Kultur des Software-Engineerings zu haben. Es gibt keinen Prozess, der garantieren kann, dass Menschen neugierig auf die Arbeit ihrer Kollegen sind. Sie können keinen Prozess für Neugier haben; es muss Teil der Kultur sein.

Die Bewertung der Fähigkeiten und Kompetenzen von Softwareingenieuren ist schwierig, und diese Frage ist entscheidend, denn obwohl Software eindeutig eine Teamarbeit ist und das Team mehr ist als die Summe seiner Mitglieder, hat das Grundniveau der Mitglieder des Teams einen großen Einfluss auf die Leistung des Teams als Ganzes.

Ein Aspekt, der meiner Meinung nach von Menschen außerhalb der Softwarebranche weitgehend unterschätzt wird und manchmal auch von Menschen innerhalb der Branche, ist die Bedeutung von Schreibfähigkeiten. Wenn Sie Software erstellen, richten Sie sich an zwei unterschiedliche Zielgruppen. Auf der einen Seite haben Sie das Publikum der Maschine - Ihren Compiler. Sie schreiben Code, und Ihr Compiler wird ihn akzeptieren oder ablehnen. Das ist der einfache Teil. Ihr Compiler ist Ihr unermüdlicher Begleiter, der Ihnen sagt, ob Ihr Code korrekt oder falsch ist. Der Compiler ist völlig vorhersehbar und hat eine unendliche Geduld.

Auf der anderen Seite haben Sie das Publikum Ihrer Kollegen, zu dem wahrscheinlich auch Sie selbst sechs Monate später gehören. Sie schreiben Code und werden ihn schließlich vergessen. Sechs Monate später schauen Sie sich den Code an, den Sie geschrieben haben, und denken, dass er von jemand anderem geschrieben wurde, weil er so unbekannt erscheint. Wenn Sie Code für Ihre Kollegen schreiben, besteht der Vorteil darin, dass Ihre Kollegen versuchen werden, zu verstehen, was Sie erreichen wollen. Der Compiler versucht nicht, Ihre Absichten zu verstehen; er wendet mechanisch eine Reihe von Regeln an.

Ihre Kollegen werden versuchen zu verstehen, aber leider sind sie nicht wie Compiler. Sie haben keine unendliche Geduld und können leicht durch Ihren Code verwirrt und fehlgeleitet werden. Deshalb ist es zum Beispiel von entscheidender Bedeutung, merk- und einsichtsvolle sowie passende Namen zu wählen. Ein gutes Programm geht nicht nur darum, etwas Korrektes zu haben; selbst die Wahl der Namen von Variablen, Funktionen und Modulen ist von entscheidender Bedeutung, wenn Sie Code haben möchten, der gut mit Ihren Kollegen funktioniert, und nochmals, Ihre Kollegen schließen sich selbst sechs Monate später ein. Aus Sicht der Supply Chain ist die wichtigste Erkenntnis, dass Schreibfähigkeiten von entscheidender Bedeutung sind, und ich würde sogar so weit gehen zu sagen, dass Schreibfähigkeiten häufig wichtiger sind als reine technische Fähigkeiten. Gute Schreibfähigkeiten sind die wichtigste Fähigkeit, die Sie benötigen, um die Komplexität in Ihrer Supply Chain zu beherrschen. Die Beherrschung der Komplexität Ihrer Anwendungslandschaft ist keine große technische Herausforderung; es ist eine Herausforderung, Ideen und Elemente zu organisieren und eine konsistente Geschichte zu haben. Dies sind sehr viel Schreibfähigkeiten, und wir haben diesen Aspekt in einem früheren Vortrag mit dem Titel “Schreiben für die Supply Chain” behandelt.

Wenn das Schreiben von Code eine wichtige Fähigkeit ist, um ein guter Softwareingenieur zu sein, gibt es eine weitere Fähigkeit, die überhaupt wichtig ist, um ein Softwareingenieur zu sein: Schmerztoleranz. Ich glaube, dass dies die wichtigste Fähigkeit ist, um tatsächlich ein Softwareingenieur zu sein, nicht unbedingt ein großartiger, sondern einfach ein Softwareingenieur. Genauer gesagt meine ich mit Schmerz den Widerstand gegen Langeweile und Frustration, die mit dem Prozess des Software-Engineerings einhergehen, wenn man es mit Systemen zu tun hat, die unglaublich fragil, schlecht konzipiert und auf vielfältige Weise sabotiert sind, manchmal von Menschen, die nicht einmal mehr da sind. Wenn man mit Software arbeitet, hat man vier Jahrzehnte angesammelter Probleme unter den Füßen und man kämpft ständig damit. Das kann manchmal eine unglaublich frustrierende Übung sein.

Nur um Ihnen eine Vorstellung zu geben: Als Softwareingenieur müssen Sie die Geduld haben, vier Stunden lang durch zufällige, halbwegs sinnlose Gespräche in einem Webforum zu graben, in denen ein Fehlercode erwähnt wird, der Ihrem ähnlich ist. Sie müssen sich stundenlang mit diesem Unsinn beschäftigen, um ans Ziel zu kommen, und manchmal dauert es Wochen, um einen scheinbar banalen Fehler zu beheben. Die Konsequenz davon ist, dass wir in der gesamten Softwarebranche einen sehr intensiven negativen Selektionsprozess haben, der Menschen auswählt, die eine hohe Schmerztoleranz haben. Dieser Selektionsprozess hat zwei Hauptkonsequenzen.

Erstens neigen Menschen, die Softwareingenieure bleiben, dazu, eine unglaubliche Schmerztoleranz zu haben. Wenn ich von Schmerztoleranz spreche, meine ich den Widerstand gegen Frustration aufgrund der ständigen Softwareprobleme. Da man nach Menschen mit einer unglaublichen Schmerztoleranz sucht, erkennen sie möglicherweise nicht einmal, wenn ihre Handlungen die Situation verschlimmern. Sie können zusätzliche Eigenheiten in die Softwareprodukte einbauen, was den Schmerz beim Umgang mit der Software für alle, einschließlich sich selbst, erhöht. Wenn sie jedoch eine unglaubliche Schmerztoleranz haben, achten sie nicht darauf. Dieser negative Selektionsprozess lässt normale Menschen aus, die darauf achten würden, aber keine Softwareingenieure geworden sind, weil sie den Schmerz nicht ertragen konnten. Dieses Problem ist besonders intensiv für Supply-Chain-Software, da es viele Teile gibt, die nicht besonders aufregend sind. Einige Aspekte können notwendig, aber banal sein, was bedeutet, dass Menschen mit hoher Schmerztoleranz, die in diesem Bereich tätig sind, die Situation aufgrund der Fülle an potenziell langweiligen Aufgaben verschlimmern können.

Der zweite Aspekt dieses negativen Selektionsprozesses besteht darin, dass Menschen, die es sich leisten können, aufgrund von Problemen, die intensiven Schmerz verursachen, auf ein niedriger bezahltes Gehalt zu verzichten, dies auch tun. Wenn jemand bereits gut bezahlt wird, entscheidet er sich möglicherweise für einen Job, der nicht so gut bezahlt ist, aber den Vorteil hat, weniger intensiven Schmerz zu verursachen. Die meisten Menschen würden dies wahrscheinlich tun, und in der Praxis tun es viele Menschen auch. Das bedeutet, dass die Menschen, die in dieser Branche bleiben, in der es eine sehr hohe Intensität von allgegenwärtigem Schmerz gibt, oft diejenigen sind, die es sich nicht leisten können, auf die Möglichkeit eines höheren Gehalts zu verzichten. Dies erklärt zu einem großen Teil, warum es eine signifikante Anzahl von Softwareingenieuren aus Indien und Nordafrika gibt. Diese Länder haben relativ gute Bildungssysteme, die gut ausgebildete Menschen hervorbringen, aber die Länder sind immer noch relativ arm. Menschen in solchen Positionen haben nicht die Möglichkeit, auf besser bezahlte Softwareingenieur-Jobs zu verzichten, aufgrund der hohen Nachfrage und höheren Gehälter im Vergleich zu ihren Grundgehältern. Sie haben nicht die Möglichkeit, etwas anderes zu wählen, und so sind sie in der Branche sehr verbreitet.

Es ist nichts Falsches an diesen Ländern; es ist nur eine mechanische Anwendung der Marktkräfte. Dies ist kein Urteil, sondern nur eine Beobachtung. Die Sache ist, dass Schmerztoleranz nicht alles ist, was man braucht, um ein großartiger Softwareingenieur zu sein. Es ist nur eine Voraussetzung, aber wenn man das nicht hat, ist man überhaupt kein Softwareingenieur. Wenn jedoch Schmerztoleranz das Einzige ist, was man hat, wird man ein ziemlich schlechter Softwareingenieur sein. Aus Sicht der Supply Chain ist die Lehre hier, genau darauf zu achten, welche Art von Teams Ihr Unternehmen intern oder über Softwareanbieter zusammenstellt. Stellen Sie sicher, dass die Ingenieure, die zusammengebracht werden, nicht nur Schmerztoleranz als ihre einzige Fähigkeit haben, denn das bedeutet, dass Sie in Bezug auf Softwarequalität und Mehrwert der Software ein sehr schlechtes Ergebnis haben werden. Schmerztoleranz ist zwar erforderlich, aber es reicht einfach nicht aus.

Im Jahr 1975 wies Frederick Brooks bereits darauf hin, dass Mann-Monate nicht repräsentativ für den Wert sind, der durch Software und die von Softwareingenieuren generierte Wertschöpfung entsteht. Fast fünf Jahrzehnte später gehören IT-Unternehmen zu den größten Arbeitgebern der Welt. Im Jahr 2020 gab es in den USA in der IT-Branche 3 Millionen Mitarbeiter, aber weniger als 1 Million Menschen für die gesamte Automobilindustrie. Die IT-Branche hat jetzt mindestens dreimal so viele Mitarbeiter wie die Automobilindustrie. Die meisten dieser IT-Unternehmen, von denen einige absolut gigantisch sind und mehrere hundert oder tausend Mitarbeiter haben, berechnen nicht mehr nach Mann-Monaten. Das war in den 70er Jahren. Wir berechnen jetzt nach Kilo-Tagen, was im Wesentlichen tausend Arbeitstage bedeutet. Die Situation hat sich im Vergleich zu dem Problem, das Frederick Brooks vor fast fünf Jahrzehnten skizziert hat, wahrscheinlich noch verschlimmert, hauptsächlich aufgrund des unglaublichen Anstiegs des Problems in Bezug auf Umfang und Größenordnung. Dennoch sind die meisten frühen Lehren immer noch gültig. “The Mythical Man-Month” ist nach wie vor ein sehr interessantes Buch über Softwaretechnik.

In der Softwarebranche variiert die Produktivität enorm. Auf der einen Seite gibt es keine Menschen mit geringer Produktivität; es gibt Menschen mit negativer Produktivität. Das bedeutet, dass sie, wenn sie an einem Softwareprodukt arbeiten, es nur noch verschlechtern. Man kann nicht einmal mehr ein Verhältnis zwischen der Produktivität der Menschen herstellen. Es ist viel schlimmer als das; es gibt Menschen, die Ihr Produkt aktiv verschlechtern werden. Das ist ein massives Problem. Auf der anderen Seite gibt es die sogenannten 10x-Ingenieure, Menschen, die zehnmal so produktiv sind wie Ihr durchschnittlicher Ingenieur, der hoffentlich eine positive Produktivität hat. Diese 10x-Ingenieure existieren, aber diese massive Produktivität hängt unglaublich vom Kontext ab. Man kann nicht einfach einen 10x-Softwareingenieur von einem Unternehmen in ein anderes oder sogar von einer Position in eine andere versetzen und erwarten, dass diese Person ihre unglaubliche Produktivität beibehält. Normalerweise handelt es sich um eine Kombination aus einzigartigen Fähigkeiten und einer spezifischen Situation, die diese Produktivität generiert. Dennoch ist es wichtig, im Hinterkopf zu behalten, dass eine winzige Anzahl von Menschen den Großteil des Werts generiert, der durch ein Softwareprodukt entsteht. Manchmal kommt es nur auf eine Person an, die den Großteil aller intelligenten Elemente der Software und des wahren Mehrwerts schafft, während sich der Rest mit Dingen beschäftigt, die bestenfalls zweifelhaften Mehrwert haben. Die wichtigste Lektion hier, die vor fünf Jahrzehnten identifiziert wurde, ist, dass wenn man in der Supply Chain gegen einen Termin arbeitet, die einzige vernünftige Option darin besteht, den Umfang der Softwareinitiative zu reduzieren. Alle anderen Optionen sind schlechter.

Das Hinzufügen von Arbeitskräften verschlimmert die Dinge, da es oft heißt, dass das Hinzufügen von Arbeitskräften zu einem späten Softwareprojekt es noch später macht. Diese Aussage von Brooks war vor fünf Jahrzehnten gültig und ist auch heute noch gültig. Die anderen Optionen funktionieren auch nicht. Wenn Sie Überstunden machen lassen, wird es sich negativ auswirken, da die Menschen müde werden und mehr Fehler machen, was das Produkt weiter verzögert. Wenn Sie die Qualität senken, werden Sie am Ende etwas haben, das nicht mehr funktioniert. Diese Dinge werden außer Kontrolle geraten und in Ihren Händen explodieren, daher können Sie keine Kompromisse bei der Qualität eingehen.

Aus Sicht der Supply Chain ist die wichtigste Lektion hier, dass Sie äußerst vorsichtig vorgehen sollten, wenn Sie eine Initiative angehen, die mehr als zehn Vollzeit-Softwareingenieure erfordert. In der Regel ist dies ein Zeichen dafür, dass es sich um ein sehr schlecht formuliertes Problem handelt. Es erfordert unglaubliche Teamarbeit, um zehn Personen gleichzeitig an demselben Produkt arbeiten zu lassen und dabei die Produktivität aufrechtzuerhalten. In der Supply Chain beobachte ich oft, dass die Menschen in Bezug auf den Umfang und die Anzahl der beteiligten Personen zu ehrgeizig sind. Ich habe ERP-Migrationsprojekte gesehen, an denen gleichzeitig 50, 100 oder 200 Personen gearbeitet haben. Das ist absolut unsinnig. Um eine Zusammenarbeit zu erreichen, sind unglaublich fähige Teamplayer erforderlich, um durch Reibung nicht alles zu verlieren. Wenn Sie Schwierigkeiten haben, halten Sie Ihre Softwareinitiative fokussiert, kurz und eng.

Meine letzte Beobachtung betrifft ein häufiges Missverständnis in Bezug auf große Unternehmen. Die meisten Menschen würden sagen, dass große Unternehmen risikoscheu sind, aber das ist nicht meine Erfahrung. Meine Erfahrung ist, dass große Unternehmen Unsicherheit scheuen, nicht Risiko, obwohl die beiden aus der Ferne verwechselt werden können. Aus der Ferne wird die rationale Erklärung gegeben, dass große Unternehmen risikoscheu sind, aber in Wirklichkeit habe ich immer wieder beobachtet, dass große Unternehmen, wenn sie vor der Wahl stehen, sich für einen sicheren Misserfolg oder einen unsicheren Erfolg zu entscheiden, immer den sicheren Misserfolg bevorzugen.

Große Unternehmen werden immer wieder den sicheren Misserfolg dem unsicheren Erfolg vorziehen. Das mag auf den ersten Blick verwirrend und irrational erscheinen, ist es aber nicht. Große Unternehmen sind keine einzelne Einheit; sie sind politische Gebilde, die aus vielen Menschen bestehen. Politik und Erscheinungsbild sind besonders in sehr großen Strukturen von größter Bedeutung.

Betrachten Sie die Perspektive derjenigen, die für eine Softwareinitiative verantwortlich sind. Auf der einen Seite haben Sie eine Initiative, bei der das Ergebnis sicher ist - sie wird scheitern. Sie halten sich jedoch an die Regeln und jeder weiß, dass sie scheitern wird. Niemand wird Ihnen die Schuld geben, wenn Sie es sicher spielen und scheitern, denn das ist es, was sie erwarten. Im Gegensatz dazu sieht unsicherer Erfolg seltsam aus. Diesen Weg zu verfolgen bedeutet, Dinge zu tun, die ungewöhnlich sind und potenziell karriereschädigend, viel mehr als nur nach den Regeln zu spielen.

Aus Sicht der Supply Chain besteht die Lehre hier darin, dass es in der Softwarewelt von entscheidender Bedeutung ist, sich nicht nur zum Scheitern zu verurteilen, nur um nach den Regeln zu spielen, insbesondere wenn das Regelwerk völlig falsch ist. Ich habe zum Beispiel Unternehmen gesehen, die jahrzehntelang mit Methoden wie ABC-Analyse und Sicherheitsbeständen scheitern, Methoden, die mathematisch und statistisch nachweislich falsch sind und das Scheitern der entsprechenden Initiativen garantieren. Diese Methoden sind aus grundlegenden mathematischen und statistischen Gründen falsch, daher sollte es nicht überraschen, dass sie keinen Mehrwert in der Supply Chain liefern. Sie wurden jedoch bevorzugt, weil sie nicht als verrückt erschienen, sondern Lehrbuchmaterial waren.

Vorsicht vor dem Komfort, der durch das Scheitern nur zur Beseitigung von Unsicherheit gewonnen werden kann. Die Beseitigung von Unsicherheit ist nicht das Ziel; das Ziel ist es, die Chance auf Erfolg zu maximieren, nicht die Unsicherheit zu reduzieren.

Zusammenfassend lässt sich sagen, dass die Softwareentwicklung zu wichtig ist, um sie nur den Softwareingenieuren zu überlassen. Software ist überall in der Supply Chain präsent und treibt die Mechanisierung intellektueller Arbeit voran. Wir befinden uns noch in einem frühen Stadium des Prozesses, aber es kann bereits ohne Zweifel gesagt werden, dass Unternehmen, die auf diesem Gebiet nicht äußerst wettbewerbsfähig bleiben, letztendlich von regulären Marktkräften vollständig vom Markt eliminiert werden. Für die Supply Chain besteht die größte Herausforderung darin, eine kulturelle zu sein. Dies ist kein technisches Problem, sondern ein kulturelles Problem. Die Softwareentwicklung stellt die Art und Weise, wie wir Probleme betrachten und angehen, in Frage. Die meisten intuitiven Lösungen tendieren dazu, falsch zu sein, spektakulär falsch.

In gewisser Weise geht es bei der Softwareentwicklung in der Supply Chain darum, das Chaos zu bändigen, die Komplexität und Unsicherheit, die überall in der Supply Chain vorhanden ist, zu bändigen. Um dieses Chaos zu bändigen, was die Aufgabe von Softwareingenieuren sein wird, wenn der Prozess selbst zu poliert oder geordnet ist, wenn der Prozess selbst keinen Kern des Chaos hat, dann bleibt kein Raum für Veränderung, Zufall oder Kreativität. Was als Exzellenz wahrgenommen wird, verfällt schnell in Stagnation und dann in Misserfolg. Für traditionellere Unternehmen besteht die größte Herausforderung dieses kulturellen Ansatzes neben dem Kulturschock darin, sich von der Illusion der Kontrolle zu lösen. Ihr fünfjähriger ERP-Migrationsplan ist eine Täuschung; Sie haben keine Kontrolle über ein so massives Projekt. Ebenso ist Ihr Geschäftsfall, der die erwarteten Gewinne Ihrer aktuellen Initiative umreißt, ebenfalls eine Illusion.

Bei der Mechanisierung intellektueller Arbeit besteht die größte Gefahr nicht darin, Dinge zu tun, die Sie nicht vollständig rationalisieren können. Die größte Gefahr besteht darin, Dinge zu tun, die unter dem Deckmantel der Rationalität völlig irrational sind.

Schauen wir uns die Frage an. Die nächste Vorlesung findet am Mittwoch, den 15. Dezember, zur gleichen Zeit um 15 Uhr Pariser Zeit statt und wird sich mit Cybersicherheit befassen. Jetzt werde ich mir die Frage ansehen.

Frage: Wie messen Sie die kapitalistische Rendite Ihrer Softwareinvestitionen?

Meistens tun Sie das nicht. Die Messung ist das Nebenprodukt des Unternehmens selbst. Es ist etwas, das verwirrend ist, wenn Sie die Rendite der Investition messen möchten. Es setzt voraus, dass Sie im Voraus eine Messung vornehmen können, was typischerweise bei dieser Art von Fragestellung impliziert wird. Es setzt voraus, dass Sie diese Messung vor dem Erstellen Ihres Geschäftsfalls mit Szenarien erstellen können und dann eine Entscheidung treffen und Ihre Softwareinvestition durchführen oder nicht. Was ich sage, ist, dass es mit Software nicht so funktioniert. Zuerst tun Sie die Sache, dann lernen Sie, was gelernt werden muss, und dann erfahren Sie sogar unterwegs, welche Vorteile es gibt. Um Ihr Handeln zu lenken, benötigen Sie ein Verständnis auf hoher Ebene. Die Lehre besteht nicht darin, Dinge zufällig zu tun, sondern nicht Dinge zu tun, die unter dem Deckmantel der Rationalität zutiefst irrational sind. Eine hochrangige Intuition kann ein viel rationaleres Argument sein, wenn Sie von etwas absolut überzeugt sind und Ihr Bauchgefühl Ihnen sagt, dass es der richtige Weg ist, im Vergleich zu ausgeklügelten Berechnungen, die nur den Anschein von Rationalität haben, aber auf Müllzahlen basieren. Die Realität ist, dass Sie im Laufe Ihres Softwareprojekts immer klarere Messungen erhalten, da Sie beginnen, zu verstehen, was Sie erreichen möchten, und dann lernen Sie, wie Sie die Angemessenheit dessen, was Sie tun, mit dem messen können, was Sie tun sollten. Die Messung ist etwas, das als Nebenprodukt entsteht, wenn Sie es gut machen. Als Konsequenz bedeutet dies jedoch, dass es im Hinblick auf Software viel besser ist, einfach Dinge auszuprobieren und schnell zu scheitern. Sie möchten sich nicht in ein massives Engagement begeben; es ist besser, es auf unglaublich inkrementelle Weise zu tun, mit weniger Personen und hoher Produktivität. Sie lernen auf dem Weg, wie Sie vorgehen sollen.

Aber dann kommt ein weiteres Problem: Sobald Sie damit anfangen, muss das Management in Unternehmen in der Lage sein, viele Initiativen gleichzeitig zu jonglieren. Dies ist sehr beunruhigend, insbesondere für traditionellere Unternehmen, da das Management nicht erwartet, so viele Initiativen in unterschiedliche Richtungen zu haben. Doch genau das passiert bereits seit Jahrzehnten in großen Softwareunternehmen, und das ist eine der Essenz der Erkenntnisse aus der Softwareentwicklung aus menschlicher Sicht.

Frage: Ist es nicht ein Widerspruch zu sagen, dass diejenigen mit vielen Schlüsselwörtern sich nicht mit einer bestimmten Technologie verbinden?

Nun, ich sage nicht, dass Sie durch viele Schlüsselwörter davor geschützt sind, sich mit einer bestimmten Technologie zu verbinden. Es handelt sich um zwei verschiedene Probleme. Das erste Problem besteht darin, dass eine Person eine starke Verbindung zwischen ihrer persönlichen Identität, ihrer wahrgenommenen Identität und ihrem Fähigkeitssatz hat. Das ist Problem Nummer eins. Das Problem Nummer zwei besteht darin, dass das Erstellen Ihres Lebenslaufs mit einem sehr starken latenten Interessenkonflikt einhergeht. Meine Botschaft ist einerseits, seien Sie sich dieser Identitätspolitik bewusst; sie sind unglaublich giftig. Meine zweite Botschaft ist, seien Sie sich aller Formen von Interessenkonflikten bewusst; sie sind ebenfalls unglaublich giftig.

Nun, wenn Sie eine bestimmte Technologie wirklich stark betonen, können Sie einige Schlüsselwörter für Technologien entfernen, die Sie in Ihrem Lebenslauf nicht gutheißen. In der Regel sind jedoch die beiden Probleme getrennt, und Sie können sogar jemanden haben, der sagt: “Meine Identität ist, dass ich ein Python-Programmierer bin”, wie ich in einer Folie gezeigt habe, und dann in Ihrem Lebenslauf 20+ Schlüsselwörter angeben. Die beiden Dinge schließen sich nicht aus; sie können sogar gleichzeitig auftreten. Unterschätzen Sie auch nicht die Tatsache, dass die Identität manchmal mit etwas Aspirationalem verbunden sein kann, etwas, das Sie erwerben möchten. Sie können sagen: “Bisher habe ich Python programmiert, aber ich möchte ein Rust-Programmierer werden, also betrachte ich mich als Rust-Programmierer, obwohl ich bisher hauptsächlich Python gemacht habe.” Es sind alle Arten von Verhaltensweisen möglich.

Frage: Softwaretechnik gilt als Hilfswissenschaft für die Supply Chain. Welche Hilfswissenschaften gibt es für die Softwaretechnik?

Wahrscheinlich sind Psychologie, Soziologie und Ethnologie alle relevante Bereiche, wenn es um Softwaretechnik geht. Wenn Sie es als Interaktion von Menschen betrachten, sind diese Hilfswissenschaften entscheidend. Um ernsthafte Arbeit in der Softwaretechnik zu leisten, geht es nicht nur um die Softwaretechnologie, obwohl Sie den Softwarekontext verstehen müssen, damit die Interaktionen zwischen Menschen Sinn ergeben. Sie müssen nicht unbedingt verstehen, was in den Code eingeht, aber Sie müssen Konzepte wie Codebasis oder die vorhandenen Tools und die Probleme, die sie lösen sollen, verstehen. Für diese Reihe von Vorlesungen zur Supply Chain muss ich jedoch eine Grenze ziehen und entscheiden, was ich einschließe und was nicht, da ich offensichtlich nicht jedes einzelne Forschungsfeld abdecken kann.

Frage: Fragen Sie zehn kluge Menschen nach einer Lösung, und sie werden mehr als zehn Möglichkeiten finden. Sich auf eine der fünf besten Lösungen zu einigen und sie konsequent zu verwenden, ist besser. Wie balancieren Sie diese beiden widersprüchlichen Ansätze und Vorteile?

Das ist eine sehr umfassende Frage, aber wenn ich versuche, sie im speziellen Fall der Softwaretechnik zu formulieren, können Sie viele Vorschläge haben, aber nicht alle sollten mit dem gleichen Gewicht betrachtet werden. Es gibt eine Fähigkeit, einen langfristigen Blick auf Software zu haben. Wenn ich sage, dass Sie sich auf das konzentrieren sollten, was sich nicht ändert, stellt sich heraus, dass einige Menschen sehr gut in dieser Arbeit sind und andere nicht. Erfahrung spielt eine Rolle, wenn Sie sehen wollen, wer die Fähigkeiten für diesen langfristigen Blick und das, was sich nicht ändert, hat. Meiner bescheidenen Erfahrung nach dauert es in der Regel mindestens 35 Jahre, bis jemand sehr gut darin wird, und die besten Leute sind über 60. Es braucht Jahre an Erfahrung, um die Bewegung und die Muster zu erkennen.

Wenn Sie sagen, dass Sie so viele Menschen haben, ist eine Illusion, dass all diese Lösungen gut aussehen, aber das ist nur ein Erscheinungsbild. Sie wissen nicht, wie viel Aufwand es kosten wird, um es auszuprobieren. Können Sie es einfach prototypisieren oder testen? Unter diesen zehn Personen gibt es einige mit einzigartigen Fähigkeiten, um Lösungen zu identifizieren, die langfristig schädlich sein werden? Denken Sie daran, dass Ihre Wartungskosten im Wesentlichen von den Entscheidungen bestimmt werden, die Sie getroffen haben. Gibt es eine wichtige Entscheidung, die Ihnen langfristig schaden kann?

Dies ist ein heikler Aspekt, und übrigens kann jemand, der den langfristigen Blick hat, erklären, warum eine bestimmte Option langfristig alle möglichen Probleme verursachen wird. Es ist nicht nur eine Ahnung oder Intuition. Sie werden Ihnen sagen: “So etwas, schon erlebt, schon gesehen. Ich habe das in anderen Produkten gesehen.” Es gibt ein Sprichwort: Der kluge Mann lernt aus seinen eigenen Fehlern, aber der weise Mann lernt aus den Fehlern anderer. Das trifft in diesem Fall sehr zu.

Frage: Wie messen Unternehmen die Steigerung der operativen Effizienz pro investiertem Dollar bei der Implementierung von Software für die Supply Chain?

Dies ist eine unglaublich schwierige Frage. Das Problem liegt buchstäblich in der Unvergleichbarkeit von Paradigmen. Es stammt aus der Erkenntnistheorie; die Idee ist, dass wenn man von einer Betriebsweise zu einer anderen übergeht und diese Paradigmen radikal unterschiedlich sind, die meisten Maßnahmen einfach sinnlos sind. Betrachten wir zum Beispiel den Telefonverkauf im Vergleich zum E-Commerce. Versandhandelsunternehmen existierten bereits seit Mitte des 19. Jahrhunderts. Wenn man den E-Commerce als Verbesserung gegenüber Versandhandelsunternehmen betrachtet, könnte man versuchen, die Verbesserung zu messen, aber die Realität ist, dass praktisch jedes einzelne Versandhandelsunternehmen bankrott gegangen ist. Die E-Commerce-Unternehmen, die heute dominieren, sind um mehrere Größenordnungen größer als das größte Versandhandelsunternehmen, das es je gab. Amazon ist wahrscheinlich 100-mal größer als das größte historische Versandhandelsunternehmen, und der Vergleich ist sehr unscharf.

Die Mechanisierung intellektueller Arbeit ist so unglaublich beunruhigend und verwirrend, weil sie nicht wie die physische Welt ist. Bei der physischen Produktion kann man die Effizienz auf kanonische Weise messen. Wenn man jedoch seine intellektuelle Arbeit mechanisiert, was bedeutet Effizienz überhaupt? Für ein Unternehmen wie Amazon wird die gesamte Supply Chain vollständig von Software gesteuert. Wenn die Mitarbeiter einfach zu Hause bleiben und nichts tun würden, vermute ich, dass die gesamte Supply Chain trotzdem reibungslos funktionieren würde, selbst wenn all diese Ingenieure einen Tag oder zwei lang nichts tun würden. Warum behält Amazon also diese Ingenieure? Nun, weil sie in ihre Verbesserungen investieren.

Übrigens, eine interessante Sache an Jeff Bezos ist sein Managementprozess namens “disagree but commit”. Er sagt, dass es Projekte gibt, bei denen sein Bauchgefühl als CEO ihm sagt, dass es falsch ist, und er widerspricht dem Projekt. Er verpflichtet sich jedoch, das Projekt finanziell zu unterstützen, weil er die Menschen, die daran arbeiten, eingestellt hat und ihnen vertraut. Es ist eine Art schizophrenischer Ansatz - als CEO sollte er die ultimative Autorität im Unternehmen sein, aber er gibt diese Autorität auf und sagt: “Ich widerspreche, aber du kannst das Budget haben und weitermachen.”

Der Grund für diesen Ansatz ist, dass Softwareprojekte in der Regel ziemlich günstig sind. Wenn jemand mit einer scheinbar verrückten Idee kommt, die nicht sehr teuer ist und das Unternehmen nicht in den Bankrott treibt, warum nicht einen Versuch wagen? Wenn es funktioniert, könnte es eine brillante Idee sein. Dies stellt einen Kulturschock dar, wenn man von traditionellen Supply-Chain-Unternehmen wechselt, in denen das Management die Vision haben und die Teams antreiben soll. Im Bereich der Software geht es bei der Führung hauptsächlich darum, Probleme zu lösen, die bei Softwareingenieuren auftreten.

Bei Lokad liegt der Schwerpunkt bei Investitionen in Software nicht auf dem Dollarertrag. Stattdessen geht es darum, ob die Investition einen grundlegenden Aspekt des Supply Chain Managements anspricht. Wenn es für eine Vielzahl von Supply-Chain-Situationen von zentraler Bedeutung ist, lohnt es sich, es zu verfolgen.

Zum Beispiel ist es im Bereich des Automobil-Ersatzteilmarktes von entscheidender Bedeutung, das Problem der mechanischen Kompatibilität anzugehen. Sie verkaufen Autoteile nicht, um Menschen zu dienen; Sie verkaufen Teile, um Autos zu dienen. Ein einzelnes Teil kann mit mehreren Fahrzeugen kompatibel sein, und einige Teile können sich mechanisch überschneiden. Dieses Problem muss angegangen werden; es ist Kerngeschäft. Wenn Sie es nicht angehen, wird es jemand anderes tun, und Sie werden letztendlich aus dem Markt gedrängt.

In Bezug auf Softwareinvestitionen ist es wichtig, Risiken einzugehen und Innovationen zu begrüßen, solange sie die finanzielle Stabilität des Unternehmens nicht gefährden.

Frage: Es ist irreführend zu sagen, dass große Projektteams lächerlich sind. Bei ERP-Systemen könnte ein 10-köpfiges Team für die Entwicklung gut sein, aber größere Projekte erfordern mehr Personen. Für den Bau eines Turms sind mehr Personen erforderlich als für ein Haus. Könnten Sie Ihre Kommentare klären?

Ich werde eine Position einnehmen, die viele Menschen verärgern könnte. Die Lebensgrundlage von Millionen Menschen hängt von unglaublich großen IT-Unternehmen ab. In den USA im Jahr 2020 repräsentierten IT-Unternehmen drei Millionen amerikanische Mitarbeiter. Wenn ich also sage, dass es absolut keinen Grund gibt, ein ERP zu haben, für das so viele Menschen erforderlich sind, werden natürlich alle Menschen, die ihren Lebensunterhalt entweder durch den Verkauf großer Teams verdienen oder Teil eines solchen Teams sind, energisch mit mir widersprechen.

Mein Gegenargument lautet: Kommt Ihr Widerspruch aus wissenschaftlichen Gründen, die erklären, warum die Arbeit nicht mit weniger Personen erledigt werden kann, oder liegt es in Ihrem eigenen finanziellen Interesse, den Status quo aufrechtzuerhalten und eine Armee von Menschen für die Arbeit zu haben? Wenn wir uns all die Innovationen anschauen, die stattgefunden haben - die kreative Zerstörung, die der Ökonom Schumpeter beschrieben hat - gab es jedes Mal eine massive Produktivitätssteigerung, wenn eine wichtige wirtschaftliche Innovation stattfand. Aber diejenigen, die hinter der Kurve zurückblieben, kämpften verbittert dagegen an, dass diese Innovationen stattfanden.

ERPs sind nichts Neues; sie existieren im Wesentlichen seit vier Jahrzehnten. Die meisten ERPs, die ich heutzutage sehe, bieten im Vergleich zu denjenigen, die Unternehmen vor ein oder zwei Jahrzehnten hatten, keinen großen Mehrwert. Ich habe viele ältere ERPs gesehen, die völlig in Ordnung sind, und neue ERPs sind oft nicht wesentlich besser, insbesondere wenn man die Millionen betrachtet, die in ERP-Migrationsprojekte investiert werden. In diesen massiven Projekten sehe ich eine erschreckend geringe Produktivität von den IT-Unternehmen.

Mein Gegenargument besteht darin, Unternehmen wie JD.com, Amazon oder Rakuten zu betrachten. Wie viele Menschen benötigen diese Unternehmen, um ähnliche Aufgaben zu erledigen? In der Regel endet man mit irrsinnigen Verhältnissen. Zum Beispiel hat Zalando, ein großes europäisches E-Commerce-Unternehmen mit Sitz in Berlin, Deutschland, sein eigenes ERP mit einem Team entwickelt, das kleiner ist als die meisten Teams, die ich für Unternehmen ähnlicher Größe gesehen habe, die ihre ERP migrieren müssen. Sie sehen also, auf der einen Seite haben Sie ein Unternehmen wie Zalando, das in der Lage ist, sein eigenes ERP zu entwickeln, das vollständig auf ihre Bedürfnisse zugeschnitten ist. Es erfüllt seine Aufgabe als geeignetes ERP sehr gut, und die Kosten und die Anzahl der beteiligten Personen sind nur ein Bruchteil dessen, was andere Unternehmen ähnlicher Größe benötigen, um nur ein Versionsupgrade durchzuführen. Die Kosten sind wiederum nur ein Bruchteil. Ich frage mich, ob es notwendig ist, so viele Menschen einzubeziehen, und das ist das Problem mit der Büroarbeit im 21. Jahrhundert. Um ein sehr guter Mitarbeiter zu sein, bedeutet das, den Mut zu haben, sich selbst zu automatisieren, sich selbst überflüssig zu machen.

Das ist etwas sehr Besonderes. Als die Arbeiter in der Produktion überflüssig gemacht wurden, wurde dies von anderen getan. Aber heutzutage gibt es kaum noch Arbeiter in der Produktion. Es erfordert eine andere Denkweise, und deshalb gibt es Schwierigkeiten, sich an dieses neue Paradigma anzupassen, das hauptsächlich aus der Softwarebranche stammt. Es ist in Ordnung, sich selbst überflüssig zu machen, weil man sich tatsächlich nicht überflüssig macht; der menschlichen Einfallsreichtum sind keine Grenzen gesetzt. Man automatisiert nur einige Aufgaben, um sich selbst für die nächste Herausforderung frei zu machen, die noch interessanter ist als die vorherige. Unternehmen wie Amazon entlassen ihre Softwareingenieure nicht, sobald sie ein Problem gelöst haben. Sie belohnen sie und befördern sie, um sich der nächsten, schwierigeren Aufgabe zu stellen.

Als Antwort auf eine Frage zur Analyse des Denkens von Supply-Chain-Praktikern nach dem Zweiten Weltkrieg stimme ich zu, dass sich die Softwareentwicklung für viele Unternehmen, nicht für alle, weiterentwickelt hat. Sie definiert sich selbst als ein Prozess der Zusammenarbeit oder ein interpretativer Prozess. Dem stimme ich zu. Die Softwarebranche dreht sich nicht nur um harte, technische Fähigkeiten. Obwohl einige Positionen unglaubliche quantitative technische Fähigkeiten erfordern, betrachtet sich der Großteil der Softwarebranche als eine Branche mit einem menschenorientierten Ansatz, einer gemeinsamen Kultur.

In großem Maße glaube ich, dass die Dominanz der USA und des Silicon Valley in der Softwarebranche weltweit auf die Schwierigkeit zurückzuführen ist, ihre Kultur zu replizieren. Kultur ist oft sehr schwer fassbar und schwer zu dokumentieren. Wenn man sie dokumentiert, zähmt man die chaotische Zutat, die für Innovationen notwendig ist. Wenn man die Kultur dokumentiert, organisiert und verarbeitet, verliert man plötzlich diesen Aspekt der rohen, chaotischen Entstehung von Ideen und Innovationen.

Es gibt Orte wie das Silicon Valley, wo diese Kultur vorherrscht, und sie sind in dieser Hinsicht ihrer Zeit voraus. Um dieses Thema abzuschließen, möchte ich William Gibson zitieren, der sagte: “Die Zukunft ist bereits da, sie ist nur ungleich verteilt.” Ich sehe, dass diese Kultur jetzt auf viel kleineren Skalen an vielen anderen Orten repliziert wird und der Prozess im Laufe der Zeit weitergehen und wachsen wird.

Das ist alles für heute. Bis zum nächsten Mal. In unserer nächsten Sitzung werden wir ein Thema besprechen, das ziemlich deprimierend sein kann, aber sehr wichtig ist: Cybersicherheit. Bis zum nächsten Mal!