Von vierundsiebzig Tagen zur physikalischen Grenze: Was Jensen Huangs Denken in „Lichtgeschwindigkeit“ an der Ingenieursarbeit verändert

Einleitung: Warum einen Zeitplan verbessern, bevor man ihn versteht?
Ein Team sagt, ein Prozess dauere vierundsiebzig Tage. Es bietet an, diese Dauer auf zweiundsiebzig Tage zu senken. Der Vorschlag klingt nach Fortschritt. Doch was wäre, wenn sich die eigentliche Arbeit in einer anderen Anordnung in sechs Tagen erledigen ließe?
Diese Zahlen veranschaulichen eine Methode und sind keine Zusage für ein bestimmtes Projekt. Jensen Huang beschreibt mit dem Denken in „Lichtgeschwindigkeit“ die Suche nach der zugrunde liegenden Grenze, bevor der bestehende Prozess als Ausgangspunkt akzeptiert wird.
Die wichtige Frage lautet nicht, wie man von denselben Menschen mehr Einsatz verlangen kann. Sie lautet, wie sich notwendige Arbeit von überkommenen Verzögerungen unterscheiden lässt.
1. Der bestehende Prozess ist ein Anhaltspunkt, kein Naturgesetz
Ein etablierter Zeitplan kann sehr unterschiedliche Dinge enthalten: physische Arbeit, Wartezeiten, Freigaben, Übergaben, gebündelte Bearbeitung und Kompromisse aus Gründen, die nicht mehr gelten.
Schrittweise Verbesserung [Continuous Improvement] setzt bei dieser bestehenden Anordnung an. Sie fragt, wie der Prozess ein wenig besser werden kann.
Das Denken aus ersten Prinzipien [First-principles Reasoning] stellt eine vorgelagerte Frage. Was muss tatsächlich geschehen, und was verhindert, dass es anders geschieht?
Das macht Erfahrung nicht wertlos. Erfahrene Menschen wissen oft genau, warum ein schwieriger Schritt existiert. Es geht darum, diese Gründe wieder sichtbar zu machen, statt den Zeitplan selbst als Erklärung zu behandeln.
2. Für jede wichtige Dimension die Grenze finden
„Lichtgeschwindigkeit“ steht hier verkürzt für die Grenze dessen, was unter den jeweiligen Einschränkungen möglich ist. Es bedeutet nicht, dass jede geschäftliche Tätigkeit buchstäblich durch die Ausbreitungsgeschwindigkeit des Lichts begrenzt wird.
Beim Rechnen können diese Dimensionen Speichertransfers, Energie, Antwortzeit [Latency], Verarbeitungsrate [Throughput], Kosten und Fertigungszeit umfassen. Ein Entwurf kann in einer Dimension nahe an seiner Grenze liegen, während in einer anderen noch erheblicher Spielraum besteht.
Diese Dimensionen zu trennen ist nützlich. Ein System, das eine Antwort schnell liefert, kann sich von einem System unterscheiden, das viele Anfragen effizient verarbeiten soll. Das eine zu optimieren bedeutet nicht automatisch, auch das andere zu optimieren.
Bevor das Team alles zu einem endgültigen Entwurf zusammenführt, sollte es verstehen, welche Anforderungen jedes Ziel stellt.
3. Eine ideale Ausgangsbasis festlegen und dann die Lücke erklären
Das Sechs-Tage-Beispiel wird erst wertvoll, wenn die übrigen achtundsechzig Tage untersucht werden.
Ein Teil dieser Lücke kann berechtigt sein. Ein langsamerer Prozess könnte weniger kosten, knappe Ausrüstung gerechter nutzen oder eine notwendige Prüfung ermöglichen. Andere Verzögerungen könnten aus doppelten Entscheidungen oder einer Abfolge entstehen, die seit Längerem niemand hinterfragt hat.
Die Übung macht diese Entscheidungen sichtbar. Statt darüber zu streiten, ob sich zwei Tage einsparen lassen, kann das Team diskutieren, warum es eine viel größere Lücke zur zugrunde liegenden Ausgangsbasis akzeptiert.
Ein physikalisches Minimum ist deshalb ein Bezugspunkt für die Beurteilung. Es ist nicht automatisch die richtige geschäftliche Frist.
4. Einfachheit bedeutet, unnötige Komplexität zu entfernen
Ein anspruchsvolles Rechensystem kann viele zusammenwirkende Teile enthalten und dennoch einen einfachen Zweck haben. Komplexität wird dann zum Problem, wenn sie besteht, ohne diesem Zweck zu dienen.
Huangs Ansatz besteht darin zu fragen, ob eine Komponente, ein Schritt oder eine Abhängigkeit notwendig ist. Ist sie notwendig, muss man sie verstehen. Ist sie es nicht, sollte man fragen, warum sie weiterhin besteht.
Das unterscheidet sich davon, ein System so weit zu reduzieren, dass es seine Aufgabe nicht mehr erfüllen kann. Stromversorgung, Kühlung, Tests und Zuverlässigkeit werden nicht optional, nur weil sie ein Diagramm kompliziert machen.
Das sinnvolle Ziel ist ein Entwurf mit genügend Komplexität, um seine Anforderungen zu erfüllen, aber ohne zusätzliche Komplexität, die lediglich Gewohnheiten bewahrt.
5. Führungskräfte müssen den Ort des Handelns verstehen
Ein Projektbericht kann eine Verzögerung beschreiben und dabei ihre Ursache verbergen. Dort, wo die Arbeit stattfindet, kann die Erklärung viel klarer sein.
Wie wird ein Kabel installiert? Warum wartet eine Komponente? Welche Entscheidung blockiert die nächste Aufgabe? Diese Fragen verbinden das Gesamtsystem mit den kleinen Handlungen, durch die es entsteht.
Dringlichkeit wird nützlich, wenn sie ein tatsächliches Hindernis beseitigt. Eine ehrgeizigere Frist immer wieder zu nennen, ohne die Arbeit zu verstehen, schafft keinen technischen Fortschritt.
Führung sollte helfen, die Einschränkung offenzulegen, das richtige Fachwissen zusammenzubringen und zu entscheiden, welche Abwägungen [Trade-offs] akzeptabel sind.
Fazit: Die Ausgangsbasis hinterfragen, bevor die Verbesserung gefeiert wird
Die Stärke des Denkens in „Lichtgeschwindigkeit“ liegt in der Disziplin, nach dem Warum zu fragen. Warum diese Reihenfolge? Warum diese Wartezeit? Warum dieser Entwurf? Welche Grenzen stammen aus der Physik und welche aus Entscheidungen?
Sind diese Antworten klar, hat schrittweise Verbesserung eine bessere Grundlage. Das Team kann einen Prozess verbessern, den es versteht, statt einen übernommenen Prozess nur aufzupolieren.
Die Methode verspricht nicht, dass jedes Vierundsiebzig-Tage-Projekt nur sechs Tage dauern wird. Sie verlangt vom Team zu wissen, warum es das nicht tut. Dieses Wissen verändert die Qualität jeder nachfolgenden Entscheidung.
Powered By K7
