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 leitet bei der DGQ das Themenfeld Qualität & Innovation. Er beobachtet, analysiert und interpretiert die Paradigmenwechsel und Trends in Gesellschaft und Wirtschaft sowie ihre Wirkungen auf das Qualitätsmanagement. Seine zahlreichen Impulse in Form von Publikationen und inspirierenden Vorträgen geben Orientierung in Zeiten des Wandels. Sie ermutigen zur Neukonzeption des Qualitätsmanagements und der Qualitätssicherung. Gemeinsam mit Expertinnen und Experten des DGQ-Netzwerks aus Praxis und Wissenschaft arbeitet Sommerhoff in Think Tanks und Pionierprojekten an der Entwicklung, Pilotierung und Vermittlung innovativer Konzepte und Methoden.

7 Kommentare bei “Darf ich Sie ‘mal ‘was fragen? – Wie bekommen wir (QS-)Butter bei die (agilen) Fische?”

  1. 93f9154fc1ebc0b6ac2d733790ce8608 Detlef Volke sagt:

    Ach lieber Herr Sommerhoff,
    es ist so gut und richtig, das Sie an der Stelle sind, wo Sie sind. Ein stets hohes Nivea für die brennenden Fragen der QM-Systeme. Schön und danke fürs teilen ;-D
    MfG von D. Volke

    1. 12fad89dbfa0bd7577219e8081bbd19e Benedikt Sommerhoff sagt:

      Danke, herr Volke, freue mich über Ihr Lob. Da fällt mir ein Satz aus der Studentenzeit ein: wir haben Niveau, wissen aber nie wo.

  2. 96aef4de1bcd26d9181a01b2f79bdbd5 Jürgen Wedel sagt:

    Vielen Dank, lieber Benedikt, für diesen treffenden Beitrag! Ein wichtiges Q-Werkzeug verliert seine Vorteile, wenn es nicht weiter entwickelt wird bzw. nicht mit der Zeit/ mit den Marktveränderungen mitgeht.

    Ich habe ein großes Interesse am Austausch in einer Erfahrungsaustauschgruppe für DGQ-Mitglieder.

    Bin ein erfahrener Qualitätsvorausplaner (Elektrotechnik und Automotive/eMobility) und ein begeisterter FMEA-Anwender. Bin tief in der Entwicklung involviert, bin aber im Herzen ein Qualitäter.

    Da ich noch (hoffentlich) einige Berufsjahre vor mir habe, möchte ich gern die zukünftige Qualitätsmethoden mitentwickeln. 🙂

    Mit inter-netten Grüßen
    J. Wedel

    1. 12fad89dbfa0bd7577219e8081bbd19e Benedikt Sommerhoff sagt:

      Klasse Jürgen, gut, Dich an Bord zu wissen. Sobald sich genügend Interessenten gefunden haben, sprechen wir gemeinsam über Form und Start unseres Erfahrungsaustausches.

  3. e1e16c46b95374cd8fb05145cc34df86 Gerd Streckfuss sagt:

    Hallo Herr Dr. Sommerhoff,

    ich habe in einem losen Netzwerk von Entwicklungsingenieuren (weitgehend über CAD/CAM Systeme) Ihre Frage weitergegeben
    und in Videochats diskutiert. Vorab: fast alle sind kein Mitglied der DGQ (ist eine andere Diskussion: Entwicklung, Software und DGQ).
    Ergebnis war:
    1, Man muss die Definition „Prozess“ und „Tools“ auseinanderhalten. Der deutsche Begriff „Methoden“ ist zweideutig (deshalb in englisch-sprachigen Diskussionen auch schwierig zu verwenden. Bp. Scrum ist eine Prozessdefinition und kein Tool.
    FMEA ist ein Tool und kein Prozess
    2. Einigkeit bestand bei der positiven Bewertung eines agilen Prozessens
    3. Ablehnung bestand überwiegend in einer Definition eines agilen Tools.
    Bp (ist simpel, ok): Ich will Löcher bohren (eine Funktion!) in eine Wand, um Bilder aufzuhängen. Der Prozess Kann starr sein (feste Planung vorab) oder agil (man fängt mal an zu bohren…)
    Tools können nun ausgewählt werden, Hammer mit Meisel bis zur automatischen Hilti. Agil räre: Ich fange mit Hammer/Meisel an und nehme dann die Hlti. Dies ist aber wein Wechsel und keine Agilität.
    3. Es gibt bei den Entwickluns-Werkzeugen („-Methoden“) eine zunehmende Forderung, diese flexibel so zu gestalten , dass nicht schon am Anfang alles festgelegt werden muss ( aus einem Meisel wird eine Hilti). Beispiele dafür sind viele Werkzeuge im Prozess des Anforderungsmanagement.
    4. Was ich persönlich bedauerte war die Auffassung vieler Teilnehmer, dass QM bei Punkt 3 nicht als Unterstützung angesehen wird (zu geringe Kenntnisse in Werkzeuge). Ich konnte leider auch keine Antwort auf Fragen nach PLM (CAD/CAM), oder Use-Cases, XP, RUP u.a. modern QFD, Funktionenanalyse mit WA u.a, geben. Diese fehlten in der letzten Zeit zu Thema Agilität, auch in den an sich wertvollen Vodeo-Konfrenzen. Die Beispiele mit den Tool „Postcript“ wurden als „grossväterlich“ bezeichnet. (hier Bp. der Kritikpinkt: wo ist eine einfache Bewertung einer Gewichtung der einzelnen Punkte).
    4. Es kann gut sein, dass wir uns alle geirrt haben (ist meine leise Hoffnung), dann ist Widerspruch hier sehr erwünscht: Aber: es geht um Werkzeuge, Tools und auch „Methoden“ und NICHT um Prozesse..
    Es bleibt meine große Anerkennung Ihrer Kommunikationsleistung innerhalb der DGQ
    Ihr Gerd Streckfuss

    1. 12fad89dbfa0bd7577219e8081bbd19e Benedikt Sommerhoff sagt:

      Klasse und danke, Herr Streckfuss, wie sie den Ball aufgenommen und weitergespielt haben. In Ihrem Kommentar stecken wichtige Impulse, die ich aufgreife.

  4. 9dcc9c922ba882703748f693afc98cdc Pasqual Jahns sagt:

    Wenn die FMEA ja (fast) immer eine Systembefriedigung ist und trotzdem ein gescheites Produkt heraus kommt, wäre ja die interessante Frage, wieso?
    Und wenn man dann noch die Frage stellt, wieso manchmal nicht, kommt man dann auf eine pragmatische Lösung die auch mit agilen Herangehensweisen kompatibel ist?

Schreibe einen Kommentar zu Gerd Streckfuss Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert