„Die richtigen Dinge tun“ vs. „Die Dinge richtig tun“

Im Jahr 2014 erhielten wir von unserer deutschen Zentrale einen Entwicklungsauftrag: ein Outdoor-Doppelkabel zu konstruieren. Oberflächlich betrachtet wirkte es unscheinbar, und seine Struktur war nicht kompliziert. Doch wir hatten keine vorherige Entwicklungserfahrung mit dieser Produktart, und die Anforderungen des Kunden erstreckten sich über mehrere Seiten — so war das Projekt vom ersten Tag an von Unsicherheit umgeben.

Dies war ein Lehrbuchprojekt der „Vorwärtsentwicklung“. Vorwärtsentwicklung bedeutet, dass das Unternehmen diese Art von Produkt zuvor noch nie hergestellt hatte: Es gab keine fertige Erfahrung und keine vorhandenen Zeichnungen, auf die man hätte zurückgreifen können, und alles musste von null auf aufgebaut werden. Gleichzeitig kann es als ein Miniaturfall der Vorwärtsentwicklung betrachtet werden, denn dieses kleine Stück Kabel trug einige sehr spezielle technische Anforderungen in sich.

Angesichts dieser Herausforderung eilten wir nicht sofort zum Zeichenbrett. Wir folgten strikt dem Produktentwicklungsprozess des Unternehmens und legten den Schwerpunkt auf das Anforderungsmanagement, das wir in vier aufeinander aufbauende Stufen unterteilten: erstens die tiefgehende Erfassung und Ordnung der ursprünglichen Kundenanforderungen, um aus einer unruhigen Oberfläche den Kernwert herauszudestillieren; zweitens die Erschließung und Konsolidierung interner Anforderungen, indem wir die angesammelten Erfahrungswerte des Unternehmens mobilisierten; drittens eine zweite Runde der Anforderungskonsolidierung und des Architekturaufbaus während der Konzeptkonstruktion; und schließlich die abschließende Kalibrierung und Umsetzung der Detailanforderungen in den 3D- und 2D-Konstruktionsphasen.

Als wir das Projekt nach Abschluss überprüften, stach eine Zahlenreihe hervor: Anforderungen, die der Kunde ausdrücklich erhoben hatte, machten nur 5 % des gesamten Anforderungssatzes aus. Anforderungen, die wir proaktiv ergänzten, basierend auf unserer tiefen Erfahrung mit anderen Produktkonstruktionen, machten 46 % aus. Anforderungen, die wir umfassend durch Concurrent Engineering — aus Fertigung, Qualität, Einkauf und anderen Abteilungen — sammelten, machten 39 % aus. Darüber hinaus fügten wir in den nachfolgenden Konzept- und Produktkonstruktionsphasen dynamisch weitere 10 % hinzu.

Es war dieses unermüdliche Streben nach dem vollständigen Anforderungssatz, das die solide Grundlage für alles Folgende legte. Mit einer so vollständigen Gefechtskarte in der Hand verlief der Rest der Entwicklung reibungslos und zügig. Während des gesamten Projekts trat keine einzige größere Designänderung auf — ein Konstruktionsdurchlauf, eine Testrunde, ein Erfolg. Am Ende lieferten wir die Engineering-Muster formell vor der vom Kunden geforderten Frist aus.

Rückblickend auf das gesamte Projekt war der zentrale Erfolgsfaktor folgender: das Produkt und die Umgebung, in der es betrieben wird, tiefgehend zu verstehen und dann den vollständigen Satz an Produktanforderungen im Vorfeld zu sammeln und präzise zu definieren. Durch diese Vorverlagerung der Arbeit erreichten wir eine First-Time-Right-Entwicklung und vermieden vollständig die hohen Kosten späterer Designänderungen, die durch unklare Anforderungen verursacht werden.

Dies war ein doppelter Sieg für Produktqualität und Entwicklungsgeschwindigkeit — und eine lebendige Veranschaulichung der Managementphilosophie „die richtigen Dinge tun“ gegenüber „die Dinge richtig tun“. In diesem Fall bedeutete das Tun der richtigen Dinge nicht, blind auf die expliziten 5 % des Kunden zu reagieren; es bedeutete, das Wesen hinter den Erscheinungen zu erkennen und proaktiv die verborgenen 95 % — den vollständigen Anforderungssatz — zu konstruieren, um sicherzustellen, dass das, was wir entwickelten, ein wirklich „richtiges Produkt“ war: eines, das tatsächlich zur Anwendung passte, fertigbar war und hohe Qualität lieferte. Das Tun der Dinge richtig spiegelte sich wiederum in der rigorosen Ausführung des vierstufigen Anforderungsmanagementprozesses wider, indem Concurrent Engineering und professionelle Erfahrung genutzt wurden, um diese Anforderungen effizient und präzise in Konstruktionszeichnungen zu übersetzen.

Letztlich bestätigte diese kleine Erfolgsgeschichte nicht nur die Weisheit der vorverlagerten Entwicklung, sondern verschaffte uns auch tieferes Vertrauen seitens der deutschen Zentrale — und seither einen stetigen Strom neuer Produktentwicklungsaufträge. Die Lehre daraus: Nur wenn Sie „die richtigen Dinge“ frühzeitig durchdenken, können Sie „die Dinge“ später korrekt — und auf schöne Weise — ausführen.

Der vierstufige Anforderungstrichter in der Praxis

Die vier Stufen sind nicht vier Besprechungen; sie sind vier Filter, jeder mit einem anderen Verantwortlichen und einem anderen Ergebnis. Wenn man sie als Trichter behandelt, wird die Aufteilung 5/46/39/10 reproduzierbar statt zufällig.

Eine Anforderung, die ihre Quelle, ihren Verantwortlichen und ihre Verifizierungsmethode nicht benennen kann, ist noch keine Anforderung — sie ist eine Meinung. Stufe 4 ist der Ort, an dem dieser Test Zeile für Zeile angewendet wird.

Durchgerechnetes Beispiel: Von „Outdoor“ zu einer messbaren Anforderung

Betrachten Sie, wie eine vage Kundenformulierung — „für den Außeneinsatz geeignet“ — zu einem Satz verifizierbarer Anforderungen wird. Der Kundentext liefert keine Zahlen; die Zahlen stammen aus den Stufen 2 und 3.

• Kundenaussage (Stufe 1): „Das Kabel muss im Freien installiert werden und funktionsfähig bleiben.“ Eine Zeile, keine Werte.
• Anwendungsfragen (Stufe 1): Wo wird es montiert — Fassade, Mast, erdverlegtes Rohr? Wie hoch ist die erwartete Lebensdauer? Wird es nach der Installation bewegt oder ist es fest verlegt?
• Interne Erschließung (Stufe 2): Frühere Outdoor-Produkte in unserem Portfolio fielen im Feld hauptsächlich durch UV-Versprödung des Mantels und Wassereintritt an der Steckerschnittstelle aus. Lessons-Learned-Aufzeichnungen weisen auf eine UV-Belastungsprüfung und eine IP-Schutzart als zwingende Ergänzungen hin.
• Konzeptkonsolidierung (Stufe 3): Das Team legt die Architektur fest — UV-stabilisierte Mantelmischung, abgedichteter Übergang zum Stecker — und weist jedem eine Zielvorgabe zu: ein definiertes Ziel für die UV-Alterungsstunden und eine definierte Schutzart, beide schriftlich mit dem Kunden vereinbart.
• Detailkalibrierung (Stufe 4): Jede Zielvorgabe wird zu einem Zeichnungseintrag und einem Test im Konstruktionsverifizierungsplan: Mantelwerkstoffspezifikation auf der 2D-Zeichnung, eine UV-Alterungsprüfung und eine Eindringprüfung an drei Mustern.

Keine dieser Zahlen stammte aus den Seiten des Kunden. Alle sind vertretbar, weil jede eine Quelle, einen Verantwortlichen und einen Test trägt. Genau das repräsentieren die Anteile von 46 % und 39 % in der täglichen Arbeit.

Schritt-für-Schritt-Checkliste für die Anforderungsphase

Verwenden Sie diese Liste als Gate-Review, bevor mit der Konzeptkonstruktion begonnen werden darf.

1. Übertragen Sie jeden Kundensatz in eine nummerierte Anforderung; behalten Sie den ursprünglichen Wortlaut neben Ihrer Interpretation bei.
2. Kennzeichnen Sie jede Zeile als explizit, abgeleitet oder angenommen — Annahmen sind die Kategorie mit dem höchsten Risiko.
3. Gehen Sie die Anwendung mit dem Kunden durch: Montage, Umgebung, Lebensdauer, Gegenstücke, Installationswerkzeuge.
4. Durchsuchen Sie die Lessons-Learned-Bibliothek und frühere 8D-Berichte nach ähnlichen Produkten; fügen Sie jede relevante Fehlerart als ergänzte Anforderung hinzu.
5. Führen Sie eine funktionsübergreifende Prüfung mit Fertigung, Qualität und Einkauf durch; halten Sie fest, wer was eingebracht hat.
6. Wandeln Sie jede Anforderung in ein messbares Abnahmekriterium mit einer Verifizierungsmethode um (Test, Analyse, Prüfung, Nachweis).
7. Kennzeichnen Sie jede Anforderung, die nicht verifiziert werden kann — definieren Sie entweder einen Test oder eskalieren Sie sie als offenes Risiko.
8. Legen Sie die Baseline des Sets fest, versionieren Sie es und frieren Sie es vor der 3D-Konstruktion ein; spätere Änderungen laufen über die Änderungslenkung.
9. Verfolgen Sie jede Anforderung vorwärts bis zu einem Zeichnungsmerkmal und einem Verifizierungsnachweis.

