#32 Kapitel 8.3 der ISO 9001: Wann Entwicklung ins QM gehört – und wann ein Ausschluss sinnvoll ist

Vor allem die Frage, ob das Thema Entwicklung überhaupt anwendbar ist, sorgt regelmäßig für Gespräche mit Auditoren, Beratern und internen QM-Verantwortlichen. Genau deshalb lohnt sich ein nüchterner Blick: Nicht jede Organisation muss 8.3 automatisch in voller Breite anwenden – aber leichtfertig ausschließen sollte man es eben auch nicht.

Bei Unternehmen, die Produkte herstellen, ist die Sache meist recht klar. Wer etwas entwickelt, verändert und anschließend auf den Markt bringt, ist mitten im Thema. Das gilt nicht nur für komplette Neuentwicklungen, sondern auch für Änderungen an bestehenden Produkten. Denn eine Änderung ist oft mehr als nur eine Kleinigkeit. Eine andere Farbe, ein neuer Lieferant, eine geänderte Schraube oder ein anderer Werkstoff können technische, regulatorische oder sicherheitsrelevante Auswirkungen haben. Genau deshalb braucht Entwicklung Struktur: Anforderungen müssen definiert, Eingaben gesammelt, Risiken betrachtet, Ergebnisse geprüft und Änderungen nachvollziehbar dokumentiert werden.

Spannend wird es bei Dienstleistungen. Hier ist die Antwort deutlich seltener ein klares Ja oder Nein. Denn viele Dienstleister entwickeln nicht im klassischen Sinn neue Produkte, sondern arbeiten mit vorhandenem Fachwissen, regulatorischen Anforderungen und kundenspezifischen Lösungen. In solchen Fällen ist die eigentliche Leistung oft eher eine individuelle Anwendung von Wissen als eine echte Dienstleistungsentwicklung. Vieles, was im Alltag passiert, läuft dann eher unter kontinuierlicher Verbesserung als unter einem formalen Entwicklungsprozess. Und genau da liegt der entscheidende Punkt: Nicht alles, was sich verändert, ist automatisch Entwicklung nach 8.3.

Trotzdem sollte die Entscheidung nie aus Bequemlichkeit getroffen werden. Die bessere Frage lautet nicht: „Können wir 8.3 ausschließen?“, sondern: „Bringt uns dieses Kapitel in unserem Unternehmen einen echten Mehrwert?“ Wenn ein strukturierter Entwicklungsprozess hilft, neue Leistungen sauber aufzusetzen, Verantwortlichkeiten zu klären, Entscheidungen abzusichern und Wissen im Unternehmen zu halten, dann kann 8.3 auch für Dienstleister sinnvoll sein. Wenn dagegen nur ein Dokumentationsmonster entsteht, das keinen praktischen Nutzen bringt, ist ein sauber begründeter Ausschluss oft die bessere Lösung.

Wichtig ist dabei vor allem die Begründung. Ein einfaches „nicht anwendbar“ reicht in der Praxis selten. Wer Entwicklung ausschließt, sollte nachvollziehbar beschreiben, warum das Kapitel für das eigene Geschäftsmodell nicht relevant ist und wie Veränderungen stattdessen gesteuert werden. Genau das schafft Transparenz – intern wie extern. Und es hilft spätestens dann, wenn im Audit die Frage kommt, warum 8.3 draußen geblieben ist.

Gleichzeitig zeigt der Blick in die Norm auch, dass Entwicklung weit mehr ist als technische Dokumentation. Es geht darum, Ideen geordnet in einen Prozess zu bringen: Wer bringt Anforderungen ein? Wer prüft Machbarkeit, Ressourcen und Risiken? Wer entscheidet, ob aus einer Idee überhaupt ein Entwicklungsprojekt wird? Und wer gibt Ergebnisse am Ende frei? Gute Entwicklung erkennt man deshalb nicht an möglichst vielen Formularen, sondern daran, dass Entscheidungen nachvollziehbar sind und dass auch Jahre später noch klar ist, warum ein Produkt oder eine Leistung genau so gestaltet wurde.

Am Ende ist 8.3 also weder reine Pflichtübung noch Selbstzweck. Das Kapitel ist dann stark, wenn es Unternehmen dabei unterstützt, Entwicklungen bewusst, nachvollziehbar und risikoorientiert zu steuern. Für produzierende Unternehmen ist das in der Regel gesetzt. Für Dienstleister heißt es wie so oft im QM: Es kommt darauf an – aber bitte mit guter Begründung.

Unsere Top 5

• Bei produzierenden Unternehmen ist Kapitel 8.3 in der Regel klar anwendbar, weil Produktänderungen und Neuentwicklungen strukturiert gesteuert werden müssen.
• Bei Dienstleistungen muss genauer geprüft werden, ob wirklich eine Entwicklung vorliegt oder ob Veränderungen eher unter kontinuierliche Verbesserung fallen.
• Entwicklung beginnt nicht erst bei der technischen Umsetzung, sondern schon bei der strukturierten Bewertung von Ideen, Anforderungen, Ressourcen und Risiken.
• Auch kleine Produktänderungen können große Auswirkungen haben und sollten deshalb nachvollziehbar bewertet, dokumentiert und freigegeben werden.
• Ein Ausschluss von 8.3 ist möglich, sollte aber immer sauber begründet werden und darf nie aus reiner Bequemlichkeit erfolgen.