PDCA-Zyklus: Definition, Phasen, Beispiele und Umsetzung im Alltag (2026)

Die meisten Teams scheitern nicht an fehlenden Verbesserungsideen. Sie scheitern daran, dass die Ideen nie zurückkommen: Im Meeting wird eine Maßnahme beschlossen, alle nicken, und drei Wochen später weiß niemand mehr, was vereinbart wurde oder ob es funktioniert hat. Genau diese Lücke schließt der PDCA-Zyklus.

Dieser Leitfaden erklärt, was der PDCA-Zyklus ist, wie die vier Phasen in der Praxis funktionieren, und zeigt konkrete Beispiele aus Vertrieb und Produktentwicklung. Dazu kommen die fünf häufigsten Gründe, warum Zyklen versanden, eine ehrliche Einordnung der Kritik „PDCA ist veraltet", der Vergleich mit OODA und OKR, eine kopierbare Vorlage und die Frage, wie KI-Meeting-Notizen die beiden Phasen retten, die Teams am häufigsten fallen lassen: Check und Act.

⚠️ Dieser Artikel wurde auf Grundlage öffentlich zugänglicher Informationen und Nutzerfeedbacks mit Stand September 2026 unabhängig zusammengestellt.

Inhaltsverzeichnis

1. Was ist der PDCA-Zyklus?
2. Die vier Phasen im Detail
3. PDCA-Beispiele aus der Praxis
4. Warum PDCA scheitert: fünf typische Muster
5. Ist PDCA veraltet?
6. PDCA vs. OODA, KPT und OKR
7. Eine PDCA-Vorlage zum Kopieren
8. Checkliste vor dem ersten Zyklus
9. Check und Act mit KI-Meeting-Notizen automatisieren
10. Häufige Fragen (FAQ)
11. Fazit

Was ist der PDCA-Zyklus?

Der PDCA-Zyklus ist eine Methode zur kontinuierlichen Verbesserung in vier Phasen: eine Veränderung planen (Plan), sie im kleinen Rahmen umsetzen (Do), die Ergebnisse mit der Erwartung vergleichen (Check) und aus den Erkenntnissen Konsequenzen ziehen (Act), bevor der nächste Zyklus beginnt. Es handelt sich bewusst um einen Kreislauf, nicht um eine Checkliste. Ein einzelner Durchlauf ist nicht das Ziel. Das Ziel ist, dass jeder Durchlauf den Prozess ein Stück besser macht und sich das Gelernte aufsummiert.

Die Methode hat eine längere Geschichte als die meisten Management-Frameworks. Sie geht auf die Arbeiten von Walter Shewhart in den Bell Labs der 1930er-Jahre zurück und wurde durch W. Edwards Deming bekannt, der sie in den 1950er-Jahren japanischen Industrieunternehmen vermittelte. Im deutschsprachigen Raum ist sie auch als Demingkreis bekannt und bildet das Rückgrat des kontinuierlichen Verbesserungsprozesses (KVP) sowie vieler Qualitätsmanagementsysteme, etwa nach ISO 9001. Deming selbst bevorzugte übrigens die Bezeichnung PDSA mit „Study" statt „Check", weil er befürchtete, Teams könnten Check als reine Bestanden-oder-nicht-Prüfung missverstehen statt als Lernschritt. Diese Sorge war, wie sich zeigen wird, berechtigt.

Eine Leitfrage trennt Teams, die von PDCA profitieren, von Teams, die den Kreis nur auf Folien zeichnen: PDCA ist ein Hypothesentest, keine To-do-Liste. Die Plan-Phase bedeutet nicht „Aufgaben auflisten", sondern „festhalten, welche Veränderung welches Ergebnis bis wann bewirken soll und woran wir das messen". Enthält der Plan keine Vorhersage, hat die Check-Phase nichts zu prüfen, und der Zyklus verkommt still zu gewöhnlicher Aufgabenverwaltung.

Die vier Phasen im Detail

