PDCA-ciklus (Plan-Do-Check-Act) — a folyamatos fejlesztés motorja

≈ 16 perc olvasás · 3128 szó

Reggel elkésel a munkából, másnap korábbra állítod az ébresztőt, este megnézed, beértél-e időben, és addig hangolod a rutint, amíg pont jó nem lesz. Ezt csinálod minden reggel, csak nem hívod így: ez a PDCA. Kitűzöl egy célt, kipróbálsz egy tervet, megnézed a tényleges eredményt, és a tanultak alapján módosítasz. A Lean ugyanezt a hétköznapi hurkot emeli tudatos módszerré a munkahelyi fejlesztéshez. Nézzük meg, mi ez, miért működik, és hogyan vezeted be.

A PDCA a folyamatos fejlesztés négylépéses, ismétlődő ciklusa: tervezünk, kicsiben kipróbálunk, tényadattal ellenőrzünk, majd szabványosítunk. A négy lépés a Plan (tervezés), Do (végrehajtás), Check (ellenőrzés) és Act (beavatkozás); a kör minden fordulat végén újraindul egy magasabb szintről. Lényege, hogy a fejlesztést kísérletként kezeljük: a változtatást ellenőrizhető feltevésként próbáljuk ki, és a döntést tényadat hozza meg, nem a benyomás. Más néven Deming-kör vagy Shewhart-ciklus; az A3 riport gyakorlatilag a PDCA-gondolkodás egylapos megjelenítése.

1. ábra — a PDCA négy fázisa zárt hurokként; minden kör végén szabványosítás (Act) vagy új ciklus.

Kinek szól?

Ez a cikk azoknak szól, akik a gyakorlatban is fejlesztenek folyamatot vagy oldanak meg problémát: operátor · műszak- és üzemvezető · folyamatmérnök · technológus · minőségmérnök · karbantartó · Lean/CI-szakember · projektvezető · HSE.

Tanulási célok

A cikk elolvasása után képes leszel:

elmondani a PDCA négy lépését, és megindokolni, miért a Check a leggyakrabban kihagyott, mégis kulcsfontosságú lépés;
megkülönböztetni a hétköznapi PDCA-t a munkahelyitől (mitől lesz belőle explicit, rétegzett struktúra);
végigvinni a rétegzett keretet: PHASE / ELEMENTS / CONTRIBUTORS / GATEWAYS, és megmondani, mi a kapu (gateway) szerepe;
megérteni, miért ugyanaz a gerince a PDCA, az A3 és a DMAIC;
felismerni, mikor nem a PDCA a helyes eszköz.

A lényeg (TL;DR)

Négy ismétlődő lépés: Plan → Do → Check → Act, majd újraindul.
Kísérleti logika: a fejlesztés hipotézis-tesztelés, nem ötletelés. A Check a kulcs.
A célhoz mérünk, nem a benyomáshoz: az eredményt mindig a tervezett célhoz és a kiinduláshoz hasonlítjuk.
Iteratív: minden befejezett kör egy magasabb standard kiindulópontja, a kaizen sosem „kész“.
Rétegzett struktúra: minden fázisnak van PHASE / ELEMENTS / CONTRIBUTORS / GATEWAYS rétege; a fázisok közt kapukon (pl. „Agree the PLAN“) lépünk át.
Közös gerinc: az A3 és a DMAIC is a PDCA-ra épül.

Miért számít? (a tét)

A PDCA nélkül a fejlesztés vakon ismételt cselekvéssé válik: bevezetünk egy változtatást, és sosem mérjük vissza, hogy tényleg segített-e. A tét nem egy elrontott projekt, hanem a tanulás elmaradása és a visszacsúszás, ami minden lezáratlan körrel halmozódik.

Ha a Check kimarad, az eredményt érzésre ítéljük meg, nem tényadatra. Ha az Act kimarad, a bevált megoldás nem épül be standardba, ezért néhány hónap múlva a régi állapot visszatér, és ugyanazt a problémát oldjuk meg újra. Így csúszik a szervezet tűzoltásba (fire-fighting): folyton a következő tűznél kapkod, ahelyett hogy a meglévőből teljesen tanulna és lezárná.

Mi a PDCA-ciklus, és hogyan működik?

