Und wieder ändert sich alles
Ich hatte das große Glück, zwei grundlegende Umbrüche in der Produktentwicklung miterleben und mitgestalten zu dürfen.
Im zweiten stecken wir gerade mittendrin.
Genau darum geht es in diesem Artikel. Um ein System, mit dem Produktentwicklung diesen Umbruch nicht nur übersteht, sondern eine erfolgreiche Zukunft baut.
Am Anfang meiner Laufbahn stand ich am Reißbrett. Bleistift und Tusche auf Transparentpapier.
Damals, als junger Ingenieur habe ich die älteren Kollegen bewundert.
Auf dem Transparentpapier entstanden Linien. Drei Seitenansichten, eine ISO-Perspektive, Schnitte. Mehr gab das Blatt nicht her.
Sie schauten darauf und sahen einen Körper.
Sie drehten ihn im Kopf, kippten ihn, schnitten ihn an einer Stelle auf, die gar nicht gezeichnet war, und wussten trotzdem, was dort zu sehen wäre.
Für mich waren es Striche, die ich mühsam zusammensetzen musste. Für sie war es ein Bauteil, das man in die Hand nehmen konnte.
Und dann kam der zweite Teil, der mich noch mehr beeindruckt hat.
Ein Kollege legte den Bleistift an den Übergang zur Rippe, tippte zweimal auf das Papier und sagte: „Da reißt es.“
Keine Rechnung. Kein Nachweis. Er hatte es gesehen.
Man nannte das „Berufserfahrung“. Es waren spezielle Fähigkeiten, die sich über viele Jahre dieser Tätigkeit ausbildeten.
Dann ersetzte der Computer das Reißbrett.
Ab da wurden diese Kompetenzen nicht mehr gebraucht.
Räumliche Darstellungen wurden im 3D-Konstruktionssystem generiert und visualisiert.
Eine weitere Schnittdarstellung? In einer Minute erledigt.
Berechnungsprogramme zeigen an, wo das Bauteil brechen wird.
Gebraucht wurden von nun an andere Kompetenzen.
Der Effizienzgewinn durch die neuen Werkzeuge vervielfachte den Output.
Eine Änderung, die früher bedeutete, dass ein halbes Blatt neu gezeichnet werden musste, war jetzt ein geänderter Wert. Was am Reißbrett Wochen brauchte, war am Bildschirm in einer Stunde erledigt.
Die Variantenvielfalt von heute wäre mit den Mitteln von damals nie entstanden. Und schon gar nicht so schnell.
Aber die Digitalisierung hatte nicht nur einen Effekt auf die Effizienz.
Gleichzeitig nahm die Zahl der Produktfunktionen zu. Erst mechanisch, dann elektrisch, dann elektronisch und vernetzt. Jede neue Funktion steht aber unweigerlich in Wechselwirkungen mit anderen.
Die inhaltliche Komplexität des Portfolios explodierte.
Jetzt kam es darauf an, diese Komplexität zu beherrschen. Zu wissen, was eine Änderung an einer Stelle drei Baugruppen weiter auslöst. Und in welcher Variantenkombination sie zum Problem wird.
Der erfahrene Entwickler von heute schaut auf eine Änderungsanfrage und sagt: „Das kollidiert mit der Schwerlastvariante.“
Keine Analyse. Kein Nachweis. Er hat es gesehen.
Das ist die Kompetenz, die wir heute bewundern.
Und nun stehen wir wieder an so einem Wendepunkt.
Künstliche Intelligenz und virtuelle Welten bieten die Basis, um auf ein ganz neues Niveau zu kommen. Viele Fähigkeiten von gestern werden dabei nicht mehr gebraucht.
Gebraucht werden wieder andere.
Wie Entwicklung in zwanzig Jahren abläuft, kann ich nicht beschreiben. Das hätte ich vor zwanzig Jahren auch nicht gekonnt.
Aber den ersten Schritt in diese Zukunft kann ich beschreiben.
Der NewPDP ist das Bindeglied zwischen dem Heute, in dem noch Defizite zu beheben sind, und dem Morgen, in dem wir anders arbeiten werden.
Wer die Defizite von heute nicht behebt, kommt im Morgen gar nicht an.
Denn eines ist auch bei diesem Technologiesprung absehbar:
Auch dieses Mal wird ein gewaltiger Effizienzgewinn stattfinden. Wer den nicht hinbekommt, der wird zum Verlierer dieser Transformation.
Darum ist das Motto des NewPDP:
Mehr entwickeln, ohne mehr zu brauchen.
Vier Jahre Arbeit stecken in diesem Modell.
Sieben Elemente, die genau dort ansetzen, wo die Entwicklung mechatronischer Produkte heute den größten Veränderungsbedarf hat.
Schauen wir sie uns an.
Vier Arbeitsweisen, drei Voraussetzungen
Practices (Arbeitsweisen) sind die Themengebiete, die transformiert werden müssen, und die Methoden, die den Effekt erzielen.
Ihre Reihenfolge ist so gewählt, dass zuerst das angepackt wird, was Grundlage für alles Weitere schafft.
Damit wende ich schon ein Prinzip an, auf das ich immer wieder zurückkommen werde:
Priorisiere die Themen, die jetzt den höchsten Wertzuwachs bringen und diejenigen, die den größten Wertverlust produzieren, wenn sie nicht jetzt gleich erledigt werden.
Enablers (Voraussetzungen) betreffen Veränderungen im Umfeld, ohne die die Transformation nicht gelingt.
Hier gibt es keine Reihenfolge.
An Führung, Organisation und Architektur kann und sollte gleichzeitig gearbeitet werden.
Neugierig?
Dann steigen wir kurz in die wesentlichen Merkmale ein.
Die vier Arbeitsweisen
1. Drum Beat System (DBS)
Im Takt zusammenarbeiten.
„Wir arbeiten gerade im QGx.”
Diesen Satz habe ich immer wieder gehört.
Er ist sprachlicher Unsinn. In einem Gate kann man nicht arbeiten. Ein Gate ist ein Kontrollpunkt.
Trotzdem sagen ihn alle. Weil unser Prozess nur die Kontrollpunkte benennt und nicht die Zeiträume dazwischen.
Genau diese Lücke füllt das Drum Beat. System.
Der Drum Beat gibt dem Dazwischen einen Rhythmus, Namen und Synchronisierungspunkte.
- Das Granatapfelbaum-Modell schafft Effektivität durch Zielpriorisierung und Gleichschritt.
- Der Universelle 4-Takt-Zyklus schafft Effizienz durch Fehlervermeidung und strukturierte Arbeitsvorbereitung.
Beide sind Bestandteil des Drum Beat Systems.
Und eine einzige Regel trägt das Ganze:
Ein Drum Beat wird nie gedehnt.
Sobald der Takt verlängert wird sind wir wieder dort, wo wir hergekommen sind. Dann verhandeln wir wieder Termine statt Inhalte.
Das Drum Beat System ist der Schmierstoff für alles andere. Wenn es funktioniert, läuft die ganze Maschine leichter.
Darum fangen wir damit an.
2. Learning Standard Routines (LSR)
Fokus schafft Professionalität.
Wahrgenommene Komplexität und Volatilität lassen eine Erkenntnis in Vergessenheit geraten:
Können entsteht durch Wiederholung.
Nicht jede Tätigkeit ist komplex und nicht das ganze Umfeld ist volatil. Repetitive Tätigkeiten in stabilem Umfeld gibt es, und es wird sie immer geben.
Für sie gilt:
- Identifizieren,
- Vorgehensweise definieren,
- dauerhaft dieselben Leute darauf ansetzen.
- Und diese Leute ihr Vorgehen selbst kontinuierlich verbessern lassen.
Jetzt kommt der Einwand: Das ist doch Taylorismus.
Zur Hälfte ja. Von Taylor bleibt die feste Zuordnung. Was wegfällt, ist die Trennung von Ausführen und Verbessern.
Ich halte das für einen der Vorteile der Old Economy.
Eigentlich wissen wir, wie das geht. Da, wo es sinnvoll ist, müssen wir es wieder kompromisslos tun.
Und ein Aspekt kommt dazu:
Standardisierte Prozesse lassen sich einfacher automatisieren und digitalisieren, als unstrukturierte. Das potenziert die Effizienzsteigerung.
Darum kommen die Lernenden Standardroutinen als zweites an die Reihe.
3. Hardware Light Development (HLD)
Virtuell vor materiell.
Digitalisierung ist in aller Munde. Jeder redet über KI, über Virtualisierung, über digitale Zwillinge.
Zu Recht.
Arbeit an echter Hardware ist langwierig und teuer.
Also müssen wir virtualisieren, was geht.
Kein Zweifel.
Die Herausforderung steckt in diesem kleinen Nachsatz: was geht.
Auch wenn mir dabei sicher nicht alle zustimmen werden: Solange das Produkt eine Hardware ist, bleibt ein Rest Hardwarearbeit unverzichtbar.
Die entscheidende Veränderung ist nicht auf Hardware komplett zu verzichten.
Sondern mit minimalstem Hardwareeinsatz die gleiche Qualität und Funktionalität zu entwickeln, nur viel schneller und billiger.
Jetzt fragen Sie sich, wie das gehen soll?
Genau das werden wir herausfinden.
4. Predictive Technology Readiness (PTR)
Reif, wenn es gebraucht wird.
Ich höre häufig: Wir müssen schneller neue Technologien in den Markt bringen.
Meine Beobachtung ist, dass wir uns allzu häufig erst dann für eine Technologieentwicklung entscheiden, wenn wir die Technologie dringend brauchen.
Das ist zu spät!
Es gibt allerdings auch den umgekehrten Fehler. Zu zeitig zu viel in innovative Technologien zu investieren.
Eine Technologie, die fertig im Regal liegt, bevor irgendjemand sie braucht, ist Bestand. Und Bestand verdirbt.
Das Wissen wandert mit den Leuten ab, der Stand veraltet.
Die Herausforderung liegt also nicht nur in der Geschwindigkeit, sondern im richtigen Maß.
Wie managen wir die Entwicklung einer Technologie so, dass sie genau dann reif ist, wenn wir sie brauchen?
Genau damit befasst sich diese Arbeitsweise.
Die drei Voraussetzungen
Leadership (L)
Klare Richtung, ein Team.
Zum Thema Führung gibt es unzählige Modelle und Meinungen.
Mich interessiert nur eine Frage:
Was muss Führung leisten, damit eine Produktentwicklung schnell und mit minimalem Ressourceneinsatz hervorragende Ergebnisse erzielt?
Eine Antwort vorweg:
Führung heißt mitarbeiten. Wer nur entscheidet, führt nicht.
- Was entscheidet das Team selbst und wie wird es befähigt, dieser Verantwortung gerecht zu werden?
- Welche Arbeitsaufträge nimmt der Chef vom Team entgegen und wie zuverlässig erledigt er sie?
Hier geht es um Vertrauen.
“Ein Team” ist keine Floskel, es ist eine Einstellung, eine Unternehmenskultur.
Wie im Teamsport gibt es unterschiedliche Spieler mit unterschiedlichen Rollen und die Art des Zusammenspiels muss klar verstanden und trainiert werden.
Und auch da gibt es Standardsituationen.
Und wenn wir das Thema schon mal auf dem Tisch haben, schauen wir uns natürlich auch die Selbstführung an.
Organisation (O)
Struktur folgt dem System.
Solange ich mich erinnern kann, erlebe ich die Debatte, ob Funktionalorganisation oder Divisionalorganisation die bessere Form ist.
Das Pendel wechselt regelmäßig die Richtung, am Ende steht fast immer eine Matrixorganisation.
Jetzt kommt das agile Unternehmen in Mode, und gleichzeitig beansprucht das Systems Engineering Einfluss auf die Organisationsform der Entwicklung.
Damit ist das eigentliche Problem benannt.
Die Matrix hat heute zwei Achsen:
- Kompetenz, also wer es kann und
- Prozess, also wie es läuft.
Das Systems Engineering bringt eine dritte ins Spiel, nämlich wie es funktioniert.
Nur überlebt eine Matrix keine dritte Achse. Drei Zugehörigkeiten, drei Zielsysteme, drei Leute, die über dieselbe Person verfügen.
Abgebildet werden müssen trotzdem alle drei. Aber es kann nur eine Organisation geben, und in ihr ist immer eine Achse führend. Das ist heute schon so, entweder führt die funktionale oder die divisionale.
Die Frage lautet deshalb nicht nur, wie wir die dritte Achse hinzufügen. Sondern welches Prinzip künftig führt. Und wie die Organisation darum herum gestaltet wird.
Darauf brauchen wir eine Antwort, denn ohne geeignete Organisationsform ist schnelles und effizientes Arbeiten nicht möglich.
Architektur (A)
Modularer Fortschritt.
Es ist der Traum jedes Entwicklers, ein vollkommen neues Produkt entwickeln zu dürfen.
Ich hatte diese Chance sogar mehrfach.
Und jedes Mal hat sich die Organisation hinterher geschworen, so etwas nie wieder zu machen.
Unendlich teuer, unendlich langwierig.
Und kaum ist man fertig, ist das Produkt veraltet und die nächsten Wünsche liegen auf dem Tisch.
In der Konsequenz habe ich mich intensiv damit beschäftigt, wie man Hardwareprodukte so modular gestaltet, dass Verbesserungen und neue Funktionalitäten inkrementell entwickelt werden können.
Wer aus der Softwarewelt kommt, erkennt darin das Inkrement.
Dort war es lange genauso.
Zu Zeiten des Spaghetticodes musste bei jeder Änderung fast alles neu gemacht werden.
Erst die objektorientierte Programmierung und die Architekturprinzipien danach haben das Inkrement möglich gemacht. Das ist Jahrzehnte her.
In der Hardware steht uns diese Entwicklung noch bevor.
Modulare Architekturen gibt es auch bei uns seit über zwanzig Jahren.
Sie sind nur nicht gut genug verstanden und nicht sauber genug definiert.
Genau darum geht es in diesem Element. Es soll die Lücken füllen, die einer inkrementellen Produktentwicklung in der Mechatronik im Weg stehen.
Wie eine solche Architektur konkret aussieht, definiert der NewPDP nicht. Das wäre zu speziell für ein generelles Framework.
Der NewPDP definiert, welche Eigenschaften und Prozesse eine Architektur aufweisen muss.
Warum ich nichts weglasse
„Das ist alles viel zu komplex, das versteht keiner. Nimm den Drum Beat raus und lass den Rest weg.“
Diesen Einwand höre ich immer wieder. Zu kompliziert, zu viel, zu umfangreich.
Der Wunsch nach Einfachheit ist nachvollziehbar, aber ist eine einfache Transformation überhaupt möglich, wenn ein ganzes Business System auf den Kopf gestellt werden muss?
Ich glaube nicht.
Was sein muss, das muss sein.
Die sieben Elemente stehen nicht nebeneinander, sie greifen ineinander. Jedes schafft Voraussetzungen für die anderen, und jedes profitiert von den anderen.
Das ist die Natur eines Systems.
Nehmen Sie sich zwei beliebige davon heraus und fragen Sie sich, was das eine ohne das andere wert ist.
Und in einem Aspekt ist der NewPDP schon eine Vereinfachung.
Alles, was heute keinen Veränderungsbedarf hat, ist gar nicht erst drin.
Mit einem Element anfangen kann man. Man muss sogar. Aber mit einem allein kommt man nicht ans Ziel.
Wenn ich in einiger Zeit wieder einen Überblicksartikel schreibe, ist die Geschichte hoffentlich etwas anders.
Wir werden Probleme gelöst haben, über die wir dann nicht mehr reden müssen, und dafür wird es neue Herausforderungen geben.
FAZIT
Der newPDP wird auf alle Phasen der Produktentwicklung angewandt, die ich im vorhergehenden Artikel beschrieben habe.
In den nächsten Artikeln werden ich jede Arbeitsweise und jede Voraussetzung im Detail besprechen, also abonnieren Sie meinen Blog, damit sie nichts verpassen.
Schauen Sie doch bitte in meinen Newsletter oder Podcast in dem sie weitere Inhalte zu diesem Thema finden.
Schreiben Sie mir doch bitte ein E-Mail, wenn sie mit mir darüber reden möchten, dann vereinbaren wir einen Videotermin.
Ich hoffe, der Artikel hat Ihnen gefallen.
Teilen Sie mir bitte mit, was Ihnen gefallen hat, wie ich mich verbessern kann, und machen Sie Vorschläge für Themen, die Sie gerne in Zukunft behandelt sehen würden.
Ihr Feedback ist entscheidend, um den Blog zu verbessern und Inhalte anzubieten, die ihren Interessen entsprechen. Ich freue mich darauf, von Ihnen zu hören!