• Plan: Problem, Maßnahme und erwartetes Ergebnis definieren. Ein brauchbarer Plan beantwortet vier Fragen. Was genau ist das Problem, möglichst in Zahlen? Welche Veränderung probieren wir aus? Welches Ergebnis erwarten wir bis wann? Woran messen wir es, und wo liegen die Daten? Ein Plan wie „Reaktionszeit verbessern" fällt durch. Ein Plan wie „alle eingehenden Demo-Anfragen laufen über eine gemeinsame Warteschlange; wir erwarten, dass die Erstreaktionszeit innerhalb von drei Wochen von 9 Stunden auf unter 2 Stunden sinkt, gemessen im Helpdesk-Dashboard" besteht.
• Do: die Veränderung klein ausrollen und Abweichungen protokollieren. Der klassische Fehler ist, eine Maßnahme sofort im gesamten Team einzuführen, bevor sie den Realitätstest bestanden hat. Besser: zuerst mit einem Team, einer Region oder einer Woche Traffic testen. Ebenso wichtig ist das Protokoll der Abweichungen. Wenn der neue Prozess an stressigen Tagen übersprungen wurde, ist genau diese Beobachtung Gold für die Check-Phase, und ohne Notiz ist sie im nächsten Monat vergessen.
• Check: Ergebnisse mit der Vorhersage vergleichen, nicht mit dem Bauchgefühl. Diese Phase wird am häufigsten übersprungen, und genau das verwandelt PDCA in PD-PD-PD: einen endlosen Strom von Änderungen, ohne zu wissen, welche davon gewirkt haben. Ein echter Check beantwortet drei Fragen. Hat sich die Kennzahl wie vorhergesagt bewegt? Was lief anders als geplant, und warum? Was haben wir gelernt, das wir vorher nicht wussten? Wichtig: „Die Kennzahl hat sich nicht bewegt" ist ein erfolgreicher Check. Sie haben eine Hypothese kostengünstig widerlegt.
• Act: standardisieren, anpassen oder verwerfen, und zwar ausdrücklich. Act kennt genau drei Ausgänge. Übernehmen: Die Maßnahme hat funktioniert, wird zum neuen Standard, dokumentiert und ausgerollt. Anpassen: Die Idee scheint richtig, die Umsetzung braucht eine Korrektur, die zum Plan des nächsten Zyklus wird. Verwerfen: Die Hypothese war falsch, die Maßnahme wird beendet und der Grund festgehalten. Alle drei sind legitim. Der einzige Fehler in Act ist Schweigen, wenn der Pilot einfach unbegrenzt weiterläuft, ohne dass jemand entscheidet.

PDCA-Beispiele aus der Praxis

Abstrakte Kreisläufe lassen sich schwer nachmachen, deshalb zwei konkrete Beispiele.

Ein Vertriebsteam mit zu niedriger Follow-up-Quote.

• Plan: Nur 40 % der Erstgespräche erhalten innerhalb von 24 Stunden eine Follow-up-E-Mail. Hypothese: Wenn Follow-ups noch am selben Tag aus den Meeting-Notizen entworfen werden, erreicht die Quote innerhalb eines Monats 90 %, gemessen im CRM.
• Do: Zwei Wochen lang entwirft ein Pod die Follow-ups direkt nach jedem Gespräch aus den KI-Meeting-Notizen. Abweichungsprotokoll: Zwei Kollegen ließen den Prozess in einer Messewoche aus.
• Check: Die Quote im Pilot-Pod lag bei 85 %, in den Vergleichs-Pods bei 42 %. Auch die Antwortquote stieg. Das 24-Stunden-Ziel wurde vor allem an Tagen mit mehr als vier Terminen verfehlt.
• Act: Übernahme für das gesamte Team, mit einer Anpassung als nächstem Plan: Entwürfe gebündelt täglich um 16 Uhr statt nach jedem Gespräch.

Ein Produktteam mit wiederkehrenden Problemen am Release-Tag.

• Plan: Drei der letzten fünf Releases erforderten innerhalb von 48 Stunden einen Hotfix. Hypothese: Ein 30-minütiges Review anhand einer Pre-Release-Checkliste senkt die Hotfixes in der Release-Woche über die nächsten zwei Releases auf null.
• Do: Review vor den nächsten beiden Releases durchführen; jeden Checklistenpunkt protokollieren, der etwas findet.
• Check: Ein Release verlief sauber, eines brauchte weiterhin einen Hotfix, verursacht durch eine Konfigurationsänderung, die die Checkliste nicht abdeckte. Vier andere Probleme fing die Checkliste vor dem Release ab.
• Act: Anpassen statt übernehmen: Konfigurations-Diffs in die Checkliste aufnehmen und den Zyklus für zwei weitere Releases wiederholen.

Beide Beispiele funktionieren aus denselben Gründen: Der Plan enthält eine Zahl und einen Termin, die Do-Phase protokolliert Abweichungen, und Check vergleicht mit der ursprünglichen Vorhersage statt mit dem vagen Gefühl, dass es besser geworden ist.

