Darf ich Sie ‘mal ‘was fragen? – Wie bekommen wir (QS-)Butter bei die (agilen) Fische?30 | 03 | 22
Das klassisch etablierte Vorgehen zur Qualitätsvorausplanung – am intensivsten ausgestaltet im APQP (Advanced Product Quality Planning) der Automobilhersteller für sich selbst und ihre Zulieferer – entstand lange, bevor so viel Software ins Auto kam. Es wurde entwickelt, bevor wir lernten, wie agile Methoden die Entwicklung beschleunigen und die Kundeneinbindung verbessern.
Immer mehr Unternehmen nutzen inzwischen agile Methoden für ihre Produktentwicklung – nicht nur für die reine Softwareentwicklung, sondern auch für die Entwicklung hybrider Mixe aus Hard- und Software oder gar für reine Hardwareentwicklung. Sie verlagern damit auch wichtige Funktionen der Qualitätssicherung aus klassischen in neue Methoden. Die FMEA ist ein Beispiel dafür. Wichtige Funktionen übernehmen nun Scrum-Werkzeuge – allerdings deutlich anders, als in der klassischen FMEA. Doch wie kann die agile Entwicklung ihren Automotive Kunden die Einhaltung der Anforderungen aus der IATF 16949 und der mitgeltenden Dokumente nachweisen? Gibt es dafür ausschließlich klassische Formate oder geht das auch in neuer Form? Lässt sich der klassische FMEA-Ansatz überhaupt in einen agilen Entwicklungsprozess transformieren? Wie geht das?
Nicht selten kommt es beim Versuch der Verbindung von klassischer Qualitätssicherung und agilen Vorgehensweisen zum „Clash of Cultures“: Es entwickelt sich ein starker Konflikt zwischen QM- und Entwicklungsabteilungen. Es wird darum gerungen, ob die klassischen Anwendungen fortgeführt oder ganz neue Methoden der Qualitätssicherung, der Prävention und der Qualitätsvorausplanung eingesetzt werden. Die Stärke agiler Methoden ist es, unter den neuen Rahmenbedingungen viel geringerer Vorhersehbarkeit weniger langfristig und detailliert zu planen und dafür sehr viel besser kleinschrittig und reaktiv voranzugehen. Hingegen gehört langfristige detaillierte Planung zum Rückgrat klassischer Qualitätssicherung. Im Konflikt zeigt sich auch ein Ringen um Deutungshoheit, Verantwortung, Zuständigkeiten und Rollen, die sich im Zuge einer Agilisierung verändern. Wie müssen wir die QS, die QS-Rollen, -Aufgaben und -Methoden verändern und weiterentwickeln, wenn die Produktentwicklung viel agiler wird?
Aus meiner Sicht ist es keine Option, die Agilisierung unter Verweis auf die klassischen, von modernen Agilitätsbestrebungen und -methodenanwendungen noch unbeeinflussten Anforderungen und Branchenstandards zu unterlassen oder auch nur zu bremsen. Für viele Unternehmen ist sie, die Agilisierung, und nicht die Orientierung an den System- Prozess- und Methoden-Anforderungen, überlebenswichtig. Sie soll schließlich Markteintrittsgeschwindigkeiten, Innovationsrate und Innovationsqualität sowie Kundenorientierung verbessern. Schnellere Markteintrittsgeschwindigkeiten, höhere Innovationsrate und gesteigerte Innovationsqualität können legitime strategische Ziele eines Unternehmens sein.
Es gilt, zuerst das Managementsystem so zu gestalten, dass es die Erreichung der eigenen Ziele und darunter auch die Qualitätsziele sehr gut unterstützt. Und weiter heißt es, den Feinschliff dann so zu machen, dass wir dabei auch die externen Anforderungen ans System erfüllen. Erfüllung der Systemanforderungen ist nicht das Ziel, sondern ihre Nichterfüllung ist das Antiziel des Qualitätsmanagements. Antiziel bedeutet: etwas, das nicht passieren darf, während wir streben, unsere Ziele zu erreichen. Bezogen auf Systemanforderungen bedeutet das: Wir müssen die Qualitätsziele des Unternehmens erreichen, ohne dass wir dabei gegen Systemanforderungen verstoßen. Bezogen auf die Pflicht zur Vorlage einer FMEA bedeutet das, wir verbiegen unseren agilen Entwicklungsprozess nicht so, dass unsere klassische FMEA dabei herausspringt. Sondern wir verändern unsere FMEA so, dass sie den agilen Entwicklungsprozess zumindest nicht stört, besser noch unterstützt. Das kann bedeuten, FMEA ganz anders zu machen, als bisher und unter anderem Elemente des Scrum-Prozesses für die neue FMEA mitzuzählen, mitzunutzen.
Und Hand aus Herz: War Ihre bisherige FMEA so gut und so valide, dass in ihr alle relevanten Risikobetrachtungen für Ihr Produkt für Sie selbst und für Ihre Kunden transparent nachvollziehbar waren? Oder war schon die alte FMEA ein nachgereichtes Stück Systembefriedigung? Ist es dann nicht besser, zusammen mit den Aguilleros einen neuen Ansatz der Risikobewertung (und anderer Elemente der Qualitätsvorausplanung) neu in den agilen Prozess einzuweben? Oder dafür geeignete vorhandene Elemente des agilen Prozesses zu erkennen und als Qualitätsvorausplanung zu deklarieren? Und wie müssen wir QS- und Entwicklerrollen, das QS-Aufgabenportfolio, das QS-Methodenportfolio und auch unsere QM- und QS-Organisation neu ausrichten und aufstellen, wenn das Ziel ist, mittels mehr Agilität, Innovationsraten, Innovationsqualität und Time-to-market zu verbessern?
Die launige Schlüsselfrage steht in der Überschrift, ich will sie abschließend erneut stellen: Wie bekommen wir (QS-)Butter bei die (agilen) Fische?
Wir wollen Kolleginnen und Kollegen aus QS- und Entwicklungsabteilungen die Möglichkeit zum Erfahrungsaustausch bieten. Stehen Sie vor den Herausforderungen, den Produktentwicklungsprozess mit neuen Methoden zu agilisieren und weiterhin die Einhaltung branchenspezifischer-QM-Standards, z.B. APQP, nachzuweisen? Wenn ausreichend Interesse besteht, richten wir eine Erfahrungsaustauschgruppe für DGQ-Mitglieder ein. Sie können sich dafür an benedikt.sommerhoff@dgq.de wenden.
Über den Autor: Benedikt Sommerhoff
Comments are closed.