No topic stirs up the people in a company as much as the organizational structure.

Not the strategy, and not the product, although both are emotional topics too.

The reason is that the organizational structure determines who is allowed to decide what, and who is responsible for what.

And, most importantly: who decides the fate of which employee.

If the structure is poorly chosen, the efficiency of the company suffers.

Anyone who wants to become more efficient and more effective with the NewPDP cannot avoid the question of organization.

Hundreds of researchers and executives have worked on this topic. Still, there is no single, finished, correct solution.

On the contrary. Right now I see completely opposing approaches, all of them recommended as best practice. And for each of them there are companies that apply it successfully.

That is why I draw on my own professional experience to sort things out.

Today I’ll limit myself to the engineering organization so the article doesn’t get too complicated. If you want to think about the other functions as well, tell me in the comments.

An Organizational Structure Fit for the Future

As a starting point for developing such a concept, it helps to look at how the organization has worked so far, and at what examples of other approaches exist.

Let’s start with where we are today.

Every Problem Starts With a Part

You’re responsible for a part? Then you’re the part owner.

You’re responsible for how several parts and components work together? Then you’re a team leader, department head, or division head.

The number of these aggregation levels determines the depth of the hierarchy.

Above it all sits the head of engineering. He is responsible for the entire product portfolio.

Fortunately, hardware and expertise usually fit together well.

The people responsible for the cab body in white know sheet metal forming.

The people responsible for the interior are plastics experts.

That’s why the structure found in engineering organizations today generally has the features of a functional organization.

Where cross-cutting expertise exists, additional units are created.

This organizational form follows one simple principle:

Every problem can be traced back to a hardware part. The owner of this part is responsible.

The owner of the failed part coordinates the fix with everyone who might be involved and is accountable for getting the vehicle running again.

A clever concept, really. Every conceivable problem has an owner.

The price is conflict.

When the cause isn’t obvious, finding out which part is actually defective can take an enormous amount of time and effort.

Structure shapes culture.

Here it’s a culture of defense.
The first reaction is almost always: It’s not my part, it’s someone else’s. Before I take responsibility, you’ll have to prove that my parts are the cause of the problem.

On top of that, every innovation needs a finished technical concept before anyone can be made responsible for developing it.

That makes this organizational form extremly management-intensive and inefficient. That alone would be reason enough to look for another alternative.

Still, it has worked so far.

Until electronics arrived.

At first, you could still find a control unit that the software ran on and that could carry the responsibility.

With the software-defined vehicle, that principle collapses.

Who owns the problem when all the software runs on a single central computer? And when it isn’t even clear whether the cause is mechanical, hydraulic, in a sensor, or in the software?

The old principle is no longer fit for the future.

Three schools of thought are currently being discussed. Let’s look at them.

The Agile Organization

Three roles carry concrete responsibility here.

Product managers and product owners are responsible for the goals. They have no line authority over people.

Self-organizing teams are responsible for the path to the goal. Collective responsibility applies here. The team wins together and loses together. There is no single person in charge until the team has reached agreement. Decisions are not made by one person, but facilitated toward consensus by a Scrum Master.

People managers carry personnel responsibility. I’ve often seen them provide and manage not only the human resources but other shared resources as well. They carry no responsibility for the content of the work.

Separating the goal from the path is pure mission command in Moltke’s sense. The product owner decides the what and the why. The team decides the how.

That’s a great strength.

The greatest weakness lies in separating responsibility for the work from responsibility for the people. Whoever decides on an employee’s development is not responsible for what that employee delivers.

I won’t go into further pros and cons here. If you’d like me to, say so in the comments. Then I’ll give the topic its own article.

The Chinese Way

The big consulting firms have studied the success of the Chinese automotive industry intensively. On organization, they offer a clear explanation.

Resources and people are assigned to managers in the classic way. The managers make decisions and enforce them with strict discipline.

Collective responsibility plays a minor role. If a goal is missed, the employee involved feels the consequences directly and personally.

In my observation, Chinese companies achieve something remarkable. They combine Prussian obedience with flexibility.

I see Clausewitz’s understanding of strategy at work here. The managers are closely involved in day-to-day business and make strategic and tactical decisions on the spot.

The greatest weakness is dependence on the boss.

The organization is only as good as the people deciding at the center.

Ideas from below have a hard time. And anyone who feels the consequences of every missed goal immediately would rather report problems late than early.

The greatest strength is speed. Every decision has a clear decision-maker, and that person is close to the action. The result is fast decisions and customer-oriented products.

Systems Engineering

Systems engineering is not recognized as an organizational form. Still, it contains structures that will sooner or later find their way into the organization.

So we have a structure and responsible people. In effect, that is an organizational structure.

Anyone who reads the INCOSE Systems Engineering Handbook will find most chapters dealing with exactly these structures.

And systems engineering has already solved a problem on which the hardware-centric organization fails.

A system includes hardware and software.

Well, at least in theory.

In practice, software developers often refuse to take responsibility for mechanical work, and for mechanical engineers systems engineering is all Greek.

But that can and must change. It isn’t a flaw in the methods, it’s poor implementation.

The holistic view of hardware and software in light of customer value is the greatest strength.

The greatest weakness: responsibility for people and resources doesn’t appear in systems engineering.

How resources are managed and people are led is a question systems engineering leaves open.

I suspect that’s exactly why it isn’t a recognized organizational form.

What an Organization Fit for the Future Must Deliver

Put the four approaches side by side, and each has something the others lack.

• The hardware-centric organization combines functional responsibility with the product structure.

• The agile organization separates the what from the how.

• The Chinese way decides fast and executes with discipline.

• Systems engineering has a product structure that looks at hardware and software as a whole.

Let’s look at the properties an organization fit for the future should have.

Fast means: every decision is made the moment it’s needed. Short-cycle planning of which decision is needed when, and from whom exist.

Efficient means: responsibilities and resources are in place and transparent to everyone. Nobody wastes energy searching for the person in charge or justifying resource needs.

Customer-centric means: the organization is open. Customers and suppliers are part of the organizational structure. The value stream doesn’t stop at the company’s boundary.

Fair to employees means: everyone has a boss they can trust. They get support when they need it. And whoever judges an employee knows their work.

The System-Centric Organization

Every known organizational form has advantages and disadvantages.

My proposal tries to combine the essential advantages and soften the disadvantages as much as possible. To do that, I borrow something from every approach.

Systems engineering is the only framework that covers hardware and software together. So I adopt its structures.

In this article, by feature I mean a benefit the customer receives. This clarification matters, because the term feature is currently used with different meanings in different contexts.

The feature is the value. Systems and functions are where that value materializes.

At the same time, I want to take the insights of Clausewitz and Moltke into account. They reflect reality, and as shown above, the known organizational forms already use them in part.

The feature describes the what and the why. It’s the strategic level.

The system and the function describe the how. They are the tactical elements of execution.

So responsibility is shared. That’s why each part gets its own organizational unit.

The Head of Engineering as Commander

Yes, that sounds odd. And many will shake their heads.

But that is exactly the role.

As a member of the executive board, he is the owners’ trustee.

That makes him responsible for carrying the purpose of the organization into engineering.

And as the owners’ trustee, he also provides the resources.

Below the head of engineering, four kinds of units stand side by side, as equals.

1. The Chief Architect

He breaks every feature down into requirements and addresses them to the systems.

To do that, he has to develop a product architecture and make it stick, and he has to understand the customer’s perspective and build it into the product.

This is the bill of materials of the new world.

Here, every problem and every product innovation is assigned an owner.

The boundaries between systems are the weak spot when it comes to assigning responsibility. So the systems must be defined large and comprehensive enough that few interfaces arise.

Clarifying those interfaces is the chief architect’s job.

His work is mostly strategic.

Since no single person can be everywhere or work everything out alone. The chief architect has his own team.

One thing he doesn’t have is authority over the systems.

He tells the system owners what their system must achieve and why. How they get there is their decision.

2. The System Owner

From the chief architect he receives the functional requirements his system must meet. From the head of engineering he receives the resources to do it.

In his system, mechanics, electronics, and software work together.

A head of engineering can only lead a limited number of system owners.
So there can only be a few systems at the top level. The organization forces the architecture into a clear, coarse cut.
That helps with the problem described above: open responsibility at the interfaces between systems.

3. The Shared Resources Owner

He is responsible for providing them. He has no product-related goals.

And he is the driver of continuous improvement. He makes sure that methods and processes don’t stand still but get better with every project.

His success is measured by whether the rest of the organization get what they need, when they need it. And by whether nobody has to fight over a shared resource.

4. Project Management

So far I’ve described the organizational structure. Who is responsible for what in the product.

In day-to-day business, that isn’t enough. There are projects: a new vehicle, a model year, a variant for a new market.
Every project needs contributions from almost all organizational units. And someone has to make sure they come together at the right time.

So there’s no getting out of the matrix.

How to run it is described in Mastering the Matrix. The principle applies here unchanged:

The project organization steers. The systems deliver.

All project managers are pooled in one unit that reports directly to the head of engineering. As equals alongside the chief architect, the systems head, and shared resources head.

He manages both in the deployment and in the execution.

I’ve already described the roles in the project organization in several articles: the project manager, the project management master, chief engineer and product architect, the representatives of the system areas, and the project management team as a whole.

So I won’t go into detail here. You’ll find the articles in my newsletter archive, feel free to take a look.

Each of the four units below the head of engineering has a clear responsibility:

• The chief architect is responsible for the architecture and the features.

• The project manager is responsible for achieving the project goals.

• The system owner is responsible for implementing both in his system.

• The shared resources owner provides the cross-cutting topics. Cross-cutting topics are resources as well as processes. That makes him the driver for continuously improving both, entirely in the spirit of Learning Standard Routines.

One Level Down: The Same Pattern

Inside the system, the pattern repeats.

Depending on the system’s complexity, he divides it into subsystems and defines the interfaces.

He has no feature responsibility. That exists only once, with the chief architect.

He does, however, carry function responsibilities.

The real work happens in the subsystem teams. This is where components are built and functions are developed.

What the system owner has decided as his How becomes the What and Why for the subsystems.

So the value flows from top to bottom without detours.

From the purpose, through the features and the systems, down to the teams who build it.

Rank Is Not Measured by Headcount

In many companies, an executive’s rank is measured by how many people report to them. The more people, the more important the boss.

In this structure, that doesn’t work.

The teams decide the How themselves. So few consolidation levels are needed.

Every extra level that only collects reports and passes them on makes the organization slower, not better.

At the same time, every boss needs enough people directly talking to him, who have no staff of their own.

The reason is this:

In this organization, a boss is manager and strategist at once.
He has to do real work himself.
He must not delegate his share of the work to the units below him, who need this input. If he did, he would break the cascade.

That’s why he needs his own people.

This reverses current practice. Staff positions are often abolished today because they are seen as a privilege.

They’re not a privilege. They’re a necessary resource.

Moltke would not have fought a single campaign without his general staff.

What Does This Mean for Employees?

Their boss is responsible for what that unit delivers. So he sees the work he judges.

The team wins together or loses together. But it knows exactly what for: for its system. The system is the tactical element that leads toward the purpose of the company.

Every employee has a concrete scope of responsibility. But it is no longer tied to a part. It’s tied to a concrete contribution of value.

That takes getting used to.

It’s not broken or missing hardware that everyone can see, but a virtual value. Software development proves that it works. So we mechanical engineers have to get over ourselves. In return, we become a real team with a common goal.

And the Rest of the Company?

This organizational form has far-reaching consequences for the rest of the company. For sales, production, purchasing.

And the collaboration with suppliers deserves a closer look as well.

But I’ll stop here for today. I think that was already a lot to think about and digest.

I’ll pick up the thread in later articles.

If you don’t want to wait, tell me in the comments, and I’ll reprioritize my articles. Or we can simply chat about it.

What Do We Take Away Today?

• The organizational structure determines who decides about whom. That’s why it’s the most emotional topic in any company.

• The hardware-centric organization worked because every problem was related to a hardware responsibility. With software, that no longer works.

• Agile separates the what from the how. The Chinese way decides fast. Systems engineering has a structure for hardware and software. None of these approaches is complete on its own.

• The system-centric organization combines them: the chief architect owns the features and thus the what. The system owners own their systems and thus the how. The head of engineering is responsible for the whole.

• The how of one level is the what of the next.

• There’s no getting out of the matrix. A lean project management unit under the head of engineering steers, the systems deliver.

• Staff positions are not a privilege. They’re what allows a boss to do his own job.

• Fair to employees means: a boss who sees the work he judges.

And now I’m curious.

How is your engineering organized today? And who owns a problem in your company that involves both hardware and software?

Feel free to write it in the comments on Substack. I read every single one and I reply.

Leave a comment

And if you’re facing this transformation and don’t want to start alone, write to me about that too.

In the coming weeks I’ll move on to the next prerequisite of the NewPDP: architecture.

If you want to follow the whole story, the best way is to subscribe to the newsletter or the podcast.

Subscribe now

Found this useful? Please share it with someone who’s dealing with the same problem.

Share

If you think a colleague would get value out of this, recommend the newsletter.

Share Uwe Mierisch

Ich wollte einfach nur geile Autos und Motorräder bauen.

Das war der ganze Plan. Konstruieren, rechnen, ausprobieren, verbessern.

Führung war etwas für andere. Etwas für die, die in Besprechungen sitzen und wichtig erscheinen wollen.

Dann habe ich etwas erlebt, das meine Sicht verändert hat. Ich erinnere mich noch sehr genau daran.

Unser Produkt war in die Jahre gekommen. Es gab eine Diskussion, ob man die Produktion nicht einfach einstellen sollte. Es verkaufte sich ja ohnehin nicht mehr.

Da sagte unser damaliger Chef:

„Baut mal schnell einen Prototypen mit dem neuesten Motor.“

Alle sagten: „Der passt doch gar nicht rein. Außerdem ist er viel zu teuer. So etwas zu entwickeln ist viel zu aufwendig, das dauert Jahre.“

Er sagte: „Jetzt schweißt so ein Auto einfach mal um, hängt den Motor rein und bringt ihn zum Laufen. Macht euch sonst keine weiteren Gedanken.“

Macht euch sonst keine weiteren Gedanken.

Alle wunderten sich. Aber sie taten es.

Nach nur einigen Monaten lief das Fahrzeug.

Am Rande der IAA organisierte der Chef eine Vorführung auf dem Contidrom bei Hannover, der Versuchsstrecke von Continental. Eingeladen waren nur wenige, aber einflussreiche Journalisten und Kunden. Sie durften das Auto selbst fahren.

Das Feedback war überragend:

„Das Auto müsst ihr unbedingt bauen. Das wollen wir haben!“

Auf einmal war das Einstellen der Produktion überhaupt kein Thema mehr. Es ging nur noch darum, wie das Projekt zu stemmen sein würde.

Das hat mich schwer beeindruckt. Von dem Tag an war mir klar: So etwas will ich auch machen.

Meine alte Sicht auf die Dinge war naiv.

Ein gutes Fahrzeug baut niemand allein. Es entsteht aus Tausenden von Entscheidungen, die Hunderte von Menschen treffen. Ob am Ende ein richtig gutes Fahrzeug dabei herauskommt, hängt weniger davon ab, wie gut jede einzelne Entscheidung ist.

Es hängt davon ab, ob alle in dieselbe Richtung zeigen.

Und dafür sorgt Führung.

War das, was mein Chef damals gemacht hat, Führung? Management? Strategie?

Das schauen wir uns im Folgenden genauer an.

Auf jeden Fall ist es das, was wir für die Zukunft wieder lernen müssen.

Vorher müssen wir aber klären, was Führung eigentlich heißt. Denn sie wird sehr leicht mit Management verwechselt.

Führung ist nicht Management

John P. Kotter von der Harvard Business School hat diese beiden Begriffe schon 1990 auseinandergenommen.

Beides wird gebraucht. Aber es ist nicht dasselbe.

Kotters Diagnose war damals eindeutig:

Die meisten Unternehmen seien overmanaged and underled. Überverwaltet und unterführt.

Daran hat sich wenig geändert.

Auf dem Organigramm sehen Management und Führung bis heute gleich aus. Dieselbe Box, derselbe Titel: Führungskraft.

Und im Kalender gewinnt fast immer das Management. Berichte, Budgets, Abstimmungen. Für Führung bleibt wenig Zeit.

Viele Unternehmen sind gut verwaltet. Aber schlecht geführt.

Für das NewPDP ist das keine Randfrage. Ein Entwicklungsmodell, das mehr leisten soll, ohne mehr zu brauchen, steht und fällt mit der Führung. Deshalb ist Leadership einer seiner drei Enabler.

Ich muss also genauer sagen, was Führung im NewPDP heißt. Und wer sie macht.

Geholfen haben mir dabei ausgerechnet zwei preußische Generäle.

Seit einiger Zeit beschäftigt mich Carl von Clausewitz. Und bei Helmuth von Moltke dem Älteren habe ich auch abgeschaut.

Beide haben sich mit der Frage herumgeschlagen, die hinter jeder Führungsdebatte steckt.

Wer entscheidet was?

Im Überblicksartikel zum NewPDP habe ich geschrieben: Führung heißt mitarbeiten. Wer nur entscheidet, führt nicht. Die Frage, wer was entscheidet, habe ich dort bewusst offen gelassen.

Heute löse ich sie auf.

Nicht zwei Ebenen, sondern drei

Üblicherweise denken wir in zwei Kategorien:

Sachbearbeiter: Diejenigen die arbeiten, die etwas erschaffen.
Führungskräfte: Diejenigen die anderen sagen, was zu tun ist und beurteilen, wie gut sie es gemacht haben.

Genau daran ist Preußen 1806 bei Jena und Auerstedt gegen Napoleon gescheitert. Soldaten, die kämpfen, und Offiziere, die Befehle geben, reichten nicht, um einen Krieg zu gewinnen.

Clausewitz war damals dabei. Er geriet in Gefangenschaft und gehörte danach zu den Reformern, die die preußische Armee neu aufgestellt haben.

Vor demselben Veränderungsbedarf stehen wir heute. Deshalb lohnt es sich, seine Erkenntnisse ernst zu nehmen.

Dazu gehört vor allem das Verständnis von drei Begriffen: Taktik, Strategie und Zweck.

Er definiert:

Da stecken drei Dinge drin.

Das Gefecht. Der Einsatz der Gefechte. Und der Zweck.

Den Zweck setzt bei Clausewitz nicht der Feldherr. Den setzt die Politik. Daher stammt sein bekanntester Satz:

Also gibt es den Zweck nicht nur im Krieg, sondern er ist auch da, wenn es keinen Krieg gibt.

Übersetzt in ein Unternehmen heißt das:

• Es gibt einen Zweck. Er beschreibt, was das Unternehmen werden soll.

• Es gibt taktische Operationen. Das sind die Aktivitäten, die real auf diesen Zweck hinarbeiten.

• Und es gibt den Strategen. Er ordnet jede dieser Operationen bezüglich ihrer Wirkung ein und entscheidet den nächsten Zug.

Drei Ebenen. Drei verschiedene Aufgaben.

Und auf jeder davon wird geführt, im Sinne von Kotter: Es wird eine Richtung gesetzt, und Menschen werden darauf ausgerichtet.

Der Zweck ist groß und er bleibt stabil

Ein Zweck ist nicht klein-klein.

Es ist auch nicht „das profitabelste Unternehmen der Welt werden”. Das ist kein Zweck, sondern ein Ergebnis. Es sagt niemandem, was er morgen tun soll.

Zum Beispiel:

• ein Hersteller von elektrischen Long-Haul-Trucks für Europa,

• der technologisch führende Hersteller von Nutzfahrzeugen in Europa und Amerika,

• ein globaler full line Anbieter von Nutzfahrzeugen auf allen Kontinenten und in allen Segmenten,

• ein Anbieter für alle Aspekte des Gütertransports auf der ganzen Welt.

Jedes davon führt zu einem völlig anderen Unternehmen. Anderen Produkten, anderen Werken, anderen Leuten, anderen Entwicklungsprojekten.

Deshalb ist die Auswahl des Zwecks Aufgabe der Geschäftsführung.

Der Zweck muss über lange Zeit stabil und durchgängig kommuniziert sein.

Alle 3 Jahre eine neue Geschäftsführung mit neuen Ideen ist tödlich. Gerade in den volatilen Zeiten des technologischen und wirtschaftlichen Umbruchs ist ein konstanter Unternehmenszweck unverzichtbar.

Diesen Unternehmenszweck zu entscheiden ist keine Sache von 5 Minuten, dem geht harte Arbeit voraus.

Was ist realistisch in Anbetracht der verfügbaren Ressourcen und Mittel?
Was sind die Interessen der Eigentümer?
Wo gehen die Belegschaft und die Kunden mit?

Alles muss Hand und Fuß haben. Und selbst nach der Entscheidung hört die Arbeit nicht auf. Alle müssen kontinuierlich auf diesen Zweck ausgerichtet werden.

Die Taktik gehört dem Team

Dann ist da noch die eigentliche Arbeit.

Und auch hier wird geführt.

Führen heißt auch hier die Richtung vorzugeben und die Absicht klar zu machen.

Entscheiden sollen die, die vor Ort sind. Dafür gilt eine einfache Regel: Die Entscheidung fällt so nah am Geschehen wie möglich.

Moltke wusste, warum:

Der Plan trifft auf die Wirklichkeit, und die Wirklichkeit hält sich nicht an den Plan. Wer dann erst fragen muss, ist zu spät.

Moltke hat daraus eine Führungsweise gemacht, die später Auftragstaktik genannt wurde.

Das Wort „warum” ist dabei der entscheidende Teil.

Wer nur das Was kennt, kann nicht sinnvoll abweichen, wenn die Lage sich ändert. Wer die Absicht kennt, kann es.

Aber Auftragstaktik ist kein Freibrief. Sie funktioniert nur, wenn ein System da ist, in dem die Leute allein und miteinander die richtigen Entscheidungen treffen können. Ein gemeinsamer Takt, sichtbare Aufgaben, klare Zuständigkeiten.

Im NewPDP ist das das Drum Beat System. Ohne einen solchen Rahmen wird aus dezentraler Entscheidung schnell dezentrales Chaos.

Einen Grundsatz der Auftragstaktik habe ich schon früheren Artikeln erwähnt, weil er wichtig ist.

Die Strategie sitzt dazwischen

Bleibt die Ebene in der Mitte.

Wer im Unternehmen heute „Strategie“ sagt, meint meistens einen langfristigen Plan. Eine Roadmap über fünf Jahre. Ein Zielbild mit Umsatzzahlen. Eine Liste von Initiativen, ordentlich priorisiert.

Das ist keine Strategie.

Das Zielbild ist das Ziel. Die Roadmap ist ein Plan. Und die Liste der Initiativen ist eine Liste.

Jeder taktische Zug verändert die Lage.

Ein neues Produkt kommt sehr gut bei den Kunden an. Oder auch nicht. Oder das Produkt ist super, aber der Wettbewerber hat auf einmal ein besseres.

Irgendjemand muss fragen: Was bedeutet das für unseren Zweck? Bringt uns dieser Zug näher heran oder weiter weg? Welche neuen Möglichkeiten haben sich gerade eröffnet?

Das ist die Aufgabe des Strategen.

Er ist der Schachspieler, der den nächsten Zug entscheidet. Er erkennt welche Wirkung der letzte Zug hatte und er kalkuliert den nächsten Zug.

Moltke nannte die Strategie deshalb ein System der Aushilfen. Kein starrer Plan, sondern das ständige Neubewerten der Lage im Licht des Zwecks.

Ist Strategie also nur eine Aufgabe für Führungskräfte?

Beim Militär lautete die Antwort schon zu Moltkes Zeit: nein.

Die Strategie entstand im Generalstab. Dort arbeiteten Offiziere, die keine Truppen befehligten. Sie analysierten die Lage, spielten Szenarien durch und planten Aufmarsch und Feldzug. Und sie wurden den kommandierenden Generälen zur Seite gestellt, damit deren Entscheidungen auf einer gründlichen Bewertung der Lage beruht.

Strategisches Denken war also nicht an den Rang gebunden. Es war eine Fähigkeit, die man gezielt ausbildete, und eine Arbeit, die viele machten.

Damit sind wir bei der eigentlichen Frage dieses Artikels.

Wer führt?

Peter Drucker hat die kürzeste Definition geliefert, die ich kenne:

Das heißt: Führung ist eine Tätigkeit, keine Position.

Aber wenn jeder führen kann, wozu braucht es dann noch einen Chef?

Was ist denn ein Chef?

Wenn Führung keine Position ist und Strategie nicht automatisch Chefsache, was bleibt dann für den Chef?

Nicht nur für das eigene Tun. Das übernimmt jeder Profi, jeder Ingenieur, jede Expertin. Sondern für das, was andere tun. Auch wenn er es selbst anders gemacht hätte. Auch wenn er es nicht bis ins Detail versteht.

