Taiichi Ohnos Führungsstil: Verschwendung ist der Feind, nicht der Arbeiter

Kernfakten: Taiichi Ohno (1912–1990) war der Architekt des Toyota Production System (TPS), der Grundlage der modernen Lean-Fertigung. Er verbrachte mehr als 40 Jahre bei Toyota (1932–1978) und erfand das Kanban-Pull-System, Just-in-Time (JIT)-Produktion und die Fünf-Warum-Methode zur Ursachenanalyse. Sein Buch Toyota Production System: Beyond Large-Scale Production (1978, englische Ausgabe 1988) war der Ausgangspunkt der globalen Lean-Bewegung und prägte Six Sigma sowie die agile Softwareentwicklung.

Taiichi Ohno trat 1932 als junger Ingenieur in die Toyoda Spinning and Weaving ein. Er wechselte zu Toyota Motor, als die Automobilsparte gegründet wurde, und verbrachte die nächsten 46 Jahre im Unternehmen damit, ein Produktionssystem aufzubauen, das seine Wettbewerber in den folgenden vier Jahrzehnten zu kopieren versuchten — und dabei weitgehend scheiterten.

Das Toyota Production System verbesserte nicht nur die Effizienz. Es veränderte, was „Management" in einer Fabrik bedeutet. Und schließlich — über die Lean-Fertigung und deren Einfluss auf die agile Softwareentwicklung — veränderte es, was Management in jeder wissensbasierten Organisation bedeutet, die das TPS-Playbook gelesen hat.

Der Kern von Ohnos Erkenntnis ist einfach zu formulieren und schwierig umzusetzen: Jeder Schritt in einem Produktionsprozess schafft entweder Wert für den Kunden — oder nicht. Die Schritte, die keinen Wert schaffen, sind Verschwendung — und Verschwendung soll konsequent, systematisch und dauerhaft beseitigt werden. Nicht gemanagt, nicht optimiert, nicht eingedämmt. Beseitigt.

Er wurde 1949 zum Maschinenhallenleiter bei Toyota befördert und erhielt die Befugnis, den Produktionsboden neu zu gestalten. Dort wurde das Toyota Production System geboren. Er schied 1978 aus Toyota aus, starb 1990 und bekleidete nie den Titel des CEO. Sein Einfluss kam aus operativer Autorität und technischer Tiefe, nicht aus dem Organigramm. Er veröffentlichte Toyota Production System: Beyond Large-Scale Production 1978; die englische Übersetzung erschien 1988 und wurde eines der einflussreichsten Wirtschaftsbücher in der Geschichte der Fertigung.

Dieses Profil ist keine Verherrlichung des Lean-Mythos. Es ist eine Untersuchung dessen, was Ohno tatsächlich aufgebaut hat, was es erfordert, es anzuwenden, und wo das Modell an seine Grenzen stößt.

Führungsstil im Überblick

Diese Kombination machte Ohno ungewöhnlich in großen Organisationen. Die meisten leitenden Fertigungsmanager im Nachkriegsjapan und in den USA managten nach oben — sie interpretierten Berichte, nahmen an Meetings teil und trafen Entscheidungen auf Basis aggregierter Daten. Ohno managte nach unten und außen und blieb während seiner gesamten Karriere mit dem tatsächlichen Produktionsprozess verbunden. Seine Autorität kam nicht davon, Menschen zu managen. Sie kam daher, dass er die Arbeit besser verstand als jeder andere.

Wesentliche Führungseigenschaften

Die Ohno-Just-in-Time-Doktrin

Die Ohno-Just-in-Time-Doktrin besagt, dass ein Produktionssystem nur das herstellen soll, was der nächste Prozessschritt benötigt, in der benötigten Menge, zum benötigten Zeitpunkt — wobei Bestände, Wartezeiten und Überproduktion als Verschwendung und nicht als Puffer betrachtet werden. Pull-basierter Kleinseriendurchfluss ersetzt Push-basierte Großserienplanung, sodass Fehler und Engpässe sofort sichtbar werden. Die Doktrin gestaltet die operative Führung um die Beseitigung nicht wertschöpfender Zeit zwischen Kundenbestellung und Zahlungseingang.

