Produktentwicklungsprozess: Stage-Gate-Flussdiagramm

So funktioniert es

1. Benennen Sie die Bahnen nach Ihren echten Funktionen

   Ersetzen Sie Produktmanagement, Entwicklung / F&E, Design, Qualität und Vertrieb durch die Funktionen, die es bei Ihnen wirklich gibt. Hardware-Teams teilen die Entwicklung meist in Mechanik, Elektronik und Fertigungstechnik; Software-Teams haben oft keine eigene Qualitätsbahn und sollten die Validierung in die Entwicklung falten, statt ein leeres Band stehen zu lassen. Führen Sie jede Bahn zusammen, der Sie keinen namentlichen Verantwortlichen zuordnen können, und bleiben Sie bei einer Zahl, die auf einen Bildschirm passt.

2. Schreiben Sie die Gate-Kriterien vor dem ersten Review

   Ein Gate ohne schriftliche Kriterien wird zur Präsentation. Halten Sie für Gate 1 fest, was der Business Case enthalten muss und welche Schwellen ein „Go“ ergeben: das Marktvolumen, das Sie für verfolgenswert halten, die Machbarkeitsfragen, die beantwortet und nicht angenommen sein müssen, und der regulatorische Rahmen. Halten Sie für Gate 2 fest, welche Pilotnachweise verlangt sind. Vereinbaren Sie beides, solange nichts am Gate wartet. Am Tag selbst verhandelte Kriterien schreibt die Person, die am stärksten an einem „Go“ hängt.

3. Klären Sie, was „Überarbeiten“ und „Pilot verlängern“ wirklich bedeuten

   An den beiden weichen Zweigen verrotten Stage-Gate-Prozesse. „Überarbeiten“ an Gate 1 sollte eine konkrete Liste dessen tragen, was sich ändern muss, dazu Verantwortlichen und Rückkehrtermin; sonst ist es ein Stopp, den niemand aussprechen wollte. „Pilot verlängern“ an Gate 2 sollte benennen, was gelernt werden soll, wie lange die Verlängerung läuft und welches Kriterium sie beendet. Halten Sie beides am Projekt fest statt im Protokoll und zählen Sie, wie oft welcher Zweig genutzt wird, ein Gate, das immer nur überarbeiten lässt, entscheidet nichts.

4. Halten Sie Design-Review und Validierung getrennt

   Sie beantworten verschiedene Fragen. Das Design-Review fragt, ob Konstruktion und Prototyp die zu Entwicklungsbeginn vereinbarte Spezifikation erfüllen, und ist eine Prüfung der Konstruktion durch Fachkolleginnen und Beteiligte. Die Validierungstests fragen, ob das fertige Produkt den Nutzerbedarf und die regulatorischen Anforderungen unter realen Bedingungen erfüllt. Diese Trennung ist es, die die beiden Rückschleifen im Diagramm sinnvoll macht: Die eine fängt ein Konstruktionsproblem ab, bevor Sie für Testmuster zahlen, die andere ein Anforderungsproblem, bevor Sie für einen Pilot zahlen.

5. Definieren Sie den Pilot und seine Abschlusskriterien

   „Begrenzte Pilotserie fahren“ bedeutet in jeder Organisation etwas anderes: eine Vorserie, ein Soft Launch in einer Region, eine Early-Access-Gruppe. Schreiben Sie auf, welches davon es ist, dazu Stückzahl oder Kundenanzahl, was gemessen wird (Ausbeute, Fehlerrate, Supportaufkommen, Aktivierung) und wie lange er läuft, bevor Gate 2 einberufen wird. Ein Pilot ohne definiertes Ende ist die übliche Art, wie Launch-Termine verrutschen, ohne dass jemand entschieden hätte.

6. Benennen Sie die Gate-Verantwortlichen und halten Sie die Entscheidungen fest

   Benennen Sie je Gate die Person, die die Entscheidung hält, und die Runde, die dabei sein muss. Ein namentlicher Verantwortlicher je Gate ist besser als ein Gremium, das durch ausbleibenden Widerspruch entscheidet. Halten Sie Ergebnis, Datum, angewandte Kriterien und Begründung fest: besonders bei einem Stopp, denn ein nicht dokumentierter Stopp kehrt in sechs Monaten als dieselbe Idee zurück. Arbeiten Sie nach einem Qualitätsmanagementsystem, ist diese Aufzeichnung zugleich der Nachweis, dass die Reviews stattgefunden haben.

7. Veröffentlichen Sie ihn und überarbeiten Sie ihn nach jedem Launch

   Teilen Sie das Diagramm dort, wo gearbeitet wird (neben den Gate-Vorlagen statt in einem Richtlinienordner) und lassen Sie es von den Bahnverantwortlichen freigeben. Gehen Sie nach jedem Launch den Ablauf mit dem Team durch: Welches Gate wurde übersprungen, welche Schleife wurde genommen und warum, und hat das Post-Launch-Review wirklich stattgefunden oder hat das nächste Projekt es überholt. Bewahren Sie die früheren Fassungen auf, damit Sie zeigen können, wann sich der Prozess geändert hat und was der Anlass war.

Häufig gestellte Fragen

Aus welchen Stufen besteht ein Produktentwicklungsprozess?

Fünf Stufen decken die meisten Produktorganisationen ab. Erstens Idee und Screening: die Idee erfassen und gegen die Strategie prüfen, bevor eine Funktion Aufwand bindet. Zweitens Business Case: technische Machbarkeit bewerten, das Konzept skizzieren, die regulatorischen Anforderungen ermitteln und das Marktpotenzial abschätzen, dann alle vier in einen Case ziehen und an Gate 1 bringen. Drittens Entwicklung und Konstruktion: Anforderungen und Spezifikation abstimmen, die Detailkonstruktion ausarbeiten, einen funktionsfähigen Prototyp bauen und ein Design-Review halten. Viertens Validierung: Validierungstests gegen die Spezifikation planen und durchführen, danach eine begrenzte Pilotserie fahren. Fünftens Launch und Review: die Entscheidung an Gate 2 treffen, das Produkt am Markt einführen, dann ein Post-Launch-Review halten und das Projekt schließen.

Was ist ein Stage-Gate-Prozess, und was kann ein Gate entscheiden?

Ein Stage-Gate-Prozess bündelt Entwicklungsarbeit in Stufen und setzt zwischen je zwei Stufen einen Entscheidungspunkt, sodass Budget und Aufwand in Schritten freigegeben werden statt vollständig zu Beginn. Die üblichen Gate-Ergebnisse sind Go, Stopp, Halten und Überarbeiten: in die nächste Stufe gehen, das Projekt beenden, es wegen Kapazität oder Priorität parken oder es zur Nachbesserung der aktuellen Stufe zurückgeben. Diese Vorlage zeigt an Gate 1 Go, Überarbeiten und Stopp und an Gate 2 Launch, Pilot verlängern und Stopp. Wenn Ihre Gates nie etwas anderes als ein Go hervorbringen, sind es keine Gates, und das Portfoliomanagement, das sie leisten sollen, findet nicht statt.

Was ist der Unterschied zwischen Design-Review und Validierungstests?

Ein Design-Review prüft die Konstruktion gegen ihre Vorgaben: Erfüllen Detailkonstruktion und Prototyp die zu Entwicklungsbeginn vereinbarte Spezifikation, und sind die offenen Risiken verstanden. Die Validierungstests prüfen das Produkt gegen den Bedarf: Funktioniert es für die Nutzenden, unter realistischen Bedingungen, gegen die Anforderungen einschließlich der regulatorischen. Verifizierung ist die erste Frage, Validierung die zweite, und Qualitätsmanagementnormen behandeln sie aus gutem Grund als getrennte Tätigkeiten. In diesem Diagramm sind es zwei Entscheidungen mit zwei getrennten Rückwegen in die Detailkonstruktion, denn ein im Review gefundener Konstruktionsfehler ist weit billiger als derselbe Fehler nach dem Bau der Testmuster.

Wie unterscheidet sich das vom Software-Release-Prozess oder einem Go/No-Go-Entscheidungsbaum?

Durch den Umfang. Dieses Diagramm deckt den gesamten Entwicklungszyklus ab, von einer Idee in der Pipeline bis zum Post-Launch-Review, und behandelt jede Launch-Entscheidung als einen einzelnen Gate-Knoten. Der Software-Release-Prozess unter /de/templates/software-release-prozess beginnt viel später, bei einem fertigen Build, und detailliert Branch-Schnitte, Test-Gates, Staging, Deployment, Rollback und Hotfixes. Der Go/No-Go-Entscheidungsbaum geht in die andere Richtung und klappt ein einzelnes Gate in ein Dutzend Nachweisfragen mit fünf benannten Ausgängen auf. Nutzen Sie diese Seite, um den Zyklus zu definieren, und eine der anderen für den Teil, den Sie genauer brauchen.

Wer sollte die einzelnen Gate-Entscheidungen verantworten?

Eine benannte Person je Gate, wobei die beitragenden Funktionen als Nachweisgeber teilnehmen und nicht als Stimmen. Gate 1 liegt üblicherweise bei der Person, die Portfolio und Budget verantwortet (Produktleitung, Geschäftsführung oder in kleineren Häusern die Leitungsrunde), denn es ist eine Entscheidung darüber, wohin Entwicklungskapazität fließt. Gate 2 ist ebenso eine Bereitschafts- wie eine kaufmännische Entscheidung, deshalb braucht die verantwortliche Person die Befugnis, einen Launch zu stoppen, wenn Qualität oder Versorgung nicht bereit sind, nicht nur die Befugnis, ihn freizugeben. Schreiben Sie die Entscheidungsbefugnisse vor dem ersten Gate auf: Ein Gate ohne Zuordnung fällt an die Person, die am Tag im Raum am ranghöchsten ist.

Wie viele Gates sollte ein Produktentwicklungsprozess haben?

Weniger, als Sie denken, und nur dort, wo es eine echte Entscheidung gibt. Hier sind es zwei, weil sie die beiden Punkte markieren, an denen die zugesagten Ausgaben springen: Gate 1 gibt die Entwicklung frei, Gate 2 die Markteinführung samt der folgenden Kosten für Produktion, Marketing und Support. Größere oder stärker regulierte Vorhaben ergänzen üblicherweise ein Gate zwischen Konzept und Detailkonstruktion und eines vor Beginn der Validierung. Der brauchbare Test lautet: Könnte das Gate plausibel etwas anderes als ein Go hervorbringen? Hat ein Review noch nie ein Projekt gestoppt oder verändert, streichen Sie es, oder verschieben Sie es dorthin, wo das Geld tatsächlich gebunden wird.