CTQ-Baum: Wie Sie Critical to Quality definieren

Ein CTQ-Baum ist eines der praktischsten Werkzeuge in Six Sigma. Er nimmt ein breites Kundenbedürfnis, etwa "Ich möchte ein zuverlässiges Produkt", und zerlegt es in konkrete, messbare Anforderungen, mit denen Engineering- und Prozessteams tatsächlich arbeiten können. Ohne diesen Übersetzungsschritt optimieren Teams am Ende Dinge, die gut klingen, aber nicht auf das zurückführen, was dem Kunden wirklich wichtig ist.

Der vollständige Name lautet Critical to Quality (CTQ)-Baum, und er ist typischerweise eines der ersten Werkzeuge, die in der Define-Phase von DMAIC eingesetzt werden. Er schlägt die Brücke zwischen der rohen Kundenstimme und den Zielkennzahlen eines Projekts.

Was ist ein CTQ-Baum?

Ein Critical-to-Quality (CTQ)-Baum ist ein strukturiertes Diagramm, das ein Kundenbedürfnis in Treiberkategorien übersetzt und diese dann in konkrete, messbare Qualitätsmerkmale mit definierten Leistungszielen aufschlüsselt. Er verläuft von links nach rechts: ein Bedürfnis, zwei bis vier Treiber pro Bedürfnis und zwei bis vier messbare CTQs pro Treiber.

Der Zweck ist Präzision. "Kunden wollen schnelle Lieferung" ist ein Bedürfnis. Es zeigt die Richtung, aber nicht das Ziel. Ein CTQ-Baum zwingt Sie dazu, zu fragen, was "schnell" für den Kunden tatsächlich bedeutet (ist es die Zeit von der Bestellung bis zum Versand, die Transitzeit von Tür zu Tür oder die Echtzeit-Sichtbarkeit der Sendungsverfolgung?), und dann die messbare Vorgabe zu definieren, die, wenn erreicht, das Bedürfnis erfüllt.

CTQ-Bäume stammen aus der Voice of the Customer (VoC)-Forschung. Die VoC erfasst die rohe Kundensprache. Der CTQ-Baum übersetzt diese Sprache in technische und betriebliche Begriffe. Von dort aus werden diese CTQs zu den Y-Größen (abhängigen Variablen), um die herum ein DMAIC- oder DMADV-Projekt aufgebaut wird.

Wichtige Fakten

• Unternehmen, die Qualitätskennzahlen direkt mit Kundenanforderungen verknüpfen, senken Fehlerkosten um 20-30 % im Vergleich zu Unternehmen, die sich ausschließlich auf intern abgeleitete Vorgaben stützen (American Society for Quality, State of Quality Report 2023).
• Schlechte Qualität kostet US-Hersteller je nach Reifegrad ihrer Qualitätssysteme etwa 5-30 % des Bruttoumsatzes (ASQ Quality Cost Survey).
• Six-Sigma-Projekte, die mit einem validierten CTQ-Baum beginnen, erreichen die Improve-Phase im Schnitt 40 % schneller, weil das Messsystem bereits korrekt abgegrenzt ist (iSixSigma-Branchenbenchmarks).

Die drei Ebenen eines CTQ-Baums

Jeder CTQ-Baum hat genau drei Ebenen. Jede Ebene beantwortet eine andere Frage.

Die CTQ auf Ebene 3 muss immer ein Ziel und eine Spezifikationsgrenze tragen. "Unter 3 Tagen" ist eine CTQ. "Schnell" ist keine. Wenn Sie dafür keinen Bestehen/Durchfallen-Test formulieren können, sind Sie noch nicht bei Ebene 3 angekommen.

CTQ-Baum vs. andere Qualitätswerkzeuge

CTQ-Bäume funktionieren als Teil einer Kette, nicht isoliert. Zu verstehen, wo sie im Verhältnis zu anderen Werkzeugen stehen, verhindert Verwirrung darüber, wann welches Werkzeug einzusetzen ist.

Voice of the Customer (VoC) erfasst, was Kunden in ihren eigenen Worten sagen, durch Umfragen, Interviews, Support-Tickets und NPS-Kommentare. Sie ist qualitativ und oft vage. Eine VoC-Erhebung könnte "Ich wünschte, der Bestellprozess wäre weniger verwirrend" zutage fördern, was ein Bedürfnis, aber keine messbare Vorgabe ist.

