Entwicklung von Produkten und Dienstleistungen

In einfachen Worten

Diese Klausel gilt, wenn Sie selbst festlegen, wie ein Produkt oder eine Dienstleistung beschaffen sein wird — wenn Sie aus einer Anforderung eine Spezifikation machen, die es vorher nicht gab. Dann verlangt 8.3 einen beherrschten Weg: Etappen und Verantwortliche planen (8.3.2), die Eingaben vorher festschreiben (8.3.3), unterwegs steuern (8.3.4), brauchbare Ergebnisse liefern (8.3.5) und Änderungen unter Kontrolle halten (8.3.6).

Das Herz der Steuerung sind zwei verschiedene Fragen: Verifizierung — erfüllt das Ergebnis die Eingaben? — und Validierung — funktioniert es im echten Gebrauch? Ein Entwurf kann jede Spezifikation erfüllen und trotzdem am Alltag scheitern. Deshalb verlangt die Norm beide Prüfungen, nicht eine.

Davor steht die ehrliche Frage: Entwickeln wir überhaupt? Wer ausschließlich nach Kundenzeichnung fertigt, handelt oder standardisierte Leistungen erbringt, entwickelt nicht — und erklärt 8.3 im Geltungsbereich (4.3) begründet für nicht anwendbar. Diese Seite erklärt beides: die Klausel und die Grenze.

Warum es diese Anforderung gibt

Entwicklungsfehler sind die teuerste Fehlerklasse: Ein Irrtum in der Spezifikation vervielfältigt sich in jedes gefertigte Teil und jede erbrachte Leistung. Im Review kostet er eine Stunde, in der Serie eine Rückrufaktion. 8.3 zwingt die unsichtbare Denkarbeit in prüfbare Schritte — nicht um Kreativität zu bremsen, sondern damit Irrtümer auffallen, solange sie billig sind.

Und die Kehrseite, die dieselbe Klausel bewacht: Wer stillschweigend mitkonstruiert und 8.3 trotzdem ausschließt, verzichtet auf das Sicherheitsnetz genau dort, wo das Risiko am größten ist. Die Ausschlussfrage ist darum eine Ehrlichkeitsfrage — dieselbe, die beim Geltungsbereich (4.3) beginnt.

Wie „gut“ aussieht

Wer entwickelt, plant in Etappen, die zum Projekt passen — die Norm schreibt kein Wasserfallmodell vor; auch agiles Arbeiten erfüllt 8.3, wenn Eingaben, Prüfungen und Freigaben erkennbar sind. Die Eingaben stehen, bevor Lösungen entstehen: was es können muss, was Gesetz und Normen fordern, was aus Vorgängerprojekten gelernt wurde — Widersprüche werden aufgelöst statt vertagt. Unterwegs: Reviews mit Konsequenzen, Verifizierung gegen die Eingaben, Validierung im Einsatzkontext. Die Ergebnisse sind so, dass die nächste Stufe damit arbeiten kann — mit Annahmekriterien. Und Änderungen nach einer Freigabe gehen durch Bewertung und Genehmigung.

Wer nicht entwickelt, hält die Grenze sauber: Machbarkeits- und Fertigungswissen fließt als Vorschlag zum Kunden zurück und kommt als dessen geänderte Vorgabe wieder — nie als stille eigene Festlegung.

Was sich mit Wachstum ändert: Ab etwa 50 Personen — mit eigenen Produkten — braucht es benannte Projektverantwortliche, protokollierte Reviews und geplante Schnittstellen zu Einkauf und Fertigung. Ab 100–250 Personen: ein Entwicklungsprozess mit Meilenstein-Freigaben, eine Design-FMEA (eine systematische Fehleranalyse), wo Branche oder Kunden sie verlangen, Konfigurationsmanagement. Und in jeder Größe gilt: Wer neu zu entwickeln beginnt, holt sich 8.3 bewusst ins System — das ist eine Änderung des QMS und gehört geplant (6.3).

Minimum zum Bestehen

Wer entwickelt:

• Je Projekt ein Plan mit Etappen, Prüfungen und Verantwortlichen — im Umfang passend zur Projektgröße.
• Dokumentierte Eingaben, bevor entworfen wird.
• Verifizierung und Validierung nachweisbar durchgeführt — als zwei Fragen, nicht eine.
• Ergebnisse freigegeben; Änderungen danach mit Bewertung und Genehmigung.

Wer nicht entwickelt:

• Ein begründeter Ausschluss im Geltungsbereich (4.3) — und eine Praxis, die der Begründung standhält.

Was ein Auditor sehen will