Die 3 Frameworks, die Taiichi Ohno definierten

1. Just-in-Time: Nur produzieren, was gebraucht wird, wann es gebraucht wird

Just-in-Time (JIT) ist das bekannteste Element des Toyota Production System und das am häufigsten missverstandene. Es bedeutet nicht, so schnell wie möglich zu produzieren oder alle Bestände zu eliminieren. Es bedeutet, genau das zu produzieren, was benötigt wird, in der benötigten Menge, zum Zeitpunkt des Bedarfs — nicht mehr und nicht weniger.

Ohno entwickelte JIT als direkte Antwort auf das Ford-Massenproduktionsmodell, das er nach dem Zweiten Weltkrieg eingehend studiert hatte. Fords System produzierte in großen Chargen: eine Million dieses Teils pressen, einlagern, zur nächsten Station transportieren, warten, bis die vorherige Stufe abgearbeitet ist, bevor die nächste Charge fließen kann. Dieses Modell maximierte die Maschinenauslastung, schuf aber enorme Bestandspuffer zwischen jeder Produktionsstufe. Diese Puffer verbargen Qualitätsprobleme, verzögerten das Feedback über Fehler und erforderten Lagerfläche, die Kosten verursachte ohne Wert zu schaffen.

JIT kehrte die Logik um. Anstatt große Chargen zu produzieren und sie stromabwärts zu schieben, zog Toyota die Produktion: Nachgelagerte Prozesse signalisierten vorgelagerten Prozessen, nur das zu produzieren, was benötigt wurde, um Verbrauchtes wieder aufzufüllen. Das Ergebnis waren kleine Chargen, die kontinuierlich durch das Produktionssystem flossen, mit kurzen Zykluszeiten und schnellen Feedback-Loops, die Qualitätsprobleme sofort sichtbar machten — nicht erst nachdem eine Million fehlerhafte Teile produziert worden waren.

Die Übertragung auf Wissensarbeit ist bedeutsam. In der Softwareentwicklung entspricht das Äquivalent von JIT der Begrenzung des Work in Progress (WIP) und dem inkrementellen Aufbau von Features auf Basis tatsächlicher Kundennachfrage statt eines vorab definierten Roadmap-Batches. Im Content-Betrieb bedeutet es, Inhalte als Reaktion auf nachgewiesenen Bedarf des Publikums zu produzieren statt auf der Basis vierteljährlicher Redaktionskalender, die die Produktion weit vor der Veröffentlichung puffern. In jedem System, in dem Arbeit gebündelt und geschoben wird, ist die Frage „Wie würde JIT hier aussehen?" eine produktive Diagnosefrage.

2. Jidoka: Qualität einbauen, nicht herausprüfen

Jidoka — unterschiedlich übersetzt als „Autonomation" oder „Automation mit menschlichem Antlitz" — ist die weniger bekannte, aber wohl wichtigere zweite Säule des Toyota Production System. Das Kernprinzip lautet: Qualität soll in den Produktionsprozess eingebaut werden, anstatt am Ende inspiziert zu werden.

In Fertigungsbegriffen bedeutete dies, Maschinen mit der Fähigkeit auszustatten, Anomalien zu erkennen und automatisch anzuhalten, anstatt weiterhin fehlerhafte Outputs zu produzieren. Wenn eine Maschine stoppte, hielt die Produktionslinie an, und ein Arbeiter untersuchte das Problem, bevor die Linie wieder anlief. Das war in den 1950er Jahren radikal: Der akzeptierte Ansatz war, Maschinen bei maximaler Auslastung laufen zu lassen und am Ende der Produktionscharge auf Fehler zu prüfen.

Ohnos Erkenntnis war, dass Inspektion im Nachhinein eine Form von Verschwendung ist. Man hat bereits Zeit und Material aufgewendet, um fehlerhafte Outputs zu produzieren — die Inspektion am Ende offenbart nur den Schaden, anstatt ihn zu verhindern. Den Erkennungsmechanismus in den Prozess selbst einzubauen, stoppt Fehler am Entstehungsort, wo die Grundursache am nächsten ist und die Korrekturkosten am niedrigsten sind.

