QiP: Qualität im Prozess und Frontloading

Schauen wir uns den Produktionsprozess einmal klassisch an: In der Fertigung wird ein Produkt hergestellt, dann erfolgt die Qualitäts-Kontrolle am Produkt und bei Problemen ist vielleicht Nacharbeit erforderlich. Übertragen auf den Entwicklungsbereich wäre das analog dazu: Nach dem Design erfolgt der Prototypentest (= Qualitäts-Kontrolle), es gibt vielleicht neue Erkenntnisse, die eine Design-Änderung erfordern (= Nacharbeit).

Arbeitsbegriffin indirekten Bereichen

Das ganze Konzept des Frontloading ist unter anderem deswegen entstanden, weil man diese Nacharbeit im Entwicklungsprozess eliminieren wollte. Immer wieder neue, weiter optimierte Prototypen zu testen ist, was den Arbeits- (= Produktions-)prozess angeht, zu viel Verschwendung. Gleichzeitig führen diese Schleifen auch zu Zeitverzögerungen im Projekt, so dass andere Abteilungen darunter zu leiden haben. Der Einkauf findet zu spät qualifizierte Lieferanten, die Produktion hat keine Zeit, den neuen Produktanlauf gründlich vorzubereiten.

Grundsätzlich geht man beim Frontloading davon aus, dass je besser ein Entwicklungsprojekt von der Idee über die Umsetzung bis zur Fertigung bearbeitet wurde, desto weniger Probleme entstehen, die Nacharbeit erfordern – sowohl im Zuge der Durchführung als auch am Ende beim Produktionsstart. Ein solches Projekt steht und fällt also mit der Qualität der Information, die in seinem Verlauf erarbeitet wird. Qualität im Prozess bei den indirekten Abteilungen ist also Qualität von Information. wird während der Arbeit nicht mit Kollegen – und schon gar nicht mit dem Chef – über den Fortgang der Arbeit, über mögliche Probleme oder Hindernisse diskutiert. Man versucht, alles selbst zu lösen und dann das Ergebnis zu präsentieren. Nur wenn ein Mitarbeiter alleine gar nicht weiter kommt, nimmt er Kontakt mit Kollegen auf. Etwas nicht alleine zu können, wird als Schwäche angesehen; die Arbeit – ebenso wie auch das eigene Expertenwissen – wird als persönliches Eigentum betrachtet.

Wie entsteht Arbeit, d.h. Information in den indirekten Bereichen? In den indirekten Abteilungen wird Arbeit in Fachbereiche, innerhalb der Fachbereiche nach Spezialisierung an einzelne Mitarbeiter verteilt. Mitarbeiter bekommen einen Arbeitsauftrag, den sie auf Basis ihres Wissens und ihrer Erfahrung erledigen. Konkret bedeutet Arbeit hier eine permanente Aneinanderreihung von Entscheidungen, die implizit auf der Basis von individuellem Wissen und Erfahrung getroffen werden.

Diese Einstellung ist nach Toyota das größte Produktivitätshindernis in den indirekten Abteilungen, sie führt zu Fehlern, Nacharbeit, Schleifen, Verzögerungen – und am Ende, wenn man dann die einzelnen Arbeitspakete wie Puzzlestückchen wieder zusammensetzt, zu Schnittstellenproblemen. Ganz abgesehen davon, dass durch diese Arbeitsweise jeder Einzelne sehr stark belastet ist und vielfach das Gefühl hat, hinter jeder Planung herzurennen.

Gerade in der Entwicklung, wo häufig Spezialisten für Module oder Komponenten verantwortlich sind und kaum Möglichkeit zum Austausch haben, werden Gründe oder Kriterien für bestimmte Entscheidungen nicht kommuniziert. Außerdem

Interdisziplinäre Teams als Lösung

Deswegen soll man auch in den indirekten Abteilungen im Team, bei Entwicklungsprojekten soweit wie möglich interdisziplinär arbeiten. So kann man versuchen, gemeinsam alle Bedingungen, möglichen Probleme, Fehler, Hindernisse zu antizipieren und vorausschauend zu lösen. Kriterien oder Beurteilungsmaßstäbe aus den einzelnen Abteilungen werden beschrieben, miteinander geteilt, gemeinsam erweitert und weiterentwickelt. Dies sind dann Gemba-Standards in den indirekten Abteilungen. Teamarbeit bedeutet hier nicht das Zusammenpuzzeln von Einzelteilen, sondern dass man alles an Wissen und Können transparent macht, miteinander teilt und bespricht, so dass man aus dieser Summe etwas komplett Neues gemeinsam entwickeln kann. Grundlegend für diese Arbeitsweise ist einerseits die Überzeugung, dass es Herrschaftswissen nicht geben darf. Andererseits müssen die Kenntnisse und Erfahrungen der Produktion und anderer Abteilungen bei der Entwicklung als unbedingt gleichwertig betrachtet werden. Dies erfordert ein gewisses Maß an Demut hinsichtlich dessen, was man selbst tut und Respekt gegenüber der Arbeit von Kollegen. Toyota hat es mit "Respect for People" formuliert. Das bedeutet, dass offen und ehrlich zwischen den Abteilungen kommuniziert wird – über Hierarchiegrenzen hinweg und auf Augenhöhe. Und dass auch Spezialistenwissen so dargestellt wird, dass jeder es verstehen, aufnehmen und damit arbeiten kann.

Die Autorin

Claudia Romberg arbeitet seit über 10 Jahren mit Shunji Yagyu zusammen und berät als Japan- und Lean-Expertin mittelständische Unternehmen. Der Fokus ihrer Arbeit liegt auf dem "Monozukuri"-Ansatz des TPS als einem wissensanreichernden organischen System, das die menschlichen Fähigkeiten bei der Entwicklung einer dynamischen, hochqualitativen und verschwendungsarmen Wertschöpfung in den Mittelpunkt stellt. im Vorfeld gründlich, um im Nachgang schneller die höchste Qualität mit weniger Verschwendung zu erreichen. Hier wird die Radikalität deutlich, mit der Toyota den Produktionsprozess als Prozess von der Idee bis zu deren Realisierung im Fertigungsprozess betrachtet. Am Ende ist die Produktion die Qualitätskontrolle für die Arbeit der indirekten Abteilungen: Kann ein Produkt tatsächlich sauber und schnell hergestellt werden? Wenn der Vertikalstart gelingt, dann haben die indirekten Abteilungen gute Arbeit geleistet.

Hier zeigt sich, dass es ganz grundsätzlich um eine gewisse Arbeitshaltung geht, die in der PDCA-Herangehensweise ihren Ausdruck findet: Im Prinzip kann jedes einzelne kleine und große Problem in bereichsübergreifenden Teams mit PDCA als Methode gelöst werden. Bei großen Projekten, wie zum Beispiel Produktentwicklungen, arbeitet man nach derselben Systematik: Man analysiert und plant

PDCA beschreibt hier weniger eine Methode als vielmehr eine Haltung gegenüber der Arbeit: Was muss alles bedacht und getan werden, damit die Arbeit schnell und sauber gelingt? Die bekannten Tools des Frontloading sollen genau das unterstützen: ein sogenanntes Obeya (lit. "großes Zimmer") als Projektraum, in dem alles visualisiert wird; ein multidisziplinäres Kernteam mit Vertretern aus allen betroffenen Abteilungen und Lieferanten, die bereits während der Entwicklung mit einbezogen werden. Und genau deswegen ist der Chief Engineer wie ein Unternehmer im Unternehmen verantwortlich für das gesamte Entwicklungsprojekt – von der Marktanalyse über die Idee und deren Konkretisierung bis zu dem Zeitpunkt, wo die Firma Geld mit dem neuen Produkt verdient.