Es gibt einen ähnlichen Satz: Führungskräfte tragen Verantwortung für ihre Mitarbeiter. Das ist Verantwortung für Menschen. Die Sicht des People Managers.

Ich meine hier etwas anderes. Verantwortung für das, was sie tun, nicht für das was sie werden sollen.

Mein damaliger Chef hat es in einem Satz gesagt:

„Macht euch sonst keine weiteren Gedanken.“

Das war keine Anweisung. Das war die Übernahme der Verantwortung. Wenn das schiefgeht, ist das meins.

Schaut man genauer hin, ist jede Aufgabe, die nur der Chef erledigen kann, genau so eine Übernahme:

• Prioritäten setzen heißt: Ich verantworte, was ihr liegen lasst.

• Die Kompromisse des Teams mittragen heißt: Ich verantworte Entscheidungen, die ich nicht selbst getroffen habe.

• Deals mit Kollegen der eigenen Ebene heißt: Ich verantworte, was mein Team für andere leistet.

• Rechtlich verbindlich handeln heißt: Ich verantworte nach außen, was hier drinnen passiert.

Deshalb kann nur der Chef Verbindlichkeit für das gemeinsame Ergebnis herstellen. Eine Zusage ist erst verbindlich, wenn jemand dafür geradesteht.

Daraus wird ein Test:

Gehört diese Aufgabe zum Chef? Nur wenn jemand für das Tun anderer geradestehen muss.

Alles andere kann das Team selbst.

Verantwortung braucht einen eigenen Beitrag

Damit klärt sich auch die Strategiefrage. Strategie entwickeln kann jeder, der die Lage überblickt.

Aber sobald eine Strategie umgesetzt wird, tun andere etwas. Hunderte von Menschen richten ihre Arbeit danach aus. Für dieses Tun muss jemand die Verantwortung übernehmen.

Das ist der Chef.

Entscheiden heißt für den Chef: die Verantwortung übernehmen. Für eine Strategie, die vielleicht ein anderer ausgearbeitet hat. Und für die Taktik, die das Team entschieden hat.

Das heißt aber nicht, einfach den Rücken hinzuhalten.

Verantwortung für das Tun anderer kann nur übernehmen, wer selbst etwas beiträgt. Der Chef muss sich mit den Themen beschäftigen, die Lage kennen, die Argumente prüfen und seinen eigenen Teil beitragen. Sonst steht er für etwas gerade, das er gar nicht beurteilen kann.

Nicht aus dem Elfenbeinturm

Strategische Arbeit klingt nach Schreibtisch. Nach Ruhe, Abstand und Überblick.

Clausewitz hat das schon vor 200 Jahren gefordert:

Zu seiner Zeit wurde Strategie gern im Kabinett gemacht, weit weg von der Armee. Er hielt das für einen großen Fehler.

Das gilt für jeden, der strategisch arbeitet. Ob Geschäftsführer, Bereichsleiter, Projektleiter oder Systemarchitektin. Auf jeder Ebene.

Das heißt nicht, dass er dort die Entscheidungen übernimmt. Was das Team selbst entscheiden kann, entscheidet das Team.

Aber manchmal stößt das Team an eine Grenze, die es allein nicht überwinden kann. Zwei Anforderungen schließen sich aus, und jemand muss sagen, welche wichtiger ist. Ein anderer Bereich muss mitziehen. Ein Risiko ist zu groß, um es ohne Rückendeckung einzugehen.

Dann muss entschieden werden. Von dem, der für das gemeinsame Ergebnis geradesteht. Und zwar sofort, nicht in der nächsten Lenkungskreissitzung.

Wer im Elfenbeinturm sitzt, sieht die Lage zu spät, und es wird zu spät entschieden. Wer vor Ort ist, sieht sie früh, ordnet sie ein und sorgt dafür, dass entschieden wird, wenn es nötig ist.

Kommen wir nun zum Management.

Management ist der Aufmarsch

Bleibt die Frage: Was ist Management eigentlich, wenn es nicht Führung ist?

Auch darauf hat Moltke eine Antwort.

Ein Satz von ihm hat mich besonders betroffen:

Die Versammlung der Armeen. Der Aufmarsch. Truppen zusammenziehen, Kräfte verteilen, Nachschub organisieren, die richtigen Leute an die richtigen Stellen bringen.

Daneben Kotters Beschreibung von Management: planen und budgetieren, organisieren, Stellen besetzen, kontrollieren.

Es ist dasselbe.

Damit wird die Arbeitsteilung klar.

Führung sagt, wohin es geht.

Management stellt die Mannschaft so auf, dass sie dort ankommen kann.

Moltke sagt auch, warum das so wichtig ist.

Der Aufmarsch ist der einzige Moment, in dem der Gegner noch nicht stört. Was sich vorbereiten lässt, lässt sich nur jetzt in Ruhe vorbereiten. Deshalb planten die Preußen ihren Aufmarsch bis in die Fahrpläne der Eisenbahn.

Alles, was vorher geklärt ist, muss später nicht mehr unter Druck entschieden werden. In der Ausführung bleibt nur die Komplexität übrig, die sich nicht vermeiden lässt. Und damit wird die Durchführung beherrschbarer.

Gutes Management reduziert die Komplexität der Ausführung auf das unvermeidbare Maß.

Genau das meint Kotter, wenn er sagt: Management bewältigt Komplexität.

Im Entwicklungsprojekt ist das nicht anders.

Markt, Wettbewerb und neue Technologien bringen genug Komplexität mit sich. Fehlende Kapazität, unklare Zuständigkeiten und Voraussetzungen, die zum Start nicht stehen, sind dagegen hausgemacht. Sie hätten im Aufmarsch geklärt werden können.

Das ist die Aufgabe des Managements. Und auch das ist harte, bodenständige Arbeit.

Management in Vorbereitung und Durchführung

Auch im laufenden Projekt muss nachgeführt werden. Ressourcen werden umgeschichtet, wo ein Engpass entsteht. Kapazität werden nachgezogen, wenn sich der Umfang ändert. Schnittstellen werden geklärt, Lieferanten nachgesteuert, Voraussetzungen nachgebessert.

Beim Militär heißt das Nachschub. Ohne ihn bleibt auch der beste Aufmarsch stecken.

Management gibt es also zweimal: in der Vorbereitung und in der Durchführung. Beides ist notwendige Arbeit, und beides liegt in der Verantwortung aller.

Hier hat auch die Mitarbeiterentwicklung ihren Platz: im Sinne von alles richtig aufstellen.

Was Management nicht ist

Trotzdem hat Management einen schlechten Ruf. Das liegt an etwas anderem.

Vieles, was heute unter dem Namen Management läuft, hat mit gutem Management nichts zu tun:

• Tracking: Fortschritt erfassen, Ampeln einfärben, Listen pflegen.

• Überwachung: nachhalten, ob alle tun, was sie sollen.

• Rechtfertigung: erklären, warum etwas noch nicht fertig ist.

Oft erledigen das Menschen mit dem Titel Manager. Aber es ist kein Management.

Der Unterschied ist einfach:

Management schafft Voraussetzungen. Tracking stellt fest, was nicht erledigt wurde.

Gutes Management braucht eine Organisation, die ihm Raum lässt. Und diese Organisation muss den Notwendigkeiten folgen. Nicht umgekehrt.

Wie eine solche Organisation aussieht, ist das Thema des nächsten Artikels.

Führung und Management sind nicht nur Chefsache

Aber sie sind auch Chefsache.

Sie finden auf drei Ebenen statt:

• Beim Unternehmenszweck. Die Geschäftsleitung legt fest, was das Unternehmen werden soll. Und sie hält diese Richtung stabil.

• In der Strategiearbeit. Wer die Lage überblickt, ordnet jeden Zug im Licht des Zwecks ein und zeigt, wie es weitergeht. Mit Chefposition oder ohne.

• In der taktisch-operativen Arbeit. Teamleiter, Abteilungsleiter, Projektleiterinnen, Expertinnen und Teams führen und managen, wenn sie in der Umsetzung die Richtung adjustieren und auf die Realität reagieren.

Der Chef hat dabei eine Aufgabe, die ihm niemand abnehmen kann. Er steht für das gemeinsame Ergebnis gerade. Und das kann er nur, wenn er selbst mitarbeitet.

• Management sorgt dafür, dass die Mannschaft ankommen kann.

• Führung sorgt dafür, dass alle in dieselbe Richtung gehen.

Klare Richtung, ein Team.

Was nehmen wir heute mit?

• 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.

• Strategen sind bei der Taktik dabei.

• Management schafft die Voraussetzung für die Durchführung, in der Vorbereitung und während der Durchführung.

Und jetzt bin ich neugierig.

Wie ist das in Ihrem Unternehmen? Wie viel von dem, was dort Management heißt, schafft Voraussetzungen? Und wie viel stellt nur fest, was nicht erledigt wurde?

Schreiben Sie es mir gern in den Kommentar auf Substack. Ich lese jeden einzelnen und antworte.

Leave a comment

Und wenn Sie vor dieser Transformation stehen und nicht alleine durchgehen wollen, schreiben Sie mir das auch.

In den kommenden Wochen geht es weiter mit den nächsten Voraussetzungen des NewPDP: Organisation und Architektur.

Gerade die Organisation hängt eng mit Führung zusammen. Sie entscheidet, wo entschieden wird und wer dafür geradesteht.

Wenn Sie die ganze Geschichte verfolgen wollen, abonnieren Sie am besten den Newsletter oder den Podcast.

Subscribe now

Und wenn Ihnen das geholfen hat, teilen Sie es mit jemandem, der vor demselben Problem steht.

Share

Share Uwe Mierisch

I have often heard the sentence: “Management has decided.”

What people meant was the bosses, the person at the top of the org chart. The higher up, the better it works as an excuse.

But just as often I heard the other one: “Management just won’t decide.”

So there’s nothing you can do. You wait.

In the way we talk, management is a group. If you’re a boss, you’re in it. Everyone else isn’t.

To be honest, that’s pretty convenient, for both sides. One side gets a title, the other gets someone whose job it is to sort things out.

It just isn’t true. Management isn’t a group of people. Management is something you do.

And everyone has to do it.

Peter Drucker saw this back in 1967. For him, every knowledge worker responsible for a contribution that materially affects the results was an executive, whether or not anyone reported to him.

What does that mean in practice?

Take an engineer preparing a test.

He has to organize the timing when the test rig is free, that the parts will arrive on time, that a measurement technician has time and that the software is at the level he needs. Only then can the test happen at all.

So he creates the preconditions.

That is management.

Once the test is running, he keeps an eye on it. Are the values where they should be? Is the schedule holding? Is anything missing?

He measures. Not to write a report, but to see where he needs to step in. Measuring is how you spot where action is needed.

If a part is missing, he gets it. If the rig turns out to be booked after all, he negotiates. And if something starts going off the rails, he acts as early as possible.

Create the preconditions, measure, adjust. All within his own area of responsibility.

A department head does basically the same thing, just for a bigger area. Top management too, just for the whole company. The activity is the same, only the scope is different.

So what happens when you leave management to the bosses?

Then the engineer waits until someone books the test rig. Nobody notices a missing part until the test is due. And the boss is supposed to manage things he can’t even see from where he sits.

And then you hear it again: “Management just won’t decide.”

If you delegate management upward, you give away your own work.

How is it where you work? Who actually manages? Tell me in the comments.

After university, I had no wish to become a manager. I wasn’t after status or a big salary.

I just wanted to build seriously cool cars and motorcycles.

That was the whole plan. Design, calculate, test, improve.

Leadership was for other people. For the ones who sit in meetings and like to look important.

Then something happened that changed my view. I still remember it very clearly.

Our product had grown old. There was a debate about whether to simply stop production. It wasn’t selling anymore anyway.

Then our boss at the time said:

“Quickly build a prototype with the latest engine.”

Everyone objected: “It won’t even fit. It’s far too expensive. Developing something like that is a huge effort. It takes years.”

He replied: “Just weld one of the vehicles together, drop the engine in and get it running. Don’t worry about anything else.”

Don’t worry about anything else.

Everyone was puzzled. But they did it.

Only a few months later, the vehicle was running.

On the sidelines of the IAA motor show, the boss organized a demonstration at the Contidrom near Hanover, Continental’s test track. Only a handful of people were invited, but influential ones: journalists and customers. They got to drive the vehicle themselves.

The feedback was overwhelming:

“You absolutely have to build this. We want it!”

Suddenly, stopping production was off the table. The only question was how to pull off the project.

That made a deep impression on me. From that day on, I knew: this is what I want to do.

My old view had been naive.

Nobody builds a good vehicle alone. It is the result of thousands of decisions made by hundreds of people.

Whether a really good vehicle comes out at the end depends less on how good each individual decision is.

It depends on whether everyone is pointing in the same direction.

And that is what leadership takes care of.

Was what my boss did back then Leadership? Management? Strategy?

That is what we will look at in this article.

Either way, it is something we need to learn to do again.

But first we need to be clear about what leadership actually means. Because it is very easily confused with management.

Leadership Is Not Management

John P. Kotter of Harvard Business School took these two terms apart back in 1990.

Both are needed. But they are not the same thing.

Kotter’s diagnosis at the time was clear: most companies are overmanaged and underled.

Not much has changed since.

On the org chart, management and leadership still look identical. Same box, same title: manager.

And in the calendar, management almost always wins. Reports, budgets, alignment meetings. Little time is left for leadership.

Many companies are well administered. But poorly led.

For NewPDP, this is not a side issue. A development model that is meant to deliver more without needing more stands or falls with leadership. That is why leadership is one of its three enablers.

So I need to be more precise about what leadership means in NewPDP. And who does it.

Of all people, two Prussian generals helped me with that.

For some time now, I have been occupied with Carl von Clausewitz. And I have borrowed a few things from Helmuth von Moltke the Elder as well.

Both wrestled with the question behind every leadership debate.

Who decides what?

In the overview article on NewPDP, I wrote: leading means working alongside. Whoever only decides is not leading. I deliberately left open the question of who decides what.

Today I will answer it.

Not Two Levels, but Three

We usually think in two categories:

Individual contributors: the people who do the work, who create something.
Managers: the people who tell others what to do and judge how well they do it.

This is exactly where Prussia failed against Napoleon at Jena and Auerstedt in 1806. Soldiers who fight and officers who give orders were not enough to win a modern war.

Clausewitz was there. He was taken prisoner and afterwards became one of the reformers who rebuilt the Prussian army.

We face the same need for change today. That is why his insights are worth taking seriously.

Above all, understanding three terms: tactics, strategy and purpose.

He defines them like this:

There are three things in that sentence.

The engagement. The use of engagements. And the purpose.

In Clausewitz’s view, the purpose is not set by the general. It is set by politics. That is where his best-known sentence comes from:

So the purpose exists not only in war. It is there even when there is no war.

Translated into a company, this means:

• There is a purpose. It describes what the company wants to become.

• There are tactical operations. These are the activities that actually move the company toward that purpose.

• And there is the strategist. He assesses the effect of each of these operations and decides the next move.

Three levels. Three different jobs.

And on each of them, there is leadership in Kotter’s sense: a direction is set, and people are aligned behind it.

The Purpose Is Big, and It Stays Put

A purpose is not about small things.

Nor is it “becoming the most profitable company in the world.” That is not a purpose. It is a result. It tells nobody what to do tomorrow.

For example:

• a manufacturer of electric long-haul trucks for Europe,

• the technology leader in commercial vehicles in Europe and the Americas,

• a global full-line supplier of commercial vehicles on every continent and in every segment,

• a provider for every aspect of freight transport worldwide.

Each of these is a reasonable purpose.

Each of them leads to a completely different company. Different products, different plants, different people, different development projects.

That is why choosing it is the job of the executive board.

The purpose has to remain stable over a long time and be communicated consistently.

A new executive board with new ideas every three years is fatal here. Especially in volatile times of technological and economic upheaval, a constant purpose is indispensable.

Deciding on that purpose is not a five-minute job. It takes hard work.

What is realistic given the available resources and means?
What are the interests of the owners?
Will the workforce and the customers come along?

Everything has to be well founded. And even after the decision, the work does not stop. Everyone has to be aligned with this purpose, continuously.

Tactics Belong to the Team

Then there is the actual work.

Here, too, there is leadership.

Here, too, leading means setting the direction and making the intent clear.

The decisions belong to the people on the spot. The rule is simple: decisions are made as close to the action as possible.

Moltke knew why:

The plan meets reality, and reality does not follow the plan. If you first have to ask upward, you are too late.

Moltke turned this into a way of leading that later became known as mission command, or Auftragstaktik.

The word “why” is the crucial part.

If you only know the what, you cannot sensibly deviate when the situation changes. If you know the intent, you can.

But mission command is not a blank check. It only works if there is a system in which people can make the right decisions, on their own and together. A shared rhythm, visible tasks, clear responsibilities.

In NewPDP, that system is the Drum Beat System. Without such a framework, decentralized decision-making quickly turns into decentralized chaos.

I have mentioned one principle of mission command in earlier articles, because it matters.

The Strategist Sits in Between

That leaves the level in the middle.

When people in a company say “strategy,” they usually mean a long-term plan. A five-year roadmap. A target picture with revenue figures. A list of initiatives, neatly prioritized.

That is not strategy.

The target picture is a target. The roadmap is a plan. And the list of initiatives is a list.

Every tactical move changes the situation.

A new product goes down very well with customers. Or it doesn’t. Or the product is great, but suddenly a competitor has a better one.

Someone has to ask: What does this mean for our purpose? Does this move bring us closer or take us further away? What new options have just opened up?

That is the strategist’s job.

He is the chess player who decides the next move. He recognizes what effect the last move had, and he calculates the next one.

That is why Moltke called strategy a system of expedients. Not a rigid plan, but the constant reassessment of the situation in light of the purpose.

So is strategy a job for managers only?

In the military, the answer was already no in Moltke’s day.

Strategy was developed in the General Staff. The officers there did not command troops. They analyzed the situation, played through scenarios and planned deployment and campaign. And they were assigned to the commanding generals, so that their decisions rested on a thorough assessment of the situation.

Strategic thinking was not tied to rank. It was a skill that was deliberately trained, and work that many people did.

Which brings us to the real question of this article.

Who Leads?

Peter Drucker gave the shortest definition I know:

In other words: leadership is an activity, not a position.

But if anyone can lead, why do we still need a boss?

So What Is a Boss?

If leadership is not a position, and strategy is not automatically the boss’s job, what is left for the boss?

Not just for what they do themselves. Every professional, every engineer, every expert does that. But for what others do.

Even if the boss would have done it differently. Even if the boss does not understand it in every detail.

There is a familiar sentence that sounds similar: managers are responsible for their people. That is responsibility for people. The people manager’s view.

What I mean here is something else. Responsibility for what they do, not for who they become.

My boss back then put it in a single sentence:

“Don’t worry about anything else.”

That was not an instruction. It was taking on responsibility. If this goes wrong, it’s on me.

Look closely, and every task that only the boss can do is exactly that kind of commitment:

• Setting priorities means: I am responsible for what you leave undone.

• Backing the team’s compromises means: I am responsible for decisions I did not make myself.

• Making deals with peers means: I am responsible for what my team delivers to others.

• Acting with legal authority means: I am responsible to the outside world for what happens in here.

That is why only the boss can create binding commitment for the shared result. A promise only becomes binding when someone stands behind it.

This gives us a test:

Does this task belong to the boss? Only if someone has to stand behind what others do.

Everything else the team can handle itself.

Responsibility Requires Your Own Contribution

This also settles the question of strategy. Anyone who has an overview of the situation can develop strategy.

But as soon as a strategy is put into practice, other people act on it. Hundreds of people align their work with it. Someone has to take responsibility for what they do.

That is the boss.

For the boss, deciding means taking responsibility. For a strategy that someone else may have worked out. And for the tactics the team has decided on.

But that does not mean simply taking the hits.

Only someone who contributes can take responsibility for what others do. The boss has to engage with the issues, know the situation, test the arguments and do their own part. Otherwise they are standing behind something they cannot even judge.

Not From the Ivory Tower

Strategic work sounds like a desk job. Calm, distance, overview.

Clausewitz demanded this 200 years ago:

In his day, strategy was often made in the cabinet, far away from the army. He considered that a mistake.

This applies to everyone who works strategically. CEO, head of department, project manager or system architect. At every level.

That does not mean the strategist takes over the decisions there. Whatever the team can decide, the team decides.

But sometimes the team hits a limit it cannot overcome on its own. Two requirements are mutually exclusive, and someone has to say which matters more. Another department has to come on board. A risk is too big to take without backing.

Then a decision has to be made. By the person who stands behind the shared result. And right away, not at the next steering committee meeting.

From the ivory tower, you see the situation too late, and decisions come too late. On the spot, you see it early, put it in context and make sure a decision is made when it is needed.

Management Is the Deployment

That leaves one question: what is management, if it is not leadership?

Moltke has an answer to that too. One of his sentences struck me in particular:

The assembly of the armies. The deployment. Bringing troops together, distributing forces, organizing supplies, getting the right people into the right places.

Put Kotter’s description of management next to it: planning and budgeting, organizing, staffing, controlling.

It is the same thing.

That makes the division of labor clear. Leadership says where we are going. Management positions the team so it can get there.

Moltke also explains why this matters so much.

The deployment is the only moment when the enemy is not yet interfering. Whatever can be prepared can only be prepared calmly now. That is why the Prussians planned their deployment right down to the railway timetables.

That is not pedantry. It is complexity reduction.

Everything settled in advance does not have to be decided under pressure later. What remains in execution is only the complexity that cannot be avoided. And that makes execution manageable.

That is exactly what Kotter means when he says management copes with complexity.

Development projects are no different.

Markets, competitors and new technologies bring plenty of complexity with them. Missing capacity, unclear responsibilities and prerequisites that are not in place at the start, on the other hand, are homemade. They could have been settled during the deployment.

That is the job of management. And it, too, is hard, down-to-earth work.

Management in Preparation and Execution

A running project also needs constant adjustment. Resources are shifted where a bottleneck appears. Capacity is added when the scope changes. Interfaces are clarified, suppliers are steered, prerequisites are fixed.

In the military, this is called supply. Without it, even the best deployment grinds to a halt.

So management happens twice: in preparation and in execution. Both are necessary work, and both are everyone’s responsibility.

This is also where developing people belongs: in the sense of getting everything into position.

What Management Is Not

Still, management has a bad reputation. That is down to something else.

Much of what runs under the name of management today has nothing to do with good management:

• Tracking: recording progress, coloring traffic lights, maintaining lists.

• Monitoring: checking whether everyone is doing what they should.

• Justifying: explaining why something is not finished yet.

This is often done by people with the title of manager. But it is not management.

The difference is simple:

Management creates the conditions for success. Tracking records what has not been done.

Good management needs an organization that gives it room. And that organization has to follow what is needed. Not the other way around.

What such an organization looks like is the topic of the next article.

Leadership and Management Are Not Only the Boss’s Job

But they are the boss’s job too.

They happen on three levels:

• At the level of purpose. The executive board decides what the company wants to become. And it keeps that direction stable.

• In strategic work. Whoever has an overview of the situation puts every move in the light of the purpose and shows how to proceed. With a management position or without one.

• In tactical and operational work. Team leaders, heads of department, project managers, experts and teams lead and manage when they adjust the direction during execution and respond to the realities.

The boss has one task nobody else can take on.

The boss stands behind the shared result. And can only do that by working alongside the team.

• Management makes sure the team can get there.

• Leadership makes sure everyone is heading in the same direction.

Clear direction, one team.

What Do We Take Away Today?

• Leadership is not management. Management copes with complexity, leadership sets the direction.

• Leadership happens on three levels: purpose, strategy and tactics.

• The executive board sets the purpose and keeps it stable.

• Strategy is not a plan. It is the constant reassessment of the situation on the way to the purpose.

• Leadership is an activity, not a position.

• A boss is someone who takes responsibility for what others do.

• Strategists are present where the tactics happen.

• Management creates the conditions for execution, both in preparation and while the work is underway.

And now I’m curious.

How does this work in your company? How much of what is called management there creates the conditions for success? And how much just records what has not been done?

Feel free to write it in the comments on Substack. I read every single one and I reply.

Leave a comment

And if you’re facing this transformation and don’t want to start alone, write to me about that too.

In the coming weeks I’ll move on to the next prerequisites of the NewPDP: organization and architecture.

Organization in particular is closely tied to leadership. It decides where decisions are made and who stands behind them.

If you want to follow the whole story, the best way is to subscribe to the newsletter or the podcast.

Subscribe now

Found this useful? Please share it with someone who’s dealing with the same problem.

Share

If you think a colleague would get value out of this, recommend the newsletter.

Share Uwe Mierisch