Die Übertragung auf Wissensarbeit sind automatisierte Tests, Continuous Integration und Definition-of-Done-Standards in der Softwareentwicklung. Anstatt Code zu schreiben und ihn in einer separaten QA-Phase auf Qualität zu prüfen, werden Qualitätsprüfungen in den Produktionsprozess eingebaut: Unit-Tests laufen bei jedem Commit, Linting fängt Fehler ab, bevor sie in die Codebasis gelangen, Code-Review-Standards verhindern, dass Fehler weiterrücken. Das Prinzip ist identisch mit Jidoka: Die Linie stoppen, wenn etwas nicht stimmt, anstatt den Fehler stromabwärts weiterzugeben, wo er teurer zu beheben ist.

3. Die 7 Verschwendungsarten: Ein Framework zum Sehen wertloser Aktivitäten

Ohno identifizierte 7 Kategorien von Verschwendung (japanisch: Muda) in Fertigungsprozessen. Sie sind: Überproduktion (mehr produzieren als nötig), Warten (Zeit, in der nichts passiert), Transport (unnötiges Bewegen von Materialien), Überbearbeitung (mehr tun als der Kunde verlangt), Bestände (mehr Material halten als benötigt), Bewegung (unnötige Bewegung von Personen) und Fehler (Outputs produzieren, die Anforderungen nicht erfüllen).

Die Stärke des Frameworks liegt darin, Verschwendung sichtbar zu machen. Die meiste Verschwendung in einem Produktionssystem ist für die Menschen, die darin arbeiten, unsichtbar, weil sie normalisiert ist — es ist einfach, wie die Dinge hier laufen. Ohnos 7 Verschwendungsarten geben Managern ein Vokabular und eine Perspektive, um nicht wertschöpfende Aktivitäten zu sehen, die sonst unsichtbar blieben.

In der Wissensarbeit übertragen sich die 7 Verschwendungsarten mit einigen Anpassungen. Überproduktion wird zum Erstellen von Features, die niemand nutzt, oder Berichten, die niemand liest. Warten wird zu Freigabe-Queues, Meeting-Verzögerungen und blockierten Arbeitselementen. Transport wird zum Kontextwechsel zwischen Meetings und Aufgaben. Bestände werden zu Work in Progress, das begonnen, aber nicht abgeschlossen wurde. Bewegung wird zum Navigieren zwischen nicht verbundenen Tools. Überbearbeitung wird zu Perfektionismus bei Deliverables, die nur gut genug sein müssen. Fehler werden zu Nacharbeit bei missverstandenen Anforderungen.

Die Disziplin liegt in der ehrlichen Anwendung des Frameworks. Die meisten Wissensarbeits-Teams würden, wenn sie ihren tatsächlichen Prozess gegen die 7 Verschwendungsarten abbildeten, feststellen, dass ein erheblicher Teil ihrer Arbeitszeit in eine dieser sieben Kategorien fällt. Das Unbehagen liegt nicht im Framework — es liegt darin, was das Framework aufdeckt.

Was Taiichi Ohno in Ihrer Rolle tun würde

Als CEO wäre Ohnos Frage an Sie die nach dem WIP (Work in Progress) an der Spitze Ihrer Organisation. Wie viele strategische Initiativen sind derzeit aktiv? Wie viele davon sind zu mehr als 50 % abgeschlossen? Die meisten Führungsteams haben zu jedem Zeitpunkt 8 bis 12 aktive Prioritäten, was bedeutet, dass keine davon genug Aufmerksamkeit erhält, um schnell voranzukommen. Ohno würde das als Überproduktion in der strategischen Planung identifizieren — mehr beginnen, als man abschließen kann, und damit Bestände schaffen, die veraltern, bevor sie fertiggestellt werden. Sein Rezept wäre, die meisten zu stoppen, zwei oder drei vollständig abzuschließen und dann neue Initiativen erst zu beginnen, wenn Kapazität frei wird. Das ist unbequem, aber so sieht JIT auf die Strategie angewendet aus.