A PDCA egy zárt hurok: megtervezel egy változtatást (Plan), kicsiben kipróbálod (Do), tényadattal a célhoz méred az eredményt (Check), majd szabványosítasz vagy korrigálsz (Act), és a kör újraindul. A négy lépés részletesen:

Plan (Tervezés) — értsd meg a vevői igényt, a problémát és a jelenlegi állapotot; tűzz ki mérhető célt; fogalmazz meg ellenőrizhető hipotézist a megoldásra (a gyökérok ellen, lásd 5-miert).
Do (Végrehajtás) — vezesd be a változtatást kicsiben, kontrollált körülmények között, és gyűjts adatot.
Check (Ellenőrzés) — hasonlítsd össze a tényleges eredményt a tervezett céllal és a kiindulással: működött-e a hipotézis, mit tanultál? Ez a leggyakrabban kihagyott lépés, pedig ez adja a tanulást.
Act (Beavatkozás) — ha működött, szabványosítsd és terjeszd ki (új standard); ha nem, korrigálj és indíts új ciklust.

Ezután a kör újraindul az új, magasabb szintről, így a szervezet lépésről lépésre, tanulásalapon javul. A mozgatóerő egy hármas gondolat: hipotézis → kísérlet → értékelés (P – D – C). A feltevést (az ellenintézkedést) valós körülmények között teszteljük, és a döntést tényadat hozza, nem a vélemény.

Honnan ered a PDCA?

A PDCA Walter Shewhart statisztikai minőség-ellenőrzéséből indult, és W. Edwards Deming népszerűsítette; innen a „Deming-kör“ elnevezés (más néven PDCA wheel vagy PDSA). Deming maga a tanuláshoz kötötte a ciklust, ezért a Check helyett gyakran a Study (tanulmányozás) szót használta. A Lean a Toyota Production System révén tette a napi problémamegoldás és a kaizen alapműveletévé.

A folyamatos fejlesztés a vállalati kultúra kulcseleme, de a lelkes hozzáállás önmagában kevés: rendszerrel (a PDCA struktúrájával) kell megerősíteni, különben elszáll a lendület. Épp ezt adja a ciklus: keretet, amelyben a jó szándékból megismételhető, mérhető fejlesztés lesz.

A hétköznapi és a munkahelyi PDCA különbsége

Otthon szabadon körözöl a hurokban: a reggeli rutint addig hangolod, amíg jó nem lesz, és senkinek nem kell elszámolnod. A munkahelyi PDCA-nak több megkötése van, mert mások is érintettek. Itt ugyanis:

fel kell mutatni az előnyt, mielőtt bármit teszünk (show benefits before doing anything);
kontrollálni kell a tevékenységet menet közben (control the activity as it happens);
kommunikálni kell minden érintettnek arról, hogy mit és miért csinálunk (communicate to all concerned what is being done and why).

Ezért a munkahelyi PDCA egy explicit, rétegzett struktúrát kap, amit a következő szakasz fejt ki.

Mi a PDCA rétegzett szerkezete?

A munkahelyi PDCA egy rétegzett meta-keret: minden fázisnak ugyanaz a négy rétege van. A PHASE → ELEMENTS → CONTRIBUTORS egyre részletesebb (ráközelítünk a fázisra), a GATEWAYS pedig a fázisok közti átlépés feltétele.

Réteg	Mit jelent
PHASE	maga a fázis (Plan / Do / Check / Act)
ELEMENTS	a fázis fő építőkövei (mit kell elérni a fázisban)
CONTRIBUTORS	a sikert hozó részletek, „belül“ minden elemhez
GATEWAYS	a kapu, amelyen át kell jutni, mielőtt a következő fázisra lépünk

2. ábra — a PDCA négy rétege: a fázistól a részletekig egyre mélyebbre nagyítunk, a kapuk (gateways) pedig két fázis között engednek tovább.

A négy fázis rendre 4 / 2 / 2 / 3 fő elemmel dolgozik. A következő szakaszok ezt bontják ki fázisonként.

PLAN — 4 kérdés (elem)

A sikeres tervezéshez négy kérdést kell megválaszolni:

Set the Goal — mit akarsz elérni?
Grasp the actual situation — hol állsz most, tények alapján?
State Activities — mit kell tenned a célhoz?
Resources — mi kell az akcióterv befejezéséhez?

A négy elem „belül“ (contributors):

