Beschränken Sie sich nicht aufs Reparieren. Finden Sie den Fehler, bevor der Kunde ihn bemerkt.

Sep 5, 2017, 18:28 by Anna Thornton, Analytics Operations Engineering
Probleme werden gern auf eine einzige Ursache zurückgeführt, die es zu beheben gilt. Belege für die Verwendung des Sündenbocks finden sich bereits in viertausend Jahre alten Schriften. Alle Sünden der Gemeinschaft wurden auf den Kopf eines Ziegenbocks übertragen, der dann in die Wildnis verjagt wurde, sodass die Menschen ihrer Probleme ledig waren. Vier Jahrtausende später ist der Glaube an die Problemlösungskraft des Sündenbocks ungebrochen. Wenn ein Produkt während des Einsatzes beim Kunden ausfällt und Rückrufe oder übermäßige Garantiekosten verursacht, haben Unternehmen schnell eine Lösung parat. Eventuell wird jemand entlassen, und alles scheint wieder in Ordnung zu sein.
Wer wird bei Fehlern in Ihrem 
Unternehmen,  zur Rechenschaft gezogen?
Die Ereignisse bei GM sind kein Einzelfall. Wenn ein Problem bekannt wird, untersuchen Notfallteams meist die Produktionsabläufe (z. B. Lieferanten, Qualitätskontrolle, Produktionskontrolle). Selten wird das ursprünglich daran beteiligte Team an einer gründlichen Analyse der Produktentwicklungs- und -vermarktungsaktivitäten beteiligt. Um die zugrunde liegenden Ursachen beheben zu können, muss den betroffenen Teams klar werden, wieso das Problem entstehen konnte und warum es nicht verhindert wurde. Zudem müssen Unternehmen oft unbeachtete kulturelle Aspekte kritisch einbeziehen, aufgrund derer in Teams mögliche Ausfälle übersehen werden. Werden diese Probleme nicht angegangen, entsteht in Unternehmen meist ein Katz-und-Maus-Spiel in Bezug auf Qualitätsaspekte (siehe meinen Beitrag zu diesem Thema).

Um aus Fehlern auch zu lernen, sollten Organisationen von der Frage “Welcher Schritt war fehlerhaft?” zur Aussage “Jeder Schritt war fehlerhaft!”gelangen.
 
Bei der Produktentwicklung wird meist nur ein kleiner Teil der Ressourcen für die Erstellung von Produkt- und Prozessdefinitionen ausgegeben. Im Idealfall könnte ein einziger brillanter Designer ein Problem definieren, eine Zeichnung sämtlicher Teile und Baugruppen für ein neues Produkt erstellen und diese dann dem Hersteller zukommen lassen. Der Hersteller würde alle Teile gleich beim ersten Mal fehlerfrei erstellen, richtig zusammensetzen, verpacken und versenden. Das Produkt würde während der gesamten Nutzungsdauer fehlerfrei funktionieren. Dieser Idealzustand existiert leider nur in den Köpfen einiger Studienanfänger (und bisweilen auch einiger Marketingmanager).

In der Realität setzen Teams ihre Produktentwicklungsressourcen größtenteils für andere Aktivitäten ein. Mit diesen Aktivitäten wird das zu lösende Problem definiert, sodass jeder auf dem gleichen Stand ist, Schwachpunkte im Design erkennt und behebt, Probleme proaktiv verhindert und die Einhaltung des Projektzeitplans sicherstellt. Die meisten Aktivitäten dienen als Filter, mit denen sich Probleme vermeiden lassen, bevor sie beim Kunden auftreten.

In diesem Diagramm sind einige Aktivitäten dargestellt, mit denen nding
Probleme erkannt und behoben werden können, bevor sie beim Kunden auftreten.

So kann die Wahl des Konzeptes für die finale Produktqualität entscheidend sein. Werden bei der Konzeptauswahl die falschen Kriterien ausgewählt oder erfolgt die Auswahl der Konzepte ohne gründliche Analyse, haben Teams während des gesamten Designprozesses mit den daraus entstehenden Schwierigkeiten zu kämpfen. So verursachte bei den Takata-Airbags die Wahl des falschen Beschleunigers langfristige Qualitäts-und Design-Probleme, die zum Rückruf des Produkts führten. Wenn zu Ende des Designprozesses die Produktprüfung nicht unter den tatsächlichen Nutzungsbedingungen erfolgt, bestehen die Produkte den Funktionstest, halten aber der Praxis nicht stand. Ich könnte mir vorstellen, dass GM das Zündungsproblem eher erkannt hätte, wenn beim Test ein schwerer Schlüsselanhänger verwendet worden wäre. In der Abbildung oben ist ein kleiner Teil der Aktivitäten zur Erkennung und Behebung von Problemen aufgeführt, bevor diese vom Kunden festgestellt werden.