Als COO ist es wert, das 7-Verschwendungsarten-Framework auf Ihre wesentlichen operativen Prozesse mindestens einmal jährlich als strukturierten Audit anzuwenden. Wählen Sie die drei wirkungsstärksten operativen Prozesse in Ihrer Organisation und kartieren Sie sie von Anfang bis Ende: jeden Schritt, jede Übergabe, jede Freigabe, jede Wartezeit. Dann kategorisieren Sie jeden Schritt als wertschöpfend oder als Verschwendung. Die meisten COOs, die diese Übung ehrlich durchführen, stellen fest, dass 40 bis 60 Prozent der Schritte in ihren Schlüsselprozessen in Verschwendungskategorien fallen. Das ist keine Kritik — es ist eine Ausgangslage. Ohno brauchte 30 Jahre, um sie bei Toyota zu reduzieren. Sie müssen das nicht in einem Quartal tun.

Als Product Leader hat Jidoka eine direkte Anwendung in Ihrem Qualitätsprozess. Wenn Ihr Release-Zyklus noch immer eine QA-Phase umfasst, die das Deployment absichert, fragen Sie sich, ob Qualität in Ihren Entwicklungsprozess eingebaut oder am Ende herausgepüft wird. Die Lücke zwischen diesen beiden Ansätzen ist die Lücke zwischen dem Finden von Fehlern, wenn sie günstig zu beheben sind (während der Entwicklung, wenn der Ingenieur, der den Code geschrieben hat, noch im Kontext ist), und dem Finden von Fehlern, wenn sie teuer zu beheben sind (während QA oder, schlimmer noch, in der Produktion). In automatisierte Tests, Pair-Programming und Definition-of-Done-Standards zu investieren ist eine Jidoka-Investition: Sie verschiebt den Erkennungspunkt nach links, näher zur Quelle.

Im Vertrieb oder Marketing gilt das JIT-Prinzip für Ihre Demand-Generation und Ihre Sales-Pipeline. Die meisten Sales-Pipelines haben enormes WIP: Hunderte oder Tausende von Opportunities in verschiedenen Stadien, viele davon veraltet, keine davon erhält konsistente Aufmerksamkeit. Das ist ein Bestandsproblem. Ohno würde Ihre durchschnittliche Deal-Zykluszeit betrachten, identifizieren, wo Deals ohne Aktivität brach liegen, und fragen, welcher Prozessfehler dazu führt, dass sie warten. Liegt es daran, dass Reps zu viele Opportunities gleichzeitig bearbeiten? Dass Qualifizierungskriterien zu schwach sind und Deals mit geringer Abschlusswahrscheinlichkeit Pipeline-Kapazität verbrauchen? Dass Freigabeprozesse Angebote verzögern? Der Engpass ist in den Wartezeit-Daten meist sichtbar — wenn Sie bereit sind, ehrlich hinzuschauen.

Rework-Analyse: Ohnos Doktrin für moderne SMB-Operationen

Ohnos zwei Nicht-Verhandelbares — Verschwendungsbeseitigung und kontinuierliche Verbesserung (Kaizen) — übertragen sich sauber auf moderne SMB-Operationen, wo die Belegschaft dünn und gepufferte Ineffizienz fatal ist. Die meisten kleinen Teams führen wöchentlich die Wissensarbeits-Äquivalente von Ohnos sieben Verschwendungsarten durch: duplizierte Spreadsheets, veraltete Pipeline-Datensätze, Freigabe-Queues, Tool-Wechsel und Nacharbeit durch fehlausgerichtete Briefings. Reworks Rolle in einem Lean-Ops-Stack besteht darin, diese Verschwendungen in einem einzigen System zu bündeln. Rework CRM + Sales Ops (12 $/Nutzer/Monat) beseitigt den Bestandspuffer verstreuter Deal-Daten; Rework Work Ops (6 $/Nutzer/Monat) ersetzt Übergabe-Queues durch eine gemeinsame Arbeitsoberfläche, die Engpässe sofort sichtbar macht, sobald sie auftreten. Die Kaizen-Disziplin — kleine, kontinuierliche, auf der Fläche beobachtete Verbesserungen — ist es, was einen Tool-Rollout in ein dauerhaftes System verwandelt. Rework liefert die Oberfläche; Ohnos Methode liefert die Gewohnheit, sie zu nutzen.