Elem	Contributors (a siker részletei)
Set the Goal	SMART (Specific, Measurable, Achievable, Realistic, Timebound); a MUST és WISH megkülönböztetése, ahol a MUST a minimum vevői követelmény (minimum Customer Requirement)
Grasp the actual situation	a probléma tisztázása (clarify the problem); a „would-be“ ötletek megfogalmazása (mit lehetne tenni); megegyezés arról, mi lesz megtéve (agree what will be done)
State Activities	munka-befejezés (work completion): SMART, logikus taskok, felelős (Responsibility), ütemterv és vizuális megjelenítés; monitoring: tény vs. cél (show versus target), problémák kiemelése, az ellenőrzés nyomásának fenntartása a haladásért (apply pressure of checking)
Resources	6 erőforrás-típus: Money (pénz), Skilled people (képzett emberek), Time (idő), Expertise (szaktudás), Material/Equipment (anyag/eszköz), Support (támogatás)

GATEWAY (PLAN → DO): „Agree the PLAN“ — a kimerítő tervet jóvá kell hagyatni, mielőtt a végrehajtásba kezdünk.

DO — 2 blokk (elem)

A végrehajtás két blokkban zajlik:

Elem	Contributors
Do the activities	a taskok végrehajtása az ütemterv szerint (carry out the tasks, following your schedule); a haladás monitorozása (monitor progress)
Adjust as needed	erőforrások újrairányítása (retarget resources); a tevékenységek sorrendjének módosítása (change order of activities); új erőforrás allokálása (allocate new resources)

GATEWAY (DO → CHECK): „Share big adjustments with customers“ — a nagyobb menet közbeni módosításokat (mellékhatásokat) meg kell osztani a vevőkkel, mielőtt továbblépünk.

CHECK — 2 elem

Az ellenőrzés két dolgot értékel: az eredményt és a folyamatot.

Elem	Contributors
Evaluate the results	a SMART cél teljesülése (SMART goal achievement); effect = nincs járulékos kár (no collateral damage)
Evaluate the process (ARM)	Measure — mi történt (what has happened); Record — írd le (write it down); Analyse — mit mond az infó (what does the information tell you)

A folyamatot az ARM (Measure–Record–Analyse) segítségével értékeljük helyesen; ez válaszol arra a kérdésre, hogy „ugyanígy csinálnád-e újra?“.

ACTION — 3 elem

A beavatkozás három elem közül választ a Check kimenetétől függően:

Elem	Mikor	Contributors
Countermeasure	ha a célt nem érted el	értsd meg, miért bukott: a cél megváltozott (goal changed); a tervet nem követték (plan not followed); rossz terv (a terv nem fedett le mindent, wrong plan)
Standardise	ha a célt elérted és a folyamat jó	a megismételhetőség és fenntarthatóság biztosítása: dokumentáld, mit és hogyan tettél; vizuális kontroll felállítása; ütemezett értékelés / audit
Kaizen	mindig	soha ne állj meg (never stand still): ha a cél elérve és a folyamat szabványosítva, javítsd vagy a standardot, vagy a folyamatot

A három elem összerakva a kaizen folyamatos motorja: a sikeres kört szabvánnyá zárjuk, a kudarcot ellenintézkedéssel javítjuk, és a legjobb állapotot is tovább tökéletesítjük.

A PDCA mint az A3 és a DMAIC gerince

A A3 riport a PDCA egylapos vizuális dokumentációja: a bal oldal a Plan (háttér, jelenállapot, elemzés, cél), a jobb oldal a Do–Check–Act (ellenintézkedés, megvalósítási terv, eredmény, követés). A DMAIC (Define–Measure–Analyze–Improve–Control) ugyanennek a kísérleti logikának az adatvezérelt, Six Sigma-változata. Aki a PDCA-t érti, mindkettőt érti.

Folyamatipari kontextus

Folyamatiparban a PDCA a szabványosított fejlesztés, a problémamegoldás és a korrekciós intézkedések motorja, egyben az MOC (moc) háttérlogikája. Minden változtatást (paraméter-optimalizálás, karbantartási rutin módosítása, incidens vagy near-miss utáni korrekció) tervezni, kontrolláltan bevezetni, mérni és értékelni kell, mielőtt szabványosítjuk. A Check méri, hogy a beavatkozás valóban megszüntette-e a kockázatot vagy a veszteséget. Ez illeszkedik az ISO 45001 és a folyamatbiztonsági menedzsment folyamatos fejlesztési (continual improvement) követelményéhez.