Wenn ein Qualitätsmangel nicht erkannt wird, liegt dies an ALLEN Produktentwicklungsaktivitäten.

Ich möchte ein halb hypothetisches Beispiel anführen (alle meine Kunden werden sich darin wiedererkennen). Nachdem ein Produkt ein Jahr im Einsatz war, kam es in einer Region plötzlich vermehrt zu Kundenbeschwerden wegen mangelhafter Leistung. Daran scheint sich nichts geändert zu haben. Qualitätsmitarbeiter können keine Änderungen bei den erhaltenen Teilen feststellen, sowohl bei der Inspektion als auch den abschließenden Funktionstests bleibt das Problem unerkannt. Nach einer langwierigen und umständlichen Untersuchung fand das Brandschutzteam heraus, dass ein Hersteller eine Änderung am Fertigungsprozess vorgenommen hatte, um Zykluszeiten zu reduzieren. Es stellte sich heraus, dass der CpK-Wert beim neuen Prozess zwar akzeptabel, aber beim ursprünglichen Prozess wesentlich besser war. Dadurch erhöhte sich die Varianz, die in Kombination mit höheren Temperaturen in einem bestimmten Bereich zu einer Leistungsminderung und damit zu einer Beschwerde führte. So zog das Team die Toleranzwerte an, führte zusätzliche Qualitätskontrollen ein, zog den Lieferanten in die Verantwortung und ging davon aus, dass das Problem behoben sei. Im nächsten Jahr führte ein unerwarteter Verschleiß zu einem Ausfall, der mit dem anderen Problem in keinem Zusammenhang stand. Die Teams konnten ein neues Material mit anderen mechanischen Eigenschaften als Ursache herausfinden. Das Produktpflegeteam behob das Problem mithilfe einer Design-Änderung und ersetzte defekte Produkte, sobald Kunden Probleme meldeten.

White Paper
Dieser Artikel bezieht sich auf das White Paper:
Reklamationsbearbeitung als integraler Bestandteil der FDA- und ISO-Compliance
Alle ausführlichen Informationen Anzeigen Ihr kostenloses White Paper.


