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. 12. Okt.

    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

  2. 28. Sept.

    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

  3. 14. Sept.

    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

  4. 17. Aug.

    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

  5. 3. Aug.

    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

  6. 13. Juli

    Der universelle Viertakt-Zyklus - DCVI

    Der universelle Viertakt-Zyklus In dieser Folge stelle ich ein Prinzip vor, das ich seit vielen Jahren in Projekten jeder Größenordnung einsetze: den universellen Viertakt-Zyklus, kurz DCVI. Es beschreibt vier Phasen, die jedes Projekt und jede Aufgabe strukturell tragen, egal ob in der Produktentwicklung, in der Organisation, bei Kostensenkung oder im ganz normalen Alltag. Die vier Phasen: Definition: Klarheit schaffen, bevor die eigentliche Arbeit beginnt. Was ist gegeben, was wird gesucht, welche Voraussetzungen müssen erst geschaffen werden, und vor allem: Wie soll das Ergebnis am Ende aussehen und für wen? Diese Phase wird am häufigsten abgekürzt, dabei zahlt sich Sorgfalt hier besonders aus. Creation: Die Lösung wird Schritt für Schritt entwickelt. Schleifen und mehrere Anläufe sind hier ausdrücklich erlaubt und gehören dazu, ebenso wie enge Teamarbeit statt Alleingänge. Validierung: Der Beweis, dass die Lösung unter realen Bedingungen tatsächlich funktioniert. Änderungen sind an dieser Stelle nur noch erlaubt, um echte Probleme zu beheben, nicht mehr um zu optimieren. Umsetzung: Das Ergebnis wird in die Realität geliefert. Eine Lösung zählt erst, wenn sie bei den Menschen ankommt, die sie brauchen, und dort auch wirkt. Kernaussage: Mit diesem Prinzip wird Erfolg keine Frage von Glück, sondern etwas, das sich gezielt steuern lässt. Das erfordert allerdings Übung und konsequente Anwendung, kein einmaliges Abhaken der vier Phasen. Nächste Folge: Wie der universelle Viertakt-Zyklus und das Granatapfelbaum-Modell als komplettes System zusammenwirken. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

    Der universelle Viertakt-Zyklus - DCVI
  7. 15. Juni

    Der Tag an dem ich das Shop Floor Management abgeschafft habe.

    ToDo Management – Die vierte Ebene des Granatapfel-Baum-Modells Zusammenfassung Shopfloor Management ist kein Nice-to-have. Das lernte ich auf die schmerzhafteste Art. Vor Jahren – es wird mir nicht leicht, das zuzugeben – traf ich eine Entscheidung, von der ich genau wusste, dass sie falsch war. Und ich tat sie trotzdem. In dieser Episode erzähle ich Ihnen, warum ein ganzes Unternehmen in die Krise läuft, wenn man sein Shopfloor-Team streicht. Und warum ToDo Management – die unterste, konkreteste Ebene des Granatapfel-Baum-Modells – das Fundament ist, auf dem alles andere ruht. Hier entstehen die Ergebnisse. Hier wird der Wert generiert. Hier, in den Fruchtkernern des Granatapfels. Kapitel 00:00 – Einstieg Die Geschichte der falschen Entscheidung und ihre Konsequenzen 05:30 – Die Lehre aus dem Fehler Warum Shopfloor Management unersetzlich ist 08:20 – Das Granatapfel-Modell und die ToDo-Ebene Die vierte Ebene und die DCVI-Phasen 12:45 – Die fünf Regeln des ToDo-Managements Ergebnisorientierung Organisatorische Verantwortung Interdisziplinarität Ergebnisüberprüfung Methoden-Support 22:10 – Die konkrete Vorgehensweise Wie sieht es in der Praxis aus? 26:30 – Soll der Chef eingebunden sein? Transparenz und Verantwortung 29:15 – Abschluss und Call to Action Was nehmen wir heute mit? Shopfloor Management schafft die Struktur, die Ergebnisse überhaupt erst möglich macht. Es ist nicht Bürokratie, es ist Fundament. Die fünf Regeln sind nicht optional. Ergebnisorientierung, organisatorische Verantwortung, Interdisziplinarität, Ergebnisüberprüfung und echter Methoden-Support – alle fünf müssen gelten. Dedizierte Ressourcen sind essentiell. Eine Methode verschwindet, wenn man aufhört, in sie zu investieren. Das gilt auch für kleine Unternehmen. Der Manager muss wissen, wie es läuft. Nicht aus Misstrauen, sondern aus Verantwortung. Transparenz schützt alle. Jeder ist der Projektmanager seines eigenen Verantwortungsbereichs. Das bedeutet nicht alles selbst zu machen – aber sicherzustellen, dass alles organisiert ist. Weiterführende Ressourcen Granatapfel-Baum-Modell: Das Kernmodell für strukturierte Produktentwicklung Drum Beat: Die dritte Ebene des Modells (vorherige Episode) DCVI-Phasen: Definition, Creation, Validation, Implementation – der Rhythmus, der auch in ToDo Management gilt Scrum und Lean Management: Die beiden Quellen, aus denen ToDo Management schöpft Ihre nächsten Schritte Haben Sie Fragen oder eigene Erfahrungen mit ToDo Management? Schreiben Sie mir einen Kommentar hier auf Substack, schicken Sie mir eine Nachricht, oder lassen Sie uns in den Kommentaren chatten. Nicht verpassen: In der nächsten Episode gehe ich ins operative Detail und zeige Ihnen anhand meiner Datenbank, wie alles konkret funktioniert. Das ist der praktische Teil – die Vorlagen, die Struktur, die Tools. Abonnieren Sie meinen Podcast oder Newsletter, damit Sie es nicht verpassen. Falls Ihnen dieser Podcast gefällt: Empfehlen Sie ihn bitte weiter. Das ist für mich das beste Feedback, das es gibt. Vielen Dank fürs Zuhören. Ich freue mich schon, Sie bei der nächsten Episode wiederzusehen. Bis dahin: Passen Sie auf sich auf und bleiben Sie innovativ. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

Info

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