Software-Engineering für supply chain - Lecture 4.6

00:02 Einführung
01:43 Mechanisierung
07:34 Jenseits des Paradoxons
12:14 Die bisherige Geschichte
14:32 Heutige Submodule
16:24 Anforderungen (mainstream 1/5)
20:12 Design (mainstream 2/5)
25:37 Implementierung (mainstream 3/5)
30:29 Testen (mainstream 4/5)
34:09 Wartung (mainstream 5/5)
41:12 Identität (Schützengräben 1/8)
46:35 Fortsetzung (Schützengräben 2/8)
51:43 Praktiken (Schützengräben 3/8)
56:47 Bastionen (Schützengräben 4/8)
01:02:00 Code-Schreiber (Schützengräben 5/8)
01:06:23 Schmerztoleranz (Schützengräben 6/8)
01:14:55 Produktivität (Schützengräben 7/8)
01:21:37 Das Unbekannte (Schützengräben 8/8)
01:27:00 Fazit
01:29:55 4.6 Software-Engineering für supply chain - Fragen?

Beschreibung

Die Beherrschung von Komplexität und Chaos ist das Fundament des Software-Engineering. Angesichts der Tatsache, dass supply chains sowohl komplex als auch chaotisch sind, sollte es nicht allzu überraschend sein, dass die meisten Probleme mit Enterprise-Software in supply chains auf schlechtes Software-Engineering zurückzuführen sind. Numerical recipes zur Optimierung von supply chains sind Software und unterliegen daher demselben Problem. Diese Probleme nehmen mit der zunehmenden Raffinesse der Numerical recipes selbst an Intensität zu. Richtiges Software-Engineering ist für supply chains das, was Asepsis für Krankenhäuser ist: an sich bewirkt es nichts – wie die Behandlung von Patienten – aber ohne es zerfällt alles.

Transkript

Willkommen zu dieser Reihe von supply chain-Vorlesungen. Ich bin Joannes Vermorel, und heute präsentiere ich „Software Engineering für supply chain.“ Software bildet die Grundlage einer modernen supply chain-Praxis, dennoch wird in den meisten supply chain-Lehrbüchern die Rolle der Software in supply chain stark unterbewertet. Software für supply chain ist nicht nur eine Anforderung wie der Zugang zu Transportmitteln; es ist viel mehr als das. Aus der Perspektive von supply chain-Praktikern wird der Großteil der Arbeit von Software bestimmt, verursacht durch Softwarefehler oder die Einschränkungen der Software und softwarebezogene Probleme.

Software-Engineering ist die Disziplin, die den Anspruch verfolgt, Menschen dabei zu helfen, bessere Software zu erschaffen, mehr aus Software herauszuholen, diese Software schneller zu entwickeln und dabei weniger Aufwand für mehr Erfolge zu betreiben. Ziel dieser Vorlesung ist es, zu verstehen, worum es im Software-Engineering geht und welche zentrale Bedeutung es für supply chain hat. Zudem soll verstanden werden, was Sie als supply chain-Praktiker tun können, um zu vermeiden, dass Ihre Softwarevorhaben durch Handeln oder Unterlassen, das leider bereits Ihren Software-Initiativen schadete, gefährdet werden.

Das 20. Jahrhundert war das Jahrhundert der Mechanisierung der Arbeitskraft. Große Unternehmen und große supply chains, wie wir sie kennen, entstanden im 20. Jahrhundert, und der Fortschritt, der durch die Mechanisierung der Arbeitskraft erzielt wurde, war unglaublich. Im Laufe des letzten Jahrhunderts hat sich die Produktivität bei fast jeder arbeitsintensiven Aufgabe, die für supply chain von Bedeutung ist, wie etwa in der Produktion oder im Vertrieb, um das Hundertfache gesteigert.

Im Gegenteil, ich bin der Meinung, dass das 21. Jahrhundert das Jahrhundert der Mechanisierung geistiger Arbeit ist und sein wird, und dieser Übergang ist sehr schwer zu begreifen. Die Intuition, die bei der Mechanisierung der physischen Arbeitskraft angewendet wird, lässt sich keineswegs auf die Mechanisierung geistiger Arbeit übertragen. Ich behaupte nicht, dass der Übergang weniger dramatisch ist, aber die Realität ist, dass der Übergang hin zur Eliminierung der Arbeitskraft, die sich mit sehr arbeitsintensiven Aufgaben beschäftigte, bereits vorbei ist.

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

Hans Moravec, ein Informatiker, bemerkte 1980, dass im Bereich der Rechnertechnik Aufgaben, die für den menschlichen Verstand am schwierigsten schienen, wie beispielsweise das Erreichen eines Großmeistertitels im Schach, tatsächlich die Aufgaben waren, die sich am einfachsten mit Computern bewältigen ließen. Im Gegensatz dazu erweisen sich Aufgaben, die für Menschen extrem einfach erscheinen, wie etwa auf zwei Beinen aufrecht zu stehen, als unglaublich schwierig für Computer. Das ist das Wesen des Moravec-Paradoxons: Unsere Intuition darüber, was im Hinblick auf geistige Aufgaben mit Computern schwer zu erreichen ist, täuscht sehr.

Ein weiterer Aspekt, der das Problem zusätzlich verkompliziert, ist, dass, wenn es um die Automatisierung von Büroangestellten geht, dies plötzlich von den Büroangestellten selbst vorgenommen wird. Dies war bei den blue-collar workers in den Fabriken nicht der Fall; sie waren es nicht, die entschieden haben, dass die Fabrik weiter automatisiert wird und ihre Arbeitsplätze wegfallen. Doch genau das geschieht bei Bürojobs. Damit stehen wir vor einer Herausforderung, bei der nicht nur der Automatisierungsprozess aufgrund des Moravec-Paradoxons zutiefst kontraintuitiv ist, sondern auch das Management derjenigen, die mit der Umsetzung dieser Automatisierung betraut sind – nämlich der Software Engineers – das Ganze sehr kontraintuitiv macht. Dies ist vermutlich eine der größten Herausforderungen für supply chain: das Management der Menschen, die auf die eine oder andere Weise für die Bewältigung dieser Automatisierung verantwortlich sind.

Hier muss ich anmerken, dass viele supply chains und die zugehörigen Unternehmen noch immer fest in einer Denkweise des 20. Jahrhunderts verankert sind, in der man die Geschäftswelt so angeht, als ob Bürokräfte die geistige Arbeit verrichten würden, die dann eine Lösung oder einen Plan entwickeln, der anschließend an blue-collar workers zur Ausführung übergeben wird. Bei einem Verhältnis von 27 zu 1 in Frankreich zwischen Bürojobs und Fabrikjobs – und vermutlich ähnlichen Statistiken in den meisten Industrieländern – entspricht dies jedoch nicht mehr der aktuellen Realität. Es geht buchstäblich darum, die 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 Neuem überzugehen. Dies ist für viele Unternehmen, die noch stark in der Denkweise des 20. Jahrhunderts verankert sind, eine große Herausforderung.

Die Meinungen gehen weit auseinander, wenn es um den Begriff des Software-Engineering geht. Eine der schärfsten Kritiken kam von Edsger Dijkstra, einem der Gründerväter der Informatik. Nach seiner Ansicht ist Software-Engineering nicht einmal als Disziplin oder Forschungsfeld möglich, und er sagte, dass es sich letztlich auf etwas wie „Wie programmiert man, wenn man es nicht kann“ reduziert – eine Art Anleitung. Die Kritik Dijkstras, die sehr interessant ist, besteht darin, dass Software-Engineering in eine Art Selbsthilfe-Fiktion abgleitet, die niemals erfolgreich sein kann. Tatsächlich, wenn wir annehmen, dass das Ziel des Software-Engineering darin besteht, den Erfolg bei der Erstellung nützlicher, überlegener Software zu sichern, dann ist Software-Engineering weitgehend zum Scheitern verurteilt. Erfolg in der Software ist unglaublich schwierig; er ist genauso schwer zu erreichen wie Erfolg in der Wissenschaft. Es bedarf eines Funkens Genie, eines ordentlichen Quäntchens Glück, und es gibt kein Rezept dafür. Zudem neigt jeder einzelne Erfolg dazu, die Möglichkeit, die zu diesem Erfolg geführt hat, aufzuzehren, sodass das Ganze nicht replizierbar wird.

Ich hingegen stimme der Ansicht nicht zu, dass Software-Engineering zum Scheitern verurteilt sei. Ich glaube, dass das Hauptproblem darin besteht, den Anspruch des Software-Engineering zu definieren. Wenn wir festlegen, dass das Ziel des Software-Engineering der Erfolg bei der Entwicklung von Software ist, dann ist es in der Tat zum Scheitern verurteilt. Entscheiden wir uns jedoch, Software-Engineering als einen engen Teilbereich der experimentellen Psychologie zu betrachten, bin ich überzeugt, dass wir darüber sehr wertvolle und umsetzbare Erkenntnisse gewinnen können – und das ist die Perspektive, die ich heute in dieser Vorlesung einnehmen werde. Somit geht es beim Software-Engineering um die Software Engineers selbst und ihre Interaktionen. Den Fokus auf die Software Engineers zu legen, ist ein guter Ausgangspunkt, weil die menschliche Natur über die Zeit hinweg stabil ist, im Gegensatz zur Softwaretechnologie, die sich ständig ändert. Die Natur der Menschen, die sich mit dieser Technologie auseinandersetzen, ändert sich dagegen nicht; die menschliche Natur ist seit sehr langer Zeit sehr stabil.

Wenn wir uns andere Bereiche, wie die Wissenschaft, ansehen, erkennen wir, dass ein Ansatz, bei dem man das Feld durch die Brille dessen betrachtet, was die Praktiker tun, sehr ergiebig sein kann. Beispielsweise ist in der Wissenschaft inzwischen allgemein bekannt, dass Interessenkonflikte zu schlechter Wissenschaft und zur Verzerrung von Wissen führen. Dieser Punkt wurde bereits in der Vorlesung „Adversarial Market Research for Enterprise Software“ behandelt. Aus dieser Perspektive sehen wir, dass es möglich ist, Erkenntnisse mit breiter Anwendbarkeit und Relevanz zu gewinnen, wenn wir uns auf die Praktiker selbst konzentrieren. Somit geht es im Software-Engineering um die Menschen, die sich mit Softwaretechnologie auseinandersetzen, um ihre Herausforderungen und Prozesse – und nicht so sehr um die Technologie selbst.

Heute ist die sechste Vorlesung der vier Kapitel. Dieses Kapitel ist den Hilfswissenschaften der supply chain gewidmet. Diese Hilfswissenschaften stellen Elemente dar, die meiner Meinung nach von grundlegender Bedeutung für eine moderne supply chain-Praxis sind, aber streng genommen keine supply chain-Elemente darstellen. Sie sind eher unterstützende Elemente für Ihre supply chain-Praxis.

Bisher, in diesem vierten Kapitel, begannen wir mit der Physik des Rechnens und beschäftigten uns mit modernen Computern, und dann erklommen wir eine Leiter der Abstraktionen. Wir gingen von Computern zu Algorithmen, die die winzigsten, kleinsten interessanten Elemente in der Software darstellen. Anschließend wandten wir uns der mathematischen Optimierung zu, die für supply chain interessant ist, aber auch für viele andere relevante Softwareprojekte, wie zum Beispiel machine learning. Wir haben gesehen, dass mathematische Optimierung direkt interessant für supply chain ist, aber auch unmittelbar für machine learning von Bedeutung ist, was wiederum auch für supply chain relevant ist.

Was die mathematische Optimierung und das machine learning betrifft, so sind die meisten der heutzutage interessanten Konzepte und Paradigmen programmgesteuert. Es handelt sich nicht nur um einfache Algorithmen; es ist etwas unglaublich Ausdrucksstarkes, das durch die Brille von Programmiersprachen betrachtet werden muss. Deshalb handelte die letzte Vorlesung von Sprachen und Compilern.

Heute steigen wir auf dieser Leiter der Abstraktionen weiter empor und konzentrieren uns auf die Menschen, anstatt darauf, was sie tun. Wir werden uns auf die Software Engineers selbst fokussieren, und genau das ist der Kern dieser Analyse des Software-Engineering.

Heute werde ich speziell zwei Perspektiven zum Software-Engineering vorstellen. Zunächst präsentiere ich die Mainstream-Ansicht, von der ich glaube, dass sie das Feld dominiert. Leider hat diese Mainstream-Ansicht, wie bereits erwähnt, Kritik hervorgerufen, da Menschen Selbsthilfeansätze vertreten, denen – auch ich persönlich – Gründe entgegenstehen, weil sie keinen realistischen Anspruch an die Disziplin des Software-Engineering vermitteln. Dennoch werde ich diese Mainstream-Ansicht beleuchten, wenn auch nur, weil einige fehlgeleitete Vorstellungen nach wie vor unglaublich populär sind. Mit diesen fehlgeleiteten Konzepten vertraut zu sein, ist von zentraler Bedeutung, um inkompetente Personen ausfindig zu machen, die supply chain durch ihre Inkompetenz gefährden könnten.

Anschließend wende ich mich einer Perspektive aus dem Schützengraben zu, einer Sammlung von Elementen, die in meiner persönlichen Erfahrung als CEO eines Softwareunternehmens verwurzelt sind, das genau im Bereich der Enterprise supply chain-Software tätig ist. Wie wir sehen werden, beziehen sich die Erkenntnisse vor allem auf die Menschen und nicht so sehr auf die Technologie selbst.

Die Mainstream-Ansicht des Software-Engineering besagt, dass eine Software-Initiative mit der Sammlung von Anforderungen für die betreffende Software beginnt. Die meisten Software-Initiativen in großen Unternehmen übernehmen diese Perspektive durch einen Prozess, der typischerweise mit einer Request for Proposal (RFP), Request for Quote (RFQ) oder Request for Information (RFI) startet. Dieser Ansatz stammt aus den Praktiken des 20. Jahrhunderts, die im Maschinenbau und Bauwesen sehr erfolgreich waren. Ich bin jedoch der Meinung, dass diese Ansätze zur Anforderungserhebung, was Software betrifft, zutiefst fehlgeleitet sind.

In der Software weiß man nicht, was man will; das tut man einfach nicht. Zu wissen, was man will, ist stets der schwierigste Teil bei Software. Wenn wir zum Beispiel ein einfaches Problem wie die Lager Lagerauffüllung betrachten, ist die Problemstellung unglaublich einfach: Jederzeit möchte ich die Menge wissen, die ich für jede einzelne SKU wieder auffüllen oder nachbestellen sollte. Das Problem selbst ist simpel, doch die Definition einer guten Menge erweist sich als teuflisch komplex und schwierig. Als Faustregel gilt, dass die Klärung der Anforderungen weitaus schwieriger ist als das Schreiben des Stücks Software selbst.

Es ist nur, wenn man seine Intuition mit dem Feedback der realen Welt konfrontiert, dass die Anforderungen allmählich entstehen können. Die Anforderungen fallen nicht vom Himmel; sie können nur durch einen ziemlich experimentellen Prozess gewonnen werden, und man muss diese Interaktion mit der realen Welt haben. Allerdings ist der einzige Weg, diese Interaktion zu ermöglichen, das Softwareprodukt zu besitzen, denn das Sammeln von Anforderungen ist im Grunde ein sehr empirischer und sich entwickelnder Prozess. Das Problem besteht darin, dass, sobald man mit den Anforderungen fertig ist, deren Vorhandensein bedeutungslos wird, denn wenn man die Anforderungen hat, bedeutet das, dass man bereits das entsprechende Produkt besitzt, das diese Anforderungen umsetzt. Somit, wenn man endlich Zugang zu den richtigen Anforderungen hat, läuft das Produkt bereits in Produktion, und die Tatsache, dass man diese Anforderungen hat, ist etwas irrelevant.

Der Punkt ist also, dass es meines Erachtens Wahnsinn ist, den Prozess durch die Linse der Anforderungen zu beginnen. Anforderungen sollten vermutlich zuletzt als Dokumentation in der Endphase kommen, in der man alle Kerngründe festhält, die einen dazu veranlasst haben, das Produkt so umzusetzen, wie man es getan hat – und nicht umgekehrt.

Sobald die Anforderungen festgelegt sind, besagt der klassische Ansatz, dass man mit der Entwurfsphase fortfahren muss. Ich stimme zu, dass irgendwann ein gewisser Entwurf stattfindet. Allerdings ist die Denkweise, die in diese Entwurfsphase einfließt, häufig fehlgeleitet. Das Problem reduziert sich darauf, die Änderungs­kosten unter Kontrolle zu bringen. Die klassische, nicht-softwarebezogene Sichtweise auf die Änderungs­kosten besagt, dass diese im Laufe der Zeit exponentiell steigen. Zum Beispiel, wenn man das Design eines Autos sehr früh ändert, wenn man sich lediglich mit einem Plan beschäftigt, sind die Änderungs­kosten minimal. Im Gegensatz dazu, wenn man wartet, bis Millionen dieser Autos auf den Straßen sind, sind die Änderungs­kosten unglaublich hoch, da das einen Rückruf zur Folge hat, der unglaublich teuer sein kann.

Allerdings steigen die Änderungs­kosten im Softwarebereich, im Gegensatz zum physischen Bereich, nicht von Natur aus exponentiell an. Der Kostenanstieg kann nicht vollständig vermieden werden; jedoch lässt er sich in großem Maße kontrollieren. Tatsächlich nehmen die Änderungs­kosten im Laufe der Zeit zu, vor allem weil Codebasen tendenziell wachsen. Ich habe noch nie gesehen, dass eine Codebasis eines Enterprise-Softwareprodukts von einem Jahr zum nächsten signifikant schrumpft; sie neigen dazu, weiter zu wachsen. Dennoch ist es möglich, die Änderungs­kosten bis zu einem gewissen Grad zu steuern.

Heutzutage wird dieser Aspekt sogar in Softwarekreisen zunehmend anerkannt. Übrigens ist dies das Wesen der Agile-Methodik. Man hat diese Begriffe vielleicht schon gehört, wenn Leute sagen: “Oh, wir haben diese Agile software methodology.” Eines der Hauptziele der Agile-Methodik ist es, die Änderungs­kosten unter Kontrolle zu bringen. Ich werde heute nicht auf die Kleinigkeiten der Agile-Methodik eingehen, aber es reicht zu sagen, dass ich diesen Ansatz etwas fehlgeleitet finde, wenn es darum geht, genau zu regeln, wie man diese Änderungs­kosten kontrollieren kann.

Ich habe festgestellt, dass die Änderungs­kosten hauptsächlich aus den Entscheidungen resultieren, die bezüglich der Software getroffen werden, und insbesondere aus der Tatsache, dass es sehr schwerfällt, dem Drang, Entscheidungen zu treffen, zu widerstehen. Stellen Sie sich vor, Sie blicken auf ein potenzielles zukünftiges Softwareprodukt, und es gibt zahlreiche Entscheidungen zu treffen. Der erste Versuch wäre, diese Entscheidungen zu treffen, nur um zu klären, was vor Ihnen liegt. Im Gegenteil: Eine sehr gute Entwurfsphase, im Gegensatz zu einem guten Design, besteht darin, alle Entscheidungen, die nicht absolut notwendig sind, aufzuschieben, solange das Produkt diese Entscheidungen nicht jetzt benötigt. Tatsächlich, wenn Sie die Entscheidung nicht treffen, solange die Entscheidung nicht getroffen ist und Sie nicht festgelegt haben, dass Sie diesen speziellen Entwurfs- oder technologischen Ansatz wählen müssen, schwebt sie weiterhin in der Luft und kann jederzeit geändert werden, weil noch nichts entschieden wurde.

Einer der Aspekte, um die Änderungs­kosten unter Kontrolle zu halten, besteht darin, zu lernen, alle Entscheidungen so weit wie praktisch möglich aufzuschieben. Aus der supply chain-Perspektive wirkt das sehr seltsam, da es bedeutet, dass für alle Mitglieder des Softwareteams und alle Beobachter des Produkts es so aussieht, als würden sie im Dunkeln gehalten. Es ist sogar noch schlimmer, weil sie absichtlich im Dunkeln gehalten werden, was sehr rätselhaft ist. Dennoch ist genau das notwendig, und es muss absichtlich geschehen. Deshalb ist es, gelinde gesagt, beunruhigend.

Nun, wenn vorzeitige Designentscheidungen in dem manchmal fehlgeleiteten Bedürfnis nach Kontrolle verwurzelt sind, hören die mit diesem Kontrollbedürfnis verbundenen Probleme nicht dort auf. Sobald die Entwurfsphase abgeschlossen ist, besagt die gängige Sichtweise in der Softwaretechnik, dass wir mit dem Bau der Software fortfahren sollten, der auch häufig als Implementierungsphase bezeichnet wird. Typischerweise wird dabei eine Art Wasserfallprojektion präsentiert, auch Gantt-Diagramme genannt. Das ist es, was Sie auf dem Bildschirm sehen. Ich glaube, dass dieser Ansatz – Gantt-Diagramme und Wasserfälle – unglaublich toxisch ist, und die Toxizität dieses Ansatzes wird in Bezug auf Software oftmals unterschätzt. So an das Problem heranzugehen bedeutet buchstäblich, dass Ihre supply chain zum Scheitern verurteilt ist, zumindest was ihre Softwareinitiativen betrifft.