Das liegt in der Natur der Sache. Sonst wären sie nicht Entwickler geworden, sondern Controller.

Und damit ist das Spannungsfeld schon umrissen, um das es heute geht.

Innovationen haben nämlich eine Eigenschaft, die sie bei Controllern unbeliebt macht.

Und Controller lieben Geld. Sie geben es nur her, wenn sie sicher sind, dass in kurzer Zeit deutlich mehr zurückkommt. Das nennt sich dann ein positiver Business Case.

Aber, Innovationen haben noch eine zweite Eigenschaft.

Sie sind eine Wundertüte.

Was drin ist, weiß man erst, wenn man sie aufmacht und hineinschaut. Und genau dieses Hineinschauen kostet Geld.

Damit sind wir beim Kern der Sache.

Die Wundertüte wird zu spät geöffnet

Wenn Innovationen Geld kosten und Controller Geld nur für einen positiven Business Case herausrücken, bleibt genau ein Weg: Die Innovation muss in ein Projekt.

Ein Projekt hat ein definiertes Ende. Ab diesem Tag fließt Geld zurück. Es gibt einen Preis, den der Kunde vermutlich bezahlt.

Damit lässt sich ein Business Case rechnen. Passt alles, ist er positiv, und der Controller (oder der Chef) gibt das Geld frei.

Also wartet der Entwickler.

Er wartet auf das nächste passende Projekt, in das er seine Innovation einplanen kann.

Dann gibt es Geld, und es geht los.

Dumm ist nur: Erst an diesem Tag wird die Wundertüte geöffnet. Ganz langsam.

Dass es Schleifen brauchen wird, ist allen klar. Man muss lernen, unvorhergesehene Probleme lösen, Dinge ausprobieren, die beim ersten Mal nicht funktionieren. Deshalb wird von Anfang an mehr Zeit eingeplant.

Das Produkt wäre zwar früher gebraucht worden. Aber bei so einer coolen Innovation, so ist die Überzeugung, verzeiht es der Kunde schon, wenn er etwas länger darauf warten muss.

Dann kam ich mit dem NewPDP.

48 Monate für ein komplett neues Fahrzeug. Und keine Erprobungsflotte im Reifegrad B.

In der Episode zu den Learning Standard Routines habe ich beschrieben, warum ein 48-Monats-Projekt genau einen möglichen Ablauf zulässt.

Und in der Episode zu Hardware Light Development, warum die Reifegrad-B-Flotte wegfällt.

In diesem Plan ist für eine Wundertüte, die erst im Projekt geöffnet wird, kein Platz.

Kein Platz für Schleifen. Kein Platz für Überraschungen. Kein Puffer, den man vorsorglich einplant.

Für die Entwickler war die Konsequenz klar: Mit dem NewPDP würden sie nie wieder Innovationen entwickeln können.

Auch das war ein Grund, warum sie zu entschiedenen Gegnern des NewPDP wurden. Und ehrlich gesagt kann ich es ihnen nicht verdenken. Für einen Entwickler gibt es kaum eine schlimmere Vorstellung.

Also musste eine Alternative auf den Tisch.

Diese Alternative ist die Predictive Technology Readiness, kurz PTR.

Und mit ihr hatte ich nun, neben den Entwicklern, auch noch die Controller gegen mich.

Viel Feind, viel Ehr.

Ich verspreche Ihnen: Am Ende sind beide Seiten zufrieden. Es gibt Innovationen. Und es gibt eine bessere Profitabilität.

Es geht nicht um Tempo. Es geht um den richtigen Zeitpunkt.

Schauen wir noch einmal auf das Timing.

Es ist nicht intuitiv, aber Schnelligkeit ist nicht das entscheidende Kriterium für den Markterfolg.

Entscheidend ist der richtige Zeitpunkt.

Das zeigt sich gerade bei den Elektro-LKW’s. Große Stückzahlen lassen sich nur verkaufen, wenn auch die Ladeinfrastruktur da ist.

Den richtigen Zeitpunkt setzen ganz unterschiedliche Dinge:

• ein Gesetzestermin, der eingehalten werden muss

• ein Kundenbedarf, der relevant wird

• Wettbewerber, die aufgeholt oder überholt haben

• interne Zwänge zu Kostensenkung und Effizienz, die plötzlich dringlich werden

• neue Märkte oder Segmente, die reif für den Eintritt sind

• es gibt noch viel mehr Gründe

Wann diese Signale sichtbar werden, ist unterschiedlich. Eines gilt aber immer: Je näher der Zeitpunkt rückt, desto sicherer weiß man, was genau gebraucht wird.

Und hier kommt die Schnelligkeit nun doch wieder ins Spiel.

Je schneller ein Projekt realisiert werden kann, desto später kann es starten. Und desto sicherer ist man, dass man das Richtige baut.

Daraus folgt etwas Unbequemes.

Beim Projektstart muss die Wundertüte schon geöffnet sein. So weit, dass man genau sehen kann, was drin ist.

Sie braucht also ausreichende Reife.

Readiness.

Und die fällt nicht vom Himmel. Dafür braucht es einen Prozess.

Genau dieser Prozess ist die Predictive Technology Readiness.

Wo kommt das Geld her?

Halten wir kurz fest, was das bedeutet.

Die Readiness muss hergestellt sein, bevor das Projekt startet. Die Wundertüte wird also nicht mehr im Projekt geöffnet, sondern davor.

Und das Öffnen kostet Geld. Für Untersuchungen, Versuche, Berechnungen und für die Leute, die diese Arbeit machen.

Dieses Geld wird gebraucht, bevor es ein Projekt gibt.

Bevor es ein Projekt gibt.

Und damit auch, bevor es einen Business Case gibt, mit dem man es begründen könnte.

Also, woher soll es kommen?

Die Antwort wird den Controllern zunächst gar nicht gefallen.

Es gibt keinen positiven Business Case, der diese Investition rechtfertigt. Es kann ihn auch gar nicht geben, denn das Projekt, aus dem das Geld zurückfließen würde, existiert noch nicht.

Eine Entscheidung. Keine Berechnung.

Vor allem die Höhe des Budgets ist eine Entscheidung mit Konsequenzen. Wer ein hochinnovatives Unternehmen sein will, braucht ein größeres Budget als ein Unternehmen, das sich bewusst als Follower positioniert.

Die größte Hürde habe ich an anderer Stelle beobachtet.

Dieses Geld steht nicht mehr für andere Dinge zur Verfügung. Für Dinge, die durchaus einen positiven Business Case haben. Und damit die besseren Argumente.

Genau deshalb muss das PTR-Budget verteidigt werden. In jeder Budgetrunde, gegen jedes Projekt, das eine Rendite vorweisen kann.

Sonst schmilzt es weg. Nicht in einer großen Entscheidung, sondern in vielen kleinen, von denen jede für sich vernünftig klingt.

In den vielen Jahren in der Entwicklung, einige davon als Leiter einer Vorentwicklungsabteilung, wurde Geld für Innovationen immer auf dieselbe Weise genehmigt: für eine konkrete Innovation.

Daraus entstanden Vorentwicklungsprojekte. Die sind sinnvoll, und ich werde ihnen eine eigene Episode widmen.

Aber sie ersetzen nicht das Budget, das die Predictive Technology Readiness braucht.

Der Unterschied ist grundlegend:

Das ist dieselbe Umkehr, die ich bei den Learning Standard Routines vorgeschlagen habe. Erst Zeit und Geld festlegen. Dann den passenden Inhalt wählen.

Wofür wird das Geld ausgegeben?

Das heißt: alle sich entwickelnden Trends und Technologien werden beobachtet und ihre Relevanz für das eigene Geschäft wird beurteilt.

Nicht nur die Technologien, die das Produkt betreffen. Auch Produktionstechnologien. Alles, was für das Geschäft Bedeutung haben kann, gehört auf den Radar.

Im nächsten Schritt wird bewertet, welche Untersuchungen helfen, eine Technologie besser einzuordnen.

Daraus leiten sich konkrete Aktivitäten ab.

Damit steht die Liste, wofür das Geld ausgegeben werden sollte.

Und jetzt der wichtigste Satz dieses Abschnitts:

• Welche Effekte lassen sich erzielen?

• Wie kann der konkrete Nutzen aussehen?

• Welche Risiken bestehen?

• Welche Kompetenzen braucht es, und sind die vorhanden?

• Welche Kosten entstehen? Sowohl im Produkt als auch in der Entwicklung.

Diese Fragen entstehen erst während der Beschäftigung mit der Technologie und jede Antwort öffnet die Wundertüte ein Stück weiter.

Wer entscheidet?

Jetzt haben wir zwei Dinge.

Ein festes Budget und eine Liste mit Aufgaben, die Technologien auf ihr Innovationspotenzial untersuchen und für die Produktentwicklung vorbereiten.

Bleibt die Frage: Wer entscheidet, welche Aufgaben Vorrang bekommen und wann wie viel Geld wofür fließt?

Diese Entscheidung ist heikel. Weder zu viel noch zu wenig investieren. Weder zu früh noch zu spät einplanen.

Wer kann das einschätzen?

Der Controller? Der Leiter der Vorentwicklung? Der Entwicklungschef? Die Geschäftsleitung?

Keiner von ihnen allein.

Der Entwickler sieht das technische Potenzial, aber vielleicht nicht so genau den Markt. Der Vertrieb sieht den Kunden, aber kann den Reifegrad nicht einschätzen. Der Controller sieht die Kosten, aber vielleicht nicht die Chancen.

Das Team darf weder zu groß noch zu klein sein. Zu groß, und es wird zum Gremium, das diskutiert statt zu entscheiden. Zu klein, und es fehlen die Perspektiven, die eine gute Entscheidung braucht.

Hinein gehören die Sichtweisen, die den richtigen Zeitpunkt bestimmen: Vorentwicklung und Serienentwicklung, Produktmanagement und Vertrieb, Produktion.

Und das Controlling.

Ja, genau. Der Controller sitzt mit am Tisch.

Nicht als Torwächter, der einen Business Case verlangt, den es nicht geben kann. Sondern als derjenige, der darauf achtet, dass das feste Budget klug verteilt wird.

Innerhalb des Budgets entscheidet das Team eigenständig. Es muss nicht jede Aktivität einzeln genehmigen lassen. Genau dafür ist das Budget fix.

Und es entscheidet nicht einmal im Jahr, sondern im Takt des Drum Beat Systems. Neue Signale aus dem Monitoring und eine neue Erkenntnis aus den Untersuchungen fließen sofort in die nächste Entscheidung ein.

Hier arbeiten wir nach dem agilen Prinzip. Was bringt den größten kurzfristigen Erkenntnisgewinn? Was kommt von der Liste, weil es keinen signifikanten Mehrwert verspricht?

Was ist das Korrektiv?

Woran können wir erkennen, ob das Entscheiderteam eine gute Arbeit macht und richtige Entscheidungen trifft?

Das ist nicht einfach zu beurteilen, denn es gibt keine Zahlen, mit denen man das ausrechnen kann.

Darum kommt die Antwort auf diese Frage auch aus dem agilen Kontext.

Regelmäßige Retrospektiven und Lessons Learned, die ehrlich auf die geleistete Arbeit schauen. Und zwar öffentlich, nicht im geheimen Stübchen. Jeder Mitarbeiter und jeder Chef kann beobachten, wie das Team arbeitet.

Und falls es Zweifel gibt, dann hilft reden. Man darf sich einmischen, und man soll sich einmischen, denn hier geht es um die Zukunft des Unternehmens.

Es geht nicht darum, Entscheidungen zu verschleppen oder zu rechtfertigen. Es geht darum, Verantwortung für die getroffenen Entscheidungen vor den Leuten zu übernehmen, die mit den Konsequenzen leben müssen. Und das sind alle Mitarbeiter, nicht nur die Geschäftsleitung.

Klar wird sich nicht jeder Mitarbeiter in jedem Drum Beat mit dem Thema befassen. Aber es gibt auch kein meckern im Nachgang.

Warum „predictive”?

Das Wort „predictive”, also vorausschauend, steht aus gutem Grund im Namen: Wir können nicht wissen, welche Technologie sich durchsetzt.

Darum müssen wir vorausschauend tätig werden. In dem Moment, in dem eine Technologie auf dem Technologieradar auftaucht, wird sofort entschieden, was der nächste offene Klärungsbedarf ist.

Dafür muss eine Prognose erstellt werden, wo man das Potenzial der jeweiligen Technologie vermutet.

„Predictive” bedeutet nicht, die Zukunft vorzuhersagt. Es heißt, sich auf die Zukunft vorzubereiten.

Genau wie bei der prädiktiven Instandhaltung. Da wartet man auch nicht erst auf den Schaden, um ihn dann zu beheben, sondern man beugt dem Ausfall vor.

Und wenn sich eine Technologie als Sackgasse erweist? Dann fliegt sie vom Radar.

Auch das ist ein Ergebnis.

Und warum sind am Ende alle zufrieden?

Ich hatte es versprochen. Also schauen wir hin.

Der Entwickler bekommen etwas, das er im alten System nie hatte: Geld für Innovationen, ohne auf das nächste passende Projekt warten zu müssen. er öffnet die Wundertüte, wenn die Technologie interessant wird. Nicht erst, wenn ein Projekt es erlaubt.

Der Controller bekommen etwas, das er im alten System auch nie hatte: Projekte ohne Wundertüte.

Denn wenn eine Technologie ins Projekt kommt, ist sie verstanden. Keine Schleifen, die niemand geplant hat. Keine Überraschungen, die das Projekt verlängern. Keine Terminverschiebungen, die den Business Case auffressen. Und auch keine unerwarteten Mehrkosten.

Ein großer Teil dieses Geldes wurde früher übrigens auch ausgegeben. Nur an der teuersten Stelle: in Schleifen mitten im Projekt, wo jede Woche Verzug das ganze Projektteam bindet und teure Doppelarbeit verursacht.

Das Innovationsbudget ist fix und damit planbar. Die Projekte werden kürzer und damit berechenbarer. Und der Markteintritt trifft den richtigen Zeitpunkt.

Damit schließt sich der Kreis zum NewPDP.

Die Predictive Technology Readiness ist kein Nice-to-have. Sie ist die Voraussetzung dafür, dass die Learning Standard Routines und das Hardware Light Development überhaupt funktionieren.

48 Monate ohne Reifegrad-B-Flotte geht nur mit Innovationen, deren Wundertüte schon offen ist.

Was nehmen wir heute mit?

• 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. Die Innovationen werden aus dem Technologieradar ausgewählt.

• Das Korrektiv ist die Transparenz. Offene Retrospektiven, in die sich jeder einmischen darf.

• Predictive heißt vorbereiten, nicht vorhersagen. Ein billiges Nein vor dem Projekt ist besser als ein teures Nein mitten im Projekt.

• PTR ist die Voraussetzung für Learning Standard Routines und Hardware Light Development.

Und jetzt bin ich neugierig.

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 gern in die Kommentare auf Substack. Ich lese jeden einzelnen und antworte darauf.

Leave a comment

Und wenn Sie vor dieser Transformation stehen und nicht allein da durchgehen wollen, schreiben Sie mir das auch.

In den nächsten Wochen geht es mit den drei Voraussetzungen des NewPDP weiter: Führung, Organisation und Architektur. Gerade die Architektur hängt eng mit der PTR zusammen. Denn eine reif gewordene Technologie muss sich einsetzen lassen, ohne das ganze Produkt aufzumachen. Wer die ganze Geschichte mitbekommen möchte, abonniert am besten den Newsletter oder den Podcast.

Subscribe now

War das hilfreich für Sie? Dann teilen Sie es gern mit jemandem, der vor demselben Problem steht.

Share

Wenn Sie glauben, dass eine Kollegin oder ein Kollege davon profitieren würde, empfehlen Sie den Newsletter bitte weiter.

Share Uwe Mierisch

Product developers love innovation.

That’s part of the job. Otherwise, they wouldn’t have become product developers. They might have become financial controllers instead.

And that already sketches the tension this article is about.

Innovation has one property that makes it unpopular with controllers.

Controllers love money.

They only let go of it when they are certain that considerably more will come back, and soon. That is called a positive business case.

But innovation has a second property.

It is a mystery box.

You only find out what is inside when you open it and look. And the looking is exactly what costs money.

Which brings us to the heart of the matter.

The Mystery Box Gets Opened Too Late

If innovation costs money, and controllers only release money for a positive business case, there is exactly one way forward: the innovation has to go into a project.

Why? Because a project has a defined end. From that day on, money flows back. And there is an estimate of the price the customer is likely to pay.

With that, a business case can be calculated. If everything adds up, it is positive, and the controller (or the boss) releases the funds.

So the engineer waits.

He waits for the next suitable project he can plan his innovation into.

Then the money arrives, and work begins.

The trouble is this: only on that day does the mystery box get opened. Very slowly.

Everyone knows there will be loops. There is learning to do, unforeseen problems to solve, things to try that do not work the first time. So extra time is planned in from the start.

The product would have been needed sooner. But with an innovation this cool, the thinking goes, customers will forgive a little extra waiting.

Then I came along with the NewPDP.

Only 48 months for a completely new vehicle. And no prototype fleet at maturity level B.

In Learning Standard Routines I described why a 48-month project allows no loops. In Hardware Light Development, why the maturity level B fleet disappears.

In that plan, there is no room for a mystery box that only gets opened inside the project.

No room for loops. No room for surprises. No buffer planned in just in case.

For the engineers, the conclusion was obvious: with the NewPDP, they would never be able to develop innovations again.

That was one more reason they became determined opponents of the NewPDP. And honestly, I cannot blame them. For an engineer, there’s hardly a worse thought.

So an alternative had to go on the table.

That alternative is Predictive Technology Readiness, PTR for short.

And with it, I now had the controllers against me as well as the engineers.

There is an old German saying: many enemies, much honour.

I promise you this: in the end, both sides are satisfied. There is innovation. And there is better profitability.

It's Not About Speed. It's About Timing.

Let’s look at timing once more.

It may not be intuitive, but speed is not the deciding factor for market success.

What decides is the right moment.

Electric trucks show this right now. Large volumes only sell once the charging infrastructure is in place.

The right moment is set by very different things:

• a regulatory deadline that has to be met

• a customer need that becomes relevant

• competitors who have caught up or pulled ahead

• internal pressure on cost or efficiency that becomes urgent

• new markets or segments that are ready for entry

• more reasons exist

When these signals become visible varies. But one thing always holds: the closer the moment gets, the more certain you are about what exactly is needed.

And this is where speed comes back into play after all.

The faster a project can be delivered, the later it can start. And the more certain it is that you build the right thing.

That leads to something uncomfortable.

When the project starts, the mystery box must already be open. Far enough that you can see exactly what is inside.

It needs sufficient maturity.

Readiness.

Readiness does not fall from the sky. It takes a process.

And that process is Predictive Technology Readiness.

Where Does the Money Come From?

Let’s be clear about what that means.

Readiness has to be established before the project starts. The mystery box is no longer opened inside the project, but ahead of it.

And opening it costs money. For investigations, tests, calculations, and for the people who do that work.

That money is needed before there is a project.

Before there is a project.

And therefore before there is a business case that could justify it.

So where is it supposed to come from?

Controllers will not like the answer at first.

There is no positive business case that justifies this investment. There cannot be one, because the project that would pay the money back does not exist yet.

A decision. Not a calculation.

The size of the budget above all is a decision with consequences. A company that wants to be highly innovative needs a larger budget than one that deliberately positions itself as a follower.

The biggest hurdle I observed was somewhere else.

This money is no longer available for other things.

Things that do have a positive business case, and therefore the better arguments.

That is exactly why the PTR budget has to be defended. In every budget round, against every project that can show a return.

Otherwise it melts away. Not in one big decision, but in many small ones, each of them perfectly reasonable on its own.

Advanced Engineering Projects: A Step Toward Series Development

In my many years in engineering, several of them as head of an advanced engineering department, money for innovation was always approved the same way: for one specific innovation.

That produced advanced engineering projects. They make sense, and I will give them an article of their own.

But they do not replace the budget that Predictive Technology Readiness needs.

The difference is fundamental:

It is the same reversal I proposed for the Learning Standard Routines. Fix time and money first. Then choose the content to match.

For certain innovations, especially big ones, an advanced engineering project with its own funding and a fixed target can still make sense. It then serves as a step between PTR and the series project. It should not be confused with PTR. Where it is used, it comes on top.

What Is the Money Spent On?

That means watching every emerging trend and technology and judging its relevance for your own business.

Not only the technologies that affect the product. Production technologies too. Anything that could matter to the business belongs on the radar.

The next step is to assess which investigations would help to classify a technology better. Concrete activities follow from that.

And with that, the list of what the money should be spent on is in place.

Now the most important sentence of this section:

• What effects can be achieved?

• What could the concrete benefit look like?

• What risks are there?

• What competencies are needed, and do they exist?

• What will it cost? Both in the product and in development.

These questions only arise while working with the technology. Every answer opens the mystery box a little further.

Who Decides?

We now have two things. A fixed budget, and a list of tasks that examine technologies for their innovation potential and prepare them for product development.

That leaves the question: who decides which tasks get priority, and when how much money goes where?

This decision is delicate. Neither too much nor too little investment. Neither too early nor too late in the plan.

Who can judge that?

The controller? The head of advanced engineering? The head of engineering? The executive board?

None of them alone.

The engineer sees the technical potential, but not the market. Sales sees the customer, but not the maturity. The controller sees the cost, but not the opportunity.

The team must be neither too large nor too small. Too large, and it becomes a committee that debates instead of deciding. Too small, and it lacks the perspectives a good decision needs.

It should bring together the viewpoints that determine the right moment: advanced engineering and series development, product management and sales, production.

And controlling.

Yes, exactly. The controller has a seat at the table.

Not as a gatekeeper demanding a business case that cannot exist. But as the person who makes sure the fixed budget is distributed wisely.

Within the budget, the team decides on its own. It does not need approval for every single activity. That is precisely why the budget is fixed.

And it does not decide once a year. It decides in the rhythm of the Drum Beat System. New signals from monitoring and new results from investigations flow straight into the next decision.

Here we work by the agile principle.

• What delivers the biggest gain in insight in the short term?

• What comes off the list because it promises no significant added value?

What Keeps the Team Honest?

How can we tell whether the decision team is doing good work and making the right calls?

That is not easy to judge. There are no numbers to calculate it with.

So the answer to this question also comes from the agile world.

Regular retrospectives and lessons learned that take an honest look at the work done.

In public, not behind closed doors. Every employee and every manager can watch how the team works.

And if there are doubts, talking helps. You may step in, and you should step in, because this is about the company’s future.

It is not about delaying decisions or justifying them. It is about taking responsibility for decisions in front of the people who have to live with the consequences.

And that is every employee, not only the executive board.

Of course not every employee will engage with the topic in every drum beat. But there is no grumbling after the fact either.

Whoever is interested gets involved. Whoever does not get involved lives with the consequences, without complaint.

Why “Predictive”?

The word “predictive” is in the name for a good reason: we cannot know which technology will win.

That is why we have to act ahead of time.

The moment a technology shows up on the technology radar, the team decides what the next open question is. That requires a forecast of where the potential of that technology is likely to lie.

“Predictive” does not mean predicting the future. It means preparing for it.

Just like predictive maintenance. There, too, it is not about prediction the breakdown in order to fix it after the fact. It is about preventing the failure.

And if a technology turns out to be a dead end? Then it comes off the radar. That is a result too.

So Why Is Everyone Satisfied in the End?

I made a promise. So let’s look.

The engineers get something they never had in the old system: money for innovation, without waiting for the next suitable project.

They open the mystery box when the technology becomes relevant. Not when a project happens to allow it.

The controllers get something they never had in the old system either: projects without a mystery box.

Because when a technology enters a project, it is understood.

• No loops nobody planned.

• No surprises that stretch the project.

• No schedule slips, no unexpected rise in product costs, nothing that eats up the business case.

Much of this money used to be spent anyway, by the way. Just in the most expensive place: in loops in the middle of the project, where every week of delay ties up the whole project team and causes costly rework.

The PTR budget is fixed and therefore plannable.

Projects get shorter and therefore more predictable.

And market entry hits the right moment.

That closes the circle back to the NewPDP.

Predictive Technology Readiness is not a nice-to-have.

It is the prerequisite for the Learning Standard Routines and Hardware Light Development to work at all. 48 months without a maturity level B fleet only works with innovations whose mystery box is already open.

What Do We Take Away Today?

• Innovations that are only worked on inside a project make that project slow and unpredictable.

• Market success is decided by timing, not speed. Fast projects need known content.

• The innovation budget is an entrepreneurial decision, not a calculation. Its size is set by how innovative a company wants to be.

• A small cross-functional innovation team decides on its use, in rhythm. Innovations are selected from the technology radar.

• Transparency is the corrective. Open retrospectives that anyone may step into.