Der CTQ-Baum sitzt unmittelbar hinter der VoC. Er nimmt diese rohe Kundensprache und strukturiert sie in die dreistufige Hierarchie. Das Ergebnis des Baums ist eine Liste messbarer CTQs mit Zielwerten. Diese CTQs fließen dann in den Messplan ein.

KPIs sind operative Kennzahlen, die das Unternehmen fortlaufend verfolgt. Sie bilden möglicherweise Kunden-CTQs ab oder auch nicht. Der Baum ist die Methode, mit der Sie diese Zuordnung bestätigen. Wenn ein KPI sich nicht auf einen Treiber und ein Bedürfnis im CTQ-Baum zurückführen lässt, verfolgt er etwas Internes, das dem Kunden womöglich egal ist.

Quality Function Deployment (QFD) (das House of Quality) nimmt CTQs und bildet sie auf Design- oder Prozessparameter ab. Der CTQ-Baum kommt zuerst; QFD ist das, was Sie mit dem Ergebnis machen.

In einem DMAIC-Projekt gehört der Baum in die Define-Phase, die VoC speist den Baum, und der Baum speist das Messsystem in der Measure-Phase.

Häufige Fehler

Bei Ebene 2 stehenbleiben. Teams definieren oft Treiber und nennen sie CTQs. "Bestellbearbeitungsgeschwindigkeit" ist ein Treiber, keine CTQ. Sie müssen eine Ebene weiter gehen und einen numerischen Zielwert festlegen.

CTQs erstellen, die sich nicht messen lassen. Wenn Ihr Team über kein System verfügt, das Daten zu einer CTQ erfassen kann, ist sie noch keine funktionierende CTQ. Beheben Sie entweder die Messlücke oder überarbeiten Sie die Vorgabe.

Interne Prozessziele mit Kunden-CTQs vermischen. "Kommissionierzeit im Lager um 15 % senken" ist ein internes betriebliches Ziel. Es kann einen Treiber unterstützen, ist aber keine CTQ, es sei denn, ein Kunde interessiert sich speziell für die Kommissionierzeit. CTQs leben im Bezugsrahmen des Kunden, nicht in dem des Prozessverantwortlichen.

Zu viele CTQs. Ein einzelnes Bedürfnis kann realistisch von sechs bis zehn CTQs getragen werden. Teams, die dreißig CTQs pro Bedürfnis generieren, vermischen meist mehrere Bedürfnisse, und der Projektumfang bläht sich auf. Halten Sie den Baum schlank. Eine gut abgegrenzte CTQ ist mehr wert als fünf sich überschneidende.

Validierung überspringen. Ein CTQ-Baum, der in einem Konferenzraum entsteht, ohne ihn mit echten Kundendaten abzugleichen, ist eine Hypothese. Prüfen Sie Treiber und CTQs immer gegen tatsächliche VoC-Eingaben, bevor Sie sie festschreiben.

So bauen Sie einen CTQ-Baum

Schritt 1: Voice-of-the-Customer-Daten sammeln

Bevor Sie etwas zeichnen, sammeln Sie rohe Kundeneingaben. Interviews, Umfragen, Beschwerdeprotokolle, NPS-Verbatims, Aufzeichnungen von Verkaufsgesprächen. Sie benötigen mindestens 20-30 verschiedene Kundenaussagen, um Muster zu erkennen. Gruppieren Sie ähnliche Aussagen zu Themen.

Schritt 2: Das Kundenbedürfnis identifizieren

Formulieren Sie aus Ihren VoC-Themen ein Bedürfnis in klarer Kundensprache. Bleiben Sie auf Ergebnisebene. "Meine Bestellung schnell und unversehrt erhalten" ist eine gute Bedürfnisformulierung. "Eine pünktliche Lieferquote von 98 % haben" beginnt bereits, die Lösung vorwegzunehmen.

Ein CTQ-Baum pro Bedürfnis. Wenn Sie drei verschiedene Bedürfnisse haben, bauen Sie drei Bäume. Kombinieren Sie sie nicht.

Schritt 3: Treiber sammeln

