Episode 231 Lean Product Development. Herzlich willkommen beim Zukunftsarchitekten, der Systems Engineering Podcast für Machende und Entscheidende. Am Mikrofon ist wieder Björn Schorre. Als Systemingenieur gebe ich dir Tipps und Impulse, damit du dein Projekt zum Erfolg führen kannst. So wirst du in dieser Episode erfahren, wie dir eine Wertstromanalyse hilft, deine Arbeitsstationen auch in der Entwicklung zu finden und wie das Verhältnis zwischen den Arbeitsstationen beschrieben werden kann.
Ja, herzlich willkommen hier im Podcast, liebe Zuhörer. Heute habe ich einen ganz besonderen Menschen hier bei mir im Podcast. Er hat genau wie ich auch Elektrotechnik studiert und das Ganze schon sogar zehn Jahre vor mir abgeschlossen, habe ich gesehen bei dem, was ich mir angeschaut habe und hat als Software-Engineer angefangen. Und das ist auch mein Werdegang. Ich bin auch direkt aus der Elektrotechnik in die Software gestiegen.
Ist dann über das Projektmanagement hin zu dem gekommen, was er heute macht, nämlich Prozesse verbessern und kontinuierlich daran arbeiten. Und damit begrüße ich dich hier bei mir im Podcast. Herzlich willkommen, Götz Müller. Hallo, Björn. Es freut mich, dass du auf meine Einladung hin Ja gesagt hast und hier zu mir gekommen bist. Denn ich habe deinen Podcast schon über mehrere Jahre gehört und immer wieder viel da rausgezogen.
Und deswegen möchte ich gerne meinen Hörern auch die Möglichkeit geben, da ein bisschen dran teilzuhaben. Das, was du ja machst, ist ja, du kümmerst dich um Prozesse, schaust dir Wertströme an, guckst, ob irgendwo Verschwendung stattfindet oder sowas und das ist auch etwas, was mir so am Herzen liegt. Ich habe ja vor kurzem auch eine Podcast-Episode zu diesem Timwood-Akronym gemacht, weil ich das auch für mich mal aufarbeiten wollte. Und ja, deswegen bist du heute hier.
Wir wollen so ein bisschen über Lean-Product-Development sprechen. Aber bevor wir einsteigen, habe ich irgendwas vergessen zu deinem Werdegang, was dir vielleicht noch wichtig ist, wo du sagen würdest, das ist das, was die Hörer eigentlich wissen sollten noch über mich. Ja, wichtig, vielleicht zu hochgegriffen. Wenn mich jemand fragen würde, wie ich mich selbst definiere, dann würde ich, und das wäre ja nur mit einem Begriff, dann würde ich mich eben als Systemingenieur bezeichnen.
Obwohl ich mich jetzt seit über 25 Jahren, und ich kann nur so ein bisschen flapsig sagen, seit dem letzten Jahrtausend mit dem Thema Lean-Management beschäftige. Aber eben von der Ausbildung her, von der Vertiefungsrichtung her, Elektrotechnik, Systemtechnik und dann eben in dem weiten Feld, in dem Komplex Telekommunikationstechnik. Das sind komplexe Systeme, das sind unheimlich verteilte Systeme.
Lange, lange, lange, bevor man im Automobil-Kontext überhaupt über so irgendwas wie Software gesprochen hat, wir haben das immer so ein bisschen flapsig auf die Runde geguckt. Ja. Also du sagst, die Telekom hat schon früher, bevor die Automobilindustrie mit Prozessen angefangen hat, mit Prozessen gearbeitet. Ja, natürlich, da gab es mechanische Einspitzpumpen, da haben wir schon Software gemacht. Ja, genau.
Ja, die waren da immer ein bisschen hinterher und das hat die dann natürlich auch manch einen Aufwand gekostet, sich dort reinzudenken. Weil das waren ja überwiegend Mechanikentwickler und vielleicht über die Elektronik ist das Ganze reingekommen, genau. Ja, genau. Und wir haben im Vorgespräch so ein bisschen herausgearbeitet, was wollen wir denn den Hörern bieten. Und wir sind eigentlich dann darauf gekommen, wir wollen uns über Lean Product Management unterhalten.
Lean haben vielleicht schon viele gehört, aber Richtung Product, Entschuldigung, nicht Product Management, Product Development, aufgepasst. Das ist nochmal ein bisschen was anderes. Also Lean Product Development, darüber wollen wir uns unterhalten und was ist dann da das Besondere? Ja. Was ist denn die, also ich glaube Produktentwicklung, Product Development, da würde jeder sagen, Ja, das kenne ich von den Hörern, aber was ist das Besondere am Lean-Product-Development aus deiner Sicht?
Ja, das halt, ich meine, da erzähle ich dir mit Sicherheit nichts Neues und wahrscheinlich auch den meisten deiner Zuhörer nichts Neues, dass natürlich die Produktentstehung schon in der Entwicklung beginnt, eben nicht erst in der Produktion. Von den Kosten über die gesamte Lebensdauer eines Produktes, mal relativ unabhängig davon, was wir da jetzt genau betrachten.
Nimmt halt die Produktentwicklung selber, also der Entwicklungsaufwand, sagt man so, im mittleren einstelligen Prozentbereich, sagen wir einfach mal eine Hausnummer 5%, der gesamten Produktkosten über die Lebensdauer und so weiter. Aber der Einfluss liegt halt bei weit über 50 Prozent auf die späteren Produktkosten, auf den Besamtkomplex. Und eben das, was letzten Endes dann ein Käufer, ein Nutzer bezahlt, wo ich ja irgendwo den Return on Invest haben will.
Und deshalb ist das halt ein ganz zentraler Punkt sich da möglichst früh Gedanken zu machen was ist denn das was ich hinterher haben will. Weil ich eben ganz früh schon die Wurzeln, den Samen lege und dann da die Wurzeln entstehen.
Genau, in dieser Konzeptphase, wie wir Systemingenieure das ja bezeichnen, da triffst du ja schon die ersten Entscheidungen, auch wenn es vielleicht erstmal nur Wünsche sind und wir das dann über verschiedene Iterationen in Anforderungen und Architekturen und Designs bringen, aber da lege ich ja schon gewisse Dinge fest. Richtig, einerseits legt man Dinge fest und andererseits, und das ist, glaube ich, auch nochmal eine Besonderheit des Lean Product Developments, ist.
Dass man eben sehr früh sehr viel investiert, aber wirkliche Entscheidungen versucht, so lange wie möglich rauszuzögern. Weil, und wie gesagt, da erzähle ich dir und wahrscheinlich allen Zuhörern auch nichts Neues, so eine Entscheidung wäre ja keine Entscheidung, wenn sie dann nicht irgendwo an einer Abzweigung, gehe ich halt links und dann gehe ich halt links weiter.
Und wenn ich dann irgendwann merke, rechts wäre doch besser gewesen, dann ist halt der Weg, den ich jetzt links gegangen habe, vor allem vom Faktor Zeit her, der ist halt verloren. Und deshalb versuche ich so lange wie möglich diese Entscheidung rauszuzögern. Ja, weil wenn ich die treffe, dann habe ich sie erstmal getroffen. Und oftmals wird. Werden Optionen dann auch rausgenommen aus dem Design. Genau. Und das spiegelt sich in zwei Konzepten, in zwei Begrifflichkeiten.
Einerseits das sogenannte Frontloading, also eben am Anfang massiv investieren, Menschen, Köpfe, aber eben, wenn man das wieder abbildet auf die gesamten Kosten, redet man halt trotzdem nur über einen. Einstelligen Prozentbereich. Ob das dann jetzt 5 oder 6 Prozent sind oder 7 Prozent, das ist dann in Anführungszeichen egal. Also ich stecke am Anfang viel Zeit rein, ich investiere viel und zöge aber trotzdem eben die Entscheidung möglichst lange raus.
Das ist der zweite Begriff, das hat sich halt irgendwie so eingebürgert, nennt sich Set-Based Concurrent Engineering.
Das heißt, ich arbeite mit Konzepten, mit Parallelen, dieses Concurrent, arbeite ich mit parallelen Konzepten und allein dadurch sollte klar sein, okay, da habe ich halt vielleicht ein Team von vielleicht auch nur eine Handvoll Leute, die sich halt um das eine Konzept kümmern und ein vergleichbares Team, das sich um das andere Konzept kümmert und die arbeiten parallel vor sich hin.
Tauschen sich natürlich schon aus, weil es wäre ja Unfug im Sinne von Verschwendungsarten, nicht genutztes Hirnkapazität letzten Endes auch, das an der einen Seite entstanden ist, überträgt man schon auf die andere Seite. Aber ich versuche halt möglichst lang diese Entscheidung zu verzögern, weil wenn ich dann wieder zurück muss, weil ich irgendwann vielleicht später merke, dass das eine Sackgasse war, muss ich halt wieder zur Kreuzung zurück, zur Abzweigung.
Das ist vom Geld her nicht schlimm, aber von der Zeit. Dieses Set-Based Design, ich glaube, du hast es jetzt etwas anders, Set-Based Concurrent Design gesagt. Das ist dieses Set, damit ist ja ein Satz gemeint, ein Satz an. Entwicklungsartefakten, die ich vorhalte, wo ich dann nochmal austauschen kann. Genau. Während meiner Entwicklung. Genau. Okay, und jetzt hast du gesagt, dann lasse ich die parallel laufen.
Das ist natürlich etwas, wo ich jetzt sagen würde, um Gottes Willen, die kann ich doch nicht alle parallel laufen lassen. Ja, das hört sich, wie gesagt, paradox an und wahrscheinlich die Controller dieser Welt kriegen jetzt die Krise. Aber wenn ich mir das halt über die Gesamtkosten anschaue, dann ist das trotzdem nur ein relativ kleiner Teil.
Und da muss man dann vielleicht eben nochmal einen weiteren Punkt und bisher auch in unserem Vorgespräch haben wir über Verschwendungsarten auch gesprochen. Und du hast gerade den Tim Wood genannt. Diese Zeitverschwendung, das sollte man, das muss man sich immer wieder klar machen. Viele, viele andere Verschwendungsarten kann ich mir Dinge zurückholen. Aber das mit der Zeitmaschine haben wir noch nicht erreicht. Und die Zeitverschwendung oder der Verlust an Zeit.
Kann ich halt nicht zurückholen. Das ist der eine Punkt. Und der zweite Punkt hat jetzt mit dem nicht so direkt was zu tun, weshalb man aber eben die Zeitverschwendung immer ganz bewusst im Kopf haben muss. Ich sehe sie nicht rumliegen. Alle anderen Verschwendungsarten sehe ich im Grunde. Wirklich physisch mit meinen Augen. Wenn sich das Lagerbiss oder die Decke stapelt, das sehe ich. Wenn die Leute unterwegs sind und sich bewegen und machen und tun und Sachen
hinter sich herziehen, das sehe ich alles. Physische Fehler sehe ich. Zeitverschwendung sehe ich halt nicht. Das ist der zweite Punkt. Und der dritte Punkt, warum Zeitverschwendung in Anführungszeichen halt eine blöde Verschwendungsart ist. Die Leute, die da tun, die sitzen ja nicht da und drehen Däumchen. Das heißt, die selber im Marmeladeglas sind ja brutal aktiv. Die merken nicht. Und wenn ich jetzt über diesen Entwicklungskontext rede, die entwickeln ja, die tun ja und machen ja.
Und dann komme ich halt irgendwann physikalisch gesprochen, ans Ende der Straße und da ist eine Sackgasse und jetzt merke ich erst, verdammt, ich bin jetzt monatelang hier in die Sackgasse reingefahren und jetzt bleibt mir nur eins, umdrehen, wieder zurückfahren. Genau. Und dieses Umdrehen und wieder zurückfahren, also wenn diese Entscheidung getroffen ist, dann beginnt ja die eigentliche Zeitverschwendung.
Dann fährst du wieder zurück, zurück, zurück, bis du an diese Kreuzung gekommen bist, wo du. Den vermeintlich falschen Weg genommen hast und ab dann läuft ja wieder die Zeit. Dann läuft sie quasi, also läuft ja eigentlich immer vorwärts, deswegen sagst du ja, das ist das Schlimmste, die schlimmste Verschwendungsart. Ja, und dann läuft ja, muss ich ja dann alles das wieder aufholen, was ich ja gerade quasi, zurück abgewickelt habe. Jetzt muss ich das ja wieder nach vorne laufen.
Jetzt muss ich das praktisch nachholen. Und wenn ich jetzt auf diesem mit diesem Set-Based Concurrent Engineering arbeite, dann kann man sich es physisch wieder so vorstellen, da stehen halt zwei Teams an der Gabelung. Und das eine Team läuft nach links und das andere läuft nach rechts.
Und wenn dann eins von den beiden Teams irgendwann merkt, es können auch drei sein oder vier, wenn dann ein Team merkt, ups, jetzt bin ich an der Sackgasse, dann müssen sie halt nicht zurück, sondern jetzt könnte man wieder sprichwörtlich sagen, dann packen sie, wenn sie im Wald wären, dann packen sie halt die Motorsäge aus und hauen sich eine Schneise durch den Wald.
Oder man sagt jetzt halt, ah, jetzt bin ich so dicht dran, an dem wo ich hin will, dass ich jetzt an der Stelle halt einfach aufhöre. Nicht dann mein Weg auf ein neues Projekt beame. Also da verliere ich dann nicht diese Zeit, die ich, also das Zurückgehen, da verliere ich jetzt nicht die Zeit, aber ich verliere die Zeit, weil ich ja den anderen Weg nicht gegangen bin. Weil ich nur einen Weg gegangen bin.
Ich muss doch einmal da einhaken. Du hast jetzt wieder gesagt, dann hast du zwei Teams oder drei oder vier. Das ist ja auch alles wirklich schön und gut, die Vorstellung. Nur wenn ich da in die heutigen Entwicklungsabteilungen reingucke. Dann höre ich da immer wieder, boah, wir haben so viel zu tun. Ich habe hier drei Projekte auf dem Stapel liegen, ich komme da gar nicht zu.
Und jetzt stelle ich mir vor, diese eine Person kriegt jetzt da noch oder dieses eine Team kriegt noch ein Projekt da hingelegt. Ich glaube nicht, dass die das alles können. Also die würden uns jetzt hier, glaube ich, einen Vogel zeigen, während wir hier reden. Deswegen die Frage, kann ich das auch mit einem Team machen?
Also wenn jetzt ein Team an dieser Kreuzung steht und weißt, okay, eigentlich müssten wir uns jetzt entscheiden links oder rechts, aber könnte auch ein Team beide Wege beschreiten, indem die mal das eine und mal das andere machen? Könnten wir natürlich theoretisch machen, aber sprichwörtlich, ich kann halt nur ein Loch schaufeln.
Ich habe halt nur eine Schaufel und ich schaufel halt entweder an dem einen Loch oder ich schaufel an dem anderen Loch, in der Hoffnung, dass ich irgendwann, entweder einen Diamanten oder auf eine Quelle stoße und das ist aber halt das ist dann das, was in dem zweiten Begriff drinsteckt, in dem Frontloading, dass ich wirklich bereit bin am Anfang, mehr zu investieren mehr Zeit und mehr Menschen eben investieren und ein Stück
weit auch ein bisschen mehr Geld aber wenn man halt wieder berücksichtigt, dass der reine Entwicklungsaufwand, nur ein ganz kleiner Teil, da ein 10% ist, dann nimmt man das halt in Kauf.
Ja, dann ist es ja vielleicht besser, also das ist ja wahrscheinlich dieses Frontloading, was du sagst, dann ist es vielleicht besser, anstatt, dass ich dann da ein ganzes Team loslaufen lasse und links oder rechts gehe, dass ich vielleicht dieses Frontloading mache und mal einen, diesen Weg entlang gehen lasse oder anfangen lasse, dieses Loch zu graben, um zu sehen.
Das Loch zu graben ist vielleicht der schlechtere Weg, schlechte Idee, aber vielleicht geht einer mal diesen Weg und schaut links und rechts, ob das überhaupt denn der richtige Weg sein kann, ob man denn damit zum Ziel kommen kann. Das wäre wahrscheinlich dieses Frontloading, die Untersuchungen, Analysen, die ich machen kann, bevor ich dann wirklich in die...
Ja, aber wie gesagt, das ist paradox und du hast im Grunde ja auch gesagt und deshalb tun sich viele damit schwer, weil es halt, sagen wir mal, manchen althergebrachten Gewohnheiten ein Stück weit widerspricht. Aber bleiben wir bei dem Beispiel. Also da sind dann wirklich zwei Teams, die halt ein Loch graben. Und die einen stoßen dann halt vielleicht auf eine Goldader und die anderen stoßen auf eine Diamantader.
Oder die einen konzentrieren sich drauf und sagen, wir wollen eine Goldader finden und die anderen halt eher eine Diamantader. Und ich zögere halt diese Entscheidung aufzuhören, dass ein oder eins von den beiden Teams aufhört zu graben, das zögere ich so lange wie möglich raus. Und das zögere ich eben auch raus dann im Kontext, und da hinten sehe ich jetzt das Beispiel ein bisschen, wenn es halt dann um so Dinge wie Fertigungsüberleitung geht.
Ja, warte, aber warte mal. Wenn ich auch da investiere. Mindestens in Gedanken, die ich mir drüber mache, wie sieht jetzt dieser Kotflügel aus oder diese Motorraumhaube oder dieser Ausschnitt von meinen Blinkern, von der Beleuchtung oder was auch immer oder irgendwas im Innenraum. Also ich investiere wirklich doppelt.
Dadurch, dass aber, und das muss man halt auch ein Stück weit wissen oder im Hinterkopf haben, aufgrund von anderen Mechanismen, die dann von dem jetzt erstmal völlig losgelöst sind, Sagt man aber durchaus, dass klassisch ein Toyota-Produktentwicklungsingenieur doppelt so produktiv ist wie ein Automobilentwickler in den westlichen Automobilunternehmen. Und dadurch relativiert sich es wieder, dieser vermeintliche Mehraufwand.
Man sieht es eben zum Beispiel, jetzt vor kurzem wieder, müsste ich raussuchen, kann man, wenn du magst, auch gerne in den Shownotes oder so verlinken, da gab es wirklich Untersuchungen, wie lange entwickelt Toyota und jetzt einfach auf dem Zeitstrahl, nicht vom Aufwand her, rein auf dem Zeitstrahl, das ist ja das, was wir als Kunde sehen. Wir sehen ja nicht, ob da jetzt 100 Leute dran arbeiten oder 50 Leute dran arbeiten. Wir sehen halt, dauert es fünf Jahre oder dauert sieben Jahre.
Das Spannende ist halt, bei Toyota legen wir jetzt nicht auf die Zahl fest, dauert es halt bloß fünf Jahre. Bei den anderen dauert es sieben. Jetzt hast du aber eben gesagt, wir haben da die Goldader und die Diamantader. Das sind ja beides eigentlich, das hört sich jetzt erstmal ja an, beides erstrebenswert. An beiden möchte ich ganz gerne weiterarbeiten. Da kann ich ja was dran verdienen.
Die Überleitung in die Fertigung könnte dort doch eigentlich sein, ich muss jetzt herausbekommen, welche Ader vielleicht die größere ist. Wo kann ich mehr Benefit rauskriegen? Und das ist auch an der jeweiligen Ader dann entsprechende oder an dem jeweiligen Projekt halt die entsprechende Untersuchung, was bringt denn jetzt am meisten Kundenzufriedenheit oder was macht dann am meisten Umsatz am Ende des Tages. Mit welcher Option sollte ich wählen, um da weiterzumachen.
Und dort, an dieser Stelle, da setze ich dann, also wir haben jetzt Gold- und Diamantader, das war dein Beispiel. Und wenn ich jetzt festgestellt habe, die eine ist eine Milliarde Euro wert und die andere nur 500 Millionen, dann weiß ich natürlich, wo investiere ich. Und dort setze ich dann zumindest primär an. Ich muss ja nicht das ganze andere wegschmeißen, aber das lasse ich dann vielleicht erstmal ruhen.
Ja, wobei an der Stelle natürlich zugegebenermaßen dieses spontane Beispiel Gold und Diamanten ein bisschen hinkt. Weil, aber es ist ein guter Punkt, die Überlegung, was wollen meine Kunden haben, das überlege ich mir natürlich auch ganz, ganz früh und da gibt es diesen einen Klassiker eben zum Beispiel aus dem Automobilkontext wieder, dass man in Amerika halt unbedingt diesen Dosenhalter braucht im Auto.
Das ist ein absolut entscheidendes Merkmal. Und jetzt wäre es natürlich saublöd, um es ein bisschen derb auszudrücken, wenn ich das erst merke, wenn das fertige Auto beim Händler steht. Wenn da der Kunde reinläuft und die quasi zweite Frage ist, nachdem er die Tür aufgemacht hat, wo stelle ich meine Dose ab? Und da kommt jetzt ein weiteres wichtiges Element rein, in der Rolle des Chief Engineers, der sich halt mit solchen Fragen sehr früh beschäftigt.
Und in dem Kontext, wo Toyota in den 70ern, 80ern in die USA expandiert hat, da hat er sich damit beschäftigt. Da ist er halt in den USA auf der Landstraße unterwegs gewesen. Und zwar nicht bloß eine Woche mal geschwind, sondern richtig, richtig lange. Und da hat er halt gemerkt, hey, die Autos, die ich mir dort anschaue, die haben all diesen komischen Dosenhalter. Also ist ihnen irgendwie klar gewesen, das scheint doch irgendwas Wichtiges zu sein. Ja, genau.
Es gibt doch dieses Kano-Modell, wo die Anforderungen in die Basisfaktoren, Leistungsfaktoren und Begeisterungsfaktoren eingeteilt werden. Und das ist so ein ganz, ganz, ganz klassischer Basisfaktor dann, wo dir keiner sagen würde, ich brauche das. Weil die einfach voraussetzen, das muss da sein. Das ist da. Das haben wir schon 20 Jahre in den Autos gehabt, da wird das auch in den nächsten Autos sein.
Aber wenn man das nicht weiß, wenn man in neue Märkte rein will, dann kann man sich da natürlich auch leicht vertun, wenn man da diese Eigenschaften, diese besonderen Dinge des Marktes nicht kennt. Also über diese Dinge, die ich mir jetzt, wenn wir zurückkommen auf unser Beispiel, wenn ich die beiden Wege gehe, da reden wir mehr über Dinge, die halt produktionsrelevant sind.
In allen technischen Details, da könnte man jetzt wahrscheinlich lang drüber reden und möglicherweise aber die Zuhörer halt unter Umständen langweilig. Weil da geht es dann wirklich in tiefste Produktionstechnik rein. Wo ich aber eben auch da versuche, möglichst lange eine Entscheidung rauszuzögern.
Zum Beispiel, indem ich auch, und das ist auch ein wichtiges Element, wo meiner Ansicht nach eine große Differenzierung, und ich nehme halt wieder die westlichen Automobilhersteller herrscht, dass halt die Zulieferer auf eine ganz andere Art einbezogen werden in die Produktentwicklung, schon in ganz frühe Zeiten rein, dass man denen eben dieses Set, nennen wir es mal so, auch denen das möglichst früh zeigt und sagt, schaut euch mal an, das sind unsere Ideen.
Was könnt ihr uns da unterstützen? Und nicht wie das halt doch eher bei den, ich nenne jetzt keine Marken, aber bei den westlichen Automobilherstellern halt eher, und da kannst du sie alle in einen Sack schmeißen, egal ob es deutsche oder amerikanische sind, da ist eher der Zulieferer die Zitrone, die ich auspresse, bis die Kerne rausfallen.
Es ist auch ein völlig anderer Ansatz. Das geht so weit, gut, das haben wir vielleicht ansatzweise, dieses Supplier-Development, das haben wir zum Teil auch bei westlichen Automobilherstellern meiner Ansicht nach zu spät. Das fängt bei Toyota viel früher an, geht sogar so weit, wie gesagt, das ist ein ganzes, man könnte es fast Ökosystem nennen, wie die unterstützt werden, damit sie eben ganz früh auch in die Produktentwicklung einbezogen werden.
Dass ich denen also nicht so sprichwörtlich eine Spezifikation über den Zaun werfe und mit der Ansage, mit der Einkäuferansage, jetzt macht mal, aber das muss so billig wie möglich sein. Ich beziehe die ganz früh ein und ich mache auch da... Keine Geheimnisgrämerei. Also ich bin auch da offen gegenüber. Man könnte es jetzt Firmengeheimnisse nennen. So im Sinne von, und natürlich ist es auch eine Vertrauensgeschichte. Da redet dann auch keiner drüber.
Hey, der baut jetzt gerade das Auto und da sieht das, was wir jetzt so im Smartphone-Kontext ja immer wieder erleben. Dass halt irgendwelche Leaks da existieren, wo halt dann schon ein Jahr bevor das Ding auf den Markt kommt, halt dann schon irgendein Formfaktor durch die Lände geht. Ja, okay.
Das heißt also, die geben schon mal ihre Subsystemspezifikationen heraus, binden die mit ein, sagen, was hast du denn da noch für Ideen oder vielleicht gehen die mit denen ja auch nochmal oder schicken sie sie auch nochmal los und sagen, mach doch mal deine eigene Untersuchung und guck dir nochmal dein spezielles Produkt in diesem Kontext an.
Nicht nur hier jetzt auf der Fahrbahn, sondern vielleicht gehst du mal und guckst dir das an, wenn das Auto bei einem Pharma ist oder wenn das Auto bei einem Immobilienhändler genutzt wird. Nutzen die das anders oder nutzen die das gleich? Da kann es auch durchaus unterschiedliche Ergebnisse geben. Ja, wobei ich das jetzt eher beim Hersteller selber noch sehe, es geht mehr halt um fertigungstechnische Aspekte.
Und es geht dann eben auch so weit, dass ich halt nicht, wie das jetzt auch eher bei westlichen Automobilherstellern ist, dass ich halt zwei, drei Zulieferern die gleiche Spezifikation auf den Tisch werfe und die wissen genau, dass das noch zwei andere haben und dadurch dann da der Preiskampf ohne Ende läuft, sondern ich gebe es halt nur einem. Und dann kann sich der eben auch darauf verlassen, die Zeit und das Geld, das er dann da auch investiert, ist halt nicht verloren.
Und er hat eine ganz andere Form von Motivation, da wirklich mitzuarbeiten. Und es gibt meiner Ansicht nach fast nur noch eine Branche, wo das noch krasser ist. Das ist ein Baukontext. Auf klassischen Baustellen herrscht im Grunde Krieg. Das sind ja viele Gewerke, jeder gegen jeden. Und jeder versucht bloß, so lange wie möglich, sich den Rücken freizuhalten, in der Hoffnung, dass irgendein anderer sprichwörtlich die Hose runterlassen muss, weil er sich völlig überbucht hat.
Aber die Automobilindustrie kommt dem schon recht nahe zu dem. Und ich bin ein bisschen in beiden Branchen unterwegs und da glaube ich, kann ich das auch vergleichen. Okay, ich muss nochmal den Schritt zurückgehen. Du bist jetzt in Richtung Fertigung unterwegs gewesen. Und ich bin aber beim Lean Product Development, bin ich ja eigentlich noch in der Entwicklung, also aus meiner Sicht zumindest. Und ich bin ja auch üblicherweise, also ich bin ein Kind der Entwicklung.
Also ich bin da groß geworden, habe da jahrelang gearbeitet. Und was ich aber immer gesehen habe, in den verschiedenen mittelständischen Firmen, wo ich war, da sind ja auch, wir haben auch immer Fertigung gehabt. Wir sind ja nicht nur Softwareentwickler gewesen, weil Software, die entwickelst du bei dir am Rechner und dann ist die fertig. Da setzt sich kein Fertigungsmitarbeiter hin und schleift da noch irgendwelche Bits und Bytes ab.
Aber Elektronik muss irgendwo eingebaut werden, du brauchst irgendwelche Mechanikbauteile und Kabel und Stromschienen und so weiter, musst du alles irgendwie einbauen. Und diese Leute, die da in der Fertigung unterwegs sind, die sind aus meiner Sicht, oder die habe ich immer versucht, frühzeitig mit einzubinden. Siehst du das auch so? Ja, absolut, genau. Also dieses Frühzeit, da gehört es definitiv dazu. Ja, aber nicht nur, dass die mir sagen, so kann ich das nicht bauen.
Sondern dass die mir auch sagen, hör zu, ich möchte ganz gerne nur gerade M-Nummern haben bei meinen Schrauben, weil ich sonst mich zu sehr vertue mit dem Rausnehmen aus den Schächtelchen. M2 und M3 sind so eng, so nah beieinander, dass ich mich da oftmals vertue in der Hektik des Alltags. Zum Beispiel. Also die liefern mir am Ende des Tages auch Anforderungen an meine Mechanikentwicklung,
an meine Elektronikentwicklung. Genau. Und deswegen finde ich auch immer ganz wichtig, dass die so früh wie möglich befragt werden, was die denn auch für Wünsche an das neue Produkt haben. Und wenn ich dein Nicken sehe und deine Aussage, dann gehört das mit zu diesem Lean-Product-Development. Absolut, absolut. Und da ist zum Beispiel auch ein wichtiger Punkt ganz entscheidend. Ich muss als Entwicklungsabteilung verstehen, dass mein Kunde die Produktion ist. Und umgekehrt muss ich dann durchaus.
Und das ist eine Sache, wo ich glaube, viele Produktionsmenschen, den würde ich da wünschen, noch ein bisschen breitere Schultern zu bekommen. Sie sind der Kunde und die Produktion ist der Lieferant. Und dann muss ich auch, so wie ich als normaler Kunde ja bereit bin. Dem Hersteller zu sagen, wenn er mir was anbietet, das fällt mir nicht, das mag ich nicht, was auch immer. Und natürlich macht man in dem Kontext dann sowas wie Kundenbefragungen usw.
Für einen externen Kunden ist das ganz normal. ein Produktmanagement, befragt sein, macht Marktuntersuchungen, so wie dieser Chief Engineer. Mit so einer Zwitterposition, eben geguckt haben, was wollen die da draußen? Ach, guck mal, die Autos haben dort alle Dosenhalter, scheint irgendwie zu sein.
So frage ich auch meinen internen Kunden, und das ist ein weiteres, glaube ich, viel zu oft unterschätzt, das kann ich nachher noch eine Anekdote erzählen, ein viel zu oft unterschätztes Thema, und zwar ist es eine, ich nenne es Dualität an Kunden-Lieferanten-Beziehungen. Weil einerseits bin ich als Produktion der Kunde, der Entwicklung.
Das heißt mit den Entwicklungsergebnissen, mit deren Produkten arbeite ich weiter, also mit Spezifikationen und allem drum und dran, mit technischen Zeichnungen, wo ich dann das Ding physisch, vorher sind es ja nur Striche auf dem Papier, um es mal so auszudrücken. Und andererseits, und das ist eine Chance, die, glaube ich, immer noch viel vergeben wird, bin ich aber auch Lieferant als Produktion, nämlich Lieferant der Information, was brauche ich denn?
Und das ist das, wo ich sage, hey, macht mal ein bisschen breite Schultern auch, einerseits. Und andererseits redet halt viel mehr miteinander. Was braucht ihr, damit ihr günstig produzieren könnt? Günstig im Sinne von Zeit, aber auch günstig im Sinne von Material. Und welche Informationen brauche ich dann, damit ich meine Entwicklung entsprechend einstellen kann? Damit ich mich drauf einstellen kann? Guck, wir haben das damals bei meinem letzten Arbeitgeber, ging es darum.
Dass wir Platinen immer lokal bestellt haben, bei einem Platinenhersteller da um die Ecke. Und die waren immer sehr teuer. Das ist jetzt nicht so großartig ins Gewicht gefallen, weil das waren halt kleine Stückzahlen, aber jeder einzelne war halt sehr teuer. Und das hat immer die Entwicklung direkt gemacht. Und dann, wenn es fertig war, dann ist der Einkauf mit eingebunden worden.
Du hast jetzt eben um die Fertigung gesprochen, da kann natürlich auch noch diese ganze Einkaufsabwicklung auch noch dazwischen hängen, aber irgendwo gibt es dann eine Fertigung.
So und die Fertigung, Quatsch und der Einkauf, der musste dann zusehen, dass diese Platinen in hoher Stückzahl bestellt worden sind und dann fingen die erst an, wenn die Entwicklung fertig war, den Lieferanten zu qualifizieren und der konnte plötzlich nicht diese Qualität liefern und der musste erst dahin gebracht werden. Und das war auch eine Zeitverschwendung, die wir dann da hatten.
Weil dann war der Einkauf in der Diskussion, nein, das passt nicht, Qualität ist nicht richtig, ach, wir müssen wieder in die Entwicklung gehen, die müssen vielleicht nochmal was umdesignen oder Beschichtung oder eine Lagenbreite ändern, damit es passt. Ja, und so ging halt natürlich auch viel Zeit ins Land. Und wir haben das dann irgendwann mal in Deutschland.
Gesprächen gelöst, indem wir uns, indem wir wirklich diese eine Gruppe, zwei, drei Entwickler und die gute Frau, die den Einkauf gemacht hat. Wir haben uns zusammengesetzt. Ich habe das moderiert und wir haben das zusammengesetzt und wir haben gegenseitig die Wünsche und die Aktivitäten ausgetauscht, die dann immer das zur Folge hatten.
Und dann konnten wir uns auf etwas einigen und das hat beiden Seiten super gut getan, sodass wir dann gesagt haben, okay, lass es uns doch in Zukunft immer so machen. Wir haben dann hingekriegt, dass auch von den zukünftigen Lieferanten in kürzester Zeit die Platinen für die Entwicklung hergestellt worden sind. Und das ging nur dadurch, dass wir diese Wünsche ausgetauscht haben. Der eine hat gesagt, ich brauche das. Und der andere hat gesagt,
ich kann dir das liefern. Oder wie willst du es geliefert haben? Und das haben wir alles ausgetauscht. Und von da an hatten wir dieses Problem aus der Welt geschafft. Und genau so, hast du es ja beschrieben, kann man es auch mit anderen Kollegen und Kolleginnen in dem Entwicklungsprojekt tun. Genau.
Und ich muss halt jetzt als Leiterplatten-Differant bereit sein, halt nicht nur auf Masse zu arbeiten, sondern ich muss halt vielleicht so was wie die Mini-Applikationsabteilung vielleicht haben, die mir halt für den Musterbau meines Kunden Dinge, also ich muss auch da bereit sein, mich ein bisschen zu bewegen. Und natürlich muss der Hersteller bereit sein, das entsprechend zu honorieren, weil natürlich jetzt ein Musterbau hat, typischerweise Leiterkarten, völlig anderen Preiskontext hat.
Also muss ich irgendwo unterm Strich, muss ich es für beide Seiten lohnen. Auf der einen Seite der Faktor Zeit, wie du es beschrieben hast, und auf der anderen Seite eben die Masse und die zusätzlichen Köpfe vielleicht, die ich jetzt, wenn ich rein auf Masse gehe, brauche ich das nicht.
Da brauche ich diese Musterbauabteilung oder diese Musterleiterplattenfertigung, wo ich dann halt auch beim Leiterplattenverpressen zum Beispiel halt darauf eingestellt sein muss, dass halt mal morgen zum 10.00 einer anruft, heute Nachmittag um zwei brauche ich hier drei Musterleiterplatten. Da darf das nicht jetzt die Produktion völlig über den Haufen werfen. Oder ich stelle halt eine extra Presse hin, wo dann nur diese Musterdinger macht. Genau.
Wir haben jetzt so ein bisschen das Problem beschrieben und vielleicht auch schon, warum wir das lösen müssen. Gibt es irgendwelche Möglichkeiten, wie wir das lösen können? Also gibt es Methoden, wie man da rangehen kann, um ein Product Development in Richtung Lean Product Development zu bringen? Ich würde sagen, das Allerwichtigste ist einfach die Einstellung der Sache gegenüber.
Wenn mir das nicht klar wird und das beginnt bei so kleinen Dingen eben wie beim Verständnis innerhalb der Entwicklung, ein Kunde ist die Produktion. Ich habe vorhin kurz eine Anekdote erwähnt. Ich erzähle die geschwind. Da hatte ich, im Grunde war es ein Tagesworkshop über ein anderes Thema, Stiefer Toyota Kata, mit einer Entwicklungsabteilung gemacht und am Ende halt so eine Feedbackrunde am späten Nachmittag und der Entwicklungsleiter war da dabei.
Das war im Grunde im weitesten Sinne ein Hausgerätehersteller, meinte, wo er sein Statement abgibt, so eine kurze Sprechpause gemacht und dann sagt er, für ihn war das Highlight diese Erkenntnis, mein Kunde ist die Produktion. Obwohl es eigentlich gar nicht das Thema war von dem Workshop, das war dann das besonders Spannende.
Sagt er, das war für ihn das Highlight, dass sein Kunde die Produktion ist, dass es ja gar nicht das Produktmanagement ist, dass das Produktmanagement zwar sein Auftraggeber ist, der die Kohle sprichwörtlich auf den Tisch legt und definiert auch, okay, wir bauen jetzt das oder wir bauen jetzt das, aber seine Entwicklungsergebnisse, also eben Spezifikationen. Zeichnungen, Pläne, Stromläufe und so weiter und so weiter, das ist ja die Produktion.
Die gehen an die Produktion und die müssen damit weiterarbeiten. Ich spreche dann immer gerne davon, dass das veredelt wird. Ich sehe das ... Fast genauso wie du. Du hast irgendwo einen Auftraggeber, du hast die Entwicklung, die aus diesem Lastenheft, was da reinkommt, veredeln die das ja. Die machen aus dem Lastenheft Pläne, woraus man ein tolles Produkt bauen kann. Und das muss jetzt von irgendwem anders noch gemacht werden, nämlich von der Fertigung oder Produktion, nenn es wie du es willst,
die veredeln jetzt die Pläne in physische Elemente, die dann diese Funktion erfüllen. Genau. Und du hattest vorhin noch ein Beispiel genannt in diesem Entwicklungsmix, Hardwareentwicklung, sei es jetzt Leiterkarten oder physische Dinge, Mechanik und Software. Und das ist auch eine Sache, das weiß ich noch, das ist schon, na, ganz letztes Jahrtausend war es nicht, aber ziemlich dicht dran, Anfang des aktuellen Jahrtausends. Das ist wiederum eine Sache, die der Softwareentwicklung total fehlt.
Dieses normative Element der Produktion. Ein Test deckt sowas ansatzweise ab, aber dem Tester ist es im Grunde fast egal, was da drin passiert, weil er guckt ja eher auf so Aspekte an. Da gibt es ja ganz diffizile Unterscheidungen zwischen Verifikation.
Validierung, also habe ich es richtig gemacht, habe ich das Richtige gemacht, das sind ja zwei ganz gravierende Unterschiede und dann das Testen ist das, was drauf ist, dann auch drin und was draufsteht, ist das auch drin, solche Dinge, aber das ist einer der Punkte, wo meiner Ansicht nach, ja ich verstehe mich mal zu so einer Aussage, das wäre wahrscheinlich wirtschafts-Nobelpreis fähig, wenn da irgendeiner eine
zündende Idee hat, wie ich dieses normative Element in die Softwareentwicklung reinkriege. Das wissen die im Grunde ein Hardware-Entwickler, egal ob es jetzt ein reiner Elektronik-Entwickler ist oder ob es ein Mechanik-Entwickler ist, der ist sich oft gar nicht darüber bewusst, was für einen Sägen er da eigentlich hat. Obwohl es ja durchaus auch Kämpfe gibt, von wegen, hey, du bist so blöd, das Blech soll so biegen, wie ich mir das auf der Zeichnung überlegt habe.
Solche Dinge gibt es ja dann schon. Aber die Software-Entwickler, wenn sie sich das bewusst machen, die die würden auf den Knien so jemandem, glaube ich, entgegenrutschen, wenn es dieses normative Element gäbe. Auch wenn es dann keinen Spaß macht, mit denen umzugehen. Also Produktion und Entwicklung ist manchmal schon auch Kampf ein Stück weit. Um den Kampf, sagen wir, um den besten Weg. Aber wenn ich diesen Kampf gar nicht habe, dann werde ich auch nie wissen, ob das der beste Weg ist.
Ich habe irgendwas und dann teste ich und es macht es vielleicht. Aber ob das vielleicht im Sinne von weniger Lines of Code oder leichter produzierbar wäre, das gibt es halt in dieser Fragestellung. Ja, ich glaube, es gibt das schon. Das musst du aber dann als Softwareentwickler auch entsprechend einrichten und nutzen. Es gibt ja diese sogenannten Build-Server, die du dann ja auch automatisiert laufen lassen kannst.
Und da musst du natürlich auch ein entsprechendes Mindset für haben, um die dann zu benutzen. Also auch da habe ich schon die wildesten Dinge gesehen. Freitags 13 Uhr, jemand checkt seine Software ein, die er eine Woche lang geschrieben hat und schaltet den Rechner aus und geht nach Hause. Und zwei Stunden später steht das ganze System auf rot, weil er da einen großen, Fehler eingebaut hat und Und das ganze Testsystem ist halt stehen geblieben.
Auch sowas hat man da gesehen. Also du musst das dann halt schon regelmäßig benutzen oder du musst es vielleicht dann als Prozess, als Softwarequalität dann halt mehrstufig aufbauen. Aber das ist schon ein Mindset, was man dann benutzen muss. Also dieses Beispiel mit den Schrauben, wie du gemacht hast.
Ja, aber warte mal, bei der Software, ich muss das halt auch aktiv dann nutzen und ich muss das annehmen, dass da jemand ist, auch wenn es ein Automat ist, der mir sagt, du Björn, guck mal, in der Zeile sowieso, und das ist ja das Tolle bei diesen Tools, die sagen dir ja sogar genau, wo du das Problem produziert hast. Das ist ja bei der Mechanik oder der Elektronik manchmal nicht so.
Aber deswegen, das sehe ich da so, dass man sich das selber auch auferlegen kann als Softwareentwickler, wenn man da dann so die Qualität hochhalten kann. Okay, das heißt also, eine Möglichkeit wäre, da ranzugehen an dieses Thema, sich klarzumachen, wer ist der Kunde, wer ist der Lieferant oder wer ist der Auftraggeber und wer nimmt mir meine Arbeitsergebnisse ab. Vielleicht muss ich mir auch erst mal klar werden, was sind überhaupt meine Arbeitsergebnisse.
Es ist vielleicht nicht immer die lauffähige Software, vielleicht ist es auch nur die Systemarchitektur, nämlich ein Modell in einem Tool irgendwo und dann arbeiten andere Menschen damit weiter. Gibt es noch andere Möglichkeiten, daran zu gehen? Du hast vorhin, glaube ich, die Toyota Cutter gesagt. Ist das eine Methode, die man nutzen kann? Können wir gerne noch drüber reden, würde ich sagen, hat jetzt auf den direkten,
nennen wir es mal einfach Wertstrom. Das ist auch der Punkt, auf den ich kommen will. Im Produktionsbereich ist es im Grunde ganz normal, einen Wertstrom aufzustellen vom Lieferanten, vom externen Lieferanten in allen Schritten. Wenn ich jetzt irgendwas nehme, was habe ich hier, einen Kugelschreiber rumliegen, was kriege ich geliefert?
Ich kriege vor allem das Blech, würde ich sagen. ist, dass da vorne, die Spitze ist ein Gussteil, da ist eine Feder drin, also ein Draht und noch ein bisschen andere Kram, ein paar Kunststoffteile vielleicht. Das ist das, was am einen Ende, in den typischen Darstellungen, am linken Ende reinläuft und dann halt über verschiedene.
Produktionsschritte, also da wird halt das Blech hier, ich vermute mal ganz stark, das ist schon Blech, wird halt rund gewickelt, irgendwie verschweißt, sodass man da keine Schweißnaht sieht. In zwei, drei verschiedenen Stufen, die Anzelteile der Clip hinten, der Hauptteil, da wird hier was ausgestanzt.
Dann wird hier eine Nut reingedrückt wahrscheinlich und dann fließen da so zwei, drei, vier, eine Handvoll Teile, würde ich sagen, fließen so nebeneinander her und irgendwann kommt halt ein Montageteil, wo ich vorne die Spitze draufdrehe, wo ich damit vorher was eingefügt habe und dann zum Schluss probiert vielleicht einer noch, drückt hinten drauf und macht noch zwei, drei Striche, das ist so ein sehr vereinfachtes Modell einer Kugelschreiberproduktion.
Und das stelle ich halt in diesem Wertstrom dar. Da geht es um physische Dinge. Natürlich habe ich dort auch zum Teil Informationsflüsse. Wobei man da schon wieder darüber streiten kann, brauche ich es wirklich. In einem idealen Kontext brauche ich es halt nicht. Da trägt das Ding selber, wenn es ankommt, die entsprechende Information. Beziehungsweise ich drücke es ja gar nicht durch, sondern ich ziehe es ja.
Also das ist ein weiteres sehr wichtiges Element einer schlanken, einer Lean-Production, dass ich halt im Idealfall einen fließenden Prozess mir gestalte, wenn ich das nicht hinkriege. Also fließend im Sinne von One-Piece-Flow ist der Fachbegriff. Wenn ich das nicht hinkriege, weil es vielleicht nicht so viel Sinn macht, auf dem Lastwagen immer nur eine Kugelschreiber-Spitze draufzuladen,
ich habe halt ein paar Tausend auf dem Lastwagen oder in der Schachtel schon mal. Ja. Dann gucke ich aber doch, dass ich zumindest eben das nicht durchdrücke, sondern dass ich es ziehe. Also der Fachbegriff hier, englische Fachbegriff Pull. Das heißt, wenn ich als, und dann ist auch da wieder die Montageabteilung, die die Sachen zusammenschraubt, ist der Kunde der Vorstationen. Und die Vorstationen, die Lieferanten bauen erst was, wenn die Montageabteilung was braucht.
Stichwort zum Beispiel kann man. Ich stelle denen oder zwei Behältersystemen, das ist so eine Abwandlung im weitesten Sinne. Ich stelle denen halt eine leere Box hin. Ich habe zwei Boxen am Anfang, die sind beide voll, dann leere ich die eine und wenn die eine leer ist, dann bringe ich die zurück zu der Vorgängerstation und dann weiß die, okay, das ist eine leere Box, jetzt muss ich wieder arbeiten. Und dann arbeiten die auch nur dann, Verschwendungsart, keine Überproduktion.
Ich arbeite nur, wenn meine nächste Station einen Bedarf hat. Alles andere wäre Überproduktion, schlimmste Verschwendungsart. Ja, und du musst es irgendwo auf Lager legen und Lagerhaltung betreuen. Das ist dann die Folge daraus, wie so ein Domino-Effekt. Ich muss es erst mal ins Lager. Ich habe das Lager, ich muss es dorthin transportieren. In der Regel bewegen sich die Sachen nicht von alleine. Das heißt, da läuft noch einer mit.
So kommen da die ganzen Verschwendungsarten ins Tun oder ins lästige Tun. Und sowas kann ich aber auch für eine Produktentwicklung machen, so einen Werbstrom aufstellen. Das ist natürlich herausfordernder, weil das, was man in dem Produktionskontext macht, ich gehe einfach da runter und ich gucke mir an, was da passiert. Das, was da im Hintergrund dann in den Köpfen passiert, ist das sogenannte Sehenlernen, Learning to See.
Das war der Untertitel von Mike Rotter, der in den frühen 2000ern, wenn ich es richtig im Kopf habe, dieses erste Buch geschrieben hat. Wo er beobachtet hat, was passiert denn da bei Toyota, dieses Learning to See. Ich gehe da runter und ich schaue mir an, wie fließt da der Wert der Produkte, wie verändert sich das? Und Wertschöpfung ist immer mit Veränderung verbunden. Wie fließt das durch meine Produktion durch? Das ist natürlich deutlich herausfordernder.
In einer Entwicklungsabteilung, wo ich halt nur diese informationellen Flüsse habe, da muss ich ganz anders hinschauen. Da muss ich noch mehr mit Menschen reden. Ich kann keinen physischen Kreidekreis machen und mich irgendwo in die Ecke eines Entwicklungsbüros stellen und gucken, was machen die Leute dort. Da hocken die bei Softwareentwicklung ganz extrem, aber natürlich auch bei jeder Form moderner Hardwareentwicklung.
Es ist schon nicht so, dass da irgendwelche Zeichenbretter, wie in früheren Jahrzehnten, die Menschen vorm Zeichenbrett stehen, sondern die hocken alle vorm Computer und was sie jetzt da tun, sehe ich nicht. Ja, genau, aber miteinander sprechen und das Ganze dadurch ziehen, das ist schon ganz interessant. Und wo du es gerade so erklärt hast, da fiel mir das Buch ein, das Phoenix-Projekt oder Projekt Phoenix, so rum heißt es. Kennst du das?
Das ist ein Roman über IT und DevOps. Und da geht es auch darum, dass der Protagonist in eine Produktionshalle geht und sich diesen Wertstrom anschauen soll und dann die Analogie dazu findet, wie denn das für Software und Embedded Systeme auch funktionieren kann. Also super spannendes Buch, ist ein Fachbuch, aber in Romanart geschrieben und da ist auch viel, viel von dem mit drin, was du jetzt auch gerade erzählt hast.
Also das Projekt Phönix, ich werde es auch in den Shownotes dann verlinken jetzt, wo ich es gerade erwähnt habe.
Genau, sehr, sehr spannend. Und was man halt auch nicht unterschätzen darf und das ist sicher eben in dem Entwicklungskontext oder in dem allgemeinen nicht physischen Kontext ganz entscheidend, weil ich und vielleicht ist das dann wieder ein gewisser Vorteil, den ich theoretisch habe, weil ich halt nicht diesen Kreidekreis machen kann und ich stelle mich da eine Stunde oder zwei Stunden rein und kann physisch Dinge beobachten, sondern ich muss viel mehr mit den Menschen reden.
Und idealerweise mache ich halt das dann nicht alleine, sondern ich hole dann mal alle zusammen, die da tätig sind und wer macht denn was und wer bekommt von wem was. Und wenn man das also jetzt für ein ganz breites Thema nimmt und da könnte es auch irgendwas in einem Vertriebskontext sein oder in einem, ja, bleiben wir bei dem Thema Vertriebskontext oder Controlling oder was auch immer ist mir das nicht nur einmal begegnet. Fälle, wo.
Dann jemand irgendwelche Informationen, Reports, Daten, was auch immer bekommt. Und dann fragt man den, was machen Sie da damit? Ja, das und das. Und was löst denn das aus? Ja, die Frau Meier schickt mir das. Und dann geht man zu der Frau Meier und fragt, Frau Meier, Sie schicken da einmal in der Woche dem Herrn Müller, fällt mir jetzt gerade nichts anderes ein, schicken Sie da diese Informationen. Und der macht dann da irgendwas damit. Warum machen Sie das?
Ja, das hat mir mal irgendjemand gesagt. Also das sind immer wieder spannende Effekte. Da existiert ja auch sowas wie eine Kunden-Lieferanten-Beziehung. Und die existiert ja physisch, auch wenn die vielleicht dafür nicht das Bewusstsein haben. Trotzdem, der eine produziert irgendwas und der andere macht damit irgendwas. Mit den produzierten Daten. Aber ganz oft fehlt dieser Gesamtkomplex. Warum mache ich denn das?
Wozu ist das gut? Und das ist ein ganz wichtiges Element und auch eine Chance eben, weil ich die Dinge nicht so physisch sehe, dass ich, um dieses Gesamtverständnis zu schaffen, muss ich die Menschen zusammenbringen. Natürlich kann ich jetzt jeden Einzelnen fragen, aber dann kommen unter Umständen solche Effekte gar nicht zustande. Während wenn ich die zusammenbringe und sage, okay, was ist denn das Ganze, was hinten rauskommen soll?
Meinetwegen ein Stromlauf und ein Stückchen stehen. Das ist ja so klassische Elektronikentwicklung, die zwei hauptsächlichen Stromlaufstückliste und ein Layout. Das sind also die drei. Entwicklungsprodukte, die da entstehen. Und dann gehe ich halt durch nach vorne, also flussaufwärts im Sinne des Wertstroms. Was passiert denn da vorher? Wer macht denn dann da was? Und das schreibe ich halt mal wirklich auf. Und wer fängt denn dann mit was an?
Und eben auch da viel zu oft ich glaube halt ein Stück weit ich habe da so eine persönliche Theorie dass manche Dinge bis in die Steinzeit zurückgehen aber das wäre wahrscheinlich eine extra Episode. Viel zu oft auch da wird gedrückt also für einen Lean Menschen ist eine drückende ein drückender Wertstrom. Ist ein absoluter Horror. Was wir wollen, ist ein Fluss und wenn wir das nicht, also im Sinne eines One-Piece-Flows und wenn wir das nicht hinkriegen, dann zumindest eine ziehende Produktion.
Und das Gleiche kann man eben durchaus auch auf eine Entwicklung ausdehnen. Das ist zwar richtig, richtig schwierig, mental zu verarbeiten, dass ich im Extremfall, bleiben wir bei dem Beispiel der Leiterkarte, dass ich im Extremfall halt den Stromlauf nicht anfange, wenn nicht klar ist, dass da ein Layouter verfügbar ist. Und natürlich kommen dann da Dinge mit rein, dass natürlich der Stromlauf ja nicht so entsteht.
Wenn ich das jetzt ganz abstrahiere und wieder auf das physische Auto, dann mache ich immer das Beispiel, es steht einer morgens auf und wie man das ja manchmal so hat, man greift auf den Nachttisch und hat ein Smartphone. Und dann startet man sein Online-Banking. Ach, guck mal, der Kontostand, das sieht doch gut aus. Hey, ich glaube, heute Wetter sieht gut aus. Ich glaube, ich kaufe mir heute ein Cabrio. Bei dem Wetter, ja, Sonne, super, warm draußen, kaufe ich mir heute ein Cabrio.
Macht er sich noch einen Kaffee, duscht er noch und dann geht er zum Autohändler seiner Wahl und sagt, hey, ich will ein Cabrio. Und dann sagt der Verkäufer, gut, super Sache, sowas haben wir. Dann werfen wir doch mal geschwind den K-Konfigurator an. Farbe, ja, so grünmetallig, Sitzausstattung, was man alles halt dazu gehört. Noch einen Kaffee, ja, okay. Und dann ist irgendwann der Kaffee getrunken und das Auto ist konfiguriert. Jetzt gehen wir auf den Hof, ich glaube, der steht schon da.
Das ist ja die Vision, das Fernziel, da wissen wir alle, da wird man wahrscheinlich das Beamen vorher erfinden. Aber das ist ja dieses Fernziel, wo im Grunde jeder danach strebt. Und das ist auch das, was Wenn Taichi Ono, der Erfinder des Toyota-Produktionssystems, mal gesagt hat, wo man ihn gefragt hat, was macht denn er da eigentlich? Was ist denn da so besonders dran? Da hat er gesagt, das ist ganz einfach. Da gibt es halt irgendwo einen Kunden, der will was haben, der hat sich was
für entschieden. Und dann kommt er zu uns. Und wann endet das Thema, wenn die Kohle bei uns, das ist ja anders ausgedrückt wahrscheinlich, wenn die Kohle bei uns auf dem Konto ist. Und das Einzige, was wir machen, ist, dass wir versuchen, diesen Zeitraum so kurz wie möglich zu machen. Weil einerseits der Kunde zufrieden ist, weil in Zeiten von Amazon Prime und was es noch alles gibt. Übernachtlieferungen, ich sehe irgendwas, will ich haben, sofort.
Und andererseits aber natürlich eben als Hersteller will ich halt das Geld möglichst schnell auf dem Konto haben. Genau. Weil je länger das dauert, desto mehr Zinsen könnte ich theoretisch kriegen, wenn ich das Geld eher auf die Bank getragen hätte, statt da ein Produkt draus zu bauen. Ja. Aber ich habe mich da auch jetzt gerade gefragt, als du das gesagt hast, mit dem Stromlaufplan. Wann entwickle ich den Stromlaufplan? Wenn ich weiß, dass der Layouter Zeit hat.
Also wenn der da sitzt und quasi Däumchen dreht, dann könnte ich das machen. Und das ist natürlich jetzt so ein Moment, wo uns jeder hier in der Entwicklung den Vogel zeigen wird. Der wird ja nicht da rumsitzen und warten. Und da gehört jetzt die Projektplanung dazu, dass ich aufplane dazu, du musst jetzt mit deinem Stromlaufplan anfangen, du brauchst Daumen im Wind eine Woche dafür. In einer Woche steht aber dann der Layouter da und der hat dann Zeit und dann
muss es fertig sein. Und das ist dann diese Kunst, das genau aufeinander abzustimmen. Und wenn du auch noch diese Durchlaufzeiten durch die einzelnen Abteilungen, Teams. Computer, Menschen, Fertigungseinrichtungen kennst, dann kannst du das wunderbar genau aufeinander abstimmen. Und dann ist es auch nicht mehr dieses Push-Prinzip, sondern das Pull-Prinzip. Also dann kannst du wirklich, oder nein, du hast ja gesagt, dazwischen gibt es ja auch noch diesen Flow. Also Push, Flow und Pull.
So habe ich das jetzt kennengelernt. Der Idealzustand wäre der Flow, dass du ohne Drücke arbeitest. Genau. Und die zweitbeste Lösung ist das Pull-Prinzip. Und da kommt jetzt meiner Meinung nach noch ein weiterer, ganz entscheidender Punkt, Differenzierungsmerkmal dazu in dem Lean Product Development Kontext, die Rolle der Linienführungskraft.
Da habe ich es in meinem früheren Leben in Matrix-Organisationen, auch wenn wir das Stichwort noch nicht genannt haben, aber das steckt ja ganz oft da dahinter, viel zu oft erlebt, dass Linienführungskräfte sich auf der fachlichen Ebene vermitteln. In das Thema Produktentwicklung. Also nach dem Motto, ah, das Auto muss aber rot sein, während der Produktmanager gesagt hat, nee, wir wollen grüne bauen. Also auf der Ebene sich einmischen.
Es wäre viel, viel besser und das ist eben das auch, was jetzt im Lean-Product-Development der Gedanke ist. Einerseits genau diese absolut auf Ballhöhe sein. Wann wird denn mein Layouter frei? Wie ist denn mein Stromlaufentwickler ausgelastet, dass das total ineinander greift, dass halt der eine nicht auf den Haufen arbeitet, weil der Layouter noch nicht so weit ist und im anderen Extrem, dass aber auch der Layouter nicht Däumchen dreht, weil der Stromlauf noch nicht fertig ist.
Das ist der eine Punkt, was eine ganz wichtige Rolle der Linienführungskraft ist, dazu ständig zu wissen, auf Ballhöhe zu sein Und der andere wichtige Punkt ist eben, technologische Veränderungen zu beobachten und damit zur Weiterentwicklung ihrer Mitarbeiter beizutragen. Wenn mir das gelingt, wenn ich mir das klar mache, dass das meiner Ansicht nach, und wie gesagt, das Beispiel Lean Product Development, sagt sie auch, das ist die viel wichtigere Rolle.
Statt sich inhaltlich in die Produktentwicklung einzumischen. In Features und Leistungsmerkmale und was es noch alles gibt. Ja, genau. Das ist eigentlich die Aufgabe von den Linienführungskräften. Da entsprechendes Personal zur Verfügung zu haben, was dann eingesetzt werden kann und dann aber auch fachlich gute Entscheidungen trifft und die auch zügig treffen kann und nicht immer über irgendwelche Umwege Rückfrage halten muss. Ja, super.
Ich glaube, Götz, wir haben ganz viel darüber gesprochen, was das bedeutet, wie Lean-Product-Development sich ausprägen kann. Und wir haben auch so ein bisschen über die Lösungsmöglichkeiten gesprochen, dass man ja auf der einen Seite da ein entsprechendes Mindset haben muss und verstehen muss, wie ist denn überhaupt der Wertstrom durch das Unternehmen, auch durch die Entwicklungsabteilung, weil es geht ja hier um die Entwicklung von neuen Produkten.
Also da gibt es auch einen Wertstrom. Haben wir irgendwas vergessen, bevor wir die ... Die Folge beschließen. Nicht, dass du mir gleich nach dem Gespräch, wenn ich die Aufnahme gestoppt habe, noch irgendwas erzählst.
Ja, ich würde sagen, wir haben die meisten Punkte, ich hatte mir hier noch ein paar Notizen nebenbei gemacht, Frontloading, Set-Based, Concurrent Engineering haben wir besprochen, Chief Engineer haben wir besprochen, Führungskräfte jetzt zum Schluss, eben diese technologische Weiterentwicklung auch. Ja, und du hast selber noch mal gesagt, auch eben dieses Mindset, das manchmal dahinter steckt.
Wo halt manchmal, und das ist glaube ich die größte Herausforderung, wenn ich halt aus einer in Anführungszeichen klassischen Produktentwicklung komme, da den Hebel umzulegen, das geht anderen, wenn ich jetzt über so Dinge wie Agile oder Scrum rede, das sind auch dort die größten Herausforderungen.
Bestimmte Dinge, mit denen man vielleicht groß geworden ist, die einen möglicherweise auch in eine Position gebracht haben, speziell denke ich halt an Führungskräfte, dass man halt in bestimmten Dingen gut war. Vielleicht auch, dass man sich früher mal, dass es halt früher in Anführungszeichen honoriert wurde, wenn ich mich in Sachen eingemischt habe, weil es vielleicht aus welchen Gründen auch immer eine positive Wirkung hatte.
Und wenn ich jetzt halt so eine Veränderung auslösen will, Und das ist, glaube ich, eben eine der schwersten Sachen für Menschen. Und da nehme ich mich nicht aus, jetzt plötzlich Dinge nicht mehr zu tun, die einen vielleicht eben oder ganz oft in diese Führungsposition reingebracht haben. Da zitiere ich immer gern einen früheren Ericsson, wo ich zum Schluss gearbeitet hatte als Angestellter, Ericsson-CEO, den Karl-Henriks Hornberg, der gesagt hat, ganz allgemein,
what brought us here will not keep us here. also was uns. Jetzt in dem global wirtschaftlichen Kontext des Unternehmens dorthin gebracht hat, das wird uns dort nicht halten. Und das gilt auch ganz weit runter, zum Beispiel in eine Führungskarriere rein. Das, was mich typischerweise zur Führungskraft macht, das ist nicht das, was mich dann als gute Führungskraft erhält, das mal so auszudrücken.
Also eben dieses, weil der Tag hat halt nur 24 Stunden, auch dieses in der Lage sein, dann Dinge eben loszulassen. Auch vielleicht auf dieser fachlichen Kompetenzebene. Dinge loszulassen und mich jetzt eben auf andere Dinge zu konzentrieren. Ein weiteres Zitat, das auch da wunderbar greift, ein früherer Toyota CEO, wenn ich es richtig im Kopf habe, der gesagt hat, first we build people, then we build cars. Also zuerst entwickeln wir Menschen, die Autos bauen.
Ja, ja. Da gibt es ja eine große Menge an Zitaten, die da gemacht worden sind und die wirklich immer darauf hinausgehen, dass man die Menschen nach vorne stellen muss, also das sind die, die wirklich was. Die weiterentwickelt werden müssen, damit auch die entsprechenden Produkte hochwertig sind. Genau. Wunderbar, Götz. Haben wir das, glaube ich, einigermaßen rund gekriegt. Wir haben es von vielen Ecken beleuchtet, von der Entwicklung.
Wir haben uns den Hut der Fertigung aufgesetzt. Wir waren im Einkauf. Also ich glaube, wir haben das Ganze rund gemacht und verstanden, in welche Richtung Lean-Product-Development geht und worauf man dort so ein bisschen achten sollte. Wunderbar. Ja, dann bleibt mir jetzt nur noch, dir zu danken, dass du hier bei mir im Podcast warst. Und ja, deine Kontaktdaten werde ich in die Shownotes packen.
Wer Unterstützung braucht, um Lean Product Development einzuführen oder auch mal, dass du drauf guckst bei verschiedenen Unternehmen oder bei dem Unternehmen oder in einem Projekt. Die Kontaktdaten findet ihr in den Shownotes. Wendet euch gerne an, Götz. Ich denke, da seid ihr an einer guten Adresse, was das ganze Lean-Thema angeht. Ja, ich danke dir für die Einladung. Zusammenfassend von mir drei Tipps zur heutigen Episode. Push, Flow und Pull sind drei Prinzipien im Wertstrom.
Das wünschenswerteste davon ist der Flow-Zustand. Der Push-Zustand sollte im Idealfall gar nicht angewendet werden. Der zweite Tipp, dass zwischen den einzelnen Arbeitsstationen immer eine Kunden-Lieferanten-Beziehung existiert, das haben wir heute gelernt und so solltest du auch schauen, dass du deine Arbeitsstationen, deine Teams, die einzelnen Arbeitsergebnisse miteinander verbindest.
Und der dritte Tipp, im Lean Management und im Lean Product Development sollten die Linienführungskräfte darum besorgt sein, dass die Menschen ihres Teams richtig ausgebildet sind und in ausreichender Zahl verfügbar sind. Es geht hier nicht um die Bestimmung der zu erledigenden Arbeit, sondern darum, das Team aufrechtzuerhalten und zu ermöglichen, überhaupt zu arbeiten. Wenn Dir die Episode wertvollen Input geliefert hat, dann würde ich mich freuen, wenn Du diese Episode weiterempfehlen würdest.
Außerdem freue ich mich auch über eine Bewertung oder einen Kommentar bei iTunes, Apple Podcast oder Podcast Addict. Das ist für Dich sehr einfach in Deiner Podcast App möglich und mich motiviert es, weiter tolle Episoden für Dich aufzunehmen. Das war die heutige Episode des Zukunftsarchitekten-Podcasts. Mein Name ist Björn Schorrö und ich danke dir fürs Zuhören. Hab Spaß an dem, was du machst und vor allem wünsche dir. Music.