• Predictive means preparing, not forecasting. A cheap no before the project beats an expensive no in the middle of it.

• PTR is the prerequisite for Learning Standard Routines and Hardware Light Development.

And now I’m curious.

How are decisions about innovation money made in your company? Is there a fixed budget, or does every idea have to bring its own business case?

Feel free to write it in the comments on Substack. I read every single one and I reply.

Leave a comment

And if you’re facing this transformation and don’t want to start alone, write to me about that too.

In the coming weeks I’ll move on to the three prerequisites of the NewPDP: leadership, organization and architecture.

Architecture in particular is closely tied to PTR. A technology that has matured has to be deployable without opening up the entire product.

If you want to follow the whole story, the best way is to subscribe to the newsletter or the podcast.

Subscribe now

Found this useful? Please share it with someone who’s dealing with the same problem.

Share

If you think a colleague would get value out of this, recommend the newsletter.

Share Uwe Mierisch

Not long ago I was at the IAA trade show in Hanover and ran into many former colleagues. It was good to see people again with whom I had spent a part of my life and fought many battles side by side.

But one encounter has stayed with me ever since.

On the sidelines I overheard a conversation. A few colleagues were discussing how to organize their collaboration better and become more efficient along the way.

I knew that topic well.

About five years ago I had worked out a solution to exactly this problem.

Developed as a team, aligned with everyone affected, documented as a process and filed in the official process database. Presented to management, approved, and the first savings proven.

I would bet that this process is still valid today. By rights, people should be following it.

And yet there they were, sitting together and figuring out how it might be done.

This is not an isolated case. I have seen it again and again.

Why do processes gather dust? Why are approved ways of working ignored? And why do obvious efficiency gains get left on the table, even when they are badly needed?

I tried to get to the bottom of it with the 5 Whys.

1. Why is an approved process not followed? → Because there is no consequence when it is not applied.

2. Why is there no consequence? → Because nobody notices.

3. Why does nobody notice? → Because there is no process owner keeping an eye on it.

4. Why is there no process owner? → Because nobody makes sure the process landscape is maintained and the responsibilities are actually taken up.

5. And why does nobody make sure of that? → Because, in the end, management does not care whether the processes are followed or not.

Because processes are often seen as bureaucracy. And with bureaucracy, the rule is simple: the less, the better.

That is where the chain ends. Not with the employees, not with the tools, not with the documentation.

With management.

Without that attention, the process stays valid on paper. In practice, the wheel gets reinvented.

At great effort. And without anyone knowing the solution has existed all along.

Are processes really just bureaucracy?

Are lived processes a good thing? Or is it better if everyone simply works the way they think is right?

Tell me what you think in the comments. I have a clear position on this, but your view interests me more.

Ich weiß wovon ich spreche, ich war ja immerhin selber einer. Und die Aussage trifft auch auf die Softwareentwickler zu, mit denen ich zusammengearbeitet habe.

Den Fakt habe ich mit voller Wucht zu spüren bekommen, als ich im NewPDP Pilotprojekt keine Reifegrad B Prototypenfahrzeuge eingeplant habe.

Ich glaube, das hat mich zur unbeliebtesten Person in der gesamten LKW-Entwicklung gemacht. Und aus dem Transformationsprojekt NewPDP wurde über Nacht ein Feindbild.

Vorher war es ein Projekt, bei dem alle mitmachen wollten, um die Zukunft zu erobern. Jetzt war es das Projekt, das man auf das heftigste bekämpfte.

Und dabei kam der Widerstand kam nicht von einzelnen Bedenkenträgern. Er kam aus der Breite der Belegschaft.

Mit der Überschrift „Hardware Light Development” konnte man gut leben. Mit dem Anspruch, mehr zu berechnen, auch.

Aber die komplette Reifegrad B Prototypenflotte zu streichen, das ging zu weit.

Die Intensität der Reaktion hat mich überrascht. Im Nachhinein verstehe ich sie.

Hardware ist konkret, sie ist anfassbar und sie ist brutal ehrlich.

Was nicht funktioniert, das funktioniert nicht, was nicht da ist, das fehlt und jeder sieht es.

Sie vermittelt den Eindruck von Effizienz.

Was auf Anhieb funktioniert, da muss man keine Arbeit mehr reinstecken.

Und man muss auch nicht erst mühsam suchen, was nicht funktioniert, man bemerkt es sofort und kann sich gleich darum kümmern.

Und dann gibt es ja in der Tat Entwicklungssachverhalte, die heute noch nur empirisch funktionieren, für die es einfach noch gar keine Methode gibt, sie im Computer zu erledigen.

Aber, was ich aber überhaupt nicht auf dem Schirm hatte, war Folgendes:

Die Hardware ist ein Hygienefaktor und ein Führungsinstrument.

Einer meiner Projektleiter sagte mir:

Ich brauche die Verfügbarkeit der Prototypenflotte als Meilenstein, den einfach jeder ernst nehmen muss, weil es unmissverständlich klar ist, wer nicht geliefert hat. Ohne die Reifegrad B Prototypenliefertermine kommen die Entwickler nicht auf den Punkt.

Allerdings hat das einen Preis:

Die Beschaffung von Hardware kostet sehr viel Zeit und sehr viel Geld. Und beides sind Sachen, die nie in der Menge verfügbar sind, wie sie für so eine Vorgehensweise gebraucht würden. Schon heute nicht und in Zukunft erst recht nicht mehr.

Dass die Realisierung von Reifegrad-Entwicklungsflotten viel Geld kostet, ist unumstritten. Je früher im Projekt, desto teurer sind sie. Das ist allen bewusst.

Aber eine Sache wird oft übersehen: Viele Entwickler nutzen die Fahrzeuge für ihre Entwicklungsarbeit und sind darauf angewiesen, dass die auch funktionieren.

Es gibt aber nur eine sehr begrenzte Anzahl, eben weil sie so teuer sind. Und auf Anhieb funktionieren die nie!

Wenn die Fahrzeuge nicht funktionieren, dann pausiert die Entwicklungsarbeit, bis das letzte Problem gelöst ist.
Und wenn ein Entwickler nicht rechtzeitig mit seiner Arbeit fertig wird, dann brechen die penibel geplanten Prototypen-Verwendungspläne zusammen wie ein Kartenhaus.

Das nennt man dann gern Volatilität. War nicht vorhersehbar.

Leute, das ist nicht unvorhersehbar, das passiert mit absoluter Sicherheit immer! Das ist eine Eigenschaft dieser Vorgehensweise.

Und das Ergebnis?

Es ist nicht nur teuer und verbraucht viel Zeit.

In der Realität wird es immer noch teurer als geplant und verbraucht enorme Ressourcen, um das ungeplante und den dadurch entstehenden Mangel an Geld und Zeit zu verwalten.

Diese Ineffizienzen können wir uns zukünftig nicht mehr leisten, eigentlich heute schon nicht. Also brauchen wir eine Alternative und die möchte ich im Folgenden kurz vorstellen:

Der universelle 4 Takt Zyklus

Wer die bisher veröffentlichten Artikel gelesen hat, kennt ihn schon.

Hier in dieser Arbeitsweise hat er eine besonders zentrale Rolle.

In der klassischen Fahrzeugentwicklungs-Theorie, so wie sie vom VDA empfohlen wird, durchläuft das Produkt vier Reifegradstufen, in denen es Schritt für Schritt verfeinert wird.

Aus diesem System kommt die Reifegradnomenklatur, die ich oben benutzt habe.

Reifegrad B ist die zweite der vier Reifegradphasen (A, B, C, D), die der Verband der deutschen Automobilindustrie für die Zusammenarbeit zwischen Fahrzeughersteller und Lieferanten definiert hat. Wenn Sie darüber mehr wissen möchten, dann schreiben Sie es mir in die Kommentare. Ich habe darüber schon einen Artikel geschrieben.

Im NewPDP mache ich aus 4 Zyklen nur einen einzigen, so eine Art Supersprint.

Doch bevor ich den universellen 4 Takt Zyklus im Einzelnen beschreibe, möchte ich noch eine Voraussetzung erklären, die wirklich wichtig ist.

Virtuelle Prototypen

Nur ausgewählte Mitarbeiter verfügen über die Ausbildung, die Zugangsberechtigungen und die IT Programme, um Zugang zu den virtuellen Prototypen zu haben.

Das muss sich ändern:

Ich nenne das die Demokratisierung der virtuellen Prototypen.

Dafür gibt es zwei Gründe:

1. Nur wer die Fahrzeuge sieht und mit ihnen interagieren kann, kann sich eine Meinung bilden, kann seine Untersuchungen anstellen und kann rechtzeitig mit anderen Kollegen kooperieren und sich einbringen. Wer keinen uneingeschränkten Zugang zum virtuellen Prototypen hat, ist in seiner Wirksamkeit stark eingeschränkt.

2. Wenn alle sehen, was fehlt oder was wie geworden ist, besteht die Möglichkeit, Termindisziplin durchzusetzen und inhaltliche Reviews durchzuführen.

Dafür müssen Voraussetzungen gegeben sein. Und weil die nicht da waren, habe ich den Ärger der Entwickler zu spüren bekommen. Mit Recht muss ich heute zugeben.

Diese Demokratisierung der virtuellen Prototypen verlangt eine Struktur und eine IT Ausstattung. Auch das ist Stoff für eigene Artikel.

Aber nun gehe ich die 4 Phasen kurz durch:

Definition

Die erste Phase, die Phase der Definition, stellte in unserer Situation die größte Veränderung dar.

In der Vergangenheit lag der Schwerpunkt der ersten Projektphase darin, den Business Case genehmigt und damit Geld und Mittel freigegeben zu bekommen.

Die Arbeit an den Inhalten und Konzepten hat sich exklusiv auf diesen Zweck fokussiert.

War der Business Case genehmigt, begann sofort die Konstruktion und die Zeit bis zum Start der Hardwarebeschaffung war sehr kurz. Man wollte ja so schnell wie möglich zu Hardwareprototypen kommen.

Beim NewPDP ist der Business Case nicht das Ende der Definitionsphase, sondern ein Meilenstein mittendrin.

Als allererste Aktivität werden die virtuellen Projektfahrzeuge bereitgestellt.

Das sind unfertige Konzeptfahrzeuge.

Sie beinhalten alte Umfänge aus dem Vorgängerprodukt, die entweder als Übernahmeumfang oder als Veränderungsumfang gekennzeichnet sind. Sie beinhalten Platzhalter und Konzeptstudien.

Alle Projektmitglieder können vom ersten Tag an die Fahrzeuge sehen und den Entwicklungsstand mit eigenen Augen betrachten.

Das heißt, jeder kann sich an seinem Arbeitsplatz auf seinem ganz persönlichen Arbeitscomputer die Fahrzeuge anzeigen lassen und aus unterschiedlichen Perspektiven betrachten. Idealerweise hilft eine 3D Brille, den Eindruck so realistisch wie möglich zu gestalten, aber es geht auch ohne.

Dabei kann man nicht bei null anfangen. Die Ausgangssituation muss vollständig beschrieben sein. Dieses Thema ist definitiv einen eigenen Artikel wert.

Das Definition of Done, also das Ende der Definitionsphase, ist die vollständige Beschreibung aller Schnittstellen und Anforderungen.

Die vollständige, nicht die endgültige!

Die eigentliche Entwicklung startet ja erst, es ist normal und zu erwarten, dass sich dieser Stand mit steigendem Erkenntnisgewinn noch ändert.

Das darf aber nicht zu Nachlässigkeit führen, so nach dem Motto: Das ändert sich eh nochmal, da kann ich mir später immer noch Gedanken dazu machen.

Wenn diese Einstellung vorherrscht, dann wird das System nicht funktionieren.

Wir werden uns im Detail noch ansehen müssen, mit welchen Methoden und Werkzeugen die erforderliche Qualität erreicht werden kann.

In dieser Phase gibt es noch gar keine Hardwareprototypen und trotzdem sind alle Anforderungen und Konzepte beschrieben.

Achtung: Das bricht mit einer etablierten Einstellung:

„Erst müssen die Entwickler fertig sein und die Prototypenfahrzeuge auf dem Hof stehen, dann schau ich mir das an und überlege, wie wir sie produzieren.”

Setzen Sie für „produzieren” gern „reparieren”, „verkaufen”, „beschaffen” usw. ein.

Nein, Nein, Nein.

Alle Fachdisziplinen arbeiten gleichzeitig, und das Definition of Done gilt für alle!

Ich denke, nun ist es klar, warum die Demokratisierung der virtuellen Projektfahrzeuge so essentiell wichtig ist.

Creation

Nachdem alle Anforderungen und Schnittstellen beschrieben sind, kann nun die Lösungsfindung erfolgen.

Dabei werden Szenarien erstellt, verglichen und Lösungen ausgewählt.

Die Phase heißt Creation, hier darf jetzt die volle Kreativität der Organisation zur Wirkung kommen.

Wo notwendig dürfen Schnittstellen und Anforderungen neu verhandelt werden.

Die Zeit, Schnittstellen und Anforderungen zu verhandeln, ist nun zu Ende. Jetzt sind sie wirklich endgültig!

Theoretisch ist das neue Produkt jetzt fertig.

Um es nochmal deutlich zu sagen:

Das betrifft alles! Nicht nur das Produkt, sondern auch die Produktion, Service, Einkauf, you name it. Alle Lösungen liegen auf dem Tisch.

In dieser Phase ist Hardware erlaubt, allerdings nur in dem Maße, wie sie nach dem gegenwärtigen Stand der Technik unverzichtbar ist.

Entwicklungshardware wird dabei zweckentsprechend gebaut.

Nicht vollständige Projektprototypen, die alle Entwicklungsumfänge abbilden, sondern Entwicklungsträger, die auf den jeweiligen Entwicklungsumfang zugeschnitten sind.

Das Thema ist kontrovers, denn man versucht intuitiv durch Bündelung von Umfängen Kosten zu sparen.

Allerdings führt das auch zur Risikobündelung. Fällt ein Entwicklungsumfang aus dem Plan, werden weitere Umfänge mitgerissen.

Deshalb muss die Planung dieser Entwicklungsträger als sehr bewusster Kompromiss zwischen Kosten und Risiko erfolgen.

Wir haben sie als „Mules” bezeichnet: Fahrzeuge aus der laufenden Produktion, die in den relevanten Umfängen auf den jeweiligen Entwicklungsumfang umgebaut werden.

Auch in dieser Phase ist die Verfügbarkeit und Aktualität der virtuellen Projektfahrzeuge erfolgskritisch.

Anders als die Hardware-Mules beinhalten sie immer den kompletten neuen Entwicklungsumfang.

Alle sehen immer alles! Es ist wichtig, work in progress beobachten zu können, um bei unvorteilhaften Entwicklungsständen sofort eine Rückmeldung zu geben oder ein Gespräch suchen zu können.

Es ist einfach keine Zeit für Doppelarbeit durch zu spät erkannte Probleme.

Der anstrengende Teil ist geschafft. Nun kommt der teure.

Und genau darum ist es wichtig, dass der erreichte Entwicklungsstand eine perfekte Reife besitzt.

Diesen Zeitpunkt vergleiche ich mit dem Zeitpunkt, an dem bei einer Klassenarbeit die Stifte weggelegt und die Zettel eingesammelt werden.

Jetzt gilt es. Von nun an werden die Fehler angestrichen.

Validierung

Jetzt wird Geld ausgegeben.

Hardware wird beschafft, Prototypen werden gebaut und in Betrieb genommen.

Validierung heißt hier wirklich validieren, nicht ausprobieren, ob es funktioniert.

Die Erwartungshaltung ist, dass alles funktioniert und das geplante Validierungsprogramm „nur noch” abgespult werden muss.

Natürlich ist das nicht der Fall. Wären wir wirklich sicher, dann müssten wir den Aufwand ja nicht treiben.

Es werden Probleme entdeckt werden, die nicht vorhergesehen wurden. Die müssen nun gelöst werden, damit sie nicht im Kundeneinsatz auftreten.

Wichtig: Es werden keine weiteren Optimierungen durchgeführt. Die definierten Anforderungen bleiben das Ziel.

Keine zusätzlichen Risiken durch späte Realisierung von neuen Umfängen, die nicht mehr ordentlich validiert werden können.

Das Definition of Done ist die Freigabe, dass das neue Produkt in diesem Zustand in den Markt gebracht werden kann.

Implementierung

Während die Definitions- und die Creation Phase harte Abschlussmeilensteine haben, bei denen das Definition of Done überprüft wird, bevor die nächste Phase startet, erfolgt der Übergang von der Validierungs- zur Implementierungsphase fließend.

Es wird von hinten geplant.

Implementierungsaktivitäten werden schon gestartet, bevor die Validierung formal abgeschlossen ist.

Es gilt: Je später die Implementierungsaktivitäten gestartet werden, desto geringer ist das Risiko, dass in der Validierung noch Probleme entdeckt werden, die Konsequenzen für die Implementierungsaktivitäten haben.

Implementierung bedeutet die echte Umstellung der Produktion auf das neue Produkt, den Verkauf des neuen Produktes an die Kunden und die Ausstattung des Service- und Werkstattnetzes mit Ersatzteilen und Spezialwerkzeugen.

Das Definition of Done ist der Start der Großserienproduktion.

Zurück zur Reifegrad B Flotte

Gehen wir zurück zum Anfang.

Mein Projektleiter hatte recht. Die Flotte war für ihn nicht nur ein Erprobungsmittel, sie war ein Führungsinstrument.

Sie hat unmissverständlich gezeigt, was fehlt, und sie hat einen Termin gesetzt, den jeder ernst nehmen musste.

Wer diese Flotte streicht, streicht nicht nur Hardware. Er reduziert Transparenz bezüglich Qualität und weicht Termindisziplin auf.

Genau das habe ich getan.

Der virtuelle Prototyp kann beides übernehmen. Er zeigt jederzeit, was fehlt, und er tut es früher, häufiger und für alle gleichzeitig.

Aber nur, wenn ihn auch jeder sehen kann.

Ohne Demokratisierung der virtuelle Prototyp ist er kein Ersatz, sondern ein Werkzeug für Spezialisten. Dann bleibt die Entwicklung intransparent, bis die ersten Fahrzeuge auf dem Hof stehen.

Mein Fehler war also nicht die Entscheidung gegen die Flotte. Mein Fehler war der Zeitpunkt. Ich habe die Hardware weggenommen, bevor der Ersatz da war.

Was nehmen wir heute mit?

• Hardwareprototypen sind teuer und verlangsamen das Projekt. Darum muss ihr Einsatz auf das absolute Minimum reduziert werden.

• Virtuelle Prototypen sind die bessere Alternative. Um Hardware ersetzen zu können, müssen die virtuellen Prototypen für alle Mitarbeiter einfach zugänglich sein.

• Berechnung und Simulation im Computer ersetzen empirische Versuche. Damit das funktioniert, müssen diese Entwicklungswerkzeuge kontinuierlich weiterentwickelt und verbessert werden.

• Aus vier Reifegradzyklen wird einer. Der universelle 4 Takt Zyklus wird nur ein einziges Mal durchlaufen, dafür mit harten Definition of Done Meilensteinen.

Die vier Phasen in Kurzform:

• Definition. Alle Anforderungen und Schnittstellen werden vollständig beschrieben, von allen Fachdisziplinen gleichzeitig. Der Business Case ist dabei ein Meilenstein mittendrin, nicht das Ziel.

• Creation. Die Zeit der Lösungsfindung. Am Ende ist der komplette neue Entwicklungsstand im virtuellen Prototypen abgebildet und alle Anforderung sind erfüllt. Hardware gibt es nur als zugeschnittene Entwicklungsträger, virtuelle Prototypen sind vollständige Projektfahrzeuge.

• Validierung. Jetzt fließen große Summen ab. Die Prototypen bestätigen den fertigen Stand, sie entwickeln ihn nicht. Es wird nur repariert, was nicht funktioniert. Keine neuen Umfänge, keine Optimierungen mehr.

• Implementierung. Produktion, Verkauf und Service werden auf das neue Produkt umgestellt. Von hinten geplant und so spät wie möglich gestartet, damit Erkenntnisse aus der Validierung nichts umwerfen.

Zum Schluss

Diese Vorgehensweise verlangt etwas, das schwerer zu beschaffen ist als Prototypen. Sie verlangt Vertrauen in etwas, das man nicht anfassen kann.

Wer über Jahrzehnte gelernt hat, dass die Wahrheit auf dem Hof steht, gibt dieses Prinzip nicht auf, weil ein Transformationsprojekt es vorsieht.

Er gibt es auf, wenn der Ersatz besser ist als das Original. Früher verfügbar, jederzeit sichtbar, für alle zugänglich.

Diese Voraussetzung muss erfüllt sein, bevor die Flotte gestrichen wird. Nicht danach.

Das habe ich damals falsch herum gemacht, und ich habe den Preis dafür bezahlt.

Und jetzt bin ich neugierig.

Wie gehen Sie mit dem Verzicht auf Prototypen um?

Haben Sie generellen Zugang zu den virtuellen Prototypen, oder ist das eine Sache für Spezialisten?

Schreiben Sie es gern in die Kommentare auf Substack. Ich lese jeden einzelnen und antworte darauf.

Leave a comment

Und wenn Sie vor dieser Transformation stehen und nicht allein da durchgehen wollen, schreiben Sie mir das auch.

In den nächsten Wochen nehme ich die weiteren Elemente des NewPDP auseinander. Die vollständige Beschreibung der Ausgangssituation und die Methoden der Definitionsphase bekommen dabei eigene Folgen. Wer die ganze Geschichte mitbekommen möchte, abonniert am besten den Newsletter oder den Podcast.

Subscribe now

War das hilfreich für Sie? Dann teilen Sie es gern mit jemandem, der vor demselben Problem steht.

Share

Wenn Sie glauben, dass eine Kollegin oder ein Kollege davon profitieren würde, empfehlen Sie den Newsletter bitte weiter.

Share Uwe Mierisch

Danke fürs Zuhören. Ich freue mich schon, Sie bei der nächsten Episode wieder begrüßen zu dürfen.

Bis dahin, passen Sie auf sich auf und bleiben Sie innovativ.

I have seen this too many times, on the test rig and in the field: the test runs, the first results come in, and only then does someone sit down and decide whether that is good enough.

That is the wrong order.

When the acceptance criterion is set after the test, it is no longer the design that gets judged. It is the result already sitting in front of you.

And a result that already exists has a strange kind of pull. You want it to pass. The parts are built, the deadline is set, no time for rework. So the line slips, a little, with no bad intent anywhere in sight.

A 2 mm crack near the end of the design life, that is hardly dramatic, the part still carries the load.

Next time: 10 mm is fine too.

The time after that, the part has actually failed, but there were only 10,000 load cycles left before the end of its planned life anyway.

So where exactly is the real acceptance limit?

Nowhere. As long as you go looking for it at the rig, it keeps moving, one part at a time.

That is why I draw a line between two numbers, both fixed before the first load cycle ever runs.

The design criterion is the target the part is engineered for. For example: no crack initiation over the full design life.

The acceptance criterion is the hard line that decides pass or fail. For example: after reaching the specified number of load cycles, no crack longer than 10 mm.

Of course that 10 mm needs its own justification too, why not 5, why not 50. That justification has to be logical and traceable.

And why two targets at all? Simply because variation and tolerance are built into the world, whether we like it or not. The design criterion describes the bullseye. The acceptance criterion describes the statistical floor.

Two numbers, not one. And neither gets renegotiated once the part is already on the rig.

Truck engineers love hardware.

And that even holds for the software developers I have worked with.

I fully realized this when I was planning the NewPDP pilot project without prototype vehicles at maturity level B.

I believe it made me the most unpopular person in engineering. And overnight, the NewPDP transformation project turned into an enemy.

Before that, it had been the project everybody wanted to join, the project that would conquer the future. Now, this was the project that people fought against with all they had.

The resistance did not come from a few sceptics. It came from the broad base of the workforce.

People could live with the headline “Hardware Light Development”. They could live with the ambition to calculate and simulate more.

But cancelling the entire maturity level B prototype fleet, that went too far.

The intensity of that reaction surprised me at the time. Today I understand it.

Hardware is concrete, you can touch it, and it is brutally honest.

What does not work, does not work. What is missing, is missing. And everybody can see it.

That creates an impression of efficiency.

Whatever works right away needs no further effort.

And whatever isn’t working, you don’t have to go through the trouble of looking for it— you notice it right away and can take care of it immediately.

On top of that, there really are engineering problems that today can only be answered empirically. For some of them, no method exists yet to settle the question in a computer.

But here is what I had not considered at all:

Hardware is also a hygiene factor and a management tool.

One of my project managers put it to me like this:

I need the prototype fleet availability as a milestone that everyone simply has to take seriously, because it is unmistakably clear who has not delivered. Without the maturity level B prototype delivery dates, the engineers never get to the point.