Fragen Sie: Welche Faktoren würden, wenn sie gut funktionieren, dieses Bedürfnis erfüllen? Treiber sind Leistungskategorien, noch keine Messungen. Für "meine Bestellung schnell und unversehrt erhalten" könnten Treiber sein: Bestellbearbeitungsgeschwindigkeit, Leistung des Speditionspartners, Verpackungsintegrität und Sichtbarkeit der Sendungsverfolgung.

Streben Sie zwei bis fünf Treiber pro Bedürfnis an. Weniger bedeutet, dass Ihnen wahrscheinlich etwas fehlt. Mehr als fünf bedeutet, dass einige Ihrer Treiber verkappte CTQs sein könnten.

Schritt 4: Messbare CTQs mit Zielwerten definieren

Definieren Sie für jeden Treiber zwei bis vier CTQs. Jede CTQ muss haben:

• Ein klares, messbares Merkmal (z. B. "Transitzeit in Werktagen")
• Einen Zielwert (z. B. "3 Tage")
• Eine Spezifikationsgrenze (z. B. "höchstens 5 Tage bei 99 % der Bestellungen")

Prüfen Sie an dieser Stelle das SIPOC-Diagramm für Ihren Prozess. Es hilft zu bestätigen, welche Prozessergebnisse tatsächlich jeder CTQ entsprechen, damit Sie wissen, wo Sie Daten erheben müssen.

Schritt 5: Mit Kunden validieren

Legen Sie Ihre CTQ-Entwürfe einer Kundenstichprobe vor. Fragen Sie: Wenn wir dieses Ziel dauerhaft erreichen, würde das Ihr Bedürfnis erfüllen? Wenn die Kunden mit den Schultern zucken, ist die CTQ falsch. Wenn sie zustimmen, aber einen Vorbehalt anfügen, haben Sie einen neuen Treiber oder eine engere Vorgabe.

Dieser Schritt verhindert das häufigste Projektversagen: Teams verbringen Wochen damit, eine Kennzahl zu optimieren, die Kunden gar nicht interessiert.

Schritt 6: Priorisieren und den Projektumfang festlegen

Nicht jede CTQ wird zum Fokus eines Projekts. Rangieren Sie CTQs nach ihrer Wirkung auf die Kundenzufriedenheit und der aktuellen Lücke zwischen Leistung und Zielwert. Die CTQs mit der größten Lücke und der höchsten Kundenwirkung sind Ihr Startpunkt. Nutzen Sie DPMO- und Sigma-Level-Berechnungen, um die aktuelle Fehlerrate gegen jede CTQ-Vorgabe zu quantifizieren.

Beispiel eines CTQ-Baums

Dieses Beispiel folgt einem Online-Lieferdienst für Essen, der auf Kundenfeedback reagiert, dass "die Lieferung sich unvorhersehbar und langsam anfühlt".

Ein Projektteam würde dann die aktuelle Leistung gegen jede CTQ-Vorgabe bewerten, um festzustellen, welche fehlschlagen, um wie viel und in welchen Teilen des Prozesses. Das fließt direkt in die Measure-Phase von DMAIC ein, wo die Prozessfähigkeit (Cpk) für jede CTQ berechnet wird.

Best Practices

Halten Sie die Bedürfnisformulierung in der Sprache des Kunden. Widerstehen Sie dem Drang, sie in Businesssprache zu übersetzen. "Schnelle und vorhersehbare Lieferung" bleibt näher am Kunden als "Minimierung der Auftrags-bis-Tür-Zykluszeit".

Datieren Sie Ihre Bäume. Kundenerwartungen verschieben sich. Ein CTQ-Baum, der für einen E-Commerce-Kontext von 2022 gebaut wurde, kann bis 2026 zu lockere Zielwerte haben. Überprüfen Sie CTQs jährlich oder immer dann, wenn VoC-Daten eine Verschiebung der Zufriedenheitstreiber zeigen.

Verknüpfen Sie jede CTQ mit einem Prozessergebnis. Wenn Sie den Schritt in Ihrem Prozess nicht benennen können, der das CTQ-Ergebnis erzeugt, können Sie sie nicht messen. Ein SIPOC-Diagramm als Begleitdokument macht diesen Schritt schnell.