Ein viel besserer Weg, das Problem zu verstehen und den Bau der Software anzugehen, besteht darin, diesen als einen Lernprozess zu begreifen. Der Bau der Software dreht sich darum, alles zu lernen, was nötig ist, um ein gutes Produkt zu schaffen. Dies ist ein Lernprozess, und all das Gelernte ist ein Nebenprodukt der Interaktion der Welt mit der Software, die im Entstehungsprozess ist. Das zentrale Problem bei einer Wasserfallprognose besteht darin, dass man das projiziert, was man gleich entdecken wird. Definitionsgemäß ist das schlichtweg unmöglich. Was Sie gleich entdecken werden, war unbekannt, bis Sie diese Elemente entdecken. Sie können Ihre Entdeckungen nicht vorhersagen. Sie können sie erwarten, aber die Details dessen, was Sie entdecken werden, lassen sich nicht planen. Sie können Vermutungen haben, aber das ist das Beste, was Sie erreichen können. Die Vorstellung, dass man diese vagen Intuitionen in eine präzise Wasserfallprognose umwandeln kann, ist erneut völliger Wahnsinn.

Übrigens erklärt dieses scheinbare Paradox – nämlich den Bau von Software als einen Lernprozess – auch, warum die Replikation eines Softwareprodukts manchmal unglaublich einfach und manchmal unglaublich schwierig sein kann. Wenn ein Team versucht, ein bereits auf dem Markt befindliches Softwareprodukt zu replizieren und dieses Team Zugang zu dem Verständnis oder den Lektionen hat, die zur Produktion der Software geführt haben, die es zu kopieren versucht, kann die Replikation des Produkts – also die Neuimplementierung oder das Neucodieren – typischerweise mit nur einem winzigen Bruchteil der Zeit und des Budgets erfolgen, die ursprünglich für die Erstellung der Software benötigt wurden. Im Gegenteil, wenn das Team keinen Zugang zu diesen übergeordneten Einsichten hat und beispielsweise lediglich auf den Quellcode zugreifen kann, endet es sehr häufig mit einem Produkt von sehr geringer Qualität, weil im Wesentlichen all die Lernaspekte oder Wissensfragmente verloren gegangen sind. Man hat lediglich das oberflächliche Erscheinungsbild des Produkts repliziert.

Aus der supply chain-Perspektive besteht die größte Herausforderung hier darin, bereitwillig aufzugeben und das eigene Kontrollbedürfnis zu zähmen. Der Wasserfallprozess ist ein Ausdruck eines Unternehmens, das den Prozess kontrollieren möchte. Wenn ich zum Beispiel sagen würde: “Bringen wir dieses Projekt unter Kontrolle”, würde das als etwas sehr Vernünftiges wahrgenommen werden. Warum sollte man dann das Gegenteil tun? Warum sollte man beispielsweise sagen: “Lassen Sie uns dieses Projekt völlig außer Kontrolle geraten lassen?” Aber die Realität ist, dass dieser Grad an Kontrolle ein völliger Trugschluss in Bezug auf Software ist und Ihre Fähigkeit, letztlich ein hochwertiges Produkt zu liefern, völlig beeinträchtigt. Das Zähmen des Verlangens nach Kontrolle ist aus der supply chain-Perspektive wahrscheinlich die größte Herausforderung beim Bau von Software.

Seit dem Aufkommen von Computerprogrammen sind diese von Bugs und Defekten durchsetzt. Um diese offensichtlichen Probleme anzugehen, wird in der Mehrheitsmeinung davon ausgegangen, dass Tests durchgeführt werden müssen. Tests nehmen viele Formen an. Was das Bedürfnis nach Tests angeht, stimme ich zu, auch wenn dieser Punkt an dieser Stelle sehr vage ist. Einige Tools betonen, dass Tests nach der Erstellung durchgeführt werden müssen, andere betonen, dass Tests während der Erstellung erfolgen müssen, und wieder andere spezifizieren, 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 erfolgen müssen.

Meine generelle Ansicht zum Problem ist, dass man alles tun sollte, um den Feedback-Zyklus so kurz wie möglich zu halten. Wir haben diesen Punkt in der vorherigen Vorlesung besprochen: Den Feedback-Zyklus so kurz wie möglich zu halten, ist von entscheidender Bedeutung, um tatsächlich etwas zu erhalten, das in der realen Welt funktioniert. Daher würde ich grundsätzlich empfehlen, darauf zu achten, ob das, was Sie in Bezug auf Tests tun, diesen Feedback-Zyklus tatsächlich verkürzt oder nicht. Zum Beispiel würde ich in den meisten Situationen nicht automatisch testgetriebene Entwicklung empfehlen (eine Methodik, die besagt, dass Tests an erster Stelle stehen), da in den meisten Fällen das Ersttesten lediglich die Zeit verzögert, die benötigt wird, um Feedback zu Ihrem Softwareprodukt aus der größeren Welt zu erhalten.

Doch meine größte Sorge beim Testen ist eine unerzählte Einschränkung, etwas, das allgemein zu vernachlässigen scheint. Letztlich können Tests nur die Einhaltung der von Ihnen selbst festgelegten Regeln bewerten. Das Problem ist, dass es in der Software keine harten Einschränkungen gibt. Es gibt keinen naturwissenschaftlichen Ansatz, um die Angemessenheit Ihres Produkts in Bezug auf das Problem, das Sie zu lösen versuchen, zu beurteilen. Dies unterscheidet sich stark vom physischen Bereich. Beispielsweise gibt es im Maschinenbau einen kanonischen Maßstab: die Maßtoleranz eines Teils. Was auch immer Sie im Maschinenbau konstruieren, die Maßtoleranz wird von primärer Bedeutung sein. Sie ist ein offensichtlicher und natürlicher Kandidat. Allerdings gibt es in der Software keine natürlichen und offensichtlichen Kandidaten.

Das Problem hier wird zu einem der Angemessenheit. Wenn wir ein supply chain-Beispiel nehmen, wie zum Beispiel safety stocks, dann ist es völlig einfach, eine automatisierte Testsuite zu entwerfen, um die Berechnungen der Sicherheitspuffer zu validieren. Es ist sehr unkompliziert, diese Art von Testlogik zu implementieren. Allerdings kann dies nicht aussagen, dass safety stocks von vornherein eine schlechte Idee sind. Sie testen nur das, was Sie bereits kennen.

Wenn wir es mit einer physischen Maschine zu tun haben, erwarten wir Abnutzung und Verschleiß und somit auch irgendeine Art von Wartung, um die Maschine funktionsfähig zu halten. Doch warum sollte Software irgendeine Art von Wartung benötigen, um weiterzulaufen? Natürlich müssen wir Computer gelegentlich ersetzen, wenn sie im Laufe der Zeit ausfallen. Dieser Aspekt ist jedoch sehr marginal, und in der Enterprise-Software machen die physischen Ausfälle von Maschinen nicht einmal 10 % der tatsächlichen Wartungskosten aus. So etwas existiert zwar, aber die Auswirkungen dieser Art von Wartung sind unglaublich gering.

Dennoch ist die Wartung in der Enterprise-Software von zentraler Bedeutung. Die Wartungskosten sind enorm. Für viele Anbieter von Enterprise-Software machen die Wartungskosten buchstäblich 80 % oder mehr der Engineering-Kosten aus. Es stellt sich heraus, dass die Faktoren, die diesen Wartungsbedarf erzeugen, nur sehr wenig mit physikalischen Gegebenheiten zu tun haben. Der erste Faktor ist die willingness to pay der Kunden selbst. Wenn ein Anbieter mit einer jährlichen Wartungsgebühr von 20 % im Verhältnis zu dem, was im ersten Jahr für die Einrichtung der Software gezahlt wurde, davonkommen kann, wird der Softwareanbieter genau diesen Betrag berechnen. Grundsätzlich werden die Wartungskosten aus Kostensicht durch die Zahlungsbereitschaft der Enterprise-Kunden bestimmt.

Der zweite Faktor ist die Art der Wartung, die erforderlich ist, um die Software einfach am Laufen zu halten. Tatsächlich weicht mit jedem einzelnen Tag die Umgebung, die das betreffende Produkt umgibt, immer mehr von dem Produkt ab. Das Betriebssystem entwickelt sich weiter, das Datenbanksystem entwickelt sich weiter, und dasselbe gilt für all die Drittanbieter-Bibliotheken, die von der Software verwendet werden. Kein Softwareprodukt ist eine Insel. Jedes einzelne Softwareprodukt ist von zahllosen anderen Softwareprodukten abhängig, und diese anderen Produkte entwickeln sich eigenständig weiter. Die Entwickler dieser Produkte arbeiten ständig an ihnen, und während sie an diesen Produkten arbeiten, verändern sie diese kontinuierlich. So kommt es zu einem Zeitpunkt, an dem das Produkt schlicht nicht mehr funktioniert, weil eine Inkompatibilität entsteht – man hat nichts gemacht, außer nicht mit dem Rest des Marktes Schritt gehalten zu haben. Der zweite Faktor umfasst all die Wartung, die notwendig ist, um die Software am Laufen zu halten und sie kompatibel mit dem Rest des Marktes zu machen.

Der dritte Faktor ist der Aufwand, der notwendig ist, um das Produkt nützlich zu halten. Die Software wurde nämlich zu einem bestimmten Zeitpunkt entworfen und entwickelt, und mit jedem Tag weicht die Welt immer mehr von dem ab, was zum Zeitpunkt der Entwicklung als Grundlage diente. Somit stellt sich heraus, dass selbst wenn es in puncto Hardwarekompatibilität nichts wirklich zu beanstanden gibt, die Nützlichkeit des Produkts unweigerlich abnimmt, weil die Welt einfach von den im Produkt verankerten Erwartungen abweicht. Wenn Sie die Software nützlich halten wollen, müssen Sie sie ständig warten.

Aus der supply chain-Perspektive ist die Wartung eine große Herausforderung, und diesen Aspekt haben wir bereits in der vorherigen Vorlesung, die sich mit der produktorientierten Lieferung für die supply chain beschäftigte, angesprochen. Die Wartungskosten haben einen erheblichen Einfluss auf die kapitalistischen Vorteile, die Sie aus Ihrem Softwarevorhaben ziehen können. Idealerweise möchten Sie, dass Ihr Softwarevorhaben eine sehr hohe Rendite erzielt, doch um das zu erreichen, müssen Sie sicherstellen, dass Sie nicht am Ende mit massiven Wartungskosten dastehen. Diese Kosten würden den kapitalistischen Gewinn und die Rendite, die Sie aus Ihrer Softwareinvestition ziehen können, vollständig zunichtemachen.