There is a price for that, though.

Procuring hardware costs a great deal of money and a great deal of time. Neither is ever available in the quantity this way of working would require. Not today, and even less so in the future.

That maturity level fleets are expensive is undisputed. The earlier in the project, the more expensive they are. Everyone is aware of that.

But one thing is often overlooked. Many engineers use those vehicles for their own development work and depend on them being operational.

But, there are only very few of them, precisely because they are so expensive. And they never work right away.

When the vehicles do not work, development work pauses until the last problem is solved.
When one engineer does not finish on time, the meticulously planned prototype allocation plans collapse like a house of cards.

People like to call that volatility. Nobody could have seen it coming.

Let me be blunt. This is not unpredictable, it happens with absolute certainty, every single time. It is a property of this way of working.

The result?

It is not only expensive and time consuming.

In reality, it ends up costing even more than planned, and enormous resources are devoted to managing the inevitable deviations from the plan.

We will not be able to afford these inefficiencies in the future. Strictly speaking, we cannot afford them today. So we need an alternative, and that is what I want to outline now.

The Universal 4-Stroke Cycle

Anyone who has read the previous articles already knows it.

In Hardware Light Development it plays a particularly central role.

In classical vehicle development theory, as recommended by the VDA, a project goes through four stages of maturity during which the product is refined.

That system is where the maturity level nomenclature I used above comes from.

Maturity level B is the second of the four maturity phases (A, B, C, D) that the German Association of the Automotive Industry defines for the cooperation between vehicle manufacturer and supplier. If you would like to know more about that, write it in the comments.

In the NewPDP I turn those 4 cycles into a single one. A kind of super sprint.

But before I describe the universal 4-stroke cycle in detail, there is one prerequisite I need to explain, and it really matters.

Virtual prototypes

Today, virtual prototypes are an elite affair.

Only selected employees have the training, the access rights and the tools to work with them.

That has to change.

I call that the democratization of virtual prototypes.

There are two reasons for it.

1. Only someone who can see the vehicles and interact with them can form an opinion, run their own investigations, cooperate with colleagues in time and contribute. Anyone without unrestricted access to the virtual prototype is severely limited in their effectiveness.

2. When everybody can see what is missing and how things have turned out, it becomes possible to enforce schedule discipline and to run content reviews.

But certain conditions have to be in place for that. They were not, and that is why I got the anger of the engineers. Rightly so, I have to admit.

This democratization of virtual prototypes requires a structure and an IT setup. That, too, is material for its own articles.

Now let me walk through the 4 phases.

Definition

The first phase, the definition phase, was the biggest change in our situation.

In the past, the focus of the first project phase was on getting the business case approved and with it the money and the resources released.

Work on content and concepts was aimed exclusively at that purpose.

Once the business case was approved, development started immediately, and the time until the start of hardware procurement was very short. Everybody wanted to get hardware prototypes as quickly as possible.

In the NewPDP the business case is not the end of the definition phase. It is a milestone in the middle of it.

The very first activity is to provide the virtual project vehicles.

They are unfinished concept vehicles. They contain old scopes from the predecessor product, marked either as carry over or as change scope. They contain placeholders and concept studies.

From day one, every project member can see vehicles and look at the state of development with their own eyes.

That means everyone can display the vehicles at their own workplace, on their own computer, and look at them from different perspectives. Ideally a 3D headset makes the impression as realistic as possible, but it also works without one.

For that to be possible, you can’t start from scratch. The initial situation must be fully described. That topic definitely deserves an article of its own.

The definition of done, meaning the end of the definition phase, is the complete description of all interfaces and requirements.

The complete description, not the final one.

Actual development is only just starting. It is normal and to be expected that this content changes as knowledge grows.

But that must not lead to sloppiness, along the lines of: it will change anyway, so I can think about it later.

Where that attitude prevails, the system will not work.

We will have to look in detail at the methods and tools that deliver the required quality.

In this phase there are no hardware prototypes at all, and still every requirement and every concept is described.

That breaks with an established mindset:

“First the engineers have to finish and the prototype vehicles have to be standing in the yard, then I will look at it and work out how we produce them.”

Feel free to replace “produce” with “repair,” “sell,” “procure,” etc.

No. No. No.

All disciplines work at the same time, and the definition of done applies to all of them.

I think it is clear by now why the democratization of the virtual project vehicles and the system engineering tool chain are so essential.

Creation

Once all requirements and interfaces are described, the search for solutions can begin.

Scenarios are built, compared and selected.

The phase is called creation, and this is where the full creativity of the organization gets to work.

Where necessary, interfaces and requirements may be renegotiated.

The time for negotiating interfaces and requirements is now over. Now they really are final.

In theory, the new product is finished at this point.

To say it clearly once more:

This applies to everything. Not only the product, but also production, service, purchasing, you name it. Every solution is on the table.

Hardware is permitted at this stage, but only to the extent that it is indispensable according to the current state of the art.

Development hardware is built for its purpose.

Not complete project prototypes representing every development scope, but development carriers tailored to the specific scope they serve.

The topic is controversial, because the intuitive move is to bundle scopes and save cost.

But bundling scopes also bundles risk. If one development scope falls out of plan, it drags others down with it.

That is why planning these development carriers has to be a very deliberate compromise between cost and risk.

We called them “mules”. Vehicles from running production, rebuilt in the relevant areas to the new state of development.

In this phase, too, the availability of the virtual project vehicles is critical to success.

Unlike the hardware mules, they always contain the complete new development scope.

Everybody sees everything, all the time. It matters that work in progress can be observed, so that an unfavourable state of development gets immediate feedback or a conversation.

There is simply no time for rework caused by problems recognized too late.

The exhausting part is done. Now comes the expensive part.

And that is exactly why the state of development reached here has to be perfectly mature.

I compare this moment to the moment in a school exam when the pens go down and the papers are collected.

This is it. From now on, the mistakes get marked in red.

Validation

Now the money goes out.

Hardware is procured, prototypes are built and put into operation.

Validation here really means validating, not testing whether it works.

The expectation is that everything works and that the planned validation programme “only” has to be run through.

Of course that is not the case. If we were truly certain, we would not need to make the effort at all.

Problems will be discovered that nobody anticipated. They now have to be solved so they never reach the customer.

One thing is important. No further optimizations are carried out. The requirements defined earlier remain the goal.

No additional risk through late introduction of new scopes that can no longer be properly validated.

The definition of done is the release confirming that the new product can go to market in this condition.

Implementation

The definition and creation phases have hard closing milestones where the definition of done is checked before the next phase starts. The transition from validation to implementation, by contrast, is fluid.

It is planned backwards.

Implementation activities start before validation is formally complete.

So the rule is this: The later the implementation activities start, the lower the risk of discovering problems in validation that have consequences for those activities.

Implementation means the real changeover: production switching to the new product, the new product being sold to customers, and the service and workshop network being equipped with spare parts and special tools.

The definition of done is the start of volume production.

Back to the maturity level B fleet

Let’s go back to the beginning.

My project manager was right. For him the fleet was not only a means of testing, it was his management tool. It did two things no status report does. It showed unmistakably what was missing, and it set a date everyone had to take seriously.

Whoever cancels that fleet does not only cancel hardware. He cancels honesty and he cancels schedule discipline.

That is exactly what I did.

The virtual prototype can take over both. It shows at any time what is missing, and it does so earlier, more often and for everyone at once.

But only if everyone can actually see it.

Without democratization the virtual prototype is not a replacement, it is a tool for specialists. And then development stays blind until the first vehicles are standing in the yard.

So my mistake was not the decision against the fleet. My mistake was the timing. I took the hardware away before the replacement was there.

What do we take away today?

• Hardware prototypes are expensive and slow down the project. Which is why its use has to be reduced to the absolute minimum.

• Virtual prototypes are the better alternative. To replace hardware, they have to be easily accessible for every employee.

• Calculation and simulation replace empirical testing. For that to work, these engineering tools have to be developed and improved continuously.

• Four maturity cycles become one. The universal 4-stroke cycle is run through a single time, but with hard definition of done milestones.

The four phases in short:

• Definition. All requirements and interfaces are described completely, by all disciplines at the same time and without a single piece of hardware. The business case is a milestone in the middle, not the goal.

• Creation. The time for finding solutions. At the end, the complete new state of development is represented in the virtual prototype and every requirement is met. Hardware only as a tailored development carrier, never as a complete project vehicle.

• Validation. Now large sums of money are flowing out. The prototypes confirm a finished state, they do not develop it. No new scopes, no more optimization.

• Implementation. Production, sales and service switch to the new product. Planned backwards and started as late as possible, so findings from validation cannot overturn anything.

In closing

This way of working demands something that is harder to procure than prototypes. It demands trust in something you cannot touch.

Someone who has learned over decades that the truth is standing in the yard does not give up that principle because a transformation project says so.

They give it up when the replacement is better than the original. Available earlier, visible at any time, accessible to everyone.

This prerequisite must be met before the fleet is removed, not afterward.

I did it the other way round, and I paid the price for it.

And now I’m curious.

How do you handle doing without prototypes?

Do you have general access to the virtual prototypes, or is that a matter for specialists?

Feel free to write it in the comments on Substack. I read every single one and I reply.

Leave a comment

And if you’re facing this transformation and don’t want to start alone, write to me about that too.

In the coming weeks I’ll be taking apart the remaining elements of the NewPDP. The complete description of the starting situation and the methods of the definition phase will get episodes of their own. If you want to follow the whole story, the best way is to subscribe to the newsletter or the podcast.

Subscribe now

Found this useful? Please share it with someone who’s dealing with the same problem.

Share

If you think a colleague would get value out of this, recommend the newsletter.

Share Uwe Mierisch

It seems to have become fashionable: you let an AI summarize a text and save yourself the time it would take to read it.

This is celebrated as brilliant efficiency.

I see it differently.

I have a confession to make: I may not be entirely normal.

I cannot put a text aside until I feel I have truly understood it.

It is a quirk of mine and it costs me a lot of time. But it may also be the reason people have generally seen me as competent and capable.

That is why there is one thing I never do: I don’t have an AI summarize other people’s texts for me.

I do read summaries, though. I always have, long before generative AI existed.

To me, a summary is an extended table of contents. Nothing more.

It tells me what a text is about.

Then I decide:

• Is the content worth the effort of understanding it?

• Am I interested in the topic at all?

• Or is it simply not what I am looking for?

And that is exactly what I expect from the author: a summary of what the text describes. That is the author’s job, not mine.

Whether the author writes it with or without AI makes no difference to me. But I am not going to take over the author’s job.

A summary helps me decide whether to read. It cannot do the reading for me.

Not every text needs a summary, of course.

A book? Absolutely.

Meeting minutes? Definitely not. Minutes are a record of decisions. There is nothing to understand.

A blog post or a newspaper article? No need either. An experienced reader skims it first and knows whether it deserves a proper read.

Reading is learning.

Understanding happens along the way. While working through the text, stumbling, flipping back, at the point where something doesn’t add up and you start again from the beginning. While reflecting and holding it up against your own experience and conclusions.

No summary can do that for you.

And if a summary really could replace the text, why does the long text exist at all? Why would anyone take the trouble to write it?

Perhaps the author circled the topic for pages without ever getting to the point. Then the summary is questionable too, because the author was evidently never clear about it, right up to the last page.

A seasoned colleague I hold in high regard once gave me a motto, and I have made it my own:

That is why I read.

Die Zeitvorgabe kam von einer großen Management-Beratung, die dazu umfangreiche Benchmark-Untersuchungen angestellt hatte. Da war Substanz dahinter, das war keine heiße Luft.

Als ich mich in die Materie eingearbeitet hatte, kam ich zu einer Erkenntnis, die mich selbst überrascht hat.

Um ein komplett neues Fahrzeug in 48 Monaten zu entwickeln, gibt es genau eine mögliche Vorgehensweise.

Eine einzige!

Ich habe die harten Zeitspannen für Aktivitäten, die sich nicht verkürzen lassen, mit sinnvollen Zeitspannen für die flexiblen Aktivitäten kombiniert. Was dabei herauskommt, ist ein Plan, der nur in Wochen Ermessensspielraum zulässt.

Heißt das, dass jedes Entwicklungsprojekt 48 Monate dauern muss?

Natürlich nicht. Bei Funktionsupgrades, Modellpflegen und kleineren Entwicklungsumfängen sind kürzere Projekte durchaus machbar.

Aus dieser Erkenntnis heraus entstand ein grundlegender Wandel in der Vorgehensweise, wie Projekte geplant werden sollten.

1. In der Vergangenheit legten wir zuerst den Entwicklungsumfang fest.

2. Darauf basierend wurde die Vorgehensweise geplant, und Zeit und Kosten wurden bestimmt.

3. Und weil nie genug Geld oder Zeit da war, wurde an den Details herumgedoktert, bis ein scheinbar tragbarer Kompromiss herauskam, der dann beschlossen wurde.

Das Ergebnis:

Jedes Projekt war anders. Jedes Projekt war ein Unikat.

Für die Zukunft schlage ich folgende Herangehensweise vor:

Nicht der Inhalt definiert das Projekt, sondern die Zeit

Was würde passieren, wenn wir es umdrehen? Wenn wir zuerst Zeit und Geld festlegen und den Inhalt dazu passend auswählen?

Und was würde passieren, wenn dabei nicht jedes Mal ein neues Szenario entstünde, sondern wenn es standardisierte Vorlagen gäbe, die immer wieder angewendet und gezielt durch Lessons Learned verbessert würden?

Die Vorteile sind schwer von der Hand zu weisen.

• Die Fehlerwahrscheinlichkeit sinkt mit jedem Durchlauf.

• Die Liefertreu steigt mit jedem Durchlauf.

• Der realisierbare Inhalt steigt von Projekt zu Projekt an.

Warum?

• Mitarbeiter sammeln Erfahrung und wenden diese im nächsten Projekt sofort an.

• Strukturen und Muster werden sichtbar und damit verbesserbar.

• Der Zeitplan wird nicht mehr verhandelt, sondern nur noch angewendet. Schon das allein spart Zeit und setzt Ressourcen frei.

Die Revolution: standardisierte Abläufe statt Freestyle Planning

Wer an dieser Stelle denkt, ich hätte die Zeichen der Zeit nicht erkannt, den bitte ich um etwas Geduld. Ich breche nicht mit den agilen Prinzipien. Ich kombiniere sie mit klassischen Prinzipien, so dass ein hybrides System entsteht.

Schauen wir uns das ganze System einmal im Zusammenhang an.

Die Learning Standard Routines sind die zweite Arbeitsweise im NewPDP. Sie bauen auf dem Drum Beat System auf.

Lernend heißt hier nicht, dass die Routine selbst denkt. Es heißt, dass sie nach jeder Wiederholung kontinuierlich verbessert wird.

Das Motto lautet:

Das Grundprinzip besteht in einer zweigeteilten Vorgehensweise:

1. Alles, was volatil, unvorhersehbar oder unvorhergesehen ist, wird kurzzyklisch geplant und auf die konkrete Situation bezogen entschieden.

2. Alles, was stabil und wiederholbar ist, wird standardisiert, kontinuierlich verbessert und von Spezialisten erledigt.

Damit arbeiten wir bedarfsgerecht.

Wo Volatilität besteht, reagieren wir agil auf die Situation.

Wo stabile Verhältnisse herrschen, verlassen wir uns auf die lernenden Standardroutinen.

Die lernenden Standardroutinen selbst laufen auf drei Ebenen.

Die erste trägt den Philosophiewandel. Die zweite verbindet die erste und die dritte. Die dritte erzeugt den eigentlichen Nutzen und ist entscheidend für den erfolgreichen Einsatz von KI.

Ebene 1: Projekt- und ITEM-Templates

Hier komme ich auf den 48-Monats-Plan zurück.

Denn wenn es für einen bestimmten Entwicklungsablauf in einem vorbestimmten Zeitraum nur eine sinnvolle Vorgehensweise gibt, dann kann man sie aufschreiben und jedes Mal wieder anwenden.

Ist der Umfang kleiner, geht es schneller. Auch das kann man aufschreiben.

Ich habe deshalb vorgeschlagen, neben dem 48-Monats-Template auch eines für 36, für 24 und für 12 Monate zu erstellen.

Sind das alle?

Das weiß ich nicht. Ich überlasse es dem lernenden System, das herauszufinden. Wichtig ist nicht die Anzahl. Wichtig ist, diese Vorgehensweisen immer wieder anzuwenden und gezielt weiterzuentwickeln.

In der Konsequenz entsteht ein Katalog an Projekttemplates, aus dem jeweils das passende ausgewählt wird.

In diesen Templates ist dabei nicht, wie in unseren heutigen Masterplänen, alles bis ins letzte Detail vorgeschrieben.

Sie folgen dem Grundsatz, den ich schon beim Drum Beat System angewendet und interpretiert habe. Er stammt von Helmuth von Moltke:

„Ein Befehl soll alles enthalten, was der Untergebene zur selbständigen Erreichung eines Zieles wissen muss, und nichts weiter.”

Übertragen auf unsere Arbeit liest er sich so:

Die Feinplanung passiert dort, wo sie hingehört: situationsabhängig, im Rhythmus von Drum Beat und ToDo.

Ebene 2: standardisierte Prozesse

Diese Ebene geht tiefer.

Hier werden standardisierbare Prozesse aus den Projekt- und ITEM-Templates herausgelöst und eigenständig gepflegt.

Es gibt immer Abläufe, die sich standardisieren lassen.

• Wie die Beschaffung von Prototypenteilen abläuft.

• Wie ein konkreter Test durchgeführt wird.

• Wie eine FMEA gemacht wird.

• Wie das Kostencontrolling arbeitet.

Die Liste ist lang, und sie ist unspektakulär. Nichts davon gewinnt einen Innovationspreis.

Aber genau darum geht es. Keine unnötigen Risiken eingehen und keine unnötige Komplexität schaffen!

An dieser Stelle kommt berechtigterweise der Einwand: Das machen wir doch schon lange so.

Zum Teil stimmt das. Der Unterschied liegt im Detail.
Viele Prozesse sind heute schon dokumentiert und zur Anwendung verpflichtend vorgeschrieben.

Werden sie aber auch als Standard konsequent angewandt und weiterentwickelt?

Wenn ja, dann ist alles gut.

Wenn nicht, was ich häufig beobachte, dann müssen wir uns darum kümmern.

Das passiert nicht, weil die Leute den Chef ärgern wollen. Es gibt Ursachen, die analysiert und beseitigt werden müssen.

Erst wenn ein Ablauf beschrieben und als Standard konsequent implementiert ist, treten die Effekte zutage, die wir brauchen, um mehr zu entwickeln, ohne mehr zu brauchen. So wie es das Motto des NewPDP ja aussagt.

Woher weiß man nun, was auf diese Ebene gehört und was nicht?

Ein Ablauf gehört in die Standardroutinen, wenn zwei Kriterien zutreffen:

1. Er tritt wiederholt auf.

2. Sein Umfeld ist stabil genug, dass Flexibilität in der Vorgehensweise keinen Nutzen bringt.

Fehlt eine der beiden Bedingungen, gehört er ins Drum Beat System und wird pro Drum Beat flexibel geplant.

Das ist die Grenzlinie zum Agilen.

Agil standardisiert den Meta-Prozess und lässt den Fachprozess bewusst offen.

Der Standard steht der Verbesserung dabei nicht im Weg. Bei Toyota heißt es:

Ohne Standard kein KVP.

Ohne Bezugspunkt lässt sich gar nicht messen, ob etwas besser geworden ist.

Bitte nicht verwechseln: Standardroutine heißt nicht ein für allemal festgelegt. Es heißt, dass der aktuelle Standard verbindlich angewandt wird. Aber dieser Standard unterliegt einer Evolution durch kontinuierliche Verbesserung.

Und diese Verbesserung erfolgt durch diejenigen, die mit ihm arbeiten, denn nur sie wissen, wo Verbesserungspotentiale bestehen.

Ebene 3: zugeordnete Experten

Idealerweise gebündelt in eigenen Organisationseinheiten.

Das ist die ultimative Form einer sich selbst verbessernden Standardroutine.

Ich vergleiche es mit Sportlern, die in einer Disziplin trainieren und Wettkämpfe bestreiten. Von einem Allrounder sind sie nicht zu schlagen.

Und hier komme ich zu einem Punkt, der mir wichtig ist.

Diese Ebene macht eine Fehlentwicklung rückgängig, die ich seit Jahren beobachte.

Expertengruppen werden abgebaut, um Personal zu sparen.

• Der Prototypeneinkauf wird aufgelöst.

• Die Planungsexpertengruppe gibt es nicht mehr.

• Das Projektmanagementoffice muss seinen Mehrwert in Euros ausrechnen, und weil das nicht gelingt, wird es abgeschafft.

• Die Leute, die das Kostencontrolling gemacht haben, sind weg oder machen inzwischen etwas anderes.

Und dann?

Dann macht die Arbeit derjenige selbst, der das Ergebnis braucht.

Was dabei übersehen wird, ist denkbar einfach:

Die Stelle ist weg. Die Arbeit ist es nicht.

Sie ist nur nicht mehr sichtbar.

Sie sitzt jetzt, zum Beispiel beim gut bezahlten Entwickler, der zum ersten Mal seit anderthalb Jahren wieder ein Prototypenteil beschafft. Er kennt den Ablauf nicht mehr. Er sucht das Formular. Er ruft drei Leute an. Er wählt den falschen Lieferanten und merkt es erst Wochen später, wenn der Lieferant seine Termine nicht einhält.

Er ist kein schlechter Mitarbeiter. Er ist auf diesem Gebiet Laie.

Laien brauchen länger und machen mehr Fehler. Das ist keine Kritik an einer Person. Das ist eine Konsequenz von fehlender Erfahrung.

Kosten wurden scheinbar gesenkt, die Einsparung steht im Stellenplan. Sie ist eine Zahl, die berichtet werden kann.

Der Mehraufwand steht nirgends. Er verteilt sich in Stunden und halben Tagen auf hunderte Leute und taucht in keinem Budget auf.

Nirgends.

Nur reicht auf merkwürdige Weise das geplante Projektbudget nie aus, und Termine sind auch mehr Empfehlung als Fakt.

Deshalb sieht diese Maßnahme auf dem Papier immer gut aus. Und deshalb laufen Projekte so holprig.

Die dritte Ebene dreht das um. Sie holt die Arbeit dorthin zurück, wo sie effizient erledigt wird, und macht sie damit auch wieder sichtbar.

Das ist keine neue Idee. Es ist die Rücknahme einer alten Fehlentscheidung.

Ein Einwand kommt an dieser Stelle allerdings häufig: Was passiert, wenn gerade nicht genug Arbeit da ist, um die Leute auszulasten?

Kein Problem, dann helfen sie woanders aus! Sie sind und bleiben Teil des Teams, aber sie haben eine klar definierte Priorität. Für sie hat ihr Expertengeschäft Vorrang vor anderen Aufgaben.

Keine der beiden Hälften funktioniert allein.

Und die KI?

Das war bis hierher alles recht yesterday.

Das hätte man eigentlich schon lange so machen können. Man braucht dafür keine Technologierevolution.

Und trotzdem spielt die KI eine ganz entscheidende Rolle, wenn wir das volle Potential freisetzen wollen.

Also, wie kann uns künstliche Intelligenz dabei helfen?

Eigentlich ist es andersherum.

Nicht die KI hilft den lernenden Standardroutinen.

Die lernenden Standardroutinen schaffen die Voraussetzung dafür, dass eine KI so etwas eines Tages allein übernehmen kann.

Wenn es einmal so weit ist, dann sind wir in der nächsten Ära von Produktentwicklung angekommen.

Aber noch stecken wir mitten in der Transformation, und da hilft uns Standardisierung bei der Automatisierung und Virtualisierung.

Ich sehe zwei Schwerpunkte der KI-Anwendung, die schon heute erhebliche Effizienzen ermöglichen.

Der KI-Assistent

Stellen Sie sich vor, Sie fragen Ihren KI-Assistenten:

Welches Template passt für diesen Fall am besten?
Welche Entwicklungsumfänge passen dazu?

Gibt es einen Standardprozess, den wir anwenden müssen? Und wie sieht er aus?

Das heutige Problem, dass niemand mehr durch die Vielzahl an Plänen und Prozessen durchsieht und die Mühe des Suchens scheut, ist damit erledigt.

Eine Ursache dafür, dass dokumentierte Prozesse heute manchmal nicht befolgt werden, liegt darin, dass es einfacher ist, irgendwas zu machen, als sich mühsam die definierte Vorgehensweise herauszusuchen, zu verstehen und zu lernen. Wenn dem so ist, dann machen die Leute eben auch das Einfachere.

Und man kann es noch nicht mal jemandem übel nehmen, denn wir wollen ja schnell sein.