• Ein Projekt längs erzählt: der Plan, die Eingabenliste, ein Review-Protokoll mit Konsequenzen, der Verifizierungsnachweis, die Validierung im echten Einsatz.
• Eine Änderung nach der Freigabe — mit Bewertung, Genehmigung und dem Weg zurück in Fertigung oder Erbringung.
• Bei Ausschluss: der Geltungsbereich mit Begründung — und Auftragsunterlagen, die zeigen, dass Spezifikationen vollständig vom Kunden kommen.
• Die Gegenprobe des Auditors: Website und Angebote — steht dort „Konstruktion" oder „Entwicklung", während 8.3 ausgeschlossen ist?
• Im Gespräch: Wer entscheidet bei Ihnen, wie das Produkt beschaffen ist? Die Antwort verortet die Designverantwortung — drinnen oder draußen.

Typische Fehler

• „Wir passen nur an." Wer Maße, Werkstoffe oder Abläufe festlegt, die der Kunde nie freigegeben hat, entwickelt — nur eben unkontrolliert. Anpassungen summieren sich zu Design.
• Verifizierung mit Validierung verwechselt. Alle Tests grün heißt: Die Spezifikation ist erfüllt. Ob die Spezifikation das Richtige verlangt hat, zeigt erst der echte Gebrauch — die teuersten Fehler wohnen zwischen den beiden Fragen.
• Bewegliche Eingaben. Anforderungen, die nie festgeschrieben werden, machen jedes Review wertlos — das Projekt jagt ein Ziel, das mitläuft.
• Der stille Konstrukteur. Der Vertrieb verspricht „wir lösen das für Sie", und niemand bemerkt, dass 8.3 gerade aufgewacht ist. Die Grenze muss allen bewusst sein, nicht nur der QS.
• Ausschluss aus Bequemlichkeit. 8.3 abwählen, weil es nach Aufwand aussieht — nicht, weil es nicht zutrifft. Die teuerste Form der Selbsttäuschung, und im Betriebsrundgang die kurzlebigste.
• Ergebnisse ohne Fertigungsblick. Entwickelt wird, was die eigene Werkstatt nicht messen oder fertigen kann. 8.3.5 verlangt brauchbare Ergebnisse — brauchbar für die, die danach arbeiten.

Beispiel

Die Berger Präzisionsteile GmbH entwickelt nicht — und hat das durchdacht statt nur behauptet. Im Geltungsbereich steht der Ausschluss mit Begründung: Gefertigt wird ausschließlich nach beigestellten Kundenzeichnungen; Machbarkeitsprüfungen erfolgen im Rahmen der Auftragsprüfung (8.2). Die Grenze wird täglich gelebt. Als Marco für ein Frästeil eine Werkstoffänderung vorschlug — besser zerspanbar, gleiche Festigkeit —, ging der Vorschlag schriftlich an die Konstruktion des Kunden und kam als neue Zeichnungsrevision zurück; erst dann wurde gefertigt. Fertigungswissen fließt zu, die Designverantwortung bleibt beim Kunden. In der Prüfliste zur Auftragsprüfung steht die Regel ausdrücklich: Technische Vorschläge gehen immer als Anfrage zum Kunden, nie als stille Abweichung in die Fertigung.

Im Zertifizierungsaudit hielt genau das stand. „Sie haben doch eine Werkstoffänderung angestoßen — entwickeln Sie da nicht?" Frau Berger zeigte den Schriftwechsel und die Revision des Kunden: Vorschlag ja, Festlegung nein. Und sollte aus der Baugruppenmontage (4.3) eines Tages ein eigenes Katalogprodukt werden, weiß Berger, was dann passiert: Der Ausschluss fällt, und 8.3 kommt über die Änderungsplanung (6.3) bewusst ins System. Ein Ausschluss ist eine Momentaufnahme des Geschäftsmodells — kein Besitzstand.

<!-- easo:worked_example profile=service -->

Die Klarwerk GmbH dagegen entwickelt — zum Beispiel das Kundenportal für ihren größten Auftraggeber. Der Plan: vier Etappen (Konzept, zwei Umsetzungsetappen, Einführung), am Ende jeder ein Review — bewusst nicht allein durch den einen zertifizierten Engineer, sondern mit dem zweiten Entwickler und dem IT-Leiter des Kunden. Die Eingaben standen vor der ersten Zeile Code: das Lastenheft, die Datenschutz-Vorgaben samt Löschkonzept, die Schnittstelle zur Warenwirtschaft, die Lehren aus dem Vorgängerprojekt. Verifiziert wurde mit automatisierten Tests gegen das Lastenheft; validiert in zwei Pilotwochen mit echten Sachbearbeitern des Kunden — dort fiel auf, dass die Freigabe im Alltag zu viele Klicks kostete: eine Erkenntnis, die kein Test findet. Die Ergebnisse: Bereitstellungs-Dokumentation, Admin-Handbuch, Schulungsunterlagen — das, womit Betrieb und Support danach arbeiten. Und mitten im Projekt der Änderungswunsch Single Sign-on: bewertet (Aufwand, Termin, Sicherheit), beauftragt, Etappenplan neu freigegeben — 8.3.6 statt stillem Ausufern.

← Alle ISO-9001-Themen · Zum Wissenshub