ISO 9001 · Kapitel 6 · 6.3
Die Planung von Änderungen
In einfachen Worten
Wenn Sie Ihr QMS wesentlich verändern — eine neue Maschine, die Abläufe umkrempelt; neue Software; ein Umzug; eine neue Struktur; ein neues Leistungsfeld —, verlangt diese Klausel nur eines: tun Sie es geplant. Vorher bedenken: Wozu die Änderung, und welche Folgen kann sie haben? Bleibt das QMS dabei intakt — Dokumente, Prüfungen, Schulungen, Zuständigkeiten? Sind Ressourcen da? Und müssen Verantwortungen neu verteilt werden?
Kein Formular ist vorgeschrieben, kein Änderungsantrag, kein Gremium. Verlangt ist ein bewusstes Vorgehen — und dass man es hinterher nachvollziehen kann.
Die Abgrenzung, die Verwirrung spart: 6.3 meint Änderungen am System (Prozesse, Struktur, Werkzeuge des QMS). Änderungen an Produkt und laufender Fertigung — geänderte Zeichnung, neuer Fertigungsschritt — regelt die eigene Klausel 8.5.6. Die Denkbewegung ist dieselbe, die Flughöhe nicht.
Warum es diese Anforderung gibt
Reife Systeme brechen selten im Normalbetrieb — sie brechen beim Wechsel. Die neue Maschine läuft, aber die Prüfmittel fehlen; die neue Software ist da, aber niemand hat die Verfahren angepasst; der Umbau ist fertig, aber die Zuständigkeit für die Zwischenprüfung ging im Umzug verloren. Fast jede größere Abweichung, die ein Auditor findet, hat eine ungeplante Änderung in ihrer Vorgeschichte.
Die Klausel ist deshalb die Praxis-Schwester von zwei anderen Stellen: 5.3 verlangt, dass jemand über die Integrität des QMS bei Änderungen wacht — 6.3 ist der Moment, in dem diese Person arbeitet. Und die Risiken-Denkweise aus 6.1 wird hier konkret: Eine Änderung ist ein geplantes Risiko-Ereignis.
Wie „gut“ aussieht
In einem Unternehmen mit 12 Personen gibt es zwei, drei echte QMS-Änderungen im Jahr — und für jede eine halbe Seite, oft als Abschnitt der Managementbewertung oder als kurze Aufzeichnung: Warum ändern wir? Was ist betroffen — welche Prozesse, Dokumente, Prüfungen, Schulungen, Rollen? Wer macht was bis wann? Und: Woran merken wir, dass die Änderung gelungen ist?
Alles darunter — der normale Fluss besserer Dokumente — braucht kein 6.3-Ritual: Dafür ist die Dokumentenlenkung mit ihren Versionen da. Die Kunst ist die Schwelle: geplant wird, was Abläufe, Zuständigkeiten oder Nachweise wirklich verschiebt.
Was sich mit Wachstum ändert: Ab etwa 50 Personen lohnt ein einfaches Änderungslogbuch plus eine Checkliste (Dokumente? Schulung? Prüfmittel? Schnittstellen?). Ab 100–250 Personen bekommen große Änderungen ein förmliches Änderungsmanagement mit definierten Freigaben — aber die Verhältnismäßigkeit bleibt der Maßstab: Ein Change-Board für jede Kleinigkeit ist die bürokratische Form des Selbstbetrugs.
Minimum zum Bestehen
- Die letzten wesentlichen QMS-Änderungen sind nachweisbar geplant: Zweck, betrachtete Folgen, Verantwortliche, Termine.
- Die Folgen wurden breit gedacht — nicht nur Technik, sondern Dokumente, Schulung, Prüfungen, Zuständigkeiten.
- Die Planung entstand vor der Änderung, nicht als nachträgliche Dokumentation (das Datum verrät es).
- Die betroffenen Dokumente und Schulungen wurden tatsächlich nachgezogen — zeitnah, nicht Monate später.
Was ein Auditor sehen will
- Die letzte echte Änderung als Geschichte: neue Maschine, neue Software, Umbau — „Zeigen Sie mir, wie Sie das geplant haben."
- Die Versionsdaten der angepassten Dokumente rund um den Änderungszeitpunkt — hinkt die Doku der Praxis hinterher?
- Schulungs- oder Einweisungsnachweise zur Änderung.
- Die 5.3-Frage dazu: Wer hat bei dieser Änderung über die Integrität des QMS gewacht?
- Das Erfolgskriterium: Woran haben Sie festgemacht, dass die Änderung gelungen ist — und haben Sie nachgeschaut?
Typische Fehler
- Erst ändern, dann dokumentieren. Die Planung entsteht rückwirkend fürs Audit — erkennbar an Daten, die nach der Änderung liegen. Peinlicher als gar keine Planung.
- Nur die Technik geplant. Die Maschine ist bestellt, Aufstellung und Strom sind durchdacht — Rüstblätter, Prüfplan, Einarbeitung und Wartung fehlen. Die Folgenliste der Klausel ist genau dagegen gebaut.
- Die Doku hinkt. Die neue Praxis läuft seit Monaten, die Verfahren beschreiben die alte — einer der häufigsten Auditfunde überhaupt, und ein vollständig vermeidbarer.
- Niemand führt. Die Änderung „passiert", aber niemand ist benannt, der sie durchzieht und das QMS mitnimmt. 5.3 lässt grüßen.
- Alles formalisieren. Jede Dokumentkorrektur durch ein Änderungsverfahren schleusen — das erstickt die Verbesserung, die die Norm eigentlich will. 6.3 meint die wesentlichen Änderungen.
- 6.3 mit 8.5.6 verwechseln. Die geänderte Kundenzeichnung ist 8.5.6; die Umstellung der Fertigungssteuerung auf neue Software ist 6.3. Wer beides in einen Topf wirft, macht eines von beiden schlecht.
Beispiel
Die 5-Achs-Maschine der Berger Präzisionsteile GmbH — im Buch bereits als Chance (6.1) und Kontextthema (4.1) aufgetaucht — war auch ihre lehrreichste 6.3-Übung. Die Planung: eine halbe Seite in der Managementbewertung. Zweck: komplexere Medizintechnikteile (Jahresziel aus 6.2). Betroffen: Fertigungsprozess, Rüst- und Programmblätter (neu zu erstellen), Prüfplan, Einarbeitung von zwei Werkern, Wartungsplan, Versicherung. Verantwortlich: Marco, mit Terminen je Punkt. Erfolgskriterium: Erstserien-Ausschuss unter 5 % innerhalb von drei Monaten — wurde erreicht.
Die Pointe kam später: Das interne Audit (9.2) fand veraltete Rüstblätter — der erfahrene Werker arbeitete nach Kopf. Die Ursachenanalyse zeigte: Die Änderungsplanung hatte das Erstellen der Blätter enthalten, aber keinen Änderungsdienst — niemand war benannt, der geänderte Blätter künftig freigibt. Genau diese Lücke wurde als 6.3-Nachtrag geschlossen (Freigaberegel für Rüstblätter, Verantwortlicher: Marco). So gehört es zusammen: Die ungeplante Restfolge einer Änderung wurde vom Audit gefunden und von der Änderungsplanung gelernt — der Kreislauf, den die Norm meint.
So deckt easo das ab
Klausel 6.3 verlangt kein Pflichtdokument — sie zählt nicht in den Readiness-Nenner. In easo hat die Änderungsplanung trotzdem ein natürliches Zuhause:
- Die halbe Seite Planung lebt als Abschnitt der Managementbewertung oder als kurze eigene Aufzeichnung — freigegeben, versioniert, signiert; die Maßnahmen daraus als nachverfolgbare Aufgaben (was/wer/bis wann).
- Die Dokumentenseite jeder Änderung ist automatisch nachvollziehbar: Jede Anpassung ist eine signierte neue Version mit Datum — ob die Doku der Praxis hinterherhinkt, ist in easo keine Vermutung, sondern ablesbar.
- Änderungen an Prozessregister, Rollen und Unternehmenseinstellungen sind signierte Commits — wer wann was am System selbst geändert hat, steht fest, ohne dass es jemand extra aufschreibt.
Bleiben Sie auf dem Laufenden
easo ist für macOS verfügbar — die Windows-Version folgt in Kürze. Sagen Sie uns Bescheid, und wir melden uns, sobald sie da ist.