Der Produktentwickler - Podcast

Der deutsche Podcast zum englischen Newsletter von Uwe Mierisch

Prozesse, Menschen, Produkte. Der Podcast für eine schnelle, effiziente und zukunftsfähige Produktentwicklung. In dieser Audio-Edition übersetze ich die Analysen und Strategien meines englischsprachigen Newsletters ins Deutsche. So erhältst du alle Insights bequem in deiner Muttersprache – optimiert für das Hören unterwegs. Den englischen Newsletter mit allen Grafiken und Quellen findest du unter https://uwemierisch.substack.com/ uwemierisch.substack.com

  1. 3d ago

    Die Matrix meistern

    Solange jeder jeden kennt und jeder das Produkt bis ins Detail versteht, ist Teamarbeit leicht zu organisieren. Erfolgreiche Firmen wachsen aber. Irgendwann ist die Gruppe zu groß und das Produkt zu kompliziert für den hemdsärmeligen Weg. Dann kommt oft die Matrixorganisation. Sie ist sehr verbreitet und gleichzeitig sehr umstritten. Seit langer Zeit wird sie in vielen großen und erfolgreichen Unternehmen eingesetzt. Und genauso lange wird beklagt, dass sie unklare Verantwortlichkeiten, zu viele Kommunikationswege und hohe Ineffizienzen erzeugt. Uwe Mierisch zeigt, welches Problem die Matrix löst, warum sie zu Recht als schwer führbar gilt und mit welchen Regeln sie beherrschbar wird. Wo Fachkompetenz auf Projektarbeit trifft. Themen dieser Episode Welches Problem muss gelöst werden? Ein Produkt braucht viele Kompetenzen. Mit dem Wachstum arbeiten plötzlich viele Mitarbeiter im selben Fachgebiet, und auch sie müssen koordiniert werden. Kompetenzbezogene Strategien: Einkaufs-, Produkt-, Entwicklungs- und After-Sales-Strategie betreffen die Zukunft des ganzen Unternehmens, nicht nur ein einzelnes Projekt. Zwei Dimensionen, eine Matrix: Prozessorganisation (Ablauforganisation) und Funktionalorganisation (Aufbauorganisation) betreffen dieselben Mitarbeiter. Ein zweidimensionales Problem lässt sich als Matrix darstellen. Der Mitarbeiter als Integrator: Er bekommt Aufgaben und Ziele vom Projektleiter und vom Fachvorgesetzten und muss beiden gleichzeitig gerecht werden. Die offene Frage der Personalführung: Wer sie in Doppelrolle übernimmt, bekommt automatisch mehr Gewicht. Die Gleichrangigkeit der beiden Dimensionen ist dahin. Die komplexe Matrix: Mitarbeiter in mehreren Projekten gleichzeitig haben nicht zwei, sondern eine Vielzahl von Führungsbeziehungen. Die Projektorganisation steuert. Die Funktionalorganisation liefert. Der Projektleiter ist verantwortlich für das Was und Warum, nicht für das Wie. Wer verantwortet das Gesamtergebnis? Die Führungskraft, an die Projektleiter und Fachvorgesetzte berichten. Ohne besondere Regelung ist das der Vorstandsvorsitzende. Delegieren ja, aber nicht an den Projektleiter. Klare Eskalationsregeln: Szenariobeschreibungen, welches Problem welchen Eskalationsweg nimmt. Selten definiert, sofort wirksam. Zeitlicher Fokus: Drei Kategorien von Projektmitarbeitern reduzieren die Zahl der Führungsbeziehungen zu jedem Zeitpunkt. Schlanke Projektorganisation: Wer Ergebnisse liefern soll, bleibt in der Funktionalorganisation. Warum „lieber schnell selbst machen“ das Steuerungsmodell untergräbt. Key Takeaways ✓ Die Matrix entsteht, weil zwei Dimensionen gleichzeitig organisiert werden müssen: der Ablauf im Projekt und die Fachkompetenz ✓ In der Matrix kümmert sich jede Führungskraft um eine Dimension. Der Mitarbeiter integriert beide in einer gemeinsamen Lösung ✓ Die Projektorganisation steuert. Die Funktionalorganisation liefert ✓ Die ganzheitliche Verantwortung des Projektleiters gibt es in der Matrix nicht ✓ Verantwortlich für das Gesamtergebnis ist die Führungskraft, an die beide Dimensionen berichten ✓ Klare Eskalationsregeln, zeitlicher Fokus und eine schlanke Projektorganisation machen die Matrix beherrschbar Für wen ist diese Episode relevant? Führungskräfte und Fachvorgesetzte in der Produktentwicklung Projektleiter, die ohne Personalverantwortung Ergebnisse steuern müssen Mitarbeiter, die in mehreren Projekten gleichzeitig arbeiten Geschäftsleitungen wachsender Unternehmen, deren Organisation an ihre Grenzen stößt Alle, die ihre Matrix neu aufstellen wollen Weitere Informationen Arbeiten Sie in einer Matrixorganisation? Und ist bei Ihnen klar, welches Thema zum Projektleiter gehört und welches zum Fachvorgesetzten? Schreiben Sie es in die Kommentare auf Substack oder direkt als Nachricht. In der nächsten Episode geht es um die Organisationsstruktur für softwaredefinierte Produkte. Auch dort spielt die Matrix wieder eine Rolle. Newsletter oder Podcast abonnieren, um die ganze Geschichte mitzubekommen. Zum Nachlesen: der Blogartikel zur Funktionalorganisation auf uwemierisch.com (https://uwemierisch.com/functional-organization/). Hashtags #Matrixorganisation #Organisation #Projektmanagement #Funktionalorganisation #Projektorganisation #Führung #Verantwortung #Eskalation #Produktentwicklung #NewPDP #SystemsEngineering Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

  2. Oct 26

    Clausewitz und Moltke haben unser Führungsproblem gelöst. Wir haben es nur nicht gelernt.

    „Baut mal schnell einen Prototypen mit dem neuesten Motor. Macht euch sonst keine weiteren Gedanken.“ Mit diesem Satz hat ein Chef ein Produkt gerettet, dessen Produktion schon zur Diskussion stand. Für Uwe Mierisch war das der Moment, in dem er Führungskraft werden wollte. In dieser Episode geht es um Leadership, den ersten der drei Enabler des NewPDP. Klare Richtung, ein Team. Führung wird leicht mit Management verwechselt. Und die Frage, wer eigentlich was entscheidet, bleibt in den meisten Unternehmen offen. Die Antwort kommt ausgerechnet von zwei preußischen Generälen: Carl von Clausewitz und Helmuth von Moltke dem Älteren. Themen dieser Episode Führung ist nicht Management: John P. Kotter, Harvard 1990. Management bewältigt Komplexität, Führung bewältigt Veränderung. Viele Unternehmen sind overmanaged and underled. Drei Ebenen statt zwei: Clausewitz unterscheidet Taktik, Strategie und Zweck. Warum Preußen 1806 bei Jena und Auerstedt mit nur zwei Ebenen gescheitert ist. Der Zweck ist groß und er bleibt stehen: Was das Unternehmen werden will, entscheidet die Geschäftsführung als Treuhänder der Eigentümer. Und sie hält es stabil. Die Taktik gehört dem Team: Moltkes Auftragstaktik. Was und warum kommt von oben, das Wie entscheidet, wer vor Ort ist. Das funktioniert nur mit einem System wie dem Drum Beat. Der Stratege sitzt dazwischen: Strategie ist kein Fünfjahresplan, sondern ein System der Aushilfen. Nach jedem Zug neu bewerten und den nächsten wählen. Der Generalstab zeigt, dass das keine Frage des Rangs ist. Wer führt? Peter Drucker: Führer ist, wem gefolgt wird. Führung ist eine Tätigkeit, keine Position. Was ist denn ein Chef? Chef ist, wer Verantwortung für das Tun anderer übernimmt. Und das geht nur mit einem eigenen Beitrag. Nicht aus dem Elfenbeinturm: Clausewitz verlangt, dass die Strategie mit ins Feld zieht. Entschieden wird sofort, nicht in der nächsten Lenkungskreissitzung. Management ist der Aufmarsch: Gutes Management reduziert die Komplexität der Ausführung auf das unvermeidbare Maß. Tracking, Überwachung und Rechtfertigung gehören nicht dazu. Key Takeaways ✓ Führung ist nicht Management. Management bewältigt Komplexität, Führung setzt eine Richtung. ✓ Führung findet auf drei Ebenen statt: Zweck, Strategie und Taktik. ✓ Den Zweck setzt die Geschäftsführung, und sie hält ihn stabil. ✓ Strategie ist kein Plan. Sie ist das ständige Neubewerten der Lage auf dem Weg zum Zweck. ✓ Führung ist eine Tätigkeit, keine Position. ✓ Chef ist, wer Verantwortung für das Tun anderer übernimmt. ✓ Management schafft Voraussetzungen. Tracking stellt fest, was nicht erledigt wurde. Für wen ist diese Episode relevant? Geschäftsführer und Bereichsleiter, die eine Richtung über Jahre halten müssen Führungskräfte in der Produktentwicklung, deren Kalender vom Management aufgefressen wird Projektleiterinnen, Systemarchitekten und Experten, die strategisch arbeiten, ohne Chef zu sein Alle, die vor einer Transformation ihres Entwicklungssystems stehen Weitere Informationen Wie viel von dem, was in Ihrem Unternehmen Management heißt, schafft Voraussetzungen? Und wie viel stellt nur fest, was nicht erledigt wurde? Schreiben Sie es in die Kommentare auf Substack oder direkt als Nachricht. In den nächsten Episoden geht es weiter mit den beiden anderen Enablern des NewPDP: Organisation und Architektur. Newsletter oder Podcast abonnieren, um die ganze Serie mitzubekommen. Zum Nachlesen: der Artikel zu dieser Episode auf Substack. Quellen Clausewitz, Carl von: Vom Kriege. Hinterlassenes Werk des Generals Carl von Clausewitz. Berlin: Dümmler, 1832–1834. Hier: Buch 1, Kap. 1, Nr. 24 (Fortsetzung der Politik mit anderen Mitteln); Buch 2, Kap. 1 (Taktik und Strategie); Buch 3, Kap. 1 (die Strategie muss mit ins Feld ziehen). Drucker, Peter F.: Foreword. Not Enough Generals Were Killed. In: Hesselbein, Frances; Goldsmith, Marshall; Beckhard, Richard (Hrsg.): The Leader of the Future. New Visions, Strategies, and Practices for the Next Era. San Francisco: Jossey-Bass, 1996. Kotter, John P.: What Leaders Really Do. In: Harvard Business Review 68 (1990), Nr. 3, S. 103–111. Kotter, John P.: A Force for Change. How Leadership Differs from Management. New York: Free Press, 1990. Moltke, Helmuth von: Über Strategie (1871). In: Großer Generalstab (Hrsg.): Moltkes Militärische Werke, Abt. II, Teil 2: Moltkes taktisch-strategische Aufsätze aus den Jahren 1857 bis 1871. Berlin: Mittler, 1900, S. 287–293. Moltke, Helmuth von: Aus den Verordnungen für die höheren Truppenführer vom 24. Juni 1869. In: ebd., S. 171–215. Hashtags #NewPDP #Leadership #Führung #Management #Strategie #Auftragstaktik #Clausewitz #Moltke #Produktentwicklung #Transformation #SystemsEngineering Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

    Clausewitz und Moltke haben unser Führungsproblem gelöst. Wir haben es nur nicht gelernt.

  3. Oct 12

    Predictive Technology Readiness - Reif, wenn es gebraucht wird.

    Episode-Beschreibung Produktentwickler lieben Innovationen. Controller lieben einen positiven Business Case. Und Innovationen sind eine Wundertüte: Was drin ist, weiß man erst, wenn man sie öffnet. Genau dieses Öffnen kostet Geld. Im alten System wartet die Innovation deshalb auf ein passendes Projekt und wird erst dort untersucht. Mit Schleifen, Überraschungen und verschobenen Terminen. Im NewPDP mit 48 Monaten für ein komplett neues Fahrzeug und ohne Erprobungsflotte im Reifegrad B ist dafür kein Platz. Uwe Mierisch stellt das vierte Element des NewPDP vor: Predictive Technology Readiness (PTR). Die Wundertüte muss offen sein, bevor das Projekt startet. Woher das Geld dafür kommt, wofür es ausgegeben wird, wer darüber entscheidet — und warum am Ende Entwickler und Controller zufrieden sind. Themen dieser Episode Die Wundertüte wird zu spät geöffnet: Ohne Business Case kein Geld, also wartet die Innovation auf ihr Projekt. Erst dann wird sie geöffnet, ganz langsam. Diese Vorgehensweise muss sich ändern. Viel Feind, viel Ehr: Warum die PTR zuerst Entwickler und Controller gleichzeitig gegen sich hatte Es geht nicht um Tempo, sondern um den Zeitpunkt: Gesetzestermine, Kundenbedarf, Wettbewerb, Kostendruck, neue Märkte. Je schneller ein Projekt, desto später kann es starten und desto sicherer baut man das Richtige. Darum ist Geschwindigkeit doch wichtig. Wo kommt das Geld her?: Ohne Projekt gibt es keinen Business Case. Darum ist das Innovationsbudget eine unternehmerische Entscheidung, keine Berechnung — und muss in jeder Budgetrunde verteidigt werden Budget fix, Inhalt folgt: Der grundlegende Unterschied zum klassischen Vorentwicklungsprojekt Technologiemonitoring: Alle relevanten Trends auf den Radar, Produkt- wie Produktionstechnologien. Ziel ist nicht, eine Technologie fertig zu entwickeln, sondern sie besser einschätzen zu können Das Innovationsteam: Klein, interdisziplinär, mit dem Controlling am Tisch. Entscheidet eigenständig innerhalb des Budgets, im Takt des Drum Beat Systems Das Korrektiv: Öffentliche Retrospektiven und Lessons Learned. Einmischen ist erwünscht, Meckern im Nachgang nicht Warum „predictive"?: Vorbereiten, nicht vorhersagen — wie bei der prädiktiven Instandhaltung Warum am Ende alle zufrieden sind: Entwickler bekommen Geld für Innovationen ohne warten auf ein Projekt, Controller bekommen Projekte ohne Wundertüte. Am Ende geht es schneller und ist billiger. Key Takeaways ✓ Innovationen, die erst im Projekt bearbeitet werden, machen Projekte langsam und unberechenbar ✓ Nicht Schnelligkeit entscheidet über den Markterfolg, sondern der richtige Zeitpunkt. Schnelle Projekte brauchen bekannte Inhalte ✓ Das Innovationsbudget ist eine unternehmerische Entscheidung, keine Berechnung. Seine Höhe richtet sich danach, wie innovativ das Unternehmen sein will ✓ Ein kleines, interdisziplinäres Innovationsteam entscheidet im Takt über die Verwendung ✓ Das Korrektiv ist Transparenz ✓ Ein billiges Nein vor dem Projekt ist besser als ein teures Nein mitten im Projekt ✓ PTR ist die Voraussetzung dafür, dass Learning Standard Routines und Hardware Light Development funktionieren Für wen ist diese Episode relevant? Führungskräfte in der Produktentwicklung mechatronischer Produkte Mitarbeiter und Leiter von Vorentwicklung und Innovationsmanagement Controller und Finanzverantwortliche, die über Innovationsbudgets entscheiden Produktmanagement und Vertrieb, die den richtigen Markteintrittszeitpunkt mitbestimmen Geschäftsleitungen, die festlegen müssen, wie innovativ ihr Unternehmen sein will Weitere Informationen Diese Episode ist Teil der Serie zum NewPDP. Zuvor erschienen: der Überblick zum NewPDP, das Drum Beat System, die Learning Standard Routines und Hardware Light Development. In den nächsten Wochen geht es mit den drei Voraussetzungen weiter: Führung, Organisation und Architektur. Newsletter oder Podcast abonnieren, um die ganze Serie mitzubekommen. Wie wird in Ihrem Unternehmen über Geld für Innovationen entschieden? Gibt es ein festes Budget, oder muss jede Idee ihren eigenen Business Case mitbringen? Schreiben Sie es in die Kommentare auf Substack oder direkt als Nachricht. Hashtags #PredictiveTechnologyReadiness #NewPDP #Produktentwicklung #Innovation #Innovationsmanagement #Technologiemonitoring #Vorentwicklung #BusinessCase #Controlling #Fahrzeugentwicklung #LeanDevelopment #Agil Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

  4. Sep 28

    Hardware Light Development, ein Zyklus, vier Phasen.

    Episode-Beschreibung Im NewPDP Pilotprojekt habe ich die komplette Reifegrad B Prototypenflotte gestrichen. Über Nacht wurde aus dem Projekt, bei dem alle mitmachen wollten, ein Feindbild. Der Widerstand kam nicht von einzelnen Bedenkenträgern, er kam aus der Breite der Belegschaft. Und er war berechtigt. Hardware ist nicht nur ein Erprobungsmittel. Sie ist ein Hygienefaktor und ein Führungsinstrument. Sie zeigt unmissverständlich, was fehlt, und sie setzt einen Termin, den jeder ernst nehmen muss. Hardware Light Development, das dritte Element des NewPDP, heißt deshalb nicht, Hardware wegzulassen. Es heißt, sie zu ersetzen. Virtuell vor materiell. Diese Episode beschreibt, wie das geht: mit demokratisierten virtuellen Prototypen und mit dem universellen 4 Takt Zyklus, der einmal statt viermal durchlaufen wird. Definition, Creation, Validierung, Implementierung. Inhalt der Episode Hardware ist teuer, knapp und trotzdem beliebt. Sie ist konkret, anfassbar und brutal ehrlich. Was fehlt, sieht jeder sofort. Das erzeugt den Eindruck von Effizienz. Der übersehene Nutzen: Hardware ist Hygienefaktor und Führungsinstrument. Die Prototypenliefertermine sind der Meilenstein, den jeder ernst nehmen muss. Der Preis dafür: Reifegradflotten sind teuer, knapp und nie auf Anhieb funktionsfähig. Fällt ein Entwickler aus dem Plan, bricht der Prototypen-Verwendungsplan zusammen. Das ist keine Volatilität, das ist eine Eigenschaft der Vorgehensweise. Der universelle 4 Takt Zyklus wird einmal durchlaufen, nicht viermal. Eine Art Supersprint, dafür mit harten Definition of Done Meilensteinen. Demokratisierung der virtuellen Prototypen ist die Voraussetzung für alles Weitere. Zugang für jeden Projektmitarbeiter, vom ersten Tag an, so einfach wie der Gang in die Werkstatt. Ohne sie ist der virtuelle Prototyp ein Werkzeug für Spezialisten. Definition: Systems Engineering in Reinform. Alle Schnittstellen und Anforderungen werden vollständig beschrieben, von allen Fachdisziplinen gleichzeitig und ohne eine einzige Hardware. Der Business Case ist ein Meilenstein mittendrin, nicht das Ziel. Creation: die Zeit der Lösungsfindung. Am Ende ist der neue Entwicklungsstand vollständig im virtuellen Prototypen abgebildet. Hardware nur als zugeschnittener Entwicklungsträger, als „Mule", nie als vollständiges Projektfahrzeug. Bündelung von Umfängen bündelt auch Risiko. Validierung: jetzt fließen große Summen ab. Die Prototypen bestätigen einen fertigen Stand, sie entwickeln ihn nicht. Keine neuen Umfänge, keine Optimierungen mehr. Implementierung: fließender Übergang, von hinten geplant und so spät wie möglich gestartet, damit Erkenntnisse aus der Validierung nichts umwerfen. Die Lektion: Der Ersatz muss vor der Streichung da sein. Wer die Flotte streicht, streicht Ehrlichkeit und Termindisziplin, solange der virtuelle Prototyp beides nicht übernehmen kann. Für wen ist diese Episode relevant? Entwicklungs- und Projektleiter, die Prototypenflotten planen und verantworten. Führungskräfte, die Zeit und Kosten in der Produktentwicklung senken müssen. Verantwortliche für Virtualisierung, Simulation und digitale Zwillinge. Prozess- und Methodenverantwortliche, die den Reifegradprozess nach VDA anwenden. Alle, die eine Transformation vorbereiten und wissen wollen, in welcher Reihenfolge sie die Schritte gehen müssen. Weitere Informationen Hardware Light Development ist das dritte der sieben Elemente des NewPDP. Das Motto lautet: virtuell vor materiell. Zu den ersten beiden Elementen, dem Drum Beat System und den Learning Standard Routines, gibt es eigene Episoden. Zum universellen 4 Takt Zyklus und zum Granatapfelbaum-Modell gibt es ebenfalls eine eigene Episode. Die Reifegradphasen A, B, C, D des VDA sind in einem eigenen Artikel erklärt: https://uwemierisch.substack.com/p/from-concept-to-bestseller-how-products In den nächsten Wochen folgen Episoden zur vollständigen Beschreibung der Ausgangssituation und zu den Methoden der Definitionsphase. Hashtags #HardwareLightDevelopment #NewPDP #Produktentwicklung #VirtuellePrototypen #Simulation #Prototypen #Reifegrad #VDA #SystemsEngineering #Fahrzeugentwicklung #DigitalerZwilling #LeanDevelopment Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

  5. Sep 14

    Learning Standard Routines, in drei Schritten zu Perfektion

    Episode-Beschreibung „Andere entwickeln komplett neue Fahrzeuge in 48 Monaten. Finde heraus, wie das geht, und führe es bei uns ein." Dieser Auftrag führte mich zu einer Erkenntnis, die mich selbst überrascht hat: Für ein komplett neues Fahrzeug in 48 Monaten gibt es genau eine mögliche Vorgehensweise. Eine einzige. Wenn das aber so ist, dann kann man sie aufschreiben und immer wieder anwenden. Daraus entstehen die Learning Standard Routines, das zweite Element des NewPDP. Nicht der Inhalt definiert das Projekt, sondern die Zeit. Und was stabil und wiederholbar ist, wird nicht jedes Mal neu erfunden, sondern standardisiert, kontinuierlich verbessert und von zugeordneten Experten erledigt. In drei Schritten zur Perfektion: Templates, standardisierte Prozesse, zugeordnete Experten. Und am Ende die Frage, was das alles mit KI zu tun hat. Die Antwort fällt anders aus als erwartet. Inhalt der Episode Zwei Wirkprinzipien stehen hinter allem: Standardisierung ermöglicht Verbesserung, und Fokus schafft Professionalität. Für einen festen Zeitraum gibt es nur eine sinnvolle Vorgehensweise. Diese wird aufgeschrieben und immer wieder anwenden. Umkehr der Planungslogik: Nicht der Inhalt definiert das Projekt, sondern die Zeit. Zeit und Geld stehen zuerst fest, der Inhalt wird passend dazu ausgewählt. Standardvorlagen statt Einzelfallplanung: Mit jedem Durchlauf sinkt die Fehlerwahrscheinlichkeit, steigt die Liefertreue und wächst der realisierbare Inhalt. Der Zeitplan wird nicht mehr verhandelt, sondern angewandt. Zweigeteiltes Vorgehen: Volatiles wird kurzzyklisch und situationsbezogen entschieden, Stabiles wird standardisiert und kontinuierlich verbessert. Ein hybrides System aus agilen und klassischen Prinzipien. Ebene 1, Projekt- und ITEM-Templates: ein Katalog von Zeitvorgaben, zum Beispiel 48, 36, 24 und 12 Monate. Ein Template ist ein Gerippe, kein Masterplan. Es enthält, was zum Erreichen der Zeitvorgabe nötig ist, und nichts weiter. Die Feinplanung bleibt beim Drum Beat. Ebene 2, standardisierte Prozesse: aus den Templates herausgelöst und eigenständig gepflegt. Aufnahmekriterium ist wiederholtes Auftreten bei stabilem Umfeld. Fehlt eines von beidem, gehört der Ablauf ins Drum Beat System. Abgrenzung zum Agilen: Agil standardisiert den Meta-Prozess und lässt den Fachprozess offen. Im hybriden System standardisieren wir beides. Wiederholbare Fachprozesse jedes Mal neu zu erfinden ist keine Anpassungsfähigkeit, sondern Verschwendung. Ohne Standard kein KVP. Der Standard ist verbindlich, aber nicht endgültig. Weiterentwickelt wird er von denen, die mit ihm arbeiten. Ebene 3, zugeordnete Experten: feste Gruppen für einen oder mehrere Standardprozesse, idealerweise in eigenen Organisationseinheiten. Wiederholung erzeugt Professionalität. Der Abbau von Expertengruppen ist eine Scheineinsparung. Die Stelle verschwindet, die Arbeit nicht. Sie wandert zu Laien, und der Mehraufwand taucht in keinem Budget auf. Ebene 3 dreht das um und macht die Arbeit wieder sichtbar. Zuordnung und Dokument gehören zusammen: Die Zuordnung der Mitarbeiter erzeugt die Verbesserung, das Prozessdokument sichert sie ab. Keine der beiden Hälften funktioniert allein. KI-Assistent: Die Standardroutinen liefern die Datenbasis. Der Assistent senkt die Hürde, den passenden Standard zu finden und anzuwenden, und macht Lessons Learned praktikabel. KI-Agent: dokumentiert, immer gleich ablaufend, einer festen Gruppe zugeordnet. Das sind genau die Bedingungen, unter denen KI einen Ablauf vollständig übernehmen kann. Die Reihenfolge ist entscheidend: erst der Standard, dann die Automatisierung. Wer es umgekehrt versucht, automatisiert das Chaos. Für wen ist diese Episode relevant? Entwicklungs- und Projektleiter. Führungskräfte, die Effizienz in den Projekten und Abläufen schaffen wollen. Prozess- und Methodenverantwortliche. Alle, die KI in der Produktentwicklung einsetzen wollen und sich fragen, wie das geht. Organisationen, die agile und klassische Prinzipien nicht gegeneinander ausspielen wollen Weitere Informationen Die Learning Standard Routines sind das zweite der sieben Elemente des NewPDP. Sie bauen auf dem Drum Beat System auf, zu dem es eine eigene Episode gibt. In den nächsten Wochen folgen Episoden über die weiteren Elemente. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

  6. Aug 31

    Das Drum Beat System produziert Innovationen.

    „Warum schlagen die mir das alles zur Entscheidung vor, wenn sie es dann doch nicht schaffen?" und gleichzeitig: „Wenn der Chef nicht weiß, was wichtig ist, dann mache ich eben irgendwas." Beide Sätze hat Uwe Mierisch gedacht. In derselben Firma, zur selben Zeit, in zwei Rollen. Aus diesem Dilemma ist das Drum Beat System entstanden — das erste Element des NewPDP. Innovationen entstehen nicht durch Eingebung. Innovationen zu entwickeln ist Handwerk, das man lernen kann und muss. Und deshalb funktionieren viele Methoden aus der Produktion auch in der Entwicklung. Diese Episode beschreibt das Problem, bevor sie die Lösung beschreibt: das Auftragsdauerfeuer, die Illusion der Priorisierungsliste und warum kein Chef diese Entscheidung allein treffen kann. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

  7. Aug 17

    NewPDP - Mehr Entwickeln ohne mehr zu brauchen.

    Episode-Beschreibung „Das ist alles viel zu komplex, das versteht keiner. Nimm den Drum Beat raus und lass den Rest weg." — dieser Satz fiel im Hinterhof eines italienischen Restaurants in Untertürkheim. Er ist der Anlass für diese Episode. Uwe Mierisch gibt den Überblick über den NewPDP, ein Entwicklungsmodell für mechatronische Produkte: vier Arbeitsweisen, drei Voraussetzungen, vier Jahre Arbeit. Warum jedes einzelne Element gebraucht wird, in welcher Reihenfolge es drankommt — und warum nichts davon weggelassen werden kann. Der Auftrag der Old Economy ist unbequem: heute Rendite liefern und gleichzeitig die Zukunft finanzieren. Mehr entwickeln ohne mehr zu brauchen. Themen dieser Episode Das doppelte Problem: Wir sind nicht nur zu langsam — wir fangen auch zu spät an. Langsamkeit lässt sich bekämpfen, verlorene Zeit nicht zurückholen Der Sandsack der Old Economy: Warum Wettbewerber ohne Profitabilitätsdruck einen strukturellen Vorteil haben — und welche Vorteile dagegen stehen Der Aufbau des NewPDP: Vier Practices (Arbeitsweisen) in bewusster Reihenfolge, drei Enablers (Voraussetzungen) parallel Drum Beat System (DBS) — Im Takt zusammenarbeiten: Das fehlende Wort für den Zeitraum zwischen den Quality Gates. Granatapfelbaum-Modell und universeller 4-Takt-Zyklus. Die eine Regel: Ein Drum Beat wird nie gedehnt Learning Standard Routines (LSR) — Fokus schafft Professionalität: Können entsteht durch Wiederholung. Warum das nur zur Hälfte Taylorismus ist Hardware Light Development (HLD) — Virtuell vor materiell: Nicht Hardware abschaffen, sondern mit minimalstem Hardwareeinsatz dieselbe Qualität erreichen Predictive Technology Readiness (PTR) — Reif, wenn es gebraucht wird: Zu spät entscheiden ist teuer, zu früh investieren erzeugt Bestand. Und Bestand verdirbt Leadership (L) — Klare Richtung, ein Team: Führung heißt mitarbeiten. Wer nur entscheidet, führt nicht Organisation (O) — Struktur folgt dem System: Die Matrix überlebt keine dritte Achse. Welches Prinzip führt künftig? Architektur (A) — Modularer Fortschritt: Was die Hardware von der objektorientierten Programmierung noch lernen muss Warum nichts weggelassen wird: Die sieben Elemente stehen nicht nebeneinander, sie greifen ineinander Key Takeaways ✓ Zu spät anfangen ist schlimmer als zu langsam sein — vergangene Zeit holt niemand zurück ✓ Der Auftrag lautet: mehr entwickeln ohne mehr zu brauchen. Das geht nur mit grundlegender Transformation ✓ Priorisiere die Themen mit dem höchsten Wertzuwachs jetzt — und die mit dem größten Wertverlust, wenn sie liegen bleiben ✓ Der Drum Beat ist der Schmierstoff für alles andere. Darum kommt er zuerst ✓ Ein Drum Beat wird nie gedehnt. Sonst verhandeln wir wieder Termine statt Inhalte ✓ Man kann mit einem Element anfangen — man muss sogar. Aber mit einem allein kommt man nicht ans Ziel Für wen ist diese Episode relevant? Führungskräfte und Manager in der Produktentwicklung mechatronischer Produkte Alle, die vor einer Transformation ihres Entwicklungssystems stehen Prozess- und Methodenverantwortliche, die über Quality Gates hinausdenken wollen Systems Engineers, die um die Rolle der Funktionalität in der Organisation ringen Unternehmen der Old Economy im Wettbewerb mit Start-ups und geförderten Playern Weitere Informationen In den nächsten Wochen nimmt Uwe Mierisch jedes der sieben Elemente einzeln auseinander. Newsletter oder Podcast abonnieren, um die ganze Serie mitzubekommen. Welches der sieben Elemente ist in Ihrer Organisation das größte Problem? Und welches wäre am schnellsten zu haben? Schreiben Sie es in die Kommentare oder direkt als Nachricht. Hashtags #NewPDP #Produktentwicklung #DrumBeat #Transformation #SystemsEngineering #HardwareLightDevelopment #TechnologyReadiness #Leadership #Organisation #Architektur #Mechatronik #Effizienz Verwandt: [[P11 - NewPDP]] · [[NewPDP - Drum Beat System (DBS)]] · [[NewPDP - Learning Standard Routines (LSR)]] · [[NewPDP - Hardware Light Development (HLD)]] · [[NewPDP - Predictive Technology Readiness (PTR)]] · [[NewPDP - Enabler Führung]] · [[NewPDP - Enabler Organisation]] · [[NewPDP - Enabler Architektur]] · [[Show Notes - Der blinde Fleck]] Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

  8. Aug 3

    Der blinde Fleck: Wirkungsgrad in der Wissensarbeit

    Effizienz in der Wissensarbeit ist ein blinder Fleck. Warum können Ingenieure den Wirkungsgrad einer Maschine präzise messen und optimieren, während Manager in der Entwicklung völlig im Dunkeln tappen? In dieser Episode erklärt Uwe Mierisch, wie die beiden Modelle Granatapfelbaum-Modell und Universeller 4-Takt-Zyklus Effizienz und Effektivität in Organisationen messbar und steuerbar machen. Ein Ingenieur-Ansatz für das Management: Struktur statt Glück. Erfolg, der reproduzierbar ist. Themen dieser Episode Wirkungsgrad: Der grundlegende Begriff aus dem Ingenieurwesen und seine Anwendung auf Wissensarbeit Effizienz vs. Effektivität: Der kritische Unterschied zwischen "die richtigen Dinge tun" und "Dinge richtig tun" Das Granatapfelbaum-Modell: Wie man die Effektivität in einer Organisation erhöht durch bewusste Priorisierung Der Universelle 4-Takt-Zyklus (DCVI): Die Methode, um Fehler zu vermeiden und effizienter zu arbeiten Das Zusammenspiel: Warum beide Modelle zusammen funktionieren und sich gegenseitig verstärken Ressourcen-Management: Wann und wie man Ressourcen wirklich reduzieren kann Arbeitskultur & Systeme: Warum Logik allein nicht reicht — es braucht implementierte Systeme und Gewohnheiten Key Takeaways ✓ Effizienz und Effektivität sind zwei verschiedene Fragen — beides ist notwendig für Erfolg ✓ Das Granatapfelbaum-Modell schafft Transparenz über alle Aktivitäten einer Organisation ✓ Der 4-Takt-Zyklus reduziert systematisch Fehler und unnötige Schleifen ✓ Zusammen schaffen die Modelle Struktur, die Erfolg reproduzierbar macht ✓ Erfolg ist kein Glück — es ist ein System, das implementiert werden kann Für wen ist diese Episode relevant? Manager und Führungskräfte in Entwicklung, Innovation und indirekten Bereichen Produktleiter, die ihre Teams effizienter machen wollen Organisationen, die zwischen Chaos und Überplanung stecken Alle, die lernen wollen, wie Engineering-Prinzipien im Management funktionieren Unternehmer und Geschäftsführer, die ihre Ressourcen optimal nutzen wollen Weitere Informationen Dieser Podcast basiert auf einer Serie von Artikeln und tiefer gehenden Analysen zum Thema Wirkungsgrad in der Wissensarbeit. Mehr über die beiden Modelle erfahren Sie in den erweiterten Artikeln zum Granatapfelbaum-Modell und zum Universellen 4-Takt-Zyklus. Hashtags #Effizienz #Effektivität #Wirkungsgrad #Wissensarbeit #Management #Produktentwicklung #Leadership #Organisation #SystemsThinking #Engineering #Produktmanagement Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

See All (18)

About

Prozesse, Menschen, Produkte. Der Podcast für eine schnelle, effiziente und zukunftsfähige Produktentwicklung. In dieser Audio-Edition übersetze ich die Analysen und Strategien meines englischsprachigen Newsletters ins Deutsche. So erhältst du alle Insights bequem in deiner Muttersprache – optimiert für das Hören unterwegs. Den englischen Newsletter mit allen Grafiken und Quellen findest du unter https://uwemierisch.substack.com/ uwemierisch.substack.com

Information

  • Creator
    Der deutsche Podcast zum englischen Newsletter von Uwe Mierisch
  • Years Active
    2026
  • Episodes
    18
  • Rating
    Clean
  • Copyright
    © Uwe Mierisch
  • Show Website
    Der Produktentwickler - Podcast