Warum PDCA scheitert: fünf typische Muster

• Der Plan enthält keine Vorhersage. „Neuen Onboarding-Prozess ausprobieren" ist eine Aufgabe, keine Hypothese. Ohne erwartetes Ergebnis und Kennzahl wird Check zum Meinungsaustausch. Abhilfe: Do erst starten, wenn der Plan festhält „wir erwarten, dass X bis zum Termin Z auf Y steigt/sinkt".
• Check findet nie statt. Der Pilot startet, die Aufmerksamkeit wandert weiter, und niemand setzt das Review an. Abhilfe: Den Check-Termin in dem Moment buchen, in dem der Plan beschlossen wird, noch vor Beginn der Do-Phase. Ein Zyklus ohne Check-Termin im Kalender ist ein Zyklus, der sich nicht schließen wird.
• Die Entscheidungen verdunsten. Das Team bespricht die Ergebnisse durchaus, aber die Schlussfolgerungen leben nur im Gedächtnis Einzelner. Einen Monat später beginnt dieselbe Debatte von vorn. Abhilfe: Ein schriftliches Zyklus-Protokoll mit Plan, Ergebnissen und Act-Entscheidung führen und jedes Review mit dem letzten Eintrag eröffnen.
• Die Zyklen sind zu lang. Ein Quartalszyklus bedeutet vier Lerngelegenheiten pro Jahr, und beim Review erinnert sich niemand mehr an die Details. Abhilfe: Standardmäßig zwei bis vier Wochen; Quartals-Reviews dienen dazu, die Erkenntnisse der kurzen Zyklen zu bündeln.
• Check wird zur Schuldfrage. Wird eine widerlegte Hypothese als persönlicher Fehler behandelt, schlagen die Leute keine messbaren Pläne mehr vor, denn ein vager Plan kann nie widerlegt werden. Abhilfe: den Prozess beurteilen, nicht die Personen, und sauber widerlegte Hypothesen als günstigen Erkenntnisgewinn würdigen.

Ist PDCA veraltet?

Wer nach PDCA sucht, stößt schnell auf die These, die Methode sei altmodisch, zu langsam für das moderne Geschäft und längst durch OODA oder agile Methoden abgelöst. Die Kritik verdient eine klare Antwort, denn sie ist zur Hälfte berechtigt.

Der berechtigte Teil: PDCA passt schlecht, wenn sich die Lage schneller ändert, als ein Zyklus dauern kann. In einem laufenden Incident, einer dynamischen Verhandlung oder einem Wettbewerbsumfeld, das sich täglich verschiebt, hat niemand drei Wochen Zeit für einen Hypothesentest; dort passen Frameworks für schnelle Orientierung wie OODA besser. PDCA wird außerdem oft schlecht praktiziert, als jährliches Planungsritual mit pflichtschuldigem Check, und die Kritiker haben recht, dass diese Variante Papier statt Verbesserung produziert.

Der unberechtigte Teil: Für wiederholbare Prozesse unter eigener Kontrolle ist hypothesengetriebenes Iterieren kein bisschen gealtert. Was moderne Produktteams Build-Measure-Learn oder Growth-Experimente nennen, ist strukturell PDCA mit neuem Vokabular: Hypothese aufstellen, kleine Änderung ausliefern, gegen die Vorhersage messen, entscheiden. Nicht das Framework ist veraltet, sondern lange Zyklen und übersprungene Checks. Wer in Zwei-bis-vier-Wochen-Zyklen arbeitet und jeden Zyklus mit einer expliziten Act-Entscheidung abschließt, tut genau das, was die „modernen" Alternativen vorschreiben.

Das praktische Fazit: PDCA für Prozesse behalten, die man selbst steuert und messen kann, OODA-Denken für schnelle reaktive Situationen nutzen, und jede PDCA-Umsetzung mit Zyklen über einem Monat als Konstruktionsfehler behandeln, nicht als Grund, die Methode aufzugeben.

PDCA vs. OODA, KPT und OKR

Diese Frameworks werden oft als Konkurrenten dargestellt, beantworten aber unterschiedliche Fragen und lassen sich gut kombinieren.

Eine Kombination, die sich in der Praxis bewährt: OKRs legen fest, wohin das Quartal führen soll. PDCA-Zyklen sind der Weg, sich experimentell an diese Key Results heranzuarbeiten. KPT ist das Meeting-Format, mit dem viele Teams die Check-und-Act-Diskussion führen. Und OODA ist der Modus, in den man wechselt, wenn es brennt und Hypothesentests ein Luxus sind.