Die größte Herausforderung hier, erneut aus a supply chain-Perspektive, besteht darin, dass der einfachste Weg, die Wartungskosten zu minimieren, darin besteht, sich auf das zu konzentrieren, was sich nicht ändert. Wie ich bereits erwähnte, beziehen sich die meisten Kosten auf die Dinge, die sich verändern – sei es im Software-Ökosystem oder in der Welt im Großen und Ganzen. Wenn man sich jedoch auf das konzentriert, was sich nicht ändert, erhält man im Wesentlichen den Großteil der Software, die nur langsam veraltet, weil eben der Großteil dessen, was Ihre Software bearbeitet, jenes ist, was sich nicht ändert.

Das Problem ist, dass es leichter gesagt als getan ist, sich auf das zu konzentrieren, was sich nicht ändert, da eine sehr menschliche Kraft dieser Absicht entgegenwirkt: die Angst, etwas zu verpassen. Wenn Sie sich die Presse, die Medien, Ihre Kollegen etc. anschauen, wird es einen ständigen Strom von Neuheiten, Schlagwörtern geben, und jedes einzelne Schlagwort verspürt – bedingt durch die Angst, etwas zu verpassen – den Drang, einfach die Sache zu tun und nicht zurückzubleiben. Zum Beispiel wären all diese Schlagwörter AI, blockchain, IoT und all die anderen Dinge, die sehr präsent sind. Ich glaube, dass diese Schlagwörter in a supply chain wirklich ablenkend wirken und erheblich zu Wartungsproblemen beitragen, weil sie von dem ablenken, was sich nicht ändert. Im Gegenteil, wenn Sie anfangen, sich diese Schlagwörter anzuschauen, reiten Sie auf einer Welle, und Sie reiten genau die Art von Dingen, die sich sehr wahrscheinlich im Laufe der Zeit verändern, wodurch Ihre Wartungskosten im Laufe der Zeit steigen.

Nun, da wir die Mainstream-Sicht auf Softwareentwicklung hinter uns gelassen haben, tauchen wir in eine Reihe persönlicher Nuggets ein, die hoffentlich nützlich sein werden, um Softwareinitiativen unter Beachtung der supply chain durchzuführen. Eines der häufigsten Probleme im Umgang mit Softwarefachleuten ist ein Missverständnis bezüglich der eigenen Identität, und ich leihe mir diese Idee von einem Unternehmer namens Paul Graham. Ein Ingenieur wird zum Beispiel sagen: “Ich bin ein Python-Ingenieur.” Auch wenn es vielleicht nicht so extrem ist, kommt es sehr häufig vor, dass Softwareingenieure ihre eigene Identität durch die kurze Reihe von Technologien wahrnehmen, die sie beherrschen und die ihren Kompetenzbereich ausmachen. Diese Verwechslung zwischen ihrer Identität und ihrem aktuellen Kompetenzset wird noch verstärkt durch die in der IT- und Softwarewelt vorherrschenden Einstellungspraktiken. Aus arbeitgebersicht gibt es viele Unternehmen, die in ihren Stellenausschreibungen angeben: “Ich brauche einen Python-Programmierer.” So denkt auf der einen Seite jemand: “Ich bin ein Python-Programmierer”, und dann gibt es ein Unternehmen, das eine Stelle ausschreibt, in der im Grunde geschrieben steht: “Ich brauche einen Python-Programmierer.” Plötzlich ist es also nicht nur eine Frage der Wahrnehmung, die richtige Identität zu haben; es gibt finanzielle Anreize, die mit der richtigen Identität, dem richtigen Label, dem richtigen Schlagwort verbunden sind, das Sie an sich selbst anheften können – was Sie auf dem Markt attraktiver macht.

Diese identitätsgetriebene Wahrnehmung, bei der Technologien als Teil des Selbst eines Softwareingenieurs verankert werden, führt zu zahlreichen Problemen, die nahezu jedes einzelne Softwareprojekt betreffen – insbesondere Softwareprojekte in a supply chain. Wenn Sie mit einer Person interagieren, typischerweise einem Softwareingenieur, der seine Identität stark an die in Ihrem Unternehmen eingesetzte Technologie knüpft, wird das Problem dadurch verschärft, dass jede Kritik an der Technologie als persönliche Kritik aufgefasst wird. Wenn Sie sagen, dass ich ein Python-Programmierer bin und Sie meine Software kritisieren, nehmen ich das persönlich. Das Problem ist, dass sobald Menschen Kritik an der Technologie als persönliche Kritik auffassen, es sehr schwierig wird, diese Probleme sachlich zu erörtern. Diese Softwareingenieure neigen leider dazu, jegliches Feedback abzuwehren, weil sie es teilweise als persönliche Kritik ansehen.

Umgekehrt, wenn das Unternehmen zufällig eine Technologie verwendet, die nicht als Kernidentität des Softwareingenieurs wahrgenommen wird – beispielsweise, wenn Ihr Unternehmen einige Systeme in Java implementiert hat und ein Softwareingenieur sagt: “Ich bin ein Python-Programmierer” – dann wird jedes Problem durch die Brille betrachtet, dass dieses Stück Technologie minderwertig sei. Wiederum entsteht hier ein weiteres Problem, bei dem Kritik und Feedback als “nicht mein Problem; das liegt nur an dieser sehr schlechten Technologie, die hier und jetzt in diesem Unternehmen verwendet wurde” abgewehrt werden. In beiden Situationen – ob der Softwareingenieur nun eine Identität hat, die an die von Ihnen verwendete Technologie gebunden ist, oder eine Identität, die an eine Technologie gebunden ist, die Sie nicht verwenden – entstehen eine ganze Reihe von Problemen, und das Feedback wird abgewiesen, anstatt genutzt zu werden, um die Technologie zu verbessern.

Aus a supply chain-Perspektive müssen wir bedenken, dass die supply chain-Umgebung unglaublich chaotisch ist und deshalb ständig Probleme auftreten. Gerade aufgrund dieses allgegenwärtigen Chaos ist es sehr wichtig, Teams von Softwareingenieuren zusammenzustellen, die den Problemen direkt ins Auge blicken und etwas dagegen unternehmen – und nicht einfach das Feedback abwehren, wenn es auftritt. Es ist entscheidend, Teams zu bilden, die kein Drama zusätzlich zum supply chain-Chaos fördern, bedingt durch ihre Wahrnehmung ihrer Identität.

Diese Idee erstreckt sich auch auf Softwareingenieure, die oft Technologien wählen, die zu ihrer Identität oder zu der Identität passen, die sie erwerben möchten. Sie wählen Technologien, um Fähigkeiten zu erwerben, sodass sie einen weiteren Schlagwort zu ihrem Lebenslauf hinzufügen können. Dieser Ansatz führt jedoch dazu, Technologien aus Gründen auszuwählen, die nichts mit der Lösung der Probleme des Unternehmens zu tun haben. Das ist die falsche Perspektive, um zu entscheiden, ob eine Technologie relevant oder geeignet ist, um die spezifischen Probleme der Organisation zu adressieren.

Das Erstellen eines Lebenslaufs kann ein starker Motivator für Softwareingenieure sein, da es reale finanzielle Vorteile bringt, eine Liste von Schlagwörtern darin zu haben. Die allerbesten Softwareunternehmen blicken oft herab auf Lebensläufe mit einer langen Liste von Schlagwörtern. Als CEO von Lokad, wenn ich einen Lebenslauf mit einer halben Seite Schlagwörtern sehe, wird dieser direkt verworfen. Dennoch suchen viele Unternehmen, insbesondere mittelmäßige, aktiv nach Personen mit vielen Schlagwörtern, in der Annahme, dass diese Personen innerhalb der Organisation unglaublich vielseitig und agil sein werden. Nach meiner Erfahrung ist dies oft genau das Gegenteil.

Im Weiterführen des Themas Identität und Lebenslauferstellung ist es von entscheidender Bedeutung, darauf zu achten, dass Softwarearchitekten sich nicht zu sehr an eine bestimmte Technologie binden sollten. Es ist ohnehin schon schwierig, Softwareingenieure einzustellen, sodass manchmal Kompromisse gemacht werden müssen. Wenn es jedoch um Softwarearchitekten geht, kann ein Kompromiss, bei dem Personen mit einer emotionalen Bindung an eine bestimmte Technologie ausgewählt werden, katastrophal sein. Diese Personen werden langfristig einen großen Einfluss auf Ihr Unternehmen haben.

Dieses Problem der Lebenslauf-Bildungsvoreingenommenheit ist nicht auf Softwareingenieure oder Softwarefachleute beschränkt. Es tritt auch beim IT-Personal auf. Beispielsweise habe ich mehrere IT-Direktoren in großen Unternehmen getroffen, die zu SAP wechseln wollten, obwohl ihr bestehendes Legacy ERP völlig in Ordnung war. Die enormen Kosten, die mit dem Übergang zu SAP verbunden sind, würden niemals durch die erwarteten Vorteile eines moderneren ERP kompensiert werden. In diesen Fällen spielte ein irrationales Verhalten eine Rolle, bei dem das persönliche Interesse des IT-Direktors, SAP in seinen Lebenslauf aufzunehmen, das Interesse des Unternehmens selbst überstieg.

Aus a supply chain-Sicht ist es essenziell, auf diese Interessenkonflikte zu achten. Es bedarf nicht vieler Softwarekenntnisse oder Kompetenzen, um Interessenkonflikte zu erkennen. In anderen Bereichen, wie der medizinischen Wissenschaft, können sogar Ärzte die falschen Medikamente verschreiben aufgrund von Interessenkonflikten – selbst wenn Leben auf dem Spiel stehen. Dies zeigt, dass Interessenkonflikte unglaublich giftig sind. Stellen Sie sich vor, wie sich diese Probleme im supply chain-Management entfalten, wo keine Leben auf dem Spiel stehen und das Hauptanliegen Geld ist. Hier besteht noch weniger Zurückhaltung, Interessenkonflikte entstehen zu lassen.

Anders als im physischen Bereich bietet der Softwarebereich sehr wenige Einschränkungen, wie Softwareinitiativen vorzugehen und die Arbeit anzugehen. Die menschliche Natur mag kein Vakuum, und Menschen können durch einen Mangel an Struktur verunsichert werden. Infolgedessen sind im Laufe der Jahre zahlreiche Praktiken entstanden und tauchen weiterhin auf. Mit jeder Praxis kommt eine Vorstellung von Orthodoxie. Einige Beispiele für diese Praktiken sind Extreme Programming, Domain-Driven Design, Test-Driven Design, Microservices, Scrum und agile Programmierung. Es gibt viele Praktiken, und jedes Jahr tauchen neue auf.

