Umgang mit späten Konstruktionsänderungen

Der Umgang mit Konstruktionsänderungen ist für Hersteller in jeder Phase des Entwicklungszyklus eine unumgängliche Realität. Eine klare, fest vereinbarte Konstruktionsspezifikation, die auf solider Marktforschung, Kundenanforderungen und Konstruktionsmethodik basiert, kann helfen, zahlreiche Fehler zu vermeiden, die Konstruktionsänderungen notwendig machen könnten.

Doch Änderungen können sogar bei noch so vielversprechenden und durchdachten Entwürfen notwendig sein. Dafür gibt es im Entwicklungszyklus unzählige Gründe. Eines ist aber sicher: Änderungen am Modell werden immer teurer und sind mit größeren Störungen verbunden, je weiter der Entwicklungszyklus fortgeschritten ist.

Änderungen an einem bereits am Markt erhältlichen Produkt können sogar noch unangenehmere Konsequenzen haben, beispielsweise teure Produktrückrufe, mögliche Haftungsforderungen von Verbrauchern und Vertrauensverlust bei den Kunden.

Der Schaden an seiner Marke, der durch eine groß angelegte Rückrufaktion im Jahr 2010 entstand, kostete Toyota nach Schätzungen Umsatzeinbußen in Höhe von 770 bis 880 Millionen US-Dollar. Die Kosten durch verlorenes Kundenvertrauen lassen sich nur schwer beziffern, sind aber höchst wahrscheinlich genauso beträchtlich. Zwar schwanken die Schätzungen.

Als Faustregel gilt jedoch, dass die Kosten von Konstruktionsänderungen sich bei jedem Schritt des Konstruktionsprozesses verzehnfachen. Eine Änderung in der ersten Phase der Konzeptentwicklung würde also beispielsweise 10 US-Dollar kosten. Hat das Modell erst einmal die Produktionsphase erreicht, würde dieselbe Änderung bereits Kosten in Höhe von 100.000 US-Dollar verursachen. Herstellern ist das bewusst. Leider lassen sich Fehler nie ganz ausschließen. Die Frage muss also lauten: Wie geht man am besten mit Änderungen um, die erst spät im Entwicklungszyklus ihr hässliches Haupt erheben?

 Warum jetzt?

Das ist eine häufige Frage, wenn Konstruktionsänderungen in späten Entwicklungsphasen erforderlich werden. Manchmal sind sie notwendig, um auf geänderte Kundenanforderungen zu reagieren. Manchmal werden sie von standortspezifischen Fertigungsfähigkeiten verursacht. Änderungen können erforderlich sein, wenn sich ein Material oder ein Fertigungsverfahren ändert.

Das wiederum kann durch Materialengpässe, Beschaffungsschwierigkeiten für eine bestimmte Komponente oder einen Lieferantenwechsel verursacht werden. Diese Phänomene sind oft das Ergebnis voneinander getrennter Prozesse innerhalb der Organisation, bei denen die Mitglieder des Konstruktionsteams nicht zeitnah über sich ändernde Produktanforderungen und die fertigungsbezogenen Entwurfsparameter informiert werden. Die Konstruktionsteams konzentrieren sich einzig und allein auf den Entwurf, während vor- und nachgelagerte Teams die Designer kontinuierlich mit Produktanforderungsdaten versorgen müssen.

Wenn eine Änderung notwendig ist, müssen alle Teammitglieder offen miteinander kommunizieren und zusammenarbeiten, um die richtige Lösung zu finden. Eine Änderung am Entwurf hat oft Auswirkungen auf nachgelagerte Prozesse. Ingenieure und Designer müssen daher realistisch einschätzen, welche Folgen die Änderung auf Zeitpläne und Kostenschätzungen hat, und alle davon betroffenen Personen darüber informieren.

Flexibel sein

Zwar kann eine sorgfältig ausformulierte Konstruktionsspezifikation dazu beitragen, gewisse Konstruktionsänderungen zu vermeiden, sie kann aber auch zu mangelnder Flexibilität und Reaktionsfähigkeit führen, wenn doch Änderungen notwendig sind. Unternehmen müssen kontinuierliche Berührungspunkte mit Kunden schaffen, um Produktkonzepte, Prototypen und Funktionsmerkmale während des Entwicklungs- und Einführungszyklus testen zu können.

Untersuchungen haben gezeigt, dass sich dadurch gegenüber dem herkömmlichen Konstruktionskonzept mit Gates und der strengen Einhaltung der zu Beginn des Entwicklungszyklus erarbeiteten Konstruktionsspezifikationen die Zykluszeit um 30 Prozent und die Entwicklungskosten um 40 Prozent verringern lassen. Zu Beginn des Prozesses greifen diese schlanken Entwicklungsmethoden aber nicht.

Die verbesserte Effizienz der schlanken Produktentwicklung ist (wie beim Gate-Modell) immer noch stark von der frühzeitigen Stabilisierung der Anforderungen abhängig. Das Erstellen von Iterationen, Optimieren und Erarbeiten von Kompromissen bei den Anforderungen, bis das beste Produkt-Design gefunden ist, ist bei dieser Arbeitsweise ebenfalls nicht vorgesehen. Jegliche Innovation bei diesem Konzept basiert daher in erster Linie auf dem Schutz des Status quo, nicht auf Kreativität. So bleiben die Unternehmen anfällig für spätere Störungen und Veränderungen am Markt.

Wir lernen daraus, dass durch die verstärkte Globalisierung ein zunehmend vom Wettbewerb geprägtes Umfeld für Hersteller entstanden ist. Die Produktentwicklungsumgebung ist für starre, standardisierte Prozesse zu veränderlich geworden. Designer und Ingenieure müssen, ebenso wie das übrige Entwicklungsteam, flexibel, offen und bereit sein, sich mit den unumgänglichen Änderungen auseinanderzusetzen, die während des gesamten Prozesses anfallen, um Probleme schnell zu lösen und die Produkte mit möglichst geringen Störungen wieder zeitplangemäß weiterzuentwickeln.

Dieser Eintrag wurde veröffentlicht in Die Konstruktion neu erfunden und getagged , , , , , . Bookmarken: Permanent-Link. Trackbacks sind geschlossen, aber sie können Kommentieren.

Einen Kommentar schreiben

Ihre E-Mail wird niemals veröffentlicht oder verteilt. Benötigte Felder sind mit * markiert

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

Du kannst diese HTML Tags und Attribute verwenden: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <pre> <q cite=""> <s> <strike> <strong>