Eine PDCA-Vorlage zum Kopieren

Diese Vorlage in den gemeinsamen Arbeitsbereich kopieren und pro Zyklus duplizieren.

# PDCA-Zyklus ― [Prozess/Team] ― Zyklus Nr. [n]
Verantwortlich: [Name]   Zeitraum: [Start] → [Ende]   Check-Termin: [Datum, gebucht]

## Plan
- Problem (mit Zahlen): [Ist-Zustand]
- Maßnahme, die wir ausprobieren: [ein Satz]
- Vorhersage: Wir erwarten, dass [Kennzahl] von [X] auf [Y] bis [Datum] geht
- Datenquelle für die Kennzahl: [Dashboard/Report]

## Do (während des Zyklus ausfüllen)
- Gestartet: [Datum]   Umfang: [Pilotteam/-segment]
- Abweichungsprotokoll: [was wann ausgelassen oder geändert wurde]

## Check (im Review ausfüllen)
- Ergebnis: [Kennzahl vorher → nachher, im Vergleich zur Vorhersage]
- Was anders lief als geplant, und warum:
- Was wir gelernt haben:

## Act (genau eine Option wählen)
- [ ] Übernehmen ― als neuer Standard ausrollen; dokumentiert unter: [Link]
- [ ] Anpassen ― Plan des nächsten Zyklus: [ein Satz]
- [ ] Verwerfen ― Grund festgehalten: [ein Satz]

Drei Hinweise zur Nutzung. Den Check-Termin beim Schreiben des Plans buchen, nicht erst nach der Do-Phase. Das Abweichungsprotokoll während Do pflegen, denn diese Notizen machen den Check ehrlich. Und in Act genau ein Kästchen erzwingen; ein leerer Act-Abschnitt bedeutet, dass sich der Zyklus nie geschlossen hat.

Checkliste vor dem ersten Zyklus

• Ist das Problem mit einer Zahl beschrieben statt mit einem Adjektiv?
• Sagt der Plan ein konkretes Ergebnis mit Termin vorher?
• Ist die Datenquelle der Kennzahl vor dem Pilotstart vereinbart?
• Ist der Pilotumfang klein genug, um gefahrlos zu scheitern?
• Steht der Check-Termin bereits im Kalender?
• Ist eine Person als Zyklus-Verantwortliche benannt?
• Dauert der Zyklus höchstens vier Wochen?
• Gibt es einen festen schriftlichen Ort für das Zyklus-Protokoll?

Wer alle acht Punkte abhaken kann, liegt mit dem ersten Zyklus bereits vor den meisten PDCA-Einführungen.

Check und Act mit KI-Meeting-Notizen automatisieren

Ein Blick zurück auf die Fehlermuster zeigt ein Muster: PDCA stirbt selten in Plan oder Do. Es stirbt im Bindegewebe, dort, wo Ergebnisse in Meetings besprochen, Entscheidungen mündlich getroffen und nichts davon festgehalten wird. Das Check-Meeting findet statt, seine Aufzeichnung nicht.

Genau diesen Teil übernimmt ein KI-Meeting-Assistent. SuperIntern ist eine botlose Desktop-App für Mac und Windows, die Meetings direkt über den Geräteton aufzeichnet, ohne dass ein Bot dem Call beitritt. Dadurch funktioniert sie identisch in Zoom, Google Meet, Microsoft Teams und Webex sowie im Besprechungsraum, wo viele Check-Diskussionen tatsächlich stattfinden.

Für PDCA konkret:

• Dem AI Canvas das Zyklus-Format einmal beibringen. Die Anweisung „dies ist ein PDCA-Review; erfasse Ergebnisse im Vergleich zur Vorhersage, Abweichungen, Erkenntnisse und die Act-Entscheidung mit Verantwortlichen" genügt, und jedes Review erzeugt in Echtzeit ein strukturiertes Zyklus-Protokoll, während alle bei der Diskussion bleiben statt mitzuschreiben.

• Die Act-Entscheidung wird im Moment des Aussprechens erfasst. „Wir übernehmen die Warteschlange und schauen uns das Bündeln im nächsten Zyklus an" landet als Entscheidung mit Verantwortlichem in den Notizen, nicht als etwas, woran sich hoffentlich jemand erinnert.
• Vergangene Zyklen bleiben abfragbar. Vor dem nächsten Review lässt sich der meetingübergreifende KI-Chat fragen: „Was haben wir in den letzten drei PDCA-Reviews zum Onboarding-Prozess entschieden, und welche Vorhersagen sind noch offen?"
• Verteilte Teams prüfen in einer Sprache. Mit Echtzeit-Übersetzung in über 50 Sprachen braucht ein Check-Meeting zwischen Standorten keine gemeinsame Muttersprache, und jede Seite liest die Zusammenfassung in ihrer eigenen.