Mit jeder Praxis kommt eine Vorstellung von Orthodoxie. Sobald Menschen beginnen, einer Praxis zu folgen, stellen sie eventuell infrage, ob sie den Kernprinzipien tatsächlich gerecht werden. Softwareingenieure sind schließlich nur Menschen, und Menschen lieben Rituale und Stämme. Eine Praxis vermittelt ein Gefühl der Zugehörigkeit zu einem Stamm mit gemeinsamen Überzeugungen. Genau deshalb werden Sie auch Meetups finden, die mit diesen Praktiken verbunden sind und ein sehr menschliches Bedürfnis erfüllen.

Es kann schwierig und sogar deprimierend sein, einem Problem ins Auge zu blicken, in Ungewissheit zu verharren und fast niemanden zu haben, mit dem man sich austauschen kann, wenn es darum geht, das Problem anzugehen. Das Interessante ist, dass, obwohl eine Praxis fragwürdig oder leicht irrational sein kann, ihre Vorteile real sein können. Eine Praxis innerhalb und außerhalb Ihres Unternehmens zu bewerben, kann die Moral steigern und dabei helfen, potenzielle Bewerber einzustellen.

In einem Vorstellungsgespräch, wenn man fragt, wie Sie arbeiten, ist es nicht gerade überzeugend zu sagen, dass Sie improvisieren und keine Regeln haben. Es ist effizienter, Vertrauen zu wecken, indem Sie eine Praxis präsentieren, als ob sie die Probleme im Unternehmen lösen würde. Der entscheidende Punkt ist, dass diese Praktiken kurzfristig nicht alle schlecht sind, auch wenn sie überwiegend irrational erscheinen. Ein Zugehörigkeitsgefühl zu erzeugen kann vorteilhaft sein. Allerdings wird es giftig, wenn Praktiken zu ernst genommen oder zu lange beibehalten werden. Eine Praxis kann interessant sein, gerade 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. Man sollte nicht zu lange bei einem einzigen Blickwinkel verweilen. Aus a supply chain-Sicht illustriert dies die radikale Absonderlichkeit des Softwarebereichs.

Auf der Fabrikebene bedeutet Exzellenz, immer exakt dasselbe zu tun. In der Softwarewelt ist es genau das Gegenteil. Wenn Sie immer dasselbe tun, so ist das ein Rezept für Stagnation und langfristigen Misserfolg.

Software ist komplex, und Unternehmenssoftware noch mehr. Häufig arbeiten mehrere Ingenieure an einer bestimmten Initiative, was zu einer natürlichen Neigung zur Spezialisierung führt. Wenn ein Ingenieur an einem bestimmten Teil des Codebases arbeitet, ist es naheliegend, dieselbe Person heranzuziehen, wenn neue Aufgaben denselben Teil des Codebases betreffen. Der Vorteil liegt darin, dass diese Person den Code bereits kennt und produktiver sein kann.

Das Hauptproblem bei der Spezialisierung ist, dass sie zu einem Gefühl des Eigentums an Teilen des Codebases führen kann, was wiederum verschiedene Probleme nach sich zieht. Es gibt zwei Problembereiche, die mit diesem Eigentum verbunden sind: den “Truck Factor” und Machtspiele. Der truck Faktor bezieht sich auf das Risiko, einen Mitarbeiter zu verlieren, der über einzigartiges Wissen oder spezielle Fähigkeiten verfügt. Dies könnte daran liegen, dass der Mitarbeiter das Unternehmen verlässt oder aus einem anderen Grund nicht mehr arbeiten kann. Machtspiele können auftreten, wenn ein Mitarbeiter merkt, dass sein Beitrag für das Unternehmen entscheidend ist und diesen Hebel einsetzt, um ein höheres Gehalt oder andere Vorteile zu fordern.

Meiner Erfahrung nach neigen Softwareingenieure normalerweise nicht dazu, Machtspiele zu spielen, aber diese Probleme können in größeren Unternehmen zunehmend häufiger werden. Es gibt viele Software-Engineering-Praktiken, die versuchen, dieses Problem direkt anzugehen – wie zum Beispiel Pair Programming. Der entscheidende Punkt ist jedoch, dass zu viel von etwas Gutem giftig für das Unternehmen sein kann. Das Beste ist, sich dieser Problematik bewusst zu sein, anstatt sich ausschließlich auf eine bestimmte Praxis zu verlassen, die das Problem lösen soll. Denn solche Praktiken können andere Probleme hervorrufen, ablenken oder Ihre Fähigkeit einschränken, anderen Dingen Aufmerksamkeit zu schenken, die Sie noch nicht gesehen haben. Aus softwaretechnischer Sicht lautet die Schlüssellektion hier, dass Kultur das Gegenmittel gegen diese Problematik ist – nicht Prozesse.

Wir stehen vor einer Situation, in der ein sehr feiner Kompromiss besteht zwischen den Produktivitätsgewinnen, die erzielt werden, wenn Menschen sich auf bestimmte Codebereiche spezialisieren, und den Risiken, die damit verbunden sind, dass diese Personen diese Abschnitte des Codes besitzen. Was Sie anstreben sollten, ist eine Situation, in der immer ein gewisser Grad an Redundanz im Wissen über das Codebase im gesamten Team vorhanden ist, sodass jeder einzelne Ingenieur in etwa überlappende Kompetenzen besitzt. Dies ist ein sehr feiner Kompromiss, den Sie erreichen müssen, wenn Sie irgendeinen Grad an Produktivität aufrechterhalten möchten. Der einzige Weg, dies in der realen Welt tatsächlich zu erreichen, besteht in einer gut verstandenen Kultur des Software-Engineerings. Es gibt keinen Prozess, der garantieren kann, dass die Menschen neugierig auf die Arbeit ihrer Kollegen sind. Über Neugier kann man keinen Prozess etablieren; sie muss Teil der Kultur sein.

Die Beurteilung der Fähigkeiten und Kompetenzen von Softwareingenieuren ist schwierig, und diese Frage ist entscheidend, denn obwohl Software eindeutig eine Teamleistung darstellt und das Team mehr als die Summe seiner Mitglieder ist, hat das Basisniveau der einzelnen Teammitglieder einen großen Einfluss auf die Gesamtleistung des Teams.

Ein Aspekt, den ich beobachtet habe und der von Personen außerhalb der Softwarebranche – und manchmal auch von Personen innerhalb der Branche – weitgehend unterschätzt wird, ist die Bedeutung von Schreibfähigkeiten. Wenn Sie Software entwickeln, richten Sie sich an zwei unterschiedliche Zielgruppen. Einerseits 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 mitteilt, ob Ihr Code korrekt oder fehlerhaft ist. Der Compiler ist vollkommen vorhersehbar und besitzt eine unendliche Geduld.

Auf der anderen Seite hast du das Publikum deiner Kollegen, zu dem vermutlich auch du selbst in sechs Monaten gehörst. Du schreibst Code, den du irgendwann vergessen wirst. Sechs Monate später wirst du den von dir geschriebenen Code betrachten und denken, dass er von jemand anderem verfasst wurde, weil er dir so fremd erscheint. Wenn du Code für deine Kollegen schreibst, ist der Vorteil, dass im Gegensatz zu Compilern deine Kollegen versuchen, zu verstehen, was du erreichen möchtest. Der Compiler versucht nicht, deine Absichten zu verstehen; er wendet mechanisch ein Regelwerk an.

Deine Kollegen werden versuchen zu verstehen, aber leider sind sie nicht wie Compiler. Sie haben nicht unendlich viel Geduld und können durch deinen Code leicht verwirrt und fehlgeleitet werden. Deshalb ist es beispielsweise von primärer Bedeutung, einprägsame, aufschlussreiche und passende Namen zu wählen. Ein gutes Programm besteht nicht nur darin, etwas Korrektes zu haben; selbst die Wahl der Namen für Variablen, Funktionen und Module ist von entscheidender Wichtigkeit, wenn du Code erstellen möchtest, der gut mit deinen Kollegen harmoniert – und wieder einmal gehören deine Kollegen, inklusive dir selbst in sechs Monaten, dazu. Aus supply chain-Perspektive ist die wichtigste Erkenntnis, dass Schreibfähigkeiten von höchster Bedeutung sind, und ich würde sogar behaupten, dass Schreibfähigkeiten häufig wichtiger sind als reine technische Fertigkeiten. Gute Schreibfähigkeiten sind die Nummer-eins-Fähigkeit, die du brauchst, um die in deiner supply chain vorhandene Komplexität zu bändigen. Die Bändigung der Komplexität deiner applikativen Landschaft ist keine große technische Herausforderung; es ist vielmehr eine Herausforderung, Ideen und Elemente zu organisieren, um eine durchgängig konsistente Geschichte zu erzählen. Genau das sind vor allem Schreibfertigkeiten, und wir haben diesen Aspekt in einer früheren Vorlesung mit dem Titel “Writing for Supply Chain” angesprochen.

Wenn Schreibfertigkeiten von entscheidender Bedeutung sind, um ein guter Softwareingenieur zu sein, gibt es eine weitere Fähigkeit, die grundlegend dafür ist, überhaupt Softwareingenieur zu werden: Schmerzresistenz. Ich glaube, dies ist die Nummer-eins-Fähigkeit im Sinne dessen, was es tatsächlich braucht, um ein Softwareingenieur zu sein – nicht unbedingt ein großartiger, sondern einfach einer. Genauer gesagt, wenn ich von Schmerz spreche, meine ich die Fähigkeit, der Langeweile und Frustration zu widerstehen, die mit dem Engineering von Software einhergehen, wenn man mit Systemen konfrontiert wird, die unglaublich fragil, schlecht entworfen und auf allerlei Weisen mit Fallen versehen sind, manchmal sogar von Personen, die nicht mehr da sind. Wenn du dich mit Software beschäftigst, stehen dir vier Jahrzehnte angesammelter Probleme im Weg, und du kämpfst ständig damit. Das kann manchmal eine unglaublich frustrierende Angelegenheit sein.

Um es zu veranschaulichen: Als Softwareingenieur wirst du die Geduld aufbringen müssen, vier Stunden lang zufällige, halbwegs unbrauchbare Diskussionen in einem Webforum durchzugehen, in denen ein Fehlercode erwähnt wird, der dem ähnelt, mit dem du konfrontiert bist. Du wirst stundenlang solchen Unsinn durchforsten müssen, um dem Problem auf den Grund zu gehen, und manchmal dauert es Wochen, einen scheinbar trivialen Fehler zu beheben. Folglich gibt es in der gesamten Softwareindustrie einen sehr intensiven Prozess der Fehlselektion, der Menschen auswählt, die eine hohe Schmerzresistenz besitzen. Dieser Selektionsprozess hat zwei wesentliche Konsequenzen.