Bemerkenswerte Zitate und Lektionen jenseits des Boardrooms

„Wir schauen nur auf die Zeitlinie, vom Moment, in dem der Kunde uns eine Bestellung gibt, bis zu dem Punkt, an dem wir das Geld einziehen. Und wir verkürzen diese Zeitlinie, indem wir die nicht wertschöpfenden Verschwendungen entfernen." Das stammt aus Toyota Production System: Beyond Large-Scale Production, veröffentlicht 1978. Es ist eine präzise Beschreibung dessen, was Lean Operations tatsächlich anstrebt, und es lohnt sich, es gegen jede Verbesserungsinitiative Ihrer Organisation zu halten. Wenn Sie keine direkte Verbindung von der Initiative zur Verkürzung der Kunden-zu-Kasse-Zykluszeit ziehen können, ist es wert zu fragen, was Sie eigentlich optimieren.

„Ohne Standards kann es keine Verbesserung geben." Dieses Zitat fasst den weniger gefeierten Teil von Ohnos System zusammen: Bevor Sie einen Prozess verbessern können, müssen Sie definieren, was der aktuelle Prozess ist. Die meisten Wissensarbeitsprozesse sind nicht gut genug dokumentiert, um systematisch verbessert zu werden — sie werden von jeder Person, die sie ausführt, unterschiedlich durchgeführt. Einen Prozess zu standardisieren bedeutet nicht Starrheit; es bedeutet, eine Baseline zu schaffen, die Verbesserungen sichtbar macht. Man kann nicht wissen, ob man etwas besser gemacht hat, wenn man nicht weiß, wie der „aktuelle Zustand" aussieht.

Die andere ehrliche Lektion aus Ohnos Karriere handelt vom Unterschied zwischen dem Installieren von Tools und dem Aufbau einer Kultur. Die meisten westlichen Fertigungsunternehmen, die in den 1990er Jahren Lean einführen wollten, installierten die Tools — Kanban-Boards, 5S-Programme, Kaizen-Events — ohne die zugrundeliegende Philosophie zu verinnerlichen. Das Ergebnis war Lean-Theater: Die Oberflächenmerkmale des TPS ohne die Managementdisziplin, die es bei Toyota zum Funktionieren brachte. Ohnos System erfordert Beobachtung auf der Fläche, ehrliche Problemsichtbarkeit und langfristige Geduld, die die meisten quartalsorientierten Organisationen nicht aufrechterhalten können. Das ist kein Argument dagegen, es zu versuchen. Es ist ein Argument dafür, zu verstehen, worauf man sich tatsächlich einlässt, bevor man beginnt.

Wo dieser Stil an seine Grenzen stößt

Das Toyota Production System wurde für die Hochvolumen-Niedrigvariabilitäts-Fertigung konzipiert — die Produktion von Hunderttausenden gleicher Teile nach gleicher Spezifikation. Es lässt sich schwieriger auf kundenspezifische oder projektbasierte Arbeit anwenden, bei der Variabilität das Produkt und nicht der Fehler ist. Die 5-Whys-Methode funktioniert gut bei mechanischen Fehlern mit einzelnen Grundursachen, kann aber in komplexen soziotechnischen Systemen versagen, in denen mehrere gleichzeitige Ursachen interagieren — fünfmaliges Fragen nach dem Warum erzeugt eine Kausalitätskette statt des Netzes beitragender Faktoren, das das Problem tatsächlich erfordert. Und Ohnos Autoritätsmodell auf der Fläche setzt Manager voraus, die die verwaltete Arbeit wirklich verstehen — was in Wissensarbeit-Führungsebenen selten ist, wo die meisten Manager zwei oder drei Abstraktionsebenen von der tatsächlichen Ausführung entfernt sind. Die Prinzipien übertragen sich. Die spezifischen Methoden erfordern erhebliche Anpassung.

---

Zur weiterführenden Lektüre empfehlen wir Peter Druckers Führungsstil, Andy Groves Führungsstil, W. Edwards Demings Führungsstil, Akio Toyodas Führungsstil, Mary Barras Führungsstil und Hochleistungsteams aufbauen.