Der Ehrlichkeit halber: SuperIntern ist ein Live-Meeting-Rekorder mit Notizfunktion, kein Kennzahlen-Dashboard und kein Projektmanagement-Tool. Die Zahlen der Check-Phase kommen weiterhin aus den eigenen Analytics; viele Teams übertragen die beschlossenen Maßnahmen anschließend über die MCP-Integration von SuperIntern mit Agenten wie Claude oder ChatGPT in Tools wie Linear oder Jira. Es gibt einen kostenlosen Plan, der Test im nächsten Review kostet also nichts.

Häufige Fragen (FAQ)

Wofür steht PDCA?

Für Plan, Do, Check, Act: eine Veränderung mit vorhergesagtem Ergebnis planen, sie im kleinen Rahmen umsetzen, das Ergebnis mit der Vorhersage vergleichen und aus dem Gelernten Konsequenzen ziehen, indem die Maßnahme übernommen, angepasst oder verworfen wird.

Was ist der Unterschied zwischen PDCA und PDSA?

Es ist derselbe Zyklus mit einer umbenannten Phase. W. Edwards Deming bevorzugte „Study" statt „Check", um zu betonen, dass es in der dritten Phase um das Lernen aus Ergebnissen geht, nicht um eine Bestanden-oder-nicht-Prüfung. Wer im Check fragt „Was haben wir gelernt?", hat den Unterschied bereits abgedeckt.

Wie lange sollte ein PDCA-Zyklus dauern?

Zwei bis vier Wochen sind ein guter Standard für Geschäftsprozesse. Lang genug, damit sich eine Kennzahl bewegen kann, kurz genug, damit die Details beim Review frisch sind. Quartalslange Zyklen sind der häufigste selbstverschuldete Grund, warum sich PDCA langsam anfühlt.

Ist PDCA noch zeitgemäß, oder hat OODA es abgelöst?

Beide lösen unterschiedliche Probleme. OODA ist für schnelle, reaktive Situationen gebaut, in denen Orientierung wichtiger ist als Messung. PDCA ist für die bewusste Verbesserung von Prozessen gebaut, die man selbst steuert. Moderne experimentgetriebene Produktarbeit ist strukturell PDCA, egal wie sie genannt wird.

Woran scheitern die meisten PDCA-Vorhaben?

Die beiden Hauptursachen sind Pläne ohne Vorhersage, die einen echten Check unmöglich machen, und Check-Meetings, die nie angesetzt oder nie protokolliert werden, sodass das Gelernte verdunstet. Beides lässt sich durch Prozessdesign beheben, nicht durch mehr Anstrengung.

Funktioniert PDCA auch für Einzelpersonen?

Die Methode funktioniert in jedem Maßstab. Eine persönliche Variante, eine einzelne Veränderung der eigenen Arbeitswoche planen, umsetzen und am Freitag auswerten, ist ein risikofreier Weg, die Gewohnheit aufzubauen, bevor man sie ins Team trägt.

Fazit

PDCA hat neunzig Jahre überlebt, nicht weil die Methode raffiniert wäre, sondern weil sie die minimale ehrliche Struktur für Verbesserung ist: vorhersagen, ausprobieren, vergleichen, entscheiden. Teams, die damit kämpfen, kämpfen fast nie mit dem Konzept. Sie kämpfen mit Plänen, die nichts vorhersagen, mit Checks, die nie stattfinden, und mit Entscheidungen, die auf dem Weg aus dem Meetingraum verdunsten.

Wer diese drei Punkte behebt, bringt den Zyklus zum Laufen. Jeden Plan als Vorhersage mit Zahl und Termin formulieren. Den Check-Termin buchen, bevor die Do-Phase beginnt. Und das Meeting-Protokoll sich selbst schreiben lassen, damit Act-Entscheidungen länger überleben als das Gedächtnis derer, die sie getroffen haben.

SuperIntern kostenlos testen ― botlose KI-Meeting-Notizen, die Check-Ergebnisse und Act-Entscheidungen in Echtzeit festhalten und jeden Zyklus für das nächste Review durchsuchbar machen.