Erstens neigen Menschen, die Softwareingenieur bleiben, dazu, unglaublich schmerzresistent zu sein. Wenn ich von Schmerzresistenz spreche, meine ich die Fähigkeit, der Frustration durch die ständigen Softwareprobleme zu widerstehen. Da gezielt Menschen mit extremer Schmerzresistenz ausgewählt werden, merken sie vielleicht gar nicht, wenn ihre Handlungen die Situation verschlechtern. Sie könnten zusätzliche Marotten in die Softwareprodukte einbauen, wodurch der Schmerzpegel bei der Interaktion mit der Software für alle – einschließlich ihnen selbst – steigt. Allerdings, wenn sie äußerst schmerzresistent sind, nehmen sie das nicht wahr. Dieser Prozess der Fehlselektion schließt gewöhnliche Menschen aus, die zwar aufpassen würden, aber keine Softwareingenieure wurden, weil sie den Schmerz nicht ertragen konnten. Dieses Problem ist besonders intensiv bei Software im supply chain, weil es viele Komponenten gibt, die alles andere als spannend sind. Einige Aspekte können notwendig, aber langweilig sein, was bedeutet, dass Menschen mit hoher Schmerzresistenz in diesem Bereich die Situation durch die Vielzahl potenziell langweiliger Aufgaben noch verschlimmern können.

Der zweite Aspekt dieses Selektionsprozesses besteht darin, dass Menschen, die sich den Luxus leisten können, ein niedrigeres Gehalt in Kauf zu nehmen, um Probleme zu vermeiden, die intensiven Schmerz verursachen, dies auch tun. Wenn jemand bereits gut bezahlt ist, entscheidet er sich möglicherweise für einen Job, der zwar weniger gut vergütet wird, aber den Vorteil geringerer Schmerzintensität bietet. Die meisten würden dies wahrscheinlich tun, und in der Praxis tun es viele. Das bedeutet, dass die Menschen, die in dieser Branche verbleiben – wo eine sehr hohe allgegenwärtige Schmerzintensität herrscht – oft diejenigen sind, die es sich nicht leisten können, auf die Chance eines höheren Gehalts zu verzichten. Dies erklärt weitgehend, warum es eine signifikante Anzahl von Softwareingenieuren gibt, die aus Indien und Nordafrika kommen. Diese Länder verfügen über ziemlich gute Bildungssysteme, die gut ausgebildete Individuen hervorbringen, jedoch sind die Länder insgesamt relativ arm. Menschen in diesen Positionen haben nicht den Luxus, auf höher bezahlte Jobs im Software Engineering zu verzichten, aufgrund der hohen Nachfrage und der im Vergleich zu ihrem Basisgehalt besseren Bezahlung. Sie haben nicht den Luxus, sich für etwas anderes zu entscheiden, und deshalb sind sie in der Branche so zahlreich vertreten.

An diesen Ländern ist nichts auszusetzen; es handelt sich lediglich um eine mechanische Anwendung der Marktkräften. Dies ist kein Urteil, sondern nur eine Beobachtung. Tatsache ist, dass Schmerzresistenz nicht alles ist, was es braucht, um ein großartiger Softwareingenieur zu sein. Es ist nur eine Voraussetzung – ohne sie bist du überhaupt kein Softwareingenieur. Wenn hingegen Schmerzresistenz das Einzige ist, was du besitzt, wirst du ein ziemlich schlechter Softwareingenieur sein. Aus supply chain-Perspektive lautet die Lehre hier, dass man genau darauf achten sollte, welche Teams dein Unternehmen zusammenstellt – sei es intern oder über Softwareanbieter. Stelle sicher, dass die eingesetzten Ingenieure nicht ausschließlich über Schmerzresistenz verfügen, denn das bedeutet, dass du ein sehr schlechtes Ergebnis in Bezug auf Softwarequalität und den daraus resultierenden Mehrwert erzielen wirst. Nochmals: Schmerzresistenz ist erforderlich, aber allein nicht genug.

Bereits 1975 wies Frederick Brooks darauf hin, dass Mannmonate nicht repräsentativ für den durch Software geschaffenen Wert und den von Softwareingenieuren insgesamt generierten Wert seien. 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 3 Millionen Beschäftigte in der IT-Branche, aber weniger als 1 Million im gesamten Automobilsektor. Die IT-Branche hat inzwischen mindestens dreimal so viele Mitarbeiter wie die Automobilindustrie. Die meisten dieser IT-Unternehmen – einige davon absolut gigantisch mit mehreren hundert oder tausend Angestellten – rechnen nicht mehr pro Mannmonat ab. Das waren die 70er. Heute rechnen wir nach Kilo-Tagen ab, was im Grunde Tausend Tage an Arbeitskraft entspricht. Die Situation hat sich angesichts der unglaublichen Zunahme von Umfang und Ausmaß des Problems gegenüber dem, was Frederick Brooks vor fast fünf Jahrzehnten skizzierte, deutlich verschlechtert. Doch die meisten der frühen Erkenntnisse gelten weiterhin. “The Mythical Man-Month” bleibt ein sehr interessantes Buch über Software Engineering.

In der Software variiert die Produktivität enorm. Am einen Ende des Spektrums hat man nicht nur Menschen mit geringer Produktivität, sondern solche mit negativer Produktivität. Das bedeutet, dass sie, sobald sie mit der Arbeit an einem Softwareprodukt beginnen, es einfach verschlimmern. Man kann nicht einmal mehr ein Verhältnis zwischen der Produktivität der Menschen herstellen. Es ist noch schlimmer: Es gibt Personen, die dein Produkt aktiv verschlechtern. Das ist ein massives Problem. Am anderen Ende des Spektrums befinden sich die sogenannten 10x-Engineers, Menschen, die das Zehnfache der Produktivität eines durchschnittlichen Ingenieurs besitzen, der hoffentlich eine positive Produktivität aufweist. Diese 10x-Engineers existieren zwar, aber diese enorme Produktivität ist unglaublich kontextabhängig. Du kannst einen 10x-Softwareingenieur nicht einfach von einem Unternehmen in ein anderes oder von einer Position in eine andere übertragen und erwarten, dass diese Person ihre unglaubliche Produktivität beibehält. In der Regel ist es eine Kombination aus einzigartigen Fähigkeiten und einer spezifischen Situation, die diese Produktivität erzeugt. Dennoch ist es wichtig zu bedenken, dass nur wenige Personen den Großteil des von einem Softwareprodukt generierten Werts ausmachen können. Manchmal läuft es darauf hinaus, dass nur eine Person den Großteil all der intelligenten Elemente und den echten Mehrwert der Software schafft, während alle anderen sich mit Aufgaben beschäftigen, die bestenfalls einen fragwürdigen Mehrwert bieten. Die zentrale Erkenntnis hier, die vor fünf Jahrzehnten identifiziert wurde, ist, dass, wenn du in der supply chain unter einer Frist stehst, die einzige vernünftige Option darin besteht, den Umfang der Software-Initiative zu reduzieren. Alle anderen Optionen sind schlechter.

Mehr Personal hinzuzufügen, macht die Dinge nur schlechter, denn man sagt oft, dass ein verspätetes Softwareprojekt durch zusätzliches Personal nur noch später wird. Diese Aussage von Brooks war vor fünf Jahrzehnten gültig und ist auch heute noch zutreffend. Die anderen Optionen funktionieren ebenfalls nicht. Wenn du beginnst, dass Leute Überstunden machen, wird das nachteilig zurückschlagen, weil die Menschen müde werden und mehr Fehler machen, was das Produkt weiter verzögert. Wenn du versuchst, die Qualität zu reduzieren, landest du am Ende mit etwas, das nicht mehr funktioniert. Diese Dinge geraten außer Kontrolle und können dir in die Hände spielen, weshalb du bei der Qualität keine Kompromisse eingehen darfst.

Aus supply chain-Perspektive lautet die zentrale Erkenntnis hier, dass wenn du ein Vorhaben in Angriff nimmst, das scheinbar mehr als zehn Vollzeit-Softwareingenieure erfordert, du mit äußerster Vorsicht vorgehen solltest. In der Regel ist das ein Zeichen dafür, dass es sich um ein sehr schlecht formuliertes Problem handelt. Es erfordert unglaubliches Teamwork, damit zehn Personen gleichzeitig am selben Produkt arbeiten können und dennoch produktiv bleiben. In der supply chain beobachte ich, dass die Menschen oft zu ehrgeizig in Bezug auf den Umfang und die Anzahl der beteiligten Personen sind. Ich habe ERP-Migrationsprojekte gesehen, bei denen gleichzeitig 50, 100 oder 200 Personen daran gearbeitet haben. Das ist völlig unsinnig. Jeglicher Grad an Kooperation erfordert unglaublich fähige Teamplayer, um zu vermeiden, dass durch Reibungsverluste alles verloren geht. Wenn du Schwierigkeiten hast, halte deine Software-Initiative fokussiert, kurz und schmal.

Meine abschließende Beobachtung betrifft ein häufiges Missverständnis in Bezug auf große Unternehmen. Die meisten würden sagen, dass große Unternehmen risikoscheu sind, aber das entspricht nicht meiner Erfahrung. Meiner Erfahrung nach haben große Unternehmen eine Abneigung gegen Unsicherheit, nicht vor Risiko, obwohl diese beiden von außen verwechselt werden können. Von außen erscheint die rationale Erklärung, dass große Unternehmen risikoavers seien, aber in Wirklichkeit habe ich immer wieder beobachtet, dass große Unternehmen, wenn sie vor der Wahl stehen, einen sicheren Misserfolg einem unsicheren Erfolg vorzuziehen, stets die Sicherheit des Scheiterns favorisieren.

Große Unternehmen werden immer wieder die Sicherheit des Misserfolgs dem unsicheren Erfolg vorziehen. Das mag auf den ersten Blick verwirrend und irrational erscheinen, ist es aber nicht. Große Unternehmen sind keine einheitliche Entität; sie sind politische Ungetüme, die aus vielen Menschen bestehen. Politik und Erscheinungsbild sind von größter Bedeutung, besonders in sehr großen Strukturen.

Betrachte die Perspektive dessen, der für eine Software-Initiative verantwortlich ist. Einerseits hast du ein Vorhaben, dessen Ausgang sicher ist – es wird scheitern. Trotzdem hältst du dich an die Regeln, spielst nach Buch und jeder weiß, dass es scheitern wird. Niemand wird dir vorwerfen, auf Nummer sicher gegangen und versagt zu haben, denn genau das wird erwartet. Im Gegenteil, unsicherer Erfolg wirkt merkwürdig. Dieser Weg bedeutet, unübliche Dinge zu tun, die potenziell karriereschädigend sind – weitaus mehr, als einfach nur den Regeln zu folgen.