Überspringen Sie nicht den Messplan. Eine CTQ ohne Datenerfassungsplan ist ein Wunsch. Bevor der Baum finalisiert wird, bestätigen Sie, dass Datenquelle, Messhäufigkeit und Verantwortlicher alle zugewiesen sind.

Beziehen Sie das Prozessteam in Schritt 3 ein. Treiber, die nur von Projektleitern erarbeitet werden, übersehen tendenziell die betrieblichen Realitäten, die Mitarbeiter an der Front kennen. Gemischte Sitzungen liefern bessere Treiberlisten.

Häufig gestellte Fragen

Was ist der Unterschied zwischen einer CTQ und einem KPI?

Eine CTQ ist ein messbares Merkmal, das aus Kundensicht definiert wird, mit einem konkreten, an die Kundenzufriedenheit gebundenen Zielwert. Ein KPI ist eine interne Leistungskennzahl, die das Unternehmen für das operative Management verfolgt. CTQs sind kundenabgeleitet, KPIs sind unternehmensabgeleitet. Ein gut gestalteter Betrieb versucht, seine KPIs auf CTQs zurückzuführen, aber viele KPIs existieren aus Gründen, die nichts damit zu tun haben, was Kunden wichtig ist.

Wie viele CTQs sollte ein Six-Sigma-Projekt haben?

Ein einzelnes DMAIC- oder DMADV-Projekt fokussiert sich typischerweise auf ein bis drei CTQs. Wenn Ihr Baum fünfzehn CTQs unter einem Bedürfnis generiert, ist das für den Baum selbst normal, aber Sie würden dann für den Projektumfang auf die kritischsten priorisieren. Der Versuch, eine Leistungslücke bei zu vielen CTQs gleichzeitig zu schließen, verwässert den Teamfokus und erschwert die Isolierung von Grundursachen.

Kann man einen CTQ-Baum auch außerhalb von Six Sigma einsetzen?

Ja. Das Werkzeug funktioniert überall dort, wo Sie qualitative Anforderungen in messbare Spezifikationen übersetzen müssen: Produktentwicklung, Servicedesign, Software-QA, Onboarding in der Lieferkette. Die Methodik stammt aus Six Sigma, aber das Problem, das sie löst (vage Bedürfnisse in messbare Vorgaben verwandeln), ist universell.

Wo passt der CTQ-Baum in DMAIC?

Er gehört in die Define-Phase, nach der VoC-Forschung und vor der Finalisierung des Projektauftrags. Die CTQ-Ergebnisse werden zu den Y-Variablen im Projektauftrag und zu den Zielkennzahlen für die Measure-Phase. Wenn Sie DMADV für Designprojekte verwenden, sitzt der Baum dort ebenfalls in der Define-Phase.

Was ist der Unterschied zwischen einem Treiber und einer CTQ?

Ein Treiber ist eine Leistungskategorie, die die Kundenzufriedenheit beeinflusst. Er erklärt, warum ein Bedürfnis erfüllt wird oder nicht, ist aber allein nicht messbar. Eine CTQ ist das konkrete, messbare Merkmal innerhalb eines Treibers, mit einem Zielwert und einer Spezifikationsgrenze. "Lieferschnelligkeit" ist ein Treiber. "Tür-zu-Tür-Zeit unter 35 Minuten bei 90 % der Bestellungen" ist eine CTQ.

---

Kundenbedürfnisse in messbare Vorgaben zu übersetzen ist die Grundlage jedes Qualitätsverbesserungsprojekts. Ohne diese Übersetzung verbessern Teams die falschen Dinge. Mit einem CTQ-Baum verbindet sich jede Projektkennzahl mit etwas, von dem ein echter Kunde gesagt hat, dass es ihm wichtig ist, und genau das unterscheidet Prozessarbeit, die Zufriedenheitswerte bewegt, von Prozessarbeit, die nur Zahlen bewegt.

Weiterführende Inhalte

• Six Sigma
• DMAIC: Der fünfphasige Verbesserungszyklus
• DMADV: Design for Six Sigma
• Voice of the Customer (VoC)
• Quality Function Deployment (QFD)
• SIPOC-Diagramm
• DPMO und Sigma-Level
• Prozessfähigkeit (Cpk)