Hogyan vezeted be a gyakorlatban?

A PDCA nem plakát a falon, hanem egy konkrét problémán körbejárt hurok. Javasolt menet egy első körhöz:

Válassz egy fájó, mérhető problémát, és tűzz ki rá SMART célt (Plan). Rögzítsd a jelenállapotot tényadattal, ne emlékezetből.
Fogalmazz meg egy ellenőrizhető hipotézist a megoldásra, és hagyasd jóvá a tervet (a „Agree the PLAN“ kapu).
Vezesd be kicsiben egy műszakon vagy egy soron (Do), és gyűjts adatot menet közben.
Mérd vissza a célhoz (Check): teljesült-e a SMART cél, van-e járulékos kár, ugyanígy csinálnád-e újra?
Zárd le a kört (Act): ha bevált, írd standardba és terjeszd ki; ha nem, ellenintézkedés és új ciklus.

Kidolgozott példa (forráshű). Egy szakmai konferencia szervezői a rendezvény után visszajelzést gyűjtöttek a résztvevőktől: a kivetítést hátulról nehéz volt olvasni, csak fizetős parkoló volt a környéken, az ebéd helyszíne szűkösnek bizonyult, az időtartás akadozott, és a külföldi vendégek is magyar nyelvű konferenciatáskát kaptak. Ez a Check a korábbi rendezvényen. A következő évi konferenciára ezekből lettek a Plan és Act elemei: nagyobb, jobban látható vetítés, megoldott parkolás, tágasabb ebédhelyszín, szigorúbb moderálás, kétnyelvű anyagok. A hurok egy egész rendezvény szintjén futott végig: mérték, mi ment rosszul, megtervezték a javítást, bevezették, és a következő körben újra mérték.

Mérés / audit

A PDCA működését néhány egyszerű mutatóval követheted: mennyire pörög a hurok, és tényleg lezárul-e a tanulással. Három hasznos jelzőszám:

Lezárt PDCA-körök száma és átfutási ideje (mennyire pörög a fejlesztési hurok).
Check-arány: a bevezetett változtatások hány százalékát mérték vissza ténylegesen a célhoz.
Fenntartási arány: az Act-ban szabványosított megoldások hány százaléka tartja az eredményt 3–6 hónap múlva is.

Gyakori hibák

A PDCA buktatói szinte mind ugyanabból fakadnak: a hurkot félbehagyjuk, és a cselekvés marad meg a tanulás helyett. Anti-minta ↔ korrekció párokban:

A Check kihagyása („bevezettük, biztos jó“). Miért baj: tanulás nélkül a ciklus puszta cselekvéssé válik, és nem tudod, segített-e a változtatás. Helyette: mérd vissza a tényleges eredményt a célhoz, mielőtt továbblépnél.
Benyomás a tényadat helyett. Miért baj: az eredményt érzéshez, nem a tervezett célhoz mérik, így a döntés megalapozatlan. Helyette: ARM (Measure–Record–Analyse), és a SMART cél a mérce.
Túl nagy első lépés. Miért baj: ha azonnal teljes körben vezeted be, egy rossz feltevés nagyot üt. Helyette: kicsiben, kontrollált körülmények között teszteld, aztán terjeszd ki.
Nincs Act-szabványosítás. Miért baj: a sikeres változás nem épül standardba, ezért néhány hónap múlva visszacsúszik. Helyette: dokumentálj, állíts fel vizuális kontrollt és ütemezett auditot (standard-munka).
PDCA mint egyszeri projekt. Miért baj: ha a kör nem indul újra, a fejlesztés megáll a legutóbbi standardnál. Helyette: a lezárt kört tekintsd a következő kiindulópontjának (kaizen).

Mikor NE használd? (a módszer korlátai)

A PDCA a legtöbb fejlesztésre a helyes alapkeret, de nem minden helyzetre az erős válasz. Tudni, hol nem elég, éppolyan fontos, mint maga a módszer:

Helyzet	Miért nem (elsősorban) a PDCA	Mi a helyes válasz
Azonnali, biztonságkritikus veszély	nincs idő tervezni-tesztelni; a hurok lassú	azonnali beavatkozás / vészleállás a vonatkozó szabvány szerint ([[lopa-sil	SIL/LOPA]]), a PDCA csak utólag a kivizsgálásra
Ismeretlen gyökérok	a Do egy vak hipotézist tesztel, ami időt éget	előbb ok-feltárás (5-miert, [[a3-riport	A3]]), utána PDCA a megoldásra
Egyszeri, nem ismétlődő eltérés	nincs mit tartósan standardizálni és körözni	eseti korrekció, a tanulság rögzítése
Radikális, egészen új megoldás kell	a lépésenkénti finomítás nem visz áttöréshez	átütő újratervezés (folyamat-újratervezés, innováció), majd PDCA a stabilizálásra

Ökölszabály: a PDCA az ismétlődő, mérhető, inkrementálisan javítható problémákra a legerősebb. Azonnali veszélyre és ismeretlen gyökérokra nem helyettesíti a megfelelő eszközt, hanem kiegészíti.

Vidd haza (kulcsok)

Fejleszd kísérletként, ne ötletként: feltevés → kicsi teszt → tényadat → döntés. Ez a PDCA magja.
A Check nem opció: ha nem méred vissza a célhoz, nem tudod, javítottál-e. A leggyakrabban kihagyott, mégis legfontosabb lépés.
Zárd le az Act-tal: a bevált megoldást írd standardba, különben visszacsúszik.
A kör újraindul: minden lezárt kör egy magasabb szint kiindulópontja, a kaizen sosem „kész“.
Egy lap is elég: a munkahelyi PDCA-t az A3 fogja egy lapra; ott a bal oldal a Plan, a jobb a Do–Check–Act.

Önteszt

A négy lépés közül melyik a leggyakrabban kihagyott, és mi a következménye, ha kimarad?
Mi a különbség a hétköznapi (reggeli rutin) és a munkahelyi PDCA között? Nevezd meg a munkahelyi PDCA három plusz megkötését.
A Check azt mutatja, hogy elérted a célt, és a folyamat is jó volt. Melyik Act-elemet választod, és mi a következő lépés utána?

Hogyan jelenik meg a digitális gyakorlatban?

A PDCA nem áll meg a papíron vagy a fali táblán: ugyanez a hurok szoftveresen is megvalósul, bármely jól tervezett fejlesztés-nyilvántartó rendszerben. A kézzel vezetett akcióterv helyett itt strukturált mezők, kényszerített lezárás és automatikus visszamérés viszik a „tervezz → csináld → ellenőrizd → zárd le“ ciklust; a mechanizmus más, az elv ugyanaz.

PDCA-elem	Digitális megvalósítás	Mit ad
Plan	strukturált akció-rekord: cél, felelős, határidő, kiindulási érték	a terv rögzített és nyomon követhető, nem vész el
Do	státusz-követés, a végrehajtás lépéseinek naplózása	látszik, hol tart a bevezetés
Check	a lezáráshoz kötelező eredmény-mező: a cél teljesülése kimutatva	a kör nem zárható „ellenőrzés nélkül“
Act	szabvány / munkautasítás frissítése, a megoldás sablonná emelése	a bevált változás beépül, nem csúszik vissza
Iteráció	a visszatérő problémák automatikus kimutatása	látszik, hol kell új kört indítani

Kapcsolat az OPEREX-hez (műszaknapló)

A műszaknapló (OPEREX) a PDCA Do és Check fázisának természetes nyoma: az ott rögzített eltérések, intézkedések és azok lezárása dokumentálja, hogy a tervezett fejlesztés megtörtént és ellenőrzött lett. Így a ciklus végigkövethető, auditálható, és a korrekciós intézkedések hatékonysága visszamérhető, auditálható bizonyítékot adva a folyamatos fejlesztési hurokra (ISO 45001, 10. fejezet: Improvement).

Terminológia (HU / EN)

Magyar	Angol	Megjegyzés
Tervezés	Plan	probléma, cél, hipotézis
Végrehajtás	Do	kis léptékű, kontrollált teszt
Ellenőrzés	Check	eredmény a célhoz mérve
Beavatkozás / szabványosítás	Act	standardizál vagy korrigál
Deming-kör	Deming cycle	a PDCA másik neve (PDCA wheel, PDSA)
Ellenintézkedés	Countermeasure	a gyökérok elleni terv; Act-elem, ha a cél nem teljesült
Kötelező vs. kívánatos	MUST vs WISH	a MUST a minimum vevői követelmény
Kapu	Gateway	a fázisok közti átmenet feltétele („Agree the PLAN“)
ARM (Mérés–Rögzítés–Elemzés)	ARM (Measure–Record–Analyse)	a folyamat értékelésének eszköze a Check-ben
Szabványosítás	Standardise	Act-elem, ha a cél teljesült és a folyamat jó

GYIK

Mit jelentenek a PDCA betűi magyarul?

Plan = tervezés, Do = végrehajtás, Check = ellenőrzés, Act = beavatkozás/szabványosítás. Ez a folyamatos fejlesztés négylépéses, ismétlődő ciklusa.

Miért ciklus a PDCA?

Mert nem egyszeri projekt: minden befejezett kör végén a tanulság alapján vagy szabványosítunk, vagy új ciklust indítunk, így a szervezet folyamatosan, lépésről lépésre javul.

Mi a kapcsolat a PDCA és az A3 riport között?

Az A3 a PDCA egylapos, vizuális dokumentációja: a bal oldal a Plan (háttér, jelenállapot, elemzés, cél), a jobb oldal a Do–Check–Act (ellenintézkedés, terv, eredmény, követés).

Miért a Check a legfontosabb lépés?

Mert ez méri tényadattal, hogy a változtatás valóban elérte-e a célt. Check nélkül nincs tanulás, és a fejlesztés vakon ismételt cselekvéssé válik. A Check egyben a leggyengébb láncszem is: ahogy a célok nőnek, a prioritás a következő tevékenységek (Do) felé tolódik a tanulás helyett, így csúszik az ember tűzoltásba.

Mi a PLAN négy kérdése?

(1) Set the Goal — mit akarsz elérni (SMART cél, MUST vs. WISH); (2) Grasp the actual situation — hol állsz most, tények alapján; (3) State Activities — mit kell tenned a célhoz (taskok + monitoring); (4) Resources — mi kell a befejezéshez (6 típus: pénz, képzett emberek, idő, szaktudás, anyag/eszköz, támogatás). A PLAN-ból a DO-ba az „Agree the PLAN“ kapun át lépünk.

Mit jelent az ARM a Check fázisban?

Az ARM a folyamat értékelésének eszköze: Measure (mérd, mi történt) – Record (írd le) – Analyse (mit mond az információ). Ezzel állapítható meg, hogy ugyanígy csinálnád-e újra a munkát.

Mit teszek az Act fázisban, ha elértem a célt, és mit, ha nem?

Ha a célt elérted és a folyamat jó: Standardise (dokumentálj, vezess be vizuális kontrollt, ütemezz auditot), majd Kaizen (javítsd tovább a standardot vagy a folyamatot). Ha a célt nem érted el: Countermeasure — értsd meg, miért bukott (a cél megváltozott, a tervet nem követték, vagy rossz volt a terv), és indíts új ciklust.

Kapcsolódó fogalmak

a3-riport · kaizen · dmaic · standard-munka · 5-miert · lean-alapok

Következő lépés

Ha ezt megértetted, innen érdemes tovább menned, ebben a sorrendben:

a3-riport — a PDCA egylapos formája: ezen gyakorlod, hogy a hurok egyetlen áttekinthető lapra kerüljön. Kezdd ezzel.
5-miert — a gyökérok-elemzés, amely a Plan hipotézisét megalapozza: a PDCA csak akkor talál, ha a helyes okra céloz.
kaizen — a kultúra, amelyben a PDCA-kör folyamatosan pörög, és a lezárt kör mindig a következő kiindulópontja.

Hivatkozások / További olvasnivaló

W. Edwards Deming: Out of the Crisis. MIT Press, 1986. — a Shewhart-ciklus (PDSA) és a tényalapú, tanulás-központú fejlesztés kanonikus alapműve.
Walter A. Shewhart: Statistical Method from the Viewpoint of Quality Control. Graduate School, U.S. Department of Agriculture, 1939. — a ciklus statisztikai gyökere (specifikáció–gyártás–ellenőrzés hurok).
Taiichi Ohno: Toyota Production System: Beyond Large-Scale Production. Productivity Press, 1988. — a PDCA a napi kaizen és a gyökérok-alapú problémamegoldás motorjaként.
John Shook: Managing to Learn: Using the A3 Management Process. Lean Enterprise Institute, 2008. — az A3 mint a PDCA-gondolkodás egylapos gyakorlata.