Blog der Lösungsfabrik

Qualitätsmanagement und ISO 9001

ISO 9001 pragmatisch – Entwicklung

In diesem Blogbeitrag der Serie ISO 9001 pragmatisch werde ich versuchen, ein sprichwörtlich dickes Brett zu bohren. Es ist jetzt nicht so, dass die Normforderungen der ISO 9001 im Kapitel 8.3 Entwicklung super kompliziert sind, allerdings sind sie super kompliziert formuliert und es mit etwas über 3 Seiten mit das größte Unterkapitel in der Norm. Und aus meiner Erfahrung muss ich sagen, dass sich viele Unternehmen sehr schwer mit dem Normkapitel tun, obwohl es (meiner Meinung) relativ einfach ist.

Doch ich werde mich kurz und prägnant halten – versprochen.

Beginnen möchte ich wie immer mit dem Fokus darauf, was die Norm eigentlich fordert.

Was fordert die ISO 9001 im Kapitel 8.3 Entwicklung?

Unterteilt ist das Kapitel in folgende Unterkapitel:

  • 8.3.1 Allgemeines
  • 8.3.2 Entwicklungsplanung
  • 8.3.3 Entwicklungseingaben
  • 8.3.4 Steuerungsmaßnahmen für die Entwicklung
  • 8.3.5 Entwicklungsergebnisse
  • 8.3.6 Entwicklungsänderungen

Jetzt auf diese Unterkapitel einzeln einzugehen und die Detailforderungen herauszuselektieren, würde erstens den Rahmen eines Blogbeitrages sprengen und zweitens ist das meiner Meinung nach auch nicht nötig.

Ich würde mal die kompletten Hauptforderungen im Kapitel 8.3 folgendermaßen zusammenfassen: Die Entwicklung in einem Unternehmen muss geplant stattfinden und es muss einen dementsprechenden Prozess dafür geben. Das Unternehmen muss am Anfang bestimmen, was entwickelt werden soll und dabei Entwicklungseingaben festlegen. Während der Entwicklungsphasen muss (an geeigneten Stellen) überprüft werden, ob man auf dem richtigen Weg ist. Ebenso muss am Ende der Entwicklung geprüft werden. Ebenso muss man am Ende überprüfen, ob das Ergebnis den Anforderungen bzw. Entwicklungseingaben entspricht. Außerdem muss sichergestellt werden, dass wenn es während der Entwicklung Änderungen gibt, müssen diese überprüft werden, damit diese nicht konträr zu den Entwicklungseingaben sind.

So einfach ist das – und diese kurze Beschreibung ist ohne Verifizierung, Validierung, Steuerungsebene und weitere Fachvokabeln ausgekommen.

Dabei gilt es zu beachten, dass in der Norm explizit ein Prozess und somit auch eine Prozessbeschreibung bzw. -anweisung gefordert ist. Ebenso ist das Kapitel Entwicklung das Kapitel, in dem am meisten Nachweisdokumente von der ISO 9001 gefordert werden, und zwar zu Entwicklungsplanung, Entwicklungseingaben, Steuerungsmaßnahmen, Entwicklungsergebnissen und Entwicklungsänderungen.

Wer eine komplette Liste benötigt, an welcher Stelle die ISO 9001 Vorgabe- und Nachweisdokumente verlangt, findet diese hier.

Und was bedeutet das jetzt für die praktische Umsetzung?

Praktische Umsetzung

Wie schon oben beschrieben, brauchen Sie für den Prozess der Entwicklung eine Prozessbeschreibung.

Und die restlichen von der Norm geforderten Dokumente zum Nachweis, entstehen fast von allein. Denn egal wie – ob als klassisches Entwicklungsprojekt mittels Wasserfallmethode oder als agiles Projekt mit Sprints und allem was sonst noch dazugehört – wenn Sie die dabei geführten Kommunikationen (Kick-off-Meeting, Sprints, Meeting nach dem Erreichen von Milestones u.ä.) kurz protokollieren haben Sie nahezu alle Nachweisdokumente, die von der ISO 9001 gefordert werden.

Was ebenfalls empfehlenswert ist, wäre am Anfang einer Entwicklung mit einem Lasten- und Pflichtenheft zu arbeiten. So haben Sie auch einen Nachweisdokument für die Entwicklungseingaben und eventuell hilft Ihnen dies auch dabei, das Entwicklungsprojekt bzw. -ergebnis zu konkretisieren.

Praxistipps

An dieser Stelle möchte ich Ihnen auch zwei Praxistipps mit auf den Weg geben:

  1. Beim Entwicklungsprozess handelt es sich in der Regel um einen der komplexesten Prozesse im Unternehmen. Unterliegen Sie bitte nicht der Versuchung, in dieser Prozessdarstellung alle Eventualitäten mit abdecken zu wollen. Dies macht die Prozessdarstellung nur unnötig kompliziert und umfangreich. Vielleicht so umfangreich, dass sich diese am Ende keiner mehr anschaut und das wäre dann wirklich kontraproduktiv.
  2. Sollten Sie wirklich mit einem Pflichten- und Lastenheft arbeiten, so listen Sie gerne darin alle Funktionen, Parameter u.ä. auf, die das Entwicklungsprojekt beinhalten soll. Versuchen Sie es aber auch mal andersherum – listen Sie auch alle Funktionen und Parameter auf, die Sie nicht anstreben – sozusagen als Nicht-Ziel. Erfahrungsgemäß besteht die Gefahr, dass Entwicklungsprojekte zu kompliziert werden, weil zu viel angestrebt wird und auch zu viel noch während der eigentlichen Entwicklung hinzugefügt wird. Dem können Sie dadurch einen Riegel vorschieben.

, , ,

Schreibe einen Kommentar

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