Aus supply chain-Perspektive lautet die Lehre hier, dass es in der Softwarewelt von entscheidender Bedeutung ist, sich nicht absichtlich auf ein Scheitern einzustellen, nur um Unsicherheit auszuschließen – besonders wenn das Regelwerk völlig falsch liegt. Zum Beispiel habe ich Unternehmen gesehen, die über Jahrzehnte mit Methoden wie ABC-Analyse und Sicherheitsbeständen gescheitert sind – Methoden, die nachweislich falsch sind und das Scheitern der entsprechenden Initiativen garantieren. Diese Methoden sind aus grundlegenden mathematischen und statistischen Gründen falsch, weshalb es nicht überraschen sollte, dass sie in der supply chain keinen Mehrwert liefern. Dennoch galten sie als vorzuziehen, weil sie nicht verrückt erschienen und als Lehrbuchstoff galten.

Sei vorsichtig mit dem Komfort, den es mit sich bringt, sich absichtlich zum Scheitern zu veranlassen, nur um Unsicherheit auszuschließen. Das Ziel ist nicht, Unsicherheit zu eliminieren; das Ziel ist, die Erfolgschancen zu maximieren, nicht die Unsicherheit zu reduzieren.

Zusammenfassend ist Softwareengineering zu wichtig, um es ausschließlich in den Händen von Softwareingenieuren zu belassen. Software ist überall in der supply chain präsent und treibt die Mechanisierung geistiger Arbeit voran. Wir befinden uns noch in einem frühen Stadium dieses Prozesses, aber es steht fest, dass Unternehmen, die auf diesem Gebiet nicht äußerst wettbewerbsfähig bleiben, durch die gewöhnlichen Marktkräfte vollständig vom Markt verdrängt werden. Für die supply chain ist die größte Herausforderung eine kulturelle. Dies ist kein technisches Problem, sondern ein kulturelles Problem. Softwareengineering stellt die Art und Weise, wie wir Probleme betrachten und angehen, grundlegend in Frage. Die meisten intuitiven Lösungen erweisen sich als falsch – und das in spektakulärem Ausmaß.

In gewisser Weise geht es beim Softwareengineering in der supply chain darum, das Chaos zu zähmen, all die Komplexität und Unsicherheit zu bändigen, die in der supply chain allgegenwärtig ist. Um dieses Chaos zu bändigen – was die Aufgabe der Softwareingenieure sein wird – darf der Prozess selbst nicht zu poliert oder geordnet sein; fehlt im Kern das Element des Chaos, bleibt kein Raum für Veränderung, Zufall oder Kreativität. Was als Exzellenz wahrgenommen wird, verkommt schnell zu Stagnation und führt letztlich zum Scheitern. Für traditionellere Unternehmen besteht die größte Herausforderung in diesem kulturellen Ansatz – neben dem Kulturschock darin, die Illusion der Kontrolle aufzugeben. Dein Fünfjahres-ERP-Migrationsplan ist eine Täuschung; du hast keinerlei Kontrolle über ein derart massives Projekt. Ähnlich verhält es sich mit deinem Business Case, der die erwarteten Gewinne deiner aktuellen Initiative skizziert – auch das ist eine Illusion.

Wenn es darum geht, die Mechanisierung intellektueller Arbeit in Angriff zu nehmen, besteht die größte Gefahr nicht darin, Dinge zu tun, die man nicht vollständig rationalisieren kann. Die größte Gefahr besteht darin, Dinge zu tun, die völlig irrational sind unter dem Deckmantel der Rationalität.

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

Question: Wie misst man die kapitalistische Rendite auf Ihre Softwareinvestitionen?

Meistens tut man es nicht. Die Messung ist ein Nebenprodukt des Vorhabens selbst. Es ist etwas, das rätselhaft erscheint, wenn man die Rendite der Investition messen möchte. Es wird vorausgesetzt, dass man im Vorhinein eine Messgröße festlegen kann, was typischerweise mit dieser Art von Frage impliziert wird. Es wird angenommen, dass man diese Messgröße bestimmen kann, bevor man seinen Business Case mit Szenarien aufbaut, und dann eine Entscheidung treffen kann, ob man mit der Softwareinvestition fortfährt oder nicht. Was ich sagen möchte, ist, dass es bei Software nicht so funktioniert. Es ist buchstäblich so: Zuerst führt man die Aktion aus, dann lernt man, was gelernt werden muss, und auf dem Weg dorthin erfährt man sogar, welche Art von Vorteilen es gibt. Um Ihr Handeln zu leiten, benötigen Sie ein übergeordnetes Verständnis. Die Lektion besteht nicht darin, Dinge zufällig zu tun, sondern darin, keine tief irrationalen Handlungen unter dem Deckmantel der Rationalität zu begehen. Eine Intuition auf hoher Ebene, wenn Sie absolut von etwas überzeugt sind und Ihr Bauchgefühl Ihnen sagt, dass es der richtige Weg ist, kann ein viel rationaleres Argument sein als ausgefallene Berechnungen, die nur den Anschein von Rationalität haben, aber auf Müllzahlen beruhen. Die Realität ist, dass sich die Messungen, je weiter Sie Ihr Softwarevorhaben vorantreiben, klären werden, weil Sie anfangen zu erkennen, was Sie erreichen wollen, und dann lernen, wie Sie die Angemessenheit dessen, was Sie tun, im Vergleich zu dem, was Sie tun sollten, messen. Die Messung wird als Nebenprodukt erscheinen, wenn man es gut macht. Daraus folgt aber, dass es in Bezug auf Software viel besser ist, einfach Dinge auszuprobieren und schnell zu scheitern. Man sollte sich nicht auf ein massives Commitment einlassen; es ist besser, es in unglaublich inkrementellen Schritten, mit weniger Personen und hoher Produktivität, zu tun. Man lernt unterwegs, wie man vorgeht.

Aber dann kommt ein weiteres Problem: Sobald man damit anfängt, muss das Management in Unternehmen in der Lage sein, viele Initiativen gleichzeitig zu jonglieren. Dies ist besonders für traditionellere Unternehmen sehr beunruhigend, da das Management nicht erwartet, so viele Initiativen zu haben, die alle in unterschiedliche Richtungen gehen. Doch genau das geschieht seit Jahrzehnten in großen Softwareunternehmen, und dies ist eine der wesentlichen Erkenntnisse aus der Softwaretechnik aus menschlicher Sicht.

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

Nun, ich behaupte nicht, dass viele Schlüsselwörter einen davor schützen, sich mit einer bestimmten Technologie zu identifizieren. Es gibt zwei verschiedene Probleme. Das eine ist das Problem, dass eine Person eine starke Verbindung zwischen ihrer persönlichen Identität, ihrer wahrgenommenen Identität und ihren Fähigkeiten hat. Das ist Problem Nummer eins. Problem Nummer zwei besteht darin, dass der Aufbau Ihres Lebenslaufs mit einem sehr starken latenten Interessenkonflikt einhergeht. Meine Botschaft lautet: Einerseits, hüten Sie sich vor dieser Identitätspolitik, da sie unglaublich toxisch ist. Meine zweite Botschaft ist: Hüten Sie sich vor Interessenkonflikten in all ihren Formen; auch sie sind unglaublich toxisch.

Nun, wenn Sie wirklich eine bestimmte Technologie übermäßig betonen, können Sie einige Schlüsselwörter für Technologien, die Sie ablehnen, aus Ihrem Lebenslauf entfernen. In der Regel sind diese beiden Probleme jedoch getrennt, und es kann sogar vorkommen, dass jemand sagt, “Meine Identität ist, dass ich ein Python-Programmierer bin,” wie ich es in einer Folie gezeigt habe, und dann in seinem Lebenslauf mehr als 20 Schlüsselwörter aufführt. Diese beiden Dinge schließen einander nicht aus; sie können sogar gleichzeitig auftreten. Unterschätzen Sie auch nicht die Tatsache, dass Identität manchmal mit etwas Aspirationalem, etwas, das Sie erwerben möchten, verbunden sein kann. Sie könnten sagen, “Bisher habe ich in Python programmiert, aber ich möchte ein Rust-Programmierer werden, also betrachte ich mich als solchen, obwohl ich bisher hauptsächlich Python verwendet habe.” All diese Verhaltensweisen sind möglich.

Question: Software engineering is considered to be an auxiliary science for supply chain. What would be auxiliary sciences for software engineering?

Wahrscheinlich sind Psychologie, Soziologie und Ethnologie alle relevante Bereiche, wenn es um Softwaretechnik geht. Wenn man es grundsätzlich als die Interaktion von Menschen betrachtet, sind diese Hilfswissenschaften entscheidend. Um ernsthafte Arbeit in der Softwaretechnik zu leisten, geht es nicht ausschließlich um die Softwaretechnologie, obwohl Sie den Softwarekontext verstehen müssen, damit die Interaktionen zwischen Menschen Sinn ergeben. Es ist nicht unbedingt erforderlich, zu verstehen, wie der Code im Detail aufgebaut ist, aber Sie müssen Konzepte wie Codebasis oder die vorhandenen Werkzeuge und die Probleme, die sie zu lösen versuchen, verstehen. Allerdings muss ich für den Zweck dieser supply chain Vorlesungsreihe eine Grenze ziehen und entscheiden, was ich einbeziehe und was nicht, da ich offensichtlich nicht jedes einzelne Forschungsfeld abdecken kann. Question: Fragen Sie zehn schlaue Menschen nach einer Lösung, und sie werden mehr als zehn Wege vorschlagen. Es ist besser, sich auf einen der Top-Fünf zu einigen und ihn konsequent anzuwenden. Wie balancieren Sie diese beiden widersprüchlichen Ansätze und Vorteile?

Das ist eine sehr umfassende Frage, aber wenn ich sie im speziellen Fall der Softwaretechnik betrachte, kann man viele Vorschläge haben, von denen nicht alle gleich gewichtig betrachtet werden sollten. Es gibt die Fähigkeit, eine langfristige Perspektive in Bezug auf Software zu haben. Wenn ich sage, dass Sie sich auf das konzentrieren sollten, was sich nicht ändert, stellt sich heraus, dass manche Menschen in dieser Arbeit sehr gut sind und manche nicht. Erfahrung spielt eine Rolle, wenn es darum geht, zu beurteilen, wer die Fähigkeiten für diese langfristige Sichtweise besitzt und was sich tatsächlich nicht ändert. Meiner bescheidenen Erfahrung nach braucht es in der Regel jemanden, der mindestens 35 Jahre alt ist, um darin wirklich gut zu werden, und die besten Menschen sind über 60. Es braucht Jahre der Erfahrung, um die Dynamik und die Muster zu erkennen. Wenn Sie sagen, dass Sie so viele Menschen haben, entsteht die Illusion, dass all diese Lösungen gut aussehen – das ist nur der äußere Anschein. Sie wissen nicht, wie viel Aufwand es erfordern wird, erst einmal den Boden auszuloten. Können Sie einfach einen Prototyp erstellen oder es testen? Unter diesen zehn Menschen gibt es vielleicht einige mit einzigartigen Fähigkeiten, Lösungen zu identifizieren, die langfristig schädlich sein könnten. Bedenken Sie, dass Ihre Wartungskosten im Wesentlichen von den getroffenen Entscheidungen abhängen. Gibt es eine wichtige Entscheidung, die Ihnen langfristig schaden kann? Dies ist ein kniffliger Aspekt, und übrigens kann jemand, der die langfristige Perspektive besitzt, erklären, warum eine bestimmte Option langfristig alle möglichen Probleme erzeugen wird. Es ist nicht nur ein Bauchgefühl oder eine Intuition. Man sagt: “So etwas habe ich schon erlebt, so etwas kenne ich.” Es gibt ein Sprichwort: Der kluge Mensch lernt aus seinen eigenen Fehlern, aber der weise Mensch lernt aus den Fehlern anderer. Das ist in diesem Fall sehr zutreffend. Question: Wie messen Unternehmen die Steigerung der betrieblichen Effizienz pro investiertem Dollar bei der Implementierung von Software für supply chains?

Das ist eine unglaublich schwierige Frage. Das Problem ist buchstäblich die 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 Messgrößen einfach sinnlos sind. Schauen Sie zum Beispiel auf den Vergleich zwischen Telefonverkauf und E-Commerce. Versandhandelsunternehmen existierten bereits seit der Mitte des 19. Jahrhunderts. Wenn man E-Commerce als Verbesserung gegenüber Versandhandelsunternehmen betrachtet, könnte man versuchen, diese Verbesserung zu messen, aber in Wirklichkeit ging nahezu jedes einzelne Versandhandelsunternehmen bankrott. Die E-Commerce-Unternehmen, die heutzutage dominieren, sind mehrere Größenordnungen größer als das größte Versandhandelsunternehmen, das jemals existierte. 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 rätselhaft, weil sie nicht wie der physische Bereich funktioniert. Bei der physischen Produktion kann man Effizienz auf kanonische Weise messen. Wenn man jedoch beginnt, seine intellektuelle Arbeit zu mechanisieren, was bedeutet Effizienz überhaupt? Bei einem Unternehmen wie Amazon wird die gesamte supply chain vollständig von Software gesteuert. Wenn die Menschen einfach zu Hause bleiben und nichts tun würden, vermute ich, dass die gesamte supply chain einwandfrei funktionieren würde, selbst wenn all diese Ingenieure ein oder zwei Tage lang nichts tun würden. Warum also hält Amazon diese Ingenieure überhaupt? Weil sie in ihre Verbesserungen investieren. Übrigens, eine interessante Tatsache über 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 sie falsch sind, und er dem Projekt widerspricht. Dennoch verpflichtet er sich, das Projekt budgetmäßig zu unterstützen, weil er die Personen, die daran arbeiten, eingestellt hat und ihnen vertraut. Es ist eine Art schizophrenen Ansatz – als CEO soll er die oberste Autorität im Unternehmen sein, aber er gibt diese Autorität auf und sagt: “Ich bin nicht einverstanden, aber ihr könnt das Budget nutzen und weitermachen.” Der Grund für diesen Ansatz liegt darin, dass Softwareprojekte in der Regel ziemlich kostengünstig sind. Wenn jemand mit einer scheinbar verrückten Idee aufwartet, die nicht sehr teuer ist und das Unternehmen nicht in den Bankrott treibt, warum sollte man es nicht ausprobieren? Wenn es funktioniert, könnte es eine brillante Idee sein. Dies stellt einen Kulturschock dar beim Übergang von traditionellen supply chain Unternehmen, in denen das Management die Vision haben und die Teams leiten soll, zur Softwarewelt, in der Führung hauptsächlich darin besteht, Probleme zu lösen, die unter Softwareingenieuren entstehen. Bei Lokad steht bei Softwareinvestitionen nicht der finanzielle Ertrag im Vordergrund. Stattdessen liegt der Fokus darauf, ob die Investition einen grundlegenden Aspekt des supply chain Managements adressiert. Wenn sie zentral für eine Vielzahl von supply chain Situationen ist, dann lohnt sie sich. Zum Beispiel ist im automobilen Aftermarket die Bewältigung des Problems der mechanischen Kompatibilität von primärer Bedeutung. Man verkauft keine Autoteile, um Menschen zu bedienen; man verkauft Teile, um Autos zu bedienen. Ein einzelnes Teil kann mit mehreren Fahrzeugen kompatibel sein, und manche Teile können sich mechanisch überschneiden. Dieses Problem muss angegangen werden; es ist der Kern des Geschäfts. Wenn Sie es nicht angehen, wird es jemand anderes tun, und Sie werden letztlich aus dem Markt gedrängt. Bezüglich Softwareinvestitionen ist es wichtig, Risiken einzugehen und Innovation zu fördern, solange diese nicht die finanzielle Stabilität des Unternehmens gefährden. Question: Es ist irreführend zu sagen, dass große Projektteams lächerlich sind. In ERP-Systemen mag ein 10-köpfiges Team für die Entwicklung ausreichend sein, aber größere Projekte erfordern mehr Personen. Ein Turm benötigt mehr Arbeitskräfte als ein Haus. Könnten Sie Ihre Kommentare erläutern? Ich werde eine Position einnehmen, die viele Menschen verärgern könnte. Der Lebensunterhalt von Millionen hängt von unglaublich großen IT-Unternehmen ab. In den USA repräsentierten IT-Unternehmen im Jahr 2020 drei Millionen amerikanische Arbeitnehmer. Wenn ich also sage, dass es absolut keinen Grund gibt, ein ERP zu haben, das so viele Personen erfordert, werden offensichtlich alle, die ihren Lebensunterhalt entweder durch den Verkauf großer Teams oder als Teil eines solchen Teams verdienen, heftig widersprechen. Mein Gegenargument lautet: Stammt Ihr Widerspruch aus grundlegenden 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 beizubehalten und eine Armee von Personen zu beschäftigen? Wenn wir uns die gesamten Innovationen ansehen – die von dem Ökonomen Schumpeter beschriebene kreative Zerstörung – gab es jedes Mal, wenn es eine bedeutende wirtschaftliche Innovation gab, in der Regel einen massiven Produktivitätszuwachs. Doch diejenigen, die hinter der Kurve standen, kämpften heftig, um diese Innovationen zu verhindern. ERPs sind nichts Neues; sie existieren im Grunde genommen seit vier Jahrzehnten. Die meisten ERPs, die ich heutzutage sehe, bieten nicht viel mehr als die, die Unternehmen vor ein oder zwei Jahrzehnten hatten. Ich habe viele ältere ERPs gesehen, die just in Ordnung sind, und neue ERPs sind oft nicht wesentlich besser, besonders angesichts der Millionen, die in ERP-Migrationsprojekte geflossen sind. In diesen massiven Projekten sehe ich eine erschreckend geringe Produktivität seitens der IT-Unternehmen. Mein Gegenargument besteht darin, sich Unternehmen wie JD.com, Amazon oder Rakuten anzusehen. Wie viele Personen benötigen diese Unternehmen, um ähnliche Aufgaben zu erfüllen? In der Regel endet man mit unglaublichen 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 aufgebaut, das kleiner ist als die meisten Teams, die ich bei Unternehmen ähnlicher Größe gesehen habe, die ihr ERP migrieren müssen. So sieht man: Auf der einen Seite gibt es ein Unternehmen wie Zalando, das in der Lage ist, sein eigenes ERP zu entwickeln, vollständig auf seine Bedürfnisse zugeschnitten. Es erfüllt seine Funktion als passendes ERP für sie sehr gut, und die Kosten sowie die Anzahl der beteiligten Personen sind nur ein Bruchteil dessen, was andere Unternehmen ähnlicher Größe benötigen, um lediglich ein Versionsupgrade durchzuführen. Die Kosten sind erneut nur ein Bruchteil. Ich hinterfrage, ob es notwendig ist, so viele Personen einzusetzen, und das ist das Problem der Büroarbeit im 21. Jahrhundert. Ein sehr guter Mitarbeiter zu sein, bedeutet, den Mut zu haben, sich selbst zu automatisieren und sich überflüssig zu machen. This is something very peculiar. When blue-collar workers were being made obsolete, it was done by others. But nowadays, there are almost no blue-collar workers left. It takes a different mindset, and that’s why there’s a struggle to adapt to this new paradigm, mostly coming from the software industry. It’s fine to make yourself obsolete because you’re not actually making yourself obsolete; there’s no limit to human ingenuity. You’re just automating some tasks, freeing yourself to tackle the next challenge, which is even more interesting than the previous one. Companies like Amazon don’t fire their software engineers as soon as they solve a problem. They reward them and promote them to tackle the next, more difficult problem.

In Beantwortung einer Frage zu supply chain Praktikern, die in der analytischen Denkweise der Zeit nach dem Zweiten Weltkrieg feststecken, stimme ich zu, dass sich die Softwareentwicklung – bei vielen Unternehmen, nicht bei allen – weiterentwickelt hat. Sie definiert sich als ein Personalprozess oder ein interpretativer Prozess. Dem stimme ich zu. Die Softwareindustrie dreht sich nicht ausschließlich um harte, kerntechnologische Aspekte. Obwohl einige Positionen unglaubliche quantitative technische Fähigkeiten erfordern, sieht sich der Großteil der Softwareindustrie als einen menschenorientierten Ansatz, eine geteilte Kultur.

In großem Maße glaube ich, dass die Dominanz, die die USA und Silicon Valley weltweit in der Softwarebranche haben, auf die Schwierigkeit zurückzuführen ist, ihre Kultur zu replizieren. Kultur tendiert dazu, sehr immateriell und schwer zu dokumentieren zu sein. Wenn man sie dokumentiert, zähmt man das chaotische Element, das für Innovationen notwendig ist. Dokumentiert, organisiert und prozessiert man die Kultur, verliert man plötzlich diesen Aspekt des rohen, chaotischen Entstehens von Ideen und Innovationen.

Es gibt Orte wie Silicon Valley, wo diese Kultur vorherrscht, und in dieser Hinsicht sind sie ihrer Zeit voraus. Um dieses Thema abzuschließen, möchte ich William Gibson zitieren, der sagte, “Die Zukunft ist schon da; sie ist nur ungleich verteilt.” Ich sehe, wie diese Kultur nun in vielen anderen Regionen in wesentlich kleineren Maßstäben repliziert wird, und der Prozess wird im Laufe der Zeit weiterbestehen und wachsen.

Das war’s 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!