Der KI-Assistent macht es einfacher, die Standardroutinen anzuwenden und damit die positiven Effekte zu realisieren.

Ohne die Standardroutinen würde dem KI Assistenten die Datenbasis fehlen, um diese wertvolle Unterstützung leisten zu können.

Und das Lernen funktioniert genauso.

Fragen wir die KI:

Wo hat es dieses Mal geklemmt, und wie könnte es künftig besser gehen?

Ob die Antwort sofort sitzt oder noch nachgeschärft werden muss, ist zweitrangig. Wir kommen schneller zu einem Ergebnis als vor einem leeren Blatt.

Das ist der eigentliche Hebel. Lessons Learned scheitern selten am Willen. Sie scheitern daran, dass am Projektende niemand mehr Zeit investiert.

Der KI-Agent

Ein Ablauf, der als Standard dokumentiert ist, immer gleich abläuft und einer festen Gruppe gehört, erfüllt genau die Bedingungen, unter denen ein KI-Agent ihn ausführen kann.

Es ist realistisch, dass wir Routinen finden, die ein KI-Agent vollständig übernehmen kann.

Wer es umgekehrt versucht, automatisiert das Chaos.

Was nehmen wir heute mit?

Hinter den drei Ebenen stehen zwei Wirkprinzipien.

Standardisierung ermöglicht Verbesserung. Ohne Standard kein KVP. Was jedes Mal neu erfunden wird, wird nicht besser. Es wird nur anders.

Fokus schafft Professionalität. Wer dieselbe Aufgabe immer wieder erledigt, wird darin unschlagbar. Daraus entstehen Qualität und Effizienz.

Die drei Ebenen setzen diese beiden Prinzipien um.

• Ebene 1, die Templates. Nicht der Inhalt definiert das Projekt, sondern die Zeit. ITEM-Templates dienen als Blaupause, welche mit passenden Inhalten gefüllt werden. Ein Template ist dabei ein Gerippe, kein Masterplan. Auf dieser Ebene wird der Projektablauf selbst wiederholbar und damit verbesserbar.

• Ebene 2, die standardisierten Prozesse. Ein standardisierter Ablauf wird definiert und angewandt, wenn er sich wiederholt und sein Umfeld stabil ist. Der dokumentierte Standard ist nicht das Ziel an sich. Ziel sind Effizienz und messbare Verbesserung.

• Ebene 3, die zugeordneten Experten. Hier entsteht die Verbesserung wirklich, denn sie entsteht in Köpfen. Die dauerhafte Zuordnung derselben Gruppe zu derselben Aufgabe erzeugt sie. Das Prozessdokument sichert sie ab.

Lernende Standardroutinen sind die Basis für die wirkungsvolle Nutzung von KI.

KI-Assistenten unterstützen dabei, die Effekte der Standardroutinen zu optimieren.
KI-Agenten können Expertenarbeit übernehmen, wenn sie gründlich strukturiert und dokumentiert ist.

Zum Schluss

Es braucht viel Hartnäckigkeit, die lernenden Standardroutinen im Tagesgeschäft zu implementieren.

Es ist nicht neu und doch unbequem. Es ist nicht innovativ, aber es braucht eiserne Disziplin.

Das sind Eigenschaften, die eine Implementierung extrem schwierig machen.
Menschen sind für Neues leichter zu begeistern als für vermeintlich Triviales, und Disziplin ist eh nicht sehr populär. Der Drang nach Selbstbestimmtheit und Individualismus prägt unsere Zeit, und genau das scheinen die lernenden Standardroutinen nicht zu verkörpern.

Aber das ändert nichts an der Tatsache, dass sie, richtig eingesetzt, für den zukünftigen Erfolg unverzichtbar sein werden.

KI hat keinen Anspruch auf Selbstbestimmtheit und Individualismus, ganz im Gegenteil, sie braucht Daten und Muster, um arbeiten zu können.

Also werden wir uns durch diese Transformation arbeiten müssen. Schritt für Schritt, bis die KI uns alle lernenden Standardroutinen abgenommen hat.

Was uns dann bleibt, ist das Volatile und Unvorhersehbare, das, worauf die KI auf absehbare Zeit auch keine Antworten bieten kann. Genau da kommen Selbstbestimmtheit und Individualismus erst richtig zur Geltung.

Und ich glaube fest daran, dass da viel weniger übrig bleibt, als wir heute noch glauben.

Also fangen wir an und schauen, wohin uns die Reise führt.

Und jetzt bin ich neugierig.

Werden bei Ihnen lernende Standardroutinen konsequent angewandt?
Haben Sie Expertengruppen für Standardprozesse, und wenn ja, welche Erfahrung haben Sie mit ihnen gemacht?

Schreiben Sie es gern in die Kommentare auf Substack. Ich lese jeden einzelnen und antworte darauf.

Leave a comment

Und wenn Sie vor dieser Transformation stehen und nicht allein da durchgehen wollen, schreiben Sie mir das auch.

In den nächsten Wochen nehme ich die weiteren Elemente des NewPDP auseinander. Wer die ganze Geschichte mitbekommen möchte, abonniert am besten den Newsletter oder den Podcast.

Subscribe now

War das hilfreich für Sie? Dann teilen Sie es gern mit jemandem, der vor demselben Problem steht.

Share

Wenn Sie glauben, dass eine Kollegin oder ein Kollege davon profitieren würde, empfehlen Sie den Newsletter bitte weiter.

Share Uwe Mierisch

Danke fürs Zuhören. Ich freue mich schon, Sie bei der nächsten Episode wieder begrüßen zu dürfen. Bis dahin, passen Sie auf sich auf und bleiben Sie innovativ.

For years, crisis was the normal condition.

Almost every project drifted so far off course that failure looked unavoidable. Quality gates turned red. Open issues kept climbing while the time left kept shrinking, until the project was no longer under control.

And then, somewhere near the end, the team pulled it around. People were freed up to work on the problem in front of them. Compromises were agreed that had been impossible for months. Everyone met daily and delivered what they had promised. And a good vehicle reached the market after all, at the very last minute.

Every time there was relief. Every time a huge pride. People were recognized as heroes, and treated like heroes. We had done it again.

But the celebration was short, because the next crisis was already there.

Subscribe now

At some point I started asking myself an uncomfortable question. Was that our core competence? Running a project into the wall, and then, with a heroic performance in the final minutes, pulling the iron out of the fire?

Because a rescue that works every time is only a rescue until the one time it does not. A vehicle manufacturer without a product survives a few weeks. Then it is over.

The longer I thought about it, the clearer the picture became. The organization could do it. The capability was there, all of it, and it was impressive. It simply would not come out until the crisis had arrived. Pressure was the trigger, and nothing else worked as reliably.

So the task was not to build something we lacked. It was to move that performance from the end of the project to the front. And not by moving the crisis forward with it, which is the easy misreading of the solution. The point was to make the crisis unnecessary in the first place.

That turned out to be the harder half of the work, and it had nothing glamorous about it. Focus. Collaboration. Compromise. The same ingredients as in the rescue, only as a daily habit and a working structure instead of an emergency reflex. Nothing on that list is new. Nothing on it is difficult to understand.

It is a leadership matter. An organization repeats what it sees rewarded, and what gets rewarded is usually the rescue. A team that is quietly on track in the middle of a project deserves the recognition that goes to the heroes at the end. Leadership also owes its own share: the prerequisites, the structure, and the decisions taken when they are due. Management always had its part in how those projects ended up.

What is coming now is not smaller than any of that. Artificial intelligence, virtual development, technological complexity that no longer settles back down: these will change the work more deeply than anything I have seen in my career, and they are arriving with full force. Nobody gets to sit them out.

And that is exactly what makes them such a comfortable excuse.

If everything is going to be different anyway, why repair a process that will be obsolete in a few years? Why insist on human performance when the technology is going to take it over regardless? The transformation offers a respectable reason to leave the old mess where it is. It sounds forward looking. It even sounds ambitious.

But a new technology laid on top of a broken process does not repair the process. It industrializes it. Whatever was disorganized before comes back faster, at scale, and harder to control.

I doubt I was alone with this. I see it in many places across the industry: organizations that are not as good as they would need to be at the ordinary craft, and that now have a transformation to manage on top of it. Both jobs at once, with the same people.

So it is not a choice between the two. Cleaning up is not the sober alternative to transforming, and transforming is not permission to skip the cleaning up.

We have to do both. Either one on its own will not be enough to still be here.

The assignment I was given was clear and precise:

That timeframe came from a major management consultancy that had done extensive benchmarking to back it up. There was substance behind it. It wasn’t hot air.

Once I had worked my way into the subject, I arrived at a realization that surprised me.

To develop a completely new vehicle in 48 months, there is exactly one possible approach.

Exactly one.

I combined the hard, non-negotiable durations of activities that cannot be shortened with sensible durations for the flexible activities. What comes out is a plan that leaves room for judgment only in weeks.

Does that mean every development project has to take 48 months?

Of course not. For feature upgrades, facelifts, and smaller development scopes, shorter projects are entirely feasible.

That realization led to a fundamental shift in how projects should be planned.

1. In the past, we fixed the development scope first.

2. The approach was planned on that basis, and time and cost were derived from it.

3. Because there was never enough money or time, we fiddled with the details until we came up with a compromise that seemed workable, and that compromise was approved.

The result:

Every project was different. Every project was a one-off.

For the future, I propose the following approach:

Time Defines the Project, Not the Content

What would happen if we turned it around?

If we fixed time and money first, and chose the content to match?

And what would happen if that didn’t produce a new scenario every time, but standardized templates that get applied again and again and deliberately improved through lessons learned?

The advantages are hard to dismiss.

• The probability of error drops with every cycle

• Delivery reliability rises with every cycle

• The content that can realistically be delivered increases from project to project

Why?

• Employees gain experience and apply it immediately in the next project.

• Structures and patterns become visible, and therefore improvable.

• The shedule is no longer negotiated, only applied. That saves time and frees up resources in itself.

The Revolution: Standardized Processes Instead of Freestyle Planning

If you think at this point that I have missed the signs of the times, I ask for a little patience. I am not breaking with agile principles. I am combining them with classical principles, so that a hybrid system emerges.

Let’s look at the whole system in context.

The Learning Standard Routines are the second working method in the NewPDP. They build on the Drum Beat System.

The motto is:

The basic principle rests on a two-part approach:

1. Everything that is volatile, unpredictable, or unforeseen is planned in short cycles and decided on the concrete situation at hand.

2. Everything that is stable and repeatable is standardized, continuously improved, and handled by assigned experts.

That way we work according to what the situation actually needs.

Where volatility exists, we respond to it with agility.

Where conditions are stable, we rely on LSR — Learning Standard Routines.

LSR itself operates on three levels. The first carries the change in philosophy. The second bridges the first and the third. The third creates the ultimate benefits and is decisive for the successful use of AI.

Level 1: Project and ITEM Templates

Here I come back to the 48-month plan.

Because if there is only one sensible approach for a given development process within a given timeframe, then it can be written down and applied again every time.

If the scope is smaller, it goes faster. That, too, can be written down.

I therefore proposed creating templates not only for 48 months, but also for 36, 24, and 12 months.

Is that all of them?

I don’t know. I leave it to the learning system to find out. What matters is not the number. What matters is applying these approaches again and again and deliberately developing them further.

The result is a catalog of project templates, from which the right one is selected each time.

Unlike our master plans today, these templates do not prescribe everything down to the last detail.

They follow the same principle I already applied and interpreted for the Drum Beat System. It comes from Helmuth von Moltke:

“An order should contain everything a subordinate needs to know in order to independently achieve an objective, and nothing more.”

Applied to our work, it reads like this:

The detailed planning happens where it belongs: depending on the situation, in the rhythm of the Drum Beat and the ToDo.

Level 2: Standardized Processes

The next level goes deeper.

Here, processes that can be standardized are taken out of the project and ITEM templates and maintained on their own.

There are always processes that can be standardized.

• How the procurement of prototype parts works.

• How a specific test is carried out.

• How an FMEA is done.

• How cost controlling operates.

The list is long, and it is unspectacular. None of it wins an innovation award.

But that is exactly the point. Take no unnecessary risks, and create no unnecessary complexity.

At this point comes the justified objection: we’ve been doing this for a long time already.

That’s partly true. The difference is in the detail.
Many processes are already documented today and mandated for use.

But are they also consistently applied and developed further as a standard?

If so, all is well.

If not, which is what I observe frequently, then we need to deal with it.

That doesn’t happen because people want to annoy the boss. There are causes, and they need to be analyzed and removed.

Only once a process is described and consistently implemented as a standard do the effects appear that we need to develop more without needing more, exactly as the motto of the NewPDP states.

So how do you know what belongs on this level and what doesn’t?

A process belongs in the standard routines if two criteria are met:

1. It occurs repeatedly.

2. Its environment is stable enough that flexibility in the approach brings no benefit.

If either condition is missing, it belongs in the Drum Beat System and is planned flexibly with each Drum Beat.

That is the dividing line to agile.

Agile standardizes the meta-process and deliberately leaves the technical process open.

The standard doesn’t stand in the way of improvement. At Toyota they put it this way:

No standard, no continuous improvement.

Without a reference point, there is no way to measure whether something has gotten better.

Please don’t confuse this: a standard routine does not mean fixed once and for all. It means that the current standard is applied consistently. But that standard keeps evolving through continuous improvement.

And that improvement comes from the people who work with it, because only they know where the potential for improvement lies.

Level 3: Assigned Experts

Ideally bundled in their own organizational units.

That is the ultimate form of a learning standard routine.

Through constant repetition, these employees become unbeatably efficient in their field.

I compare it to athletes who train in a single discipline and compete in it. An all-rounder cannot beat them.

And here I come to a point that matters to me.

This level reverses a wrong turn I have observed for years.

Expert groups are cut to save headcount.

• Prototype procurement is dissolved.

• The planning expert group no longer exists.

• The project management office has to calculate its added value in euros, and because that doesn’t work out, it gets abolished.

• The people who did cost controlling are gone, or doing something else by now.

And then?

Then the work gets done by whoever needs the result.

What gets overlooked here is as simple as it gets:

The position is gone. The work is not.

It has just become invisible.

It now sits, for example, with the well-paid engineer procuring a prototype part for the first time in a year and a half. He no longer knows the process. He hunts for the form. He calls three people. He picks the wrong supplier and only notices weeks later, when the supplier misses its dates.

He is not a bad employee. He is simply a layman in this field.

Laymen take longer and make more mistakes. That is not a criticism of a person. It is a consequence of missing experience.

Costs appear to have gone down. The saving shows up in the headcount plan. It’s a number that can be reported.

The extra effort shows up nowhere. It’s spread in hours and half days across hundreds of people, and it never appears in any budget.

Nowhere.

And yet, strangely enough, the planned project budget is never quite enough, and deadlines turn out to be more of a suggestion than a fact.

That’s why this kind of measure always looks good on paper. And that’s why projects run so bumpily.

The third level reverses that. It brings the work back to where it gets done efficiently, and in doing so makes it visible again.

This is not a new idea. It is the reversal of an old wrong decision.

But one objection comes up often at this point: what happens when there isn’t enough work to keep the people fully utilized?

No problem, then they help out elsewhere. They are and remain part of the team, but they have a clearly defined priority. For them, their area of expertise has priority over other tasks.

Neither half works alone.

And AI?

Everything up to this point has been fairly yesterday’s news.

This could have been done this way for a long time already. It doesn’t take a technology revolution.

And yet AI plays a genuinely decisive role if we want to unlock the full potential.

So how can artificial intelligence help us here?

Actually, it’s the other way around.

AI doesn’t help the learning standard routines.

The learning standard routines create the precondition for AI to take something like this over entirely, one day.

Once we get there, we will have arrived at the next era of product development.

But for now we are still in the middle of the transformation, and standardization is what helps us with automation and virtualization.

I see two focus areas for applying AI that already enable substantial efficiencies today.

The AI Assistant

Imagine asking your AI assistant:

Which template fits this case best?
Which development scopes go with it?

Is there a standard process we need to apply? And what does it look like?

That solves today’s problem, where nobody can see through the sheer number of plans anymore and shies away from the effort of searching.

One reason documented processes sometimes go unfollowed today is that it’s easier to just do something than to painstakingly dig out the defined approach, understand it, and learn it. When that’s the case, people simply do the easier thing.

And you can’t even hold it against anyone, because we all want to be fast.

The AI assistant makes it easier to apply the standard routines and thereby realize their positive effects.

Without the standard routines, though, the AI assistant would lack the data base needed to provide that valuable support.

And learning works the same way.

Ask the AI:

Where did it get stuck this time, and how could it go better in the future?

Whether the answer is right immediately or still needs sharpening is secondary. We get to a result faster than starting from a blank page.

That’s the real lever. Lessons learned rarely fail for lack of will. They fail because, by the end of a project, nobody has time left to invest.

The AI Agent

A process that is documented as a standard, always runs the same way, and belongs to a fixed group, meets exactly the conditions under which an AI agent can execute it.

It’s realistic that we will find routines an AI agent can take over completely.

Whoever tries it the other way around ends up automating chaos.

What Do We Take Away Today?

Behind the three levels stand two operating principles.

Repetition enables improvement. No standard, no continuous improvement. Whatever gets reinvented every time doesn’t get better. It just gets different.

Focus builds mastery. Whoever does the same task over and over becomes unbeatable at it. Quality and efficiency follow from that.

The three levels put these two principles into practice.

• Level 1, the templates. Time defines the project, not the content. ITEM templates serve as a blueprint that gets filled with the matching content. A template is a skeleton, not a master plan. On this level, the project process itself becomes repeatable, and therefore improvable.

• Level 2, the standardized processes. A standardized process is defined and applied when it repeats and its environment is stable. The documented standard is not the goal in itself. The goal is efficiency and measurable improvement.

• Level 3, the assigned experts. This is where the improvement actually happens, because it happens in people’s heads. The lasting assignment of the same group to the same task creates it. The process document secures it.

Learning standard routines are the basis for using AI effectively.

AI assistants help optimize the effects of the standard routines.

AI agents can take over expert work once it is thoroughly structured and documented.

In Closing

It takes real courage to implement learning standard routines in day-to-day business.

It isn’t new, and yet it feels uncomfortable. It isn’t innovative, but it takes iron discipline.

Those are the qualities that make implementation extremely difficult.

People are easier to excite about something new than about what seems trivial, and discipline was never very popular to begin with.

Our era is shaped by the drive toward self-determination and individualism, and learning standard routines don’t seem to embody either.

But that changes nothing about the fact that, used correctly, they will be indispensable for future success.

AI has no claim to self-determination or individualism. Quite the opposite. It needs data and patterns in order to work at all.

So we’ll have to work through this transformation. Step by step, until AI has taken all the learning standard routines off our hands.

What’s left for us then is the volatile and the unpredictable, the things AI won’t be able to answer for the foreseeable future. That’s where self-determination and individualism come into their own.

And I firmly believe that what’s left will be far less than we still think today.

So let’s get started and see where the journey takes us.

And now I’m curious.

Are learning standard routines applied consistently where you work?

Do you have expert groups for standard processes, and if so, what has your experience with them been?

Feel free to write it in the comments on Substack. I read every single one and I reply.

Leave a comment

And if you’re facing this transformation and don’t want to start alone, write to me about that too.

In the coming weeks I’ll be taking apart the remaining elements of the NewPDP. If you want to follow the whole story, the best way is to subscribe to the newsletter or the podcast.

Subscribe now

Found this useful? Pleasw share it with someone who's dealing with the same problem.

Share

If you think a colleague would get value out of this, recommend the newsletter.

Share Uwe Mierisch

Thanks for listening. I’m already looking forward to welcoming you back for the next episode. Until then, take care of yourself and stay innovative.

I have witnessed two major turning points in product development, and we are right in the middle of the second one now.

Subscribe now

I started my career at the drawing board. With pencil and ink on tracing paper, watching older engineers do something I couldn’t yet understand. On the tracing paper appeared three side views, an isometric projection, a few cross-sections, all a single sheet could hold. Where I saw lines I had to piece together one by one, they saw a finished part. They could turn it over in their minds, tilt it, cut it open in a place that wasn’t even drawn, and still know exactly what would be there.

What impressed me even more happened one afternoon when a colleague placed his pencil at the junction with a rib, tapped the paper twice, and said, “It tears there.” No calculation. No proof. He had simply seen it. People called that experience, but it was really a very specific skill, built over years at that exact board, through that exact way of working.

Then the computer replaced the drawing board, and both of those skills, the eye for shape and the eye for stress, were no longer needed. Cross-sections could now be generated inside a 3D model in seconds, and the part could be turned and looked at from any side right there on the screen, instead of being pieced together in your head. Calculation software showed exactly where it would break. What once took a trained eye now took a few clicks. Because they were no longer practiced, those old skills faded away over time, the way a muscle that is no longer used slowly loses its strength. They are nice things to still have, but by now you can get along perfectly well without them.

Something else took its place instead. The new tools did not just do the old work faster, they made things possible that the drawing board never could have handled, and products picked up more features than before, first mechanical, then electrical, then electronic, then networked. Every new feature began interacting with all the others, and a different kind of challenge emerged: understanding what a change would trigger in the whole system, not just in the part itself. Today’s experienced engineer looks at a change request and says, “That conflicts with the heavy-duty version,” with the same certainty my old colleague once tapped his pencil on the tracing paper. No analysis. No proof. He has seen it.

Now the second turning point is underway. Artificial intelligence and virtual development are already reshaping the way an engineer works and thinks, much like the computer once did. Not too far in the future, engineers will no longer look at a 3D model on a flat screen. They will step inside a virtual development environment and interact with the virtual product the same way they interact with the physical one today.

That much I can already picture. What happens after that, I cannot say, any more than I could have predicted today’s world twenty years ago. But I can accompany the way there, with the experience of the past and a vision for what comes next.

One thing is already clear: this time, too, there will be a massive efficiency gain. Somewhere down the road, an engineer will look at something none of us can even picture yet, and just know. It is likely that what makes an experienced engineer today will fade away too, the way a muscle that is no longer used slowly loses its strength. But we will have to develop other skills in its place, because it will be demanded of us.

Bitte jetzt nicht böse auf mich sein, aber genau diese Auffassung hat uns dahin gebracht wo wir heute sind.

Innovationen zu entwickeln ist in erster Linie Handwerk, das man lernen kann und muss!

Es ist eben nicht die überirdische Eingebung oder die Genialität des Individuums.

In dieser Hinsicht unterscheidet sich die Entwicklung von Innovationen viel weniger von der Produktion von Produkten als allgemein angenommen wird.

Und darum sind viele Methoden und Werkzeuge aus der Produktion geeignet auch hier Probleme in den Griff zu bekommen.

Ich will aber nicht gleich auf die Methoden und Werkzeuge eingehen, dafür gibt es eigenen Artikel.

Subscribe now

Ich will erst das Problem beschreiben, das mich dazu gebracht hat, das Drum Beat System zu konzipieren.

Es waren zwei Sätze

Der erste Satz geht so:

Der zweite Satz geht so:

Beide Sätze habe ich gedacht.

Gleichzeitig, in verschiedenen Rollen, in derselben Firma. Einmal als Chef und einmal als Mitarbeiter. Denn auch als Mittelmanager hat man einen Chef, und ist damit auch Mitarbeiter.

Und beide Male hatte ich das Gefühl, im Recht zu sein.

Diese beiden Sätze sind der Ausdruck eines Dilemmas:

Sich verändernde Kundenanforderungen und ein intensiver werdender Wettbewerb erfordern immer mehr Entwicklungen. In kürzerer Zeit, mit den gleichen Ressourcen.

Daraus resultiert:

Das Auftragsdauerfeuer

So habe ich es damals genannt. Ein Maschinengewehr mit einem Magazin, das nie leer wurde. Jede Patrone ein neuer Auftrag.

Jeder, der eine Idee hatte, seiner Meinung nach eine gute, ging damit zum Chef und erklärte ihm, warum sie sofort umgesetzt werden muss.

Am besten hat man einen positiven Business Case dabei. Je größer die Einsparung, je größer das Erlöspotential, desto wahrscheinlicher kommt der Umsetzungsauftrag zurück.

Und dann waren da noch die Ideen der Chefs selbst.

Nicht nur die vom großen Chef. Auch die mittleren und die kleinen Chefs haben Kreativität.

Das Ergebnis war ein Auftragsdauerfeuer, jeden Tag, jedes Meeting kamen neue Aufträge.

Das hat mich fürchterlich aufgeregt. Und mit den Jahren wurde es schlimmer, nicht besser.

Irgendwann kam dann der Ruf nach Priorisierung, weil es einfach nicht alles zu schaffen war.

Dieser Auftrag an den Chef kam zuverlässig und immer wieder und wurde lautstark von der gesamten Belegschaft vorgetragen, die kleinen und mittleren Chefs inclusive.

Und mit ihm kamen die Prio-listen.

Ich sage es hart, weil ich es hart meine: Das ist eine unverschämte Bitte an den Chef.

“Ich schaffe das nicht. Also entscheide du, was wir weglassen. Und trage die alleinige Verantwortung für die Konsequenzen.”

Das Ergebnis war jedes Mal dasselbe: schlechte Stimmung und Misstrauen.

Und die beiden Sätze vom Anfang.

Gerade weil ich gleichzeitig Chef und Mitarbeiter war und beides erlebt und gefühlt habe, kann ich mit voller Überzeugung sagen:

Die Ursache liegt woanders.

Es fehlt ein funktionierendes Steuerungsmodell

Es sind, wie so oft, fehlende Transparenz, fehlende Struktur und ungenutzte Fähigkeiten.

Ohne Transparenz, ohne Struktur und ohne hinreichende Fähigkeiten ist es unmöglich, Wichtiges von Unwichtigem zu unterscheiden.

Wer nicht sieht, was auf der Platte liegt, kann nicht entscheiden, was herunter soll.

Wenn es aber dann ans Weglassen geht, dann ist es keine Verwaltungsaufgabe. Weglassen heißt, Risiken einzugehen.

Risikomanagement ist eine Disziplin, die Struktur in der Vorgehensweise erfordert, sonst sind Risiken nicht quantifizierbar.

Und genau da kommen die Fähigkeiten ins Spiel.

Es braucht ausgeprägte Fähigkeiten, um Risiken überhaupt zu erkennen, um Minderungsmaßnahmen zu definieren und um die Probleme, die unweigerlich trotzdem eintreten, in den Griff zu bekommen.

Und hier rede ich nicht von den Fähigkeiten des Einzelnen.

Ich rede von den Fähigkeiten der Organisation.

Denn hier ergibt 1 plus 1 mehr als 2. Die Fähigkeiten einer Organisation sind um ein Vielfaches größer als die Summe der Fähigkeiten ihrer Individuen.

Deshalb kann der Chef das nicht allein entscheiden. Nicht, weil er zu dumm wäre, sondern weil das Wissen gar nicht bei ihm liegt.

Dann gibt es noch ein weiteres Problem:

Ein Plan ist noch keine Lieferung

Bis hierher ging es ausschließlich um den Plan.

• Was ist wichtig,

• was lassen wir weg,

• welches Risiko gehen wir bewusst ein.

Das ist die Frage nach der Effektivität. Die richtigen Dinge tun.

Nur hat noch kein Plan jemals ein Produkt entwickelt.

Planung ist nicht die Lieferung und Berichterstattung ist nicht das Ergebnis.

Denn nichts frisst so viel Kapazität wie Nacharbeit.

Ein Fehler, der zu spät auffällt, erzwingt eine Schleife.

Und eine Schleife kostet zweimal: einmal die eigene Doppelarbeit und einmal die Doppelarbeit der Kollegen, die mit dem falschen Ergebnis gearbeitet haben.

Wer mühsam Themen weglässt und die gewonnene Kapazität anschließend in Schleifen verbrennt, hat nichts gewonnen.

Also brauchen wir eine zweite Sicherheit.

Das ist die Frage nach der Effizienz. Die Dinge richtig tun.

Und die Hebel sind dieselben wie vorher.

Es braucht Struktur, damit die Voraussetzungen für die Arbeit geschaffen sind, bevor sie beginnt. Fehlende Voraussetzungen sind eine Ursache für verzögerte Lieferung und für fehlerhafte Ergebnisse.

Es braucht Transparenz, wer was von wem braucht und zu welchem Zeitpunkt. Ist das nicht klar, dann entstehen Wartezeiten oder es müssen unsichere Annahmen getroffen werden, die dann wiederum zu fehlerhaften Ergebnissen führen können.

Und es braucht die Fähigkeiten der Organisation, notwendige Kompetenzen zu entwickeln und dort einzusetzen, wo sie gebraucht werden. Statt sie hinterher mühsam zu suchen, wenn die Arbeit schon läuft.

Das Drum Beat System ist das Steuerungsmodell

Das Drum Beat System setzt an genau diesen drei Punkten an.

Transparenz

Fangen wir mit der Transparenz an, weil sie das wichtigste und das am meisten missverstandene Wort in dieser Diskussion ist.

Transparenz klingt nach einer Verwaltungsaufgabe.

• Zusammentragen,

• aufschreiben,

• sichtbar machen.

Für das Was stimmt das auch. Was alles auf der Platte liegt, lässt sich zusammentragen. Das ist der einfache Teil, und genau bis dahin kommen die üblichen Listen.

Und hier liegt häufig eine Ursache für das Problem:

Dieses Warum und dieses Wie liegen nirgendwo herum. Sie existieren noch gar nicht.

Man kann nicht transparent machen, was vorher niemand erarbeitet hat.

Transparenz setzt Inhalt voraus, und dieser Inhalt erfordert Arbeit. Er entsteht nicht dadurch, dass jemand eine Vorlage ausfüllt.

Struktur

Eine KI hat mir eine Definition von Struktur vorgeschlagen, die ich super treffend finde:

Es ist das Gerüst, das immer passt, egal worum es geht.

Sie entsteht aus Erfahrung und Kompetenz.

Wir müssen nicht immer alles neu erfinden, wir müssen nicht jeden Fehler machen, den man machen kann.

Wir suchen funktionierende Muster und wenden sie immer wieder an.

Das Drum Beat System ist keine unerprobte Neuigkeit, sondern es basiert auf jahrzehntelang angewandten, erfolgreichen Prinzipien.

Das Spannende daran ist, dass ich nicht nur die Entwicklung als Inspiration verwende. Ich schaue intensiv in die Produktion.

Ein Fachbereich, in dem Strukturen seit mehr als hundert Jahren etabliert sind und kontinuierlich verbessert werden.

Es startete am 7. Oktober 1913 mit Henry Ford und seinem legendären Fließband. Es fand seine Fortsetzung im Toyota Produktionssystem.

Dabei lohnt ein genauerer Blick auf Ford. Er hat das Fließband nämlich gar nicht erfunden. Das Prinzip kannte er aus den Schlachthöfen von Chicago.

Was Ford erfunden hat, war die Austaktung. Und die entstand nicht am ersten Tag. Es dauerte rund vierzehn Monate mit Stoppuhr und Korrektur, bis aus 12,5 Stunden pro Fahrzeug 93 Minuten wurden.

Warum sollen wir nicht da lernen, wo es langjährige Erfahrungswerte gibt?

Fähigkeiten

Ein Produkt zu entwickeln erfordert eine große Zahl an Kompetenzen. Konstruktion, Berechnung, Versuch, Beschaffung, Fertigungsplanung, Zulassung. Die Liste wird länger, nicht kürzer.

Die eigentliche Frage ist aber nicht, diese Fähigkeiten zu besitzen.

Es ist, sie zum richtigen Zeitpunkt am richtigen Ort zu haben.

Auf dieses Problem höre ich zwei Antworten. Beide greifen zu kurz.

Die erste Antwort heißt Generalisten.

Aus der agilen Welt kommt der Ruf: Spezialisten sind Schnee von gestern, wir brauchen Leute, die alles können.

Was zu Goethes Zeiten ein realistischer Anspruch war, ist heute eine Utopie. Das Wissen in jeder einzelnen Disziplin ist dafür viel zu tief geworden.

Und die Antwort verschiebt das Problem nur. Aus “Ich habe den Spezialisten nicht zum richtigen Zeitpunkt” wird “Es gibt niemanden der es kann”.

Die zweite Antwort heißt künstliche Intelligenz. Die Fähigkeiten bringt künftig die KI an den Tisch, also müssen wir uns darum nicht mehr kümmern.

Diese Antwort halte ich nicht für falsch. Ich halte sie für verfrüht.

Ich glaube, dass wir eines Tages über eine KI verfügen werden, die viel davon leistet. Ich glaube aber auch, dass sie es genau so tun wird, wie wir es die ganze Zeit schon hätten tun sollen.

Also brauchen wir nicht zu warten.

Nicht die Fähigkeiten sind der Engpass. Ihre Verschaltung ist es.

Die meisten Organisationen haben fast alles, was sie brauchen. Sie bringen es nur nicht zum richtigen Zeitpunkt zusammen.

Und jetzt kommt der Punkt, an dem die meisten Steuerungsversuche scheitern.

Diese Verschaltung lässt sich nicht von oben anordnen.

Wer wann was von wem braucht, wissen nur diejenigen, die die Arbeit machen.

Der Chef kann also nicht zuteilen. Er kann nur dafür sorgen, dass die Zuteilung stattfindet.

Genau das leistet das Drum Beat System.

Nicht die Anzahl der Fähigkeiten ist entscheidend, sondern ihr Zusammenwirken.

Damit sind die drei Ursachen benannt, die dafür sorgen, dass wir uns permanent überfordert fühlen. Und in den meisten Fällen auch wirklich überfordert sind.

Bleibt noch die Frage, wie das Drum Beat System diese Ursachen operativ im Tagesgeschäft abstellt.

Zwei Modelle, ein System

Die operative Ausgestaltung übernehmen im Drum Beat System zwei Modelle.

Das Granatapfelbaum-Modell erzeugt die Effektivität, mit ihm steuern wir den Wertfluss und stellen sicher, dass am Wichtigen gearbeitet und das Unwichtige weggelassen wird.

Der Universelle 4 Takt Zyklus erzeugt die Effizienz. Er sorgt dafür, dass Fehler und Entwicklungsschleifen vermieden werden.

Zu beiden Modellen gibt es schon Artikel, die tiefer ins Detail gehen, als ich es hier in diesem Artikel tun kann.

Also lesen oder hören sie sich bitte diese Episoden und Artikel an.

Share Uwe Mierisch

Was nehmen wir heute mit?

• Das Auftragsdauerfeuer ist kein böser Wille und kein Führungsversagen. Es ist die Folge eines fehlenden Steuerungsmodells.

• Priorisierungslisten lösen das nicht. Sie schieben die Verantwortung dorthin, wo das nötige Wissen gar nicht liegt.

• Transparenz ist keine Verwaltungsaufgabe. Man kann nichts sichtbar machen, was vorher niemand erarbeitet hat.

• Struktur ist das, was bleibt, wenn der Inhalt wechselt. Sie entsteht nicht durch Einführung, sondern durch Wiederholung und Korrektur.

• Nicht die Fähigkeiten sind der Engpass, sondern ihre Verschaltung. Der Chef kann sie nicht zuteilen. Er kann nur dafür sorgen, dass die Zuteilung stattfindet.

• Das Drum Beat System ist keine Instanz und kein Verteiler. Es ist ein Rahmen.

Jetzt noch eDas Auftragsdauerfeuer habe ich in verschiedenen Situationen erlebt, in verschiedenen Rollen, zu unterschiedlichen Zeiten. Mich interessiert, wie das anderswo aussieht.

Schreiben Sie mir gern einen Kommentar, wie bei Ihnen entschieden wird, was liegen bleibt. Ich lese jeden einzelnen und antworte darauf.

Leave a comment

Und wenn Sie die weiteren Elemente des NewPDP mitverfolgen möchten, abonnieren Sie den Newsletter.

Subscribe now

Wenn ihnen die Episode gefallen hat, dann teilen sie sie doch bitte mit anderen.

Share

Und wenn ihnen mein Newsletter gefällt, dann empfehlen Sie ihn doch bitte weiter.

Share Uwe Mierisch

It is the first of the seven elements of the NewPDP: the Drum Beat System.

This is the point where I usually lose part of the room. Innovation isn’t produced, people say. Innovation comes from the inspiration of clever people.

Please don’t be angry with me, but that very belief is what got us where we are today.

Developing innovation is first of all a craft.

One that can be learned and has to be learned.

In that respect it differs far less from manufacturing products than is generally assumed, which is why so many tools from production fit our problems.

I won’t go straight to the tools, there are separate articles for those.

Subscribe now

First I want to explain the problem that led me to design the Drum Beat System.

It Was Two Sentences

The first sentence goes like this:

The second sentence goes like this:

I have thought both sentences.

At the same time, in different roles, in the same company.

Once as the boss and once as the employee. Because as a middle manager I also had a boss, which made me an employee too.

And both times I felt I was in the right.

These two sentences are the expression of a dilemma.

Changing customer requirements and intensifying competition demand more and more development. In less time, with the same resources.

What follows from that is this:

Continuous Fire

That is what I called it back then. A machine gun with a magazine that never ran empty. Every round an assignment.

Anyone who had an idea, a good one in their own view, took it to the boss and explained why it had to be implemented immediately.

Ideally with a positive business case attached. The bigger the savings, the bigger the revenue potential, the more likely the go ahead came back.

And then there were the bosses’ own ideas. Not just the big boss. The middle and the small bosses have creativity too.

Every day, in every meeting, new assignments arrived.

It made me furious. And over the years it got worse, not better.

At some point came the call for prioritization, because there was simply no way to do it all.

It came reliably and repeatedly, voiced loudly by the workforce. And with it came the priority lists.

I’ll say it harshly, because I mean it harshly. That is an outrageous thing to ask of a boss.

The message is:

“I can’t manage this. So you decide what we drop. And you carry sole responsibility for the consequences.”

The result was the same every time. Bad mood and mistrust.

And the two sentences from the beginning.

Precisely because I was boss and employee at the same time, I can say this with full conviction:

The cause lies elsewhere.

A Working Control Model Is Missing

As so often, it comes down to missing transparency, missing structure and unused capabilities.

Without transparency, without structure and without sufficient capabilities it is impossible to tell the important from the unimportant.

If you cannot see what is on the plate, you cannot decide what comes off it.

But when it comes to leaving things out, that is not an administrative task. Leaving things out means taking risks.

Risk management is a discipline that requires structure in the approach. Without it, risks cannot be quantified.

And that is exactly where capabilities come in.

It takes strong capabilities to recognize risks at all, to define mitigations, and to handle the problems that occur anyway.

And here I am not talking about the capabilities of the individual.

I am talking about the capabilities of the organization.

Because here one plus one is more than two. The capabilities of an organization are many times greater than the sum of the capabilities of its individuals.

That is why the boss cannot decide this on his own. Not because he is too stupid, but because the knowledge does not sit with him.

A Plan Is Not a Delivery

Up to this point it has been about the plan alone.

• What matters,

• what we drop,

• which risk we take deliberately.

That is the question of effectiveness. Doing the right things.

Only, no plan has ever developed a product.

Planning is not delivery, and reporting is not results.

Because nothing eats capacity like rework.

A mistake that surfaces late forces a loop, and a loop costs twice.

Once as your own duplicated work, and once as the duplicated work of the colleagues who built on the wrong result.

Dropping topics is hard work. Burning the freed capacity in loops makes it pointless.

So we need a second safeguard.

That is the question of efficiency. Doing things right.

And the levers are the same as before.

It takes structure, so that the preconditions for the work exist before the work starts. Missing preconditions are a reliable source of late delivery and faulty results.

It takes transparency about who needs what from whom, and by when. Where that is unclear, people wait, or they make uncertain assumptions that produce faulty results.

And it takes the capabilities of the organization, built and deployed where they are needed. Instead of struggling to find them once the work is already running.

The Drum Beat System Is the Control Model

The Drum Beat System attacks exactly these three points.

Transparency

Let’s start with transparency, because it is the most important and the most misunderstood word in this discussion.

Transparency sounds like an administrative task.

Collect it, write it down, make it visible.

For the What, that is true. Everything on the plate can be collected, and that is exactly as far as the usual lists get.

And here lies a frequent cause of the problem.

That Why and that How are not lying around anywhere. They do not exist yet.

You cannot make anything transparent that nobody has worked out beforehand.

Transparency presupposes content, and that content takes work. It does not appear because somebody fills in a template.

Structure

An AI suggested a definition of structure to me that I find spot on:

It is the skeleton that always fits, whatever the subject.

Structure grows out of experience and competence.

We do not have to reinvent everything every time, and we do not have to make every mistake that can be made.

We look for patterns that work, and we apply them again and again.

So the Drum Beat System is not an untested novelty.

It rests on principles that have been applied successfully for decades, and I do not take them from development alone.

I look hard at manufacturing, a field where structures have been established and continuously improved for more than a hundred years.

It began on 7 October 1913 with Henry Ford and his legendary moving assembly line, and found its continuation in the Toyota Production System.

Ford is worth a closer look, because there is a misunderstanding sitting there. He did not invent the assembly line. He knew the principle from the Chicago meatpacking plants.

What Ford did invent was line balancing. And it was not there on day one. It took roughly fourteen months of stopwatch work and correction before 12.5 hours per vehicle became 93 minutes.

So why should we not learn where decades of experience are already on the table?

Capabilities

Developing a product requires a large number of competences. Design, analysis, testing, sourcing, manufacturing engineering, homologation. The list gets longer, not shorter.

But the real problem is not possessing them. It is having them at the right time in the right place.

I hear two answers to this. Both fall short.

The first answer is generalists. From the agile world comes the call: specialists are yesterday’s model, we need people who can do everything.

What was a realistic ambition in the age of the Renaissance man is a utopia today. The knowledge inside every discipline has become too deep for it.

And the answer only shifts the problem. “I don’t have the specialist at the right time” turns into “I don’t have anyone at all who could do that”.

The second answer is artificial intelligence. AI will bring the capabilities to the table, so we no longer need to worry about them.

I don’t consider that answer wrong. I consider it premature.

One day we will have an AI that delivers much of this, and I believe it will do it in exactly the way we should have been doing it all along. So there is no reason to wait.

Capabilities are not the bottleneck. Their wiring is.

Most organizations have almost everything they need. They simply fail to bring it together at the right moment.

And now comes the point where most attempts at steering fall apart.

This wiring cannot be ordered from above.

Who needs what from whom, and when, is known only to the people doing the work.

So the boss cannot do the allocating. He can only make sure that the allocation happens.

That is precisely what the Drum Beat System does.

What matters is not the number of capabilities, but the way they work together.

That have been the three causes that leave us permanently overloaded.

Which raises the question of how the Drum Beat System removes them in day to day operations.

Two Models, One System

The operational shape is carried by two models.

The Pomegranate Tree Model produces effectiveness. With it we steer the flow of value and make sure that the important gets worked on and the unimportant gets left out.

The Universal 4-Stroke Cycle produces efficiency. It makes sure that errors and development loops are avoided.

I have written and recorded about both models in more depth than I can go into here. You find all those articles in my publication, and they are worth the detour.

Share Uwe Mierisch

What Do We Take Away Today?

• Continuous fire is not ill will and not a failure of leadership. It is the consequence of a missing control model.

• Priority lists do not solve it. They push responsibility to the place where the necessary knowledge does not sit.

• Transparency is not an administrative task. You cannot make anything visible that nobody has worked out beforehand.

• Structure is what remains when the content changes. It does not come from being introduced, it comes from repetition and correction.

• Capabilities are not the bottleneck, their wiring is. The boss cannot allocate them. He can only make sure the allocation happens.

• The Drum Beat System is not an authority and not a distributor. It is a way of organizing work.

One request before I close.

I have lived continuous fire in more than one setup. It never looked exactly the same twice. What interests me is how it looks elsewhere.

So leave me a comment on how it works where you are. I read every one and I answer.

Leave a comment

And if you want to follow the remaining elements of the NewPDP, subscribe to the newsletter.

Subscribe now

If you like this article, please share it with others who might enjoy it too.

Share

And if you like my newsletter please recommend and share with others as well.

Share Uwe Mierisch

Thanks for reading. Take care and stay innovative.

Ich sitze im Hinterhof eines italienischen Restaurants in Stuttgart Untertürkheim und esse Spaghetti aglio e olio. Mit Knoblauch. Der Termin danach ist zum Glück telefonisch.

Mein Bekannter blättert währenddessen in den Unterlagen zum NewPDP.
Dann sagt er:

„Das ist alles viel zu komplex, das versteht keiner. Nimm den Drum Beat raus und lass den Rest weg.”

Diesen Vorwurf höre ich immer wieder. Zu kompliziert, zu viel, zu umfangreich.

Aber, ist eine einfache Transformation überhaupt möglich, wenn man ein ganzes Business System auf den Kopf stellen muss?

Ich glaube nicht. Was sein muss, das muss sein.

In einer Sache hat er allerdings recht.

Der Drum Beat gehört tatsächlich als Erstes angepackt, weil er die Basis für alles andere legt. Genau deshalb habe ich ihn ausdetailliert und operativ anwendbar gemacht, seit ich den NewPDP im Januar in meinem ersten Podcast hier vorgestellt habe. Und genau deshalb werde ich auch weiterhin intensiv auf ihn eingehen.

Nur ist mir dabei der Blick auf das Ganze in den Hintergrund geraten.

Vier Jahre Arbeit stecken in diesem Modell. Und ich habe bisher fast nur über eines seiner sieben Elemente geschrieben.

Vielleicht liegt der Vorwurf also gar nicht am Umfang. Vielleicht liegt er daran, dass ich nie erklärt habe, warum jedes einzelne Element gebraucht wird und in welcher Reihenfolge es drankommt.

Genau das mache ich heute. Und in den nächsten Wochen.

Abonnieren Sie den Newsletter, damit Sie die ganze Geschichte mitbekommen.

Subscribe now

Aber zuerst: Was ist eigentlich unser Problem?

Wir sind nicht nur zu langsam, wir fangen auch zu spät an!

Auf jeder Bühne der deutschen Industrie steht gerade jemand und sagt: Wir sind zu langsam, wir sollten so schnell arbeiten wie die Chinesen.

Aber unsere Langsamkeit ist nicht das einzige Problem. Es ist viel, viel schlimmer: Wir fangen deutlich zu spät an!

Nicht, weil wir es nicht wissen würden, sondern weil wir uns nicht entscheiden können oder wollen.

Langsamkeit kann man bekämpfen und das werden wir hier auch tun. Aber vergangene Zeit kann man nicht zurückholen.

Und wer glaubt, wir holten die Verspätungen noch auf, dem sage ich: Träum weiter. Die Konkurrenz ist nicht nur clever, sie ist auch verdammt schnell.

Ich gehe deshalb beiden Fragen nach.

• Warum tun wir uns mit dem Anfangen so schwer?

• Und wie werden wir schneller?

Mehr entwickeln ohne mehr zu brauchen

Als wenn das nicht schon schwierig genug wäre, muss ich noch eine unangenehme Überraschung auf den Tisch legen:

Wir tragen einen gewaltigen Sandsack auf den Schultern, den viele unserer Konkurrenten nicht schleppen müssen.

Denn viele Wettbewerber sind Start-ups oder Regierungsunterstützte Organisationen. Sie werfen alles Geld und alle Ressourcen auf ein einziges Zukunftsthema.

Profitabilität? Hat morgen noch Zeit.

Ihre Geldgeber warten geduldig, in der Hoffnung, dass der Gewinn dann irgendwann später umso gewaltiger ausfällt.

Ich entstamme der Old Economy.

Da wollen die Investoren heute schon Profit sehen und zwar nicht zu knapp.

Die Aufgabe ist klar: Liefert heute ordentliche Rendite und finanziert gleichzeitig die Zukunft!

Wie die Überschrift sagt: Mehr entwickeln ohne mehr zu brauchen.

Eine Mission Impossible?

Ich glaube nicht, denn die Old Economy hat auch ein paar Vorteile, die wir nutzen können.

Aber eins ist für mich zweifelsfrei klar: Dafür ist eine grundlegende Transformation erforderlich!

Genug mit der Analyse.

Schauen wir uns den NewPDP an, denn er ist als Antwort darauf konzipiert.

Der Aufbau: vier Arbeitsweisen, drei Voraussetzungen

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

Neugierig?

Dann steigen wir kurz in die wesentlichen Merkmale ein.

Wer ungeduldig ist, schreibt mich einfach an, dann gehen wir direkt zum Schwerpunkt Ihrer Wahl.

Die vier Arbeitsweisen

1. Drum Beat System (DBS)

„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. Es gibt kein Wort für den Zeitraum, in dem tatsächlich gearbeitet wird.

Genau diese Lücke füllt das Drum Beat. System.

• Das Granatapfelbaum-Modell schafft Effektivität durch Ziel Priorisierung 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)

Wahrgenommene Komplexität und Volatilität lassen eine Erkenntnis in Vergessenheit geraten:

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, und er kommt zuverlässig: 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)

Digitalisierung ist in aller Munde. Jeder redet über KI, über Virtualisierung, über digitale Zwillinge.

Zu Recht.

Arbeit an echter Hardware ist langwierig und teuer.

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)

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)

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:

• 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?

“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)

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 die Produktfunktionalität.

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.

Darauf brauchen wir eine Antwort, denn ohne geeignete Organisationsform ist schnelles und effizientes Arbeiten nicht möglich.

Architektur (A)

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.

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.

Er definiert, welche Eigenschaften und Prozesse die Architektur aufweisen muss.

Warum ich nichts weglasse

Zurück zum Hinterhof in Untertürkheim. Nimm den Drum Beat raus und lass den Rest weg.

Hier ist meine Antwort.

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 der NewPDP ist in dieser Ausprägung schon eine Vereinfachung.

Er konzentriert sich ausschließlich auf die Systemelemente, die bei der Entwicklung mechatronischer Produkte heute den größten Veränderungsbedarf aufweisen.

Man kann mit einem Element anfangen. Man muss sogar. Aber man kommt mit einem allein nicht zum 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.

Ich schreibe diese Serie nicht, um recht zu haben. Ich schreibe sie, weil ich diese Transformation mit Leuten zusammen mache, die mittendrin stecken.

Wenn Sie Lust haben, machen Sie mit.

Und jetzt bin ich neugierig.

Welches der sieben Elemente ist in Ihrer Organisation das größte Problem? Und welches wäre am schnellsten zu haben?

Schreiben Sie mir das gerne in die Kommentare oder direkt als Nachricht.

Leave a comment

Und wenn Sie vor dieser Transformation stehen und nicht allein anfangen wollen, schreiben Sie mir das auch.

In den nächsten Wochen nehme ich jedes Element einzeln auseinander. Wer die ganze Geschichte mitbekommen will, abonniert am besten den Newsletter oder den Podcast.

Subscribe now

Und wenn Ihnen der Artikel gefallen hat, teilen Sie ihn. Empfehlen Sie den Newsletter weiter, damit auch andere etwas davon haben.

Share

Share Uwe Mierisch

There it goes again.

I am sitting in the back courtyard of an Italian restaurant in Stuttgart Untertürkheim, eating spaghetti aglio e olio. With garlic. Luckily my next meeting is on the phone.

My lunch companion is going through the NewPDP material. Then he says:

“This is far too complex, nobody will get it. Take out the Drum Beat and drop the rest.”

I hear this over and over. Too complicated, too much, too big.

But is a simple transformation even possible when you have to turn an entire business system upside down?

I don’t think so. What must be, must be.

On one point, though, he is right.

The Drum Beat really is the piece to tackle first, because it lays the foundation for everything else.

That is exactly why I have detailed it out and made it operationally usable ever since I introduced the NewPDP here in January, in an article. And it is exactly why I will keep going deeper on it.

Along the way, though, I lost sight of the whole.

Four years of work went into this model. And so far I have written almost exclusively about one of its seven elements.

So maybe the complaint isn’t about the size at all.

Maybe it is about the fact that I never explained why each single element is needed and in what order it comes.

That is what I am doing today. And in the weeks ahead.

Please, subscribe to the newsletter so you get the whole story.

Subscribe now

But first: what exactly is our problem?

We aren’t just too slow, we are also too late!

On every stage in German industry someone is currently saying: “We are too slow, we should work as fast as the Chinese.”

But our slowness isn’t the only problem. It is much, much worse: we start far too late!

Not because we don’t know better, but because we can’t or won’t decide.

Slowness can be fought, and we will do exactly that here. But time that has passed cannot be brought back.

And to anyone who believes we will still catch up, I say: keep dreaming. The competition isn’t just clever, it is also damn fast.

So I will pursue both questions.

• Why do we find it so hard to start?

• And how do we get faster at the same time?

Develop more without needing more

As if that weren’t difficult enough, I have to put one more unpleasant surprise on the table:

We are carrying a huge sandbag on our shoulders that many of our competitors don’t have to haul around.

Because many of our competitors are start-ups or goverment supported. They throw all their money and all their resources at a single topic of the future.

Profitability? That can wait until tomorrow.

Their investors wait patiently, hoping the profit will be all the more enormous somewhere down the line.

I come from the Old Economy.

There the investors want to see profit today, and not a small one either.

The mandate is clear: deliver a solid return today and finance the future at the same time!

As the headline says: develop more without needing more.

Mission impossible?

I don’t think so, because the Old Economy has a few advantages of its own that we can use.

But one thing is beyond doubt for me: it takes a fundamental transformation.

Enough analysis.

Let’s look at the NewPDP, because it is designed as the answer to all of this.

The structure: four practices, three enablers

Their order is chosen so that we first tackle what lays the groundwork for everything else.

In doing so I am already applying a principle I will come back to:

Prioritise the topics that create the highest gain in value right now. And those that produce the greatest loss in value if they are not dealt with immediately.

Here there is no order. Leadership, organisation and architecture can and should be worked on at the same time.

Curious?

Then let’s take a short look at the essential features of each.

And if you are impatient, just write to me and we will go straight to the topic of your choice.

The four practices

1. Drum Beat System (DBS)

“We are currently working in QGx.”

I have heard this sentence over and over.

It is linguistic nonsense. You cannot work inside a gate. A gate is a checkpoint.

People say it anyway. Because our process only names the checkpoints and not the stretches in between.

There is no word for the period in which the work actually happens.

That is exactly the gap the Drum Beat System fills.

• The pomegranate tree model creates effectiveness through goal prioritisation and keeping everyone in sync.

• The universal four-stroke cycle creates efficiency through error avoidance and structured preparation of the work.

Both are part of the Drum Beat System.

And a single rule carries the whole thing:

A Drum Beat is never stretched.

The moment the beat gets extended, we are back where we came from. Then we are negotiating dates again instead of content.

The Drum Beat System is the lubricant for everything else. When it works, the whole machine runs more easily.

That is why we start here.

2. Learning Standard Routines (LSR)

Perceived complexity and volatility have pushed one insight out of view:

Not every activity is complex, and not the whole environment is volatile. Repetitive activities in a stable environment exist, and they always will.

For those, the rule is:

• Identify them,

• define the way of working,

• put the same people on them permanently.

• And let those people improve their own way of working continuously.

Now comes the objection, and it comes reliably: isn’t that Taylorism?

Half of it, yes. What stays from Taylor is the fixed assignment. What goes is the separation of doing and improving.

I consider this one of the advantages of the Old Economy.

We actually know how to do this. Where it makes sense, we have to do it without compromise again.

And one more aspect: standardised processes are easier to automate and digitise than unstructured ones. That multiplies the efficiency gain.

That is why Learning Standard Routines come second.

3. Hardware Light Development (HLD)

Digitalisation is on everybody’s lips. Everyone talks about AI, about virtualisation, about digital twins.

And rightly so.

Working on real hardware is slow and expensive.

No doubt about it.

The challenge sits in that small qualifier: whatever we can.

Even if not everyone will agree with me here: as long as the product is a piece of hardware, a remainder of hardware work stays indispensable.

The decisive change is not to do away with hardware entirely.

It is to develop the same quality and the same functionality with the smallest possible amount of hardware, only far faster and far cheaper.

Now you are asking yourself how that is supposed to work?

That is exactly what we are going to find out.

4. Predictive Technology Readiness (PTR)

I often hear: we have to bring new technologies to market faster.

My observation is that all too often we only decide to develop a new technology once we urgently need it.

That is too late!

But there is also the opposite mistake.

Investing too much in innovative technology too early.

A technology that sits finished on the shelf before anyone needs it is inventory. And inventory ages.

The knowledge walks out of the door with the people, and what is left falls behind.

So the challenge is not only speed, it is the right measure.

How do we manage the development of a technology so that it is ready exactly when we need it?

That is precisely what this practice deals with.

The three enablers

Leadership (L)

There are countless models and opinions on leadership.

Only one question interests me:

What does leadership have to deliver so that product development achieves outstanding results quickly and with minimal resources?

One answer up front:

• What does the team decide for itself, and how is it enabled to live up to that responsibility?

• Which tasks does the boss take on from the team, and how reliably does he deliver them?

“One team” is not a platitude. It is an attitude, a company culture.

As in team sport, there are different players with different roles, and the way they play together has to be clearly understood and practised.

And there, too, you have set pieces.

And while we have the subject on the table, we will of course also look at leading yourself.

Organisation (O)

For as long as I can remember I have watched the debate over whether a functional or a divisional organisation is the better form. The pendulum keeps changing direction, and in the end we almost always land at a matrix.

Now the agile enterprise is coming into fashion, and at the same time systems engineering is laying claim to the organisational form of development.

That names the actual problem.

Today the matrix has two dimensions: competence, meaning who can do it. And process, meaning how it runs. Systems engineering brings a third into play, namely product functionality.

Only a matrix does not survive a third dimension. Three memberships, three sets of goals, three people with a claim on the same person.

All three still have to be represented. But there can only be one organisation, and inside it one dimension always leads. That is already the case today, either the functional or the divisional one leads.

We need an answer to that, because without a suitable organisational form fast and efficient work is not possible.

Architecture (A)

It is every engineer’s dream to be allowed to develop a completely new product.

I even had that chance several times.

And every time, the organisation swore afterwards never to do such a thing again.

Endlessly expensive and endlessly long.

You are barely finished, and the product is already out of date. The next wishes are on the table.

As a consequence I have spent a lot of time on how to design hardware products modularly enough that improvements and new functionality can be developed incrementally.

Anyone coming from the software world will recognise the increment in that.

Over there it was the same for a long time. In the days of spaghetti code, almost everything had to be redone with every change.

It was object-oriented programming and the architectural principles that followed it that made the increment possible in the first place. That was decades ago.

In hardware, that development is still ahead of us.

Modular architectures have existed on our side for more than twenty years too.

That is exactly what this element is about. It is meant to close the gaps that stand in the way of incremental product development in mechatronics.

The NewPDP does not define what such an architecture concretely looks like. That would be too specific for a general framework.

It defines which properties and which processes it has to have.

Why I leave nothing out

Back to the courtyard in Untertürkheim. Take out the Drum Beat and drop the rest.

Here is my answer.

The seven elements do not stand next to each other, they interlock. Each one creates preconditions for the others, and each one benefits from the others.

That is the nature of a system.

Pick any two of them and ask yourself what one is worth without the other.

And in this shape the NewPDP is already a simplification.

It concentrates exclusively on those elements of the system that carry the greatest need for change in mechatronic product development today.

You can start with one element. In fact you have to. But with one alone you will not get there.

When I write another overview article some time from now, the story will hopefully look a little different.

We will have solved problems we no longer need to talk about, and there will be new challenges instead.

I am not writing this series to be right. I am writing it because I do this transformation together with people who are in the middle of it.

Join me.

And now I am curious.

Which of the seven elements is the biggest problem in your organisation? And which one would be the quickest win?

Write it in the comments, or send me a message directly.

Leave a comment

And if you are facing this transformation and would rather not start alone, tell me that too.

Over the coming weeks I will take each element apart on its own. If you want the whole story, the best thing to do is subscribe to the newsletter.

Subscribe now

And if you liked this article, share it.

Share

Pass the newsletter on, so other people get something out of it too.

Share Uwe Mierisch

Sie kennen das noch aus der Schule:

Hier mal ein kleines Beispiel zur Erinnerung:

Ein Motor nimmt z.B. 100 kWh Energie in Form von 10l Diesel auf. Am Ende des Triebstranges kommen 40 kWh nutzbarer Arbeit am Rad auf der Straße an. Damit kann der LKW auf der Autobahn rund 36 km weit fahren.

Der Wirkungsgrad: 40 Prozent.

Meine Aufgabe als Ingenieur war klar und eindeutig: Den Wirkungsgrad kontinuierlich erhöhen.

Wie?
Indem ich penibel Energieverluste aufspüre!

Wo verschwindet die Energie, ohne nutzbare Arbeit zu leisten?
Reibung hier. Wärmeverlust dort.
Ineffizienzen suchen, finden und beseitigen. Das ist die Vorgehensweise.

Wenn die Messwerte dann den geforderten Verbesserungsfaktor zeigen, ist der Ingenieur stolz und der Chef zufrieden. Der Erfolg ist real.

Diese Arbeit ist sehr motivierend, weil Erfolg und Misserfolg klar und zweifelsfrei belegbar sind.

Wissensarbeit geht eigentlich genauso und trotzdem ist es grundlegend anders

Als ich Führungskraft in der Fahrzeugentwicklung wurde, lag der Fokus meiner eigenen Arbeit nicht mehr auf dem Wirkungsgrad des Produktes, sondern auf dem Wirkungsgrad meiner Organisation.

Die Problemstellung war eigentlich gleich, aber trotzdem viel, viel schwieriger zu lösen.

Es gibt einen Aufwand, das sind die Ressourcen, die eingesetzt werden:

• Personal,

• Material,

• Equipment.

Dieser Aufwand ist messbar. Man kann die Mitarbeiter zählen, die Materialkosten erfassen und die Abschreibung auf das Equipment berechnen.

Und es gibt einen Nutzen:

Die Profitabilität des Produktes. Die ist messbar — eigentlich.

Aber hier wird es kompliziert.

Wie übersetzt sich die Leistungsfähigkeit des Produktes in die Zahlungsbereitschaft des Kunden?

• Ist das Produkt nicht gut genug oder hat der Verkäufer schlecht verhandelt?

• Ist die Konjunktur schuld an zu hohen Kosten oder haben die Entwickler zu teure Lösungen gewählt?

Die Faktoren, die den Gewinn beeinflussen sind undurchschaubar und nicht quantifizierbar.

Es ist eine hochkomplexe Problemstellung, die sich einer ingenieurtechnische Analyse entzieht.

Also musste ich einen anderen Ansatz finden.

Ich fand ihn bei Peter Drucker. Und er war gleichzeitig einfach und tiefgreifend:

Effektivität: Die Frage, wofür die Ressourcen eingesetzt werden.

Effizienz: Die Frage, wie viel Ressourcen eingesetzt werden.

Wenn ich den Anteil von Aufwand reduziere, der in Tätigkeiten ohne Nutzen fließt, steigt der Wirkungsgrad.

Wenn ich die Menge an Aufwand reduziere, der in nutzvolle Tätigkeiten fließt ohne das Ergebnis zu beeinträchtigen, auch dann steigt er.

Schaffe ich es diese beiden Effekte systematisch und reproduzierbar zu realisieren, dann kann ich davon ausgehen, dass der Wirkungsgrad steigt.

Dafür brauche ich aber ein System, eine Methode.

Aus dieser Erkenntnis entstanden die zwei Modelle.

Das Granatapfelbaum-Modell — es schafft Effektivität.

Der Universelle 4-Takt-Zyklus — er schafft Effizienz.

Beide kombiniert erhöhen den Wirkungsgrad in der Wissensarbeit.

Und das wunderbare an der Sache ist, dass es nicht nur in der Entwicklung funktioniert, sondern in allen indirekten Bereichen.

Die Wirksamkeit steigern

Um den Wirkungsgrad bei der Arbeit zu erhöhen, beginne ich mit einer gründlichen Wertstromanalyse:

Welche Tätigkeiten haben einen echten Wertbeitrag, und welche nicht?

Doch das ist nur die halbe Wahrheit.

Denn jeder Fehler ist eine Verschwendung. Er führt zu Schleifen, Rücksetzern, Doppelarbeit, Überplanungen, Wiederholungen, verlorener Zeit.

Um das zu verhindern, müssen wir die Trefferwahrscheinlichkeit erhöhen und den direkten Weg gehen: ohne Schleifen, ohne Irrtümer, so geradlinig wie möglich zum Ziel.

Das ist klar die erste Priorität.

Aber da Fehler nicht komplett unvermeidbar sind, müssen wir in der zweiten Priorität erreichen, dass wir, wenn wir schon Fehler machen, diese so zeitig wie möglich machen und so schnell wie möglich erkennen.

Doch nun will ich kurz auf die wesentlichen Aspekte der beiden Modelle eingehen:

Das Granatapfelbaum-Modell kümmert sich um die Effektivität

Mit dem Granatapfelbaum - Modell wird der Wertstrom adressiert.

Über 4 Ebenen wird systematisch bewertet, welche Ziele bzw. Ergebnisse gerade jetzt die wichtigsten sind, um den größtmöglichen Nutzen zu erhalten.

Ressourcen werden immer verbraucht

Ich halte es für wichtig an dieser Stelle eine wichtige Beobachtung zu teilen:

Das ist im Sinne von einem hohen Wirkungsgrad sogar gut und richtig.

Naja.

Mitarbeiter die nichts zu tun haben, schaffen keinen Wert und werden trotzdem bezahlt,
Maschinen, die nicht ausgelastet sind, wurden bezahlt und schaffen weniger Wert.
Selbst beim Geld ist es ähnlich. Geld auf dem Konto, das nicht zur Wertsteigerung eingesetzt wird, verdient vielleicht gerade mal ein paar mickrige Zinsen.

Es geht also darum mit den vorhandenen Ressourcen die maximale Wertsteigerung zu erzielen.

Und das macht das Granatapfel-Modell und zwar über das gesamte Geschäftssystem hinweg.

Ziele und Ergebnisse werden so gesetzt, dass alle Ressourcen immer am maximalen Wertzuwachs arbeiten.

Wie das genau geht können sie in meinem Artikeln nachlesen, im Text zu diesem Podcast finden sie die Liste der Artikel und Podcast-Episoden.

https://uwemierisch.substack.com/p/managing-priorities
https://uwemierisch.substack.com/p/work-with-the-item-list
https://uwemierisch.substack.com/p/project-and-item-planning-
https://uwemierisch.substack.com/p/milestone-planning
https://uwemierisch.substack.com/p/drum-beat-get-things-done
https://uwemierisch.substack.com/p/drum-beat-planning-and-documenting
https://uwemierisch.substack.com/p/todo-management
https://uwemierisch.substack.com/p/the-todo-management-that-transforms

Überflüssige Ressourcen abbauen

Nun will ich aber doch noch einige Worte zum Einsparen sagen, denn auch das hat mich in meinem Berufsleben intensiv beschäftigt.

Ich unterscheide zwei Situationen, in denen Ressourcen reduziert werden müssen.

1. Es sind mehr Ressourcen verfügbar, als zu einer sinnvollen Wertsteigerung notwendig sind.

2. Durch hohe Ineffizienzen in der Organisation werden mehr Ressourcen benötigt, als idealerweise notwendig sind.

Fall Nummer 1 ist Top Managers Liebling, auch wenn es häufig mit unangenehmen Emotionen verbunden ist.

Nicht benötigtes Personal kann abgebaut, nicht gebrauchte Maschinen und Einrichtungen können abgeschafft werden. Budgets werden einfach gekürzt.

Leider ist das Szenario 1 im wahren Leben viel seltener anzutreffen als Szenario 2 und bei dem muss anders vorgegangen werden.

Hier müssen erst die Ineffizienzen beseitigt werden, bevor die Ressourcen reduziert werden.
Tut man das nicht, was ich leider sehr häufig beobachten musste, und reduziert die Ressourcen trotzdem, dann sinkt der Output und es entsteht eine Abwärtsspirale.

Zu einem zu hohen Ressourceneinsatz kommt dann zu allem Unglück noch ein fallender Nutzen hinzu und damit wird der Wirkungsgrad immer schlechter.

Die Ineffizienz besteht aus schlechter Effektivität und schlechter Effizienz und das sind ja gerade die Baustellen an denen wir mit den beiden Modellen arbeiten.

Richtig implementiert und konsequent angewandt schaffen sie die Voraussetzungen für sinnvolle Ressourceneinsparung.

Allerdings ist das dann noch eine zusätzliche Aktivität. Der Ressourcenabbau ist in den beiden Modellen nicht enthalten. Wenn es Sie interessiert, wie das geht, dann schreiben sie mir. Auch dazu kann ich Tipps geben.

Doch nun zum universellen 4 Takt Zyklus.

Der Universelle 4-Takt-Zyklus kümmert sich um die Effizienz

Damit sorgt er für Effizienz.

Die Sachen richtig machen heißt, auf möglichst direktem Wege zum gesetzten Ziel oder Ergebnis zu kommen.

Dafür bedient er sich einer Logik, die so allgemeingültig ist, dass sie in sehr vielen anderen Methoden auch zu finden ist. Es ist eine Art Naturgesetz.

Auch hier begegnet mir wieder die magische Zahl 4, denn er besteht aus 4 Phasen, wie es der Name schon andeutet.

Am Anfang steht eine Phase des bewussten Planens, Analysierens, Vorbereitens, gefolgt von der Phase des Tuns, danach die Phase der Überprüfung des Ergebnisses und der finalen Phase der Sicherstellung der Wirksamkeit.

Die genaue Beschreibung finden sie in einem eigenen Artikel und einer eigenen Podcast Episode und in weiteren Artikeln die ich demnächst schreiben werden.

Also abonnieren sie bitte den Newsletter, falls sie es noch nicht gemacht haben, damit sie nichts verpassen.

Subscribe now

Das Zusammenspiel

Beide Modelle werden gleichzeitig und sich überlagernd genutzt.

Der universelle 4 Takt Zyklus findet auf mehreren Ebenen des Granatapfelmodell statt. Mindestens allerdings zwingend auf Ebene 2 der Meilensteinplanung und Ebene 4 der ToDo Planung.

Es muss darauf geachtet werden, dass jedes ITEM mindestens die 4 Meilsteine aufweist, die den 4 Takten des universellen 4 Takt Zyklus entsprechen.

Ebenso muss jedes ToDo unbedingt alle 4 Takte durchlaufen. Auch wenn, gegebenen Falles, vielleicht ein Takt auch mal nur ein paar Minuten dauert, muss er auf jeden Fall stattfinden.

Bei jeder Planung wird immer betrachtet, in welchem Takt gerade gearbeitet werden muss.

Das klingt durcheinander und kompliziert?

Ist es aber nicht, es ist eine Sache der Gewohnheit. Hat man die Logik einmal intus, dann findet sich das ganz automatisch zusammen.

Effizienz und Effektivität befruchten sich gegenseitig.

Es ist nicht nur Logik sondern auch System

In diesem Artikel habe ich mich darauf fokussiert, wie der Wirkungsgrad bei der Wissensarbeit verbessert werden kann.

Genau wie in der Ingenieurtechnik werden systematisch Verluste reduziert oder eliminiert und damit der Nutzen gesteigert und der Aufwand reduziert.

Und um das zu erreichen müssen Regeln und Prozesse implementieren werden, die genau diese Arbeitskultur vermitteln und die notwendigen Fähigkeiten und Gewohnheiten bei dem Mitarbeitern entwickeln.

Über diese operativen Details schreibe ich in meinen kostenpflichtigen Artikeln. Ich empfehle Ihnen das Abo zu buchen.

Ich halte es für kostengünstig und im schlimmsten Falle können sie es monatlich wieder kündigen, falls es ihnen nicht gefällt.

Im bezahlten Abo ist auch der Chat und meine persönliche Verfügbarkeit für Fragen und Analyse ihrer konkreten Situation enthalten.

Der Vorteil der Methode besteht darin, dass sie nicht an eine konkrete Software gebunden ist.

Sie können die von mir empfohlene Software nutzen oder sie können das System in anderen Tools implementieren.

Wenn Sie möchten helfe ich ihnen auch dabei.

Was nehmen wir heute mit?

• Der Wirkungsgrad ist ein blinder Fleck in der Wissensarbeit. Er wird oft ignoriert, obwohl er entscheidend für den Erfolg der Unternehmung ist.

• Effektivität und Effizienz sind zwei unterschiedliche Fragen: Welche Ziele sind es wert, erreicht zu werden? und Wie stelle ich sicher, dass ich diese Ziele auch tatsächlich erreiche?

• Das Granatapfelbaum-Modell beantwortet die Frage der Effektivität.

• Der Universelle 4-TaktZyklus beantwortet die Frage der Effizienz.

• Es beginnt mit einer ehrlichen Wertstromanalyse: Welche Tätigkeiten haben echten Wertbeitrag? Priorisieren Sie diese, vermeiden Sie alles andere.

• Jeder Fehler ist Verschwendung. Um effizient zu arbeiten, müssen Sie Ihre Trefferwahrscheinlichkeit erhöhen und den direkten Weg gehen – ohne Schleifen, ohne Irrtümer.

• Nicht Logik allein schafft Erfolg. Es braucht Systeme, Prozesse und Regeln.

• Das System wird durch die Mitarbeiter implementiert bis es zur Gewohnheiten geworden sind.

• Effizienz und Effektivität befruchteten sich gegenseitig und werden gleichzeitig angewandt.

Wie schätzen sie sich ein? Wenden sie das Granatapfelmodell und den Universellen 4 Takt Zyklus schon an oder haben sie andere Erfahungen und Vorschläge?

Schreiben sie mir ich lese alles.

Leave a comment

In den nächsten Episoden werde ich weiter in die Details des Granatapfel-Modelles und des universellen 4 Taktzykluses eingehen. Also abonieren sie meinen Podcast, damit sie nichts verpassen.

Subscribe now

Wenn ihnen diese Folge gefallen hat, dann empfehlen sie meinen Podcast doch bitte weiter.

Share

Share Uwe Mierisch