Wer ein QMS in 12 Monaten Wasserfall aufbaut, hat am Ende ein Aktenwerk — und ein Team, das es nicht trägt. Wir übersetzen Normkapitel in Epics, Teilprozesse in Features und Einzelanforderungen in User Stories. So entsteht ein QMS in 2-Wochen-Sprints, das auditfähig und gleichzeitig im Alltag wirksam ist.

Warum klassisches QM-Roll-out scheitert

Klassische QM-Einführungen folgen einem Wasserfall: GAP-Analyse, Konzeption, Dokumentation, Schulung, internes Audit, Zertifizierung. Zwischen Konzept und Inbetriebnahme liegen oft 9 bis 12 Monate. Das Ergebnis ist nicht selten ein Handbuch, das niemand liest, eine Norm, die niemand wiedererkennt, und Prozesse, die parallel zu denen weiterleben, die wirklich gelebt werden.

Der Grund ist nicht mangelnde Disziplin, sondern die Architektur des Vorgehens. Wer alles auf einmal plant, kann erst spät prüfen, ob die Lösung passt. Wer 100 Anforderungen gleichzeitig umsetzt, verliert die Priorisierung. Und wer ein QMS „top-down" baut, baut es ohne die Menschen, die es täglich tragen sollen.

Die agile Übersetzung

Agile Methoden — aus Software-Entwicklung, längst auch im Anlagenbau und in der Produktentwicklung etabliert — bieten eine klare Alternative. Drei Begriffe sind dafür entscheidend:

Epic — ein Normkapitel oder ein QM-Großthema

Ein Epic ist die größte Einheit. Es bündelt alles, was zu einem Themenfeld gehört. Beispiele aus ISO 9001:2015:

  • Epic 4.1–4.4: Kontext der Organisation — interne und externe Themen, interessierte Parteien, Anwendungsbereich.
  • Epic 5: Führung — Verantwortung, Qualitätspolitik, Rollen.
  • Epic 8: Betrieb — Planung, Anforderungen, Entwicklung, Beschaffung, Produktion.

Für FSSC 22000 v6 analog: Lebensmittelsicherheits-Management, HACCP, Allergen-Management, Quality Culture, Equipment Management — jedes als eigenes Epic.

Feature — ein Teilprozess innerhalb des Epics

Features zerlegen das Epic in Teilprozesse, die zusammen das große Ziel erfüllen. Beispiel Epic „Beschaffung und Lieferantenmanagement" (ISO 9001, 8.4):

  • Feature 1: Lieferanten-Bewertung und -Auswahl.
  • Feature 2: Lieferanten-Audit-Programm.
  • Feature 3: Wareneingangsprüfung.
  • Feature 4: Lieferanten-Performance-Monitoring.

Jedes Feature ist ein eigenständiger Prozess. Es hat einen Verantwortlichen, einen Input, einen Output und eine messbare Wirksamkeit.

User Story — die einzelne, prüfbare Anforderung

User Stories formulieren konkrete Anforderungen aus Sicht der Rolle, die sie umsetzen muss. Format: „Als Rolle möchte ich Aktion, damit Ergebnis." Beispiele zum Feature Lieferanten-Bewertung:

  • Als Einkäufer möchte ich neue Lieferanten anhand eines standardisierten Fragebogens bewerten, damit die Qualifikation nachvollziehbar ist.
  • Als Qualitätsmanager möchte ich kritische Lieferanten jährlich vor Ort auditieren, damit Risiken früh erkannt werden.
  • Als Produktionsleiter möchte ich die OTIF-Quote pro Lieferant einsehen können, damit ich Engpässe frühzeitig steuere.

Jede Story ist konkret, prüfbar und einer Rolle zugeordnet. Das ist die kleinste sinnvolle Liefereinheit eines QMS.

Die Definition of Done — was „fertig" wirklich heißt

Im klassischen QM gilt eine Anforderung als erfüllt, wenn sie im Handbuch steht. Im agilen QM gilt sie als erfüllt, wenn sie auditfähig ist. Wir verwenden eine konkrete Definition of Done für jede User Story:

  1. Prozess- oder Verfahrensdokument erstellt und im DMS abgelegt.
  2. Fachlich freigegeben (vier Augen).
  3. Verantwortliche Rolle benannt und im Organigramm hinterlegt.
  4. Norm-Bezug nachweisbar (welche ISO/FSSC-Klausel wird erfüllt).
  5. Schulung erfolgt und dokumentiert.
  6. Mindestens ein Wirksamkeits-Nachweis vorhanden (Aufzeichnung, KPI, Bericht).

Ein Punkt offen — Story bleibt im Sprint. Diese Strenge unterscheidet ein „papierfähiges" QMS von einem auditfähigen.

Sprint-Struktur — wie ein QMS in zwei Wochen wächst

Wir arbeiten in 2-Wochen-Sprints mit fester Struktur:

  • Sprint Planning (Tag 1, 2 h): Auswahl von 6–10 User Stories aus dem Backlog. Kapazität realistisch schätzen.
  • Daily Stand-up (täglich, 15 min): Fortschritt, Hindernisse, gegenseitige Hilfe.
  • Review (Tag 10, 90 min): Stories präsentieren, formal abnehmen.
  • Retrospektive (Tag 10, 60 min): Was hat funktioniert, was muss sich ändern.

Nach 6 Sprints (12 Wochen) liegt typischerweise ein tragfähiges MVQ-Fundament vor — siehe Artikel zum Minimum Viable QMS. Für die vollständige Zertifizierung folgt anschließend die Aufbauphase mit Qualitätspolitik, vollständigem internen Audit und Management Review.

Worauf wir besonders achten

Die Methode wirkt nur, wenn drei Bedingungen erfüllt sind:

  • User Stories aus Rollensicht, nicht aus Normsicht. „Die Organisation muss…" ist Norm-Sprache, kein User-Story-Format. Wir schreiben Stories so, dass die Rolle erkennt, was sie persönlich tut.
  • Vertikale Schnitte, keine horizontalen. Ein Sprint liefert ein komplettes Feature auditfähig, nicht „alle Dokumente zu allen Features halb fertig".
  • Eigentum bleibt beim Team. Wir moderieren, coachen, sichern Methodik. Aber die Stories liefert immer das Team, dessen Prozess beschrieben wird.

Fazit

Epics, Features und User Stories sind nicht nur Vokabular aus einer anderen Branche. Sie strukturieren ein QMS so, dass es in greifbaren Inkrementen wächst — und dass jeder Sprint einen Nutzen liefert, der über „mehr Dokumentation" hinausgeht. Auditfähig wird ein System, das im Alltag funktioniert. Auditfähig in Sprints heißt: jede zweite Woche ein Stück mehr Realität, nicht jedes Quartal ein neues Konzeptpapier.

Lean-QA: Auditfähige Qualitätssysteme in Sprints — nicht in Aktenordnern.