Häufige Fehlerarten und wie man sie erkennt

• Stille Annahmen. Das Team glaubt, eine Anforderung sei offensichtlich, und schreibt sie nie auf. Erkennen lässt sich das, indem man jeden Ingenieur bittet, in einem Satz zu sagen, was das Produkt leisten muss — abweichende Antworten offenbaren die Lücke.
• Anbetung der Kundenspezifikation. Das Team behandelt das Kundendokument als vollständig und überspringt Stufe 2. Erkennen lässt sich das, indem man das Verhältnis von ergänzten zu expliziten Anforderungen prüft; eine nahezu Null-Ergänzungsrate bei einer neuen Produktfamilie ist ein Warnsignal, keine Effizienz.
• Nicht verifizierbare Anforderungen. Formulierungen wie „robust“ oder „langlebig“ überleben bis in die Baseline. Erkennen lassen sie sich durch einen Stichwortscan der Anforderungsliste nach Adjektiven ohne Zahlen.
• Späte Entdeckung von Anforderungen. Neue Bedarfe tauchen während der 3D-Konstruktion oder nach den ersten Mustern auf. Erkennen lässt sich das, indem man die nach der Baseline hinzugefügten Anforderungen zählt; jede einzelne sollte eine Ursachenfrage auslösen, welche Stufe sie übersehen hat.
• Concurrent Engineering nur auf dem Papier. Fertigung und Qualität unterschreiben das Prüfblatt, tragen aber nie Inhalt bei. Erkennen lässt sich das durch Prüfung der Herkunftsspalte — wenn keine Anforderung auf diese Funktionen zurückführbar ist, war die Prüfung zeremoniell.

Wie man das Ergebnis verifiziert

Die Verifizierung erfolgt auf zwei Ebenen. Auf der Anforderungsebene bestätigen Sie, dass jede Zeile eine Quelle, einen Verantwortlichen, ein messbares Kriterium und eine Verifizierungsmethode hat und dass die Trace-Matrix keine verwaisten Merkmale (Zeichnungseinträge ohne dahinterstehende Anforderung) und keine verwaisten Anforderungen (Anforderungen ohne Merkmal) enthält. Auf der Projektebene ist der Nachweis verhaltensbasiert: ein First-Time-Right-Durchlauf ohne größere Designänderung, eine einzige Testrunde und eine Lieferung termingerecht oder vorzeitig. Verfolgen Sie die Anzahl der nach dem Design-Freeze erhobenen Engineering-Änderungsanträge — in diesem Projekt war sie bei größeren Änderungen null, und diese Zahl ist die ehrliche Leistungskennzahl (KPI) für das Anforderungsmanagement.

Verbindungen zu den benachbarten D-Schritten

Diese Arbeit steht am Anfang der 8D-Kette und bestimmt, wie sich der Rest verhält. Ein vollständiger Anforderungssatz ist die Eingabe für D2 (Problembeschreibung) — ohne ihn lässt sich „das Problem“ nicht von „einer fehlenden Anforderung“ trennen. Er speist D3 (Sofortmaßnahmen), weil eine spät entdeckte Anforderungslücke Sofortmaßnahmen an bereits ausgelieferten Mustern erzwingt. Er ist die Referenz, anhand derer D4 (Ursachenanalyse) einen Konstruktionsfehler von einem Spezifikationsfehler unterscheidet. Am wichtigsten ist, dass er D5/D6 (Korrekturmaßnahmen und Validierung) schützt: Korrekturmaßnahmen, die Anforderungen nachträglich ergänzen, sind weit teurer als im Vorfeld erfasste Anforderungen, und die Validierung in D6 ist nur gegenüber einer eingefrorenen, rückverfolgbaren Baseline aussagekräftig. Kurz gesagt: Der vierstufige Trichter ist der Ort, an dem D5 und D6 kostengünstig gemacht werden.