Warum sind beide Fehler erst beim Kunden bemerkt worden? Es mag zunächst danach aussehen, als seien sehr unterschiedliche Probleme von unterschiedlichen Abteilungen innerhalb der Organisation gelöst worden. Im ersten Fall lag das Problem offenbar beim Lieferanten, im zweiten Fall mangelte es an der Übersicht über die Gesamtkonstruktion. Wenn man jedoch genauer darauf achtet, welche Filter ausfielen, fallen bestimmt Ähnlichkeiten auf. In beiden Fällen

  • waren die Spezifikationsdokumente sehr allgemein gehalten und enthielten keine detaillierten Angaben zu Betriebsbedingungen. Da die Betriebstemperatur im ersten Produkt und die tatsächlichen Lasten des zweiten nicht angegeben waren, konnten die Teams die Anforderung nicht in Toleranzwerte umrechnen und die Leistungsrisiken unter verschiedenen Betriebsbedingungen nicht richtig einschätzen. Der Lieferant hätte das Problem erkannt, wenn der zur Spezifikation passende Toleranzwert eingestellt gewesen wäre. Mit Tests beim passenden Belastungsniveau hätten die Materialprobleme früher erkannt werden können.
  • Die Teams legten sich aufgrund enger Zeitvorgaben frühzeitig auf beide Konzepte fest. Sie waren gezwungen, sich schnell für ein Konzept zu entscheiden, um die Werkzeugbestückungsphase abzuschließen. Hinzu kommt, dass in beiden Fällen die Zeitpläne ohnehin verkürzt wurden. Die Teams waren gezwungen, mit einem nicht vollständig ausgewerteten Konzept zu arbeiten, und verbrachten dafür zusätzliche Zeit damit, eine suboptimale Idee zum Laufen zu bringen.
  • Bei den Konstruktionsprüfungen ging es eher um Statusbesprechungen. Insbesondere im zweiten Fall waren die Teams mit dem neuen Material nicht vertraut und gingen einfach davon aus, dass es für den vorgesehenen Zweck geeignet sei. Die Design-Teams hatten keine Möglichkeit, ihre eigenen Konstruktionen und deren Risiken kritisch zu beurteilen. Es wurden auch keine externen Prüfer befragt. Auf Bedenken erwiderten die Teams entweder, dass diese kein Problem darstelle oder nicht genügend Zeit vorhanden sei, um alles zu überprüfen.
  • Technische Analysen und Endbenutzertests fanden nur in unzureichendem Umfang statt. Da die Produkte sowohl bei den Prüfversuchen als auch bei den Standardbewertungen keinerlei Auffälligkeiten zeigten, ging das Team davon aus, dass keine Qualitätsmängel vorlagen. Die Benutzerprüfung erfolgte nur sporadisch und es wurden nicht alle Nutzungsbedingungen erprobt. Auch wenn Fehler festgestellt wurden, war man um Ausreden nicht verlegen. Während der Pilotphase gab es so viele Konstruktionsänderungen, dass die Teams annahmen, alle erkannten Fehler seien damit behoben worden.
  • Die Konstruktionsänderungen erfolgten zu Beginn der Produktion. Viele Regeln für Pilotprozesse wurden auf marginale Änderungen zur Leistungsverbesserung reduziert. Spätere Konstruktionsänderungen wurden von Prüfungen und Validierungsprotokollen nicht erfasst.
  • Das Zusammentreffen fehlender Zeitplanung und Erfahrung sowie sprachlicher, kultureller und zeitzonenbedingter Unterschiede führte dazu, dass keine Kommunikation zwischen Lieferanten und Konstruktionsabteilung bezüglich der Herstellungsmöglichkeit erfolgte. Die Lieferanten wurden lediglich gefragt:“Geht das?”, was sie immer mit ja beantworteten.
Die technischen Ursachen der beiden Ausfälle waren durchaus unterschiedlich: Im ersten Fall gab es einen Lieferantenwechsel, im zweiten Fall lag das Problem bei der Materialspezifikation. Die (versäumten) Aktivitäten, aufgrund derer die Fehler erst beim Kunden in Erscheinung traten, sind sich in beiden Fällen jedoch sehr ähnlich. Wenn ein Unternehmen sein bisheriges Produktentwicklungskonzept nicht ändert, ist die Wahrscheinlichkeit eines weiteren Qualitätsproblems hoch.

Bei einem Fehler müssen Organisationen die Rolle jedes Einzelnen genau untersuchen, um eine eventuelle Mitschuld festzustellen. Es liegen Erkenntnisse vor, denen zufolge in Unternehmen, in denen Fehler offen angesprochen werden, diese sich seltener wiederholen. Die Liste der zu behebenden Probleme erscheint manchmal unüberschaubar lang. Jedoch reicht zur Behebung des nächsten Qualitätsproblems oft schon ein funktionierender Filter.

Beim nächsten Qualitätsproblem sollte sich Ihre Organisation also nicht mit der rein technischen Ursache zufriedengeben. Ziehen Sie alle Gründe in Betracht, aus denen das Problem nicht gefunden wurde, und versuchen Sie, mindestens eines davon zu beheben. In den folgenden Artikeln möchte ich ein grundlegendes Konzept dazu vorstellen, wie Teams zusammenfinden können, um den gesamten Prozess systematisch zu evaluieren.
 

Anna Thornton hat einen Abschluss in B.S.E. von der Princeton University und hat an der Cambridge University promoviert. Am MIT arbeitete sie sechs Jahre lang als Assistenzprofessorin im Bereich Maschinenbau. Im Jahr 2000 wurde sie Mitglied im Bereich Analytics Operations Engineering (www.nltx.com), wo Sie derzeit gemeinsam mit verschiedensten Unternehmen neue Tools, Methoden und Ansätze in Bezug auf eine Vielzahl von Problemen in mehreren globalen Branchen im Bereich Produktentwicklung, Qualitätssysteme sowie Produktionssysteme entwickelt. Sie schrieb Variation Risk Managemen (Variationsrisikomanagement) und viele weitere Artikel zum Thema Produktentwicklung und Qualität.