PDCA as a steering tool — the methodological view
To the point: The PDCA cycle (Plan, Do, Check, Act) is a repeatable, four-step loop for structured improvement. It works in the Mittelstand mainly when it is anchored to a concrete end-to-end process (order handling, goods receipt, complaints), owned by a named process owner, and run through three to five iterations against clearly defined KPIs — not as an annual project, but as a weekly rhythm.
Roughly 70 percent of continuous-improvement initiatives in the Mittelstand fall asleep within twelve months — not because the PDCA cycle is conceptually weak, but because it is treated as a QM textbook slide rather than as an operational steering tool tied to an ERP rollout or a train-the-trainer programme. Walter A. Shewhart formulated the logic of the learning cycle in 1939 at Bell Labs as a three-step sequence. W. Edwards Deming carried the methodology to Japan in the 1950s and later coined the PDSA variant, in which "Study" deliberately replaces "Check".
The Deming Institute points out that Deming considered "Check" too weak: anyone who only verifies whether a plan was carried out learns nothing about the underlying theory. Studying compares prediction with outcome and corrects the model. In most firms where we introduce the method, the Check step is interpreted as a status review — "did we do it?" replaces "did the problem shrink?". The first is a project report; the second is improvement learning.
The American Society for Quality describes PDCA as a repeatable four-step cycle in which the "Do" means a small-scale experiment, not the roll-out. ISO 9001:2015 (clause 0.3) anchors PDCA as the structural principle of the quality-management system: clauses 4–7 describe Plan, clause 8 Do, clause 9 Check, and clause 10 Act. Anyone working to ISO has PDCA implicitly as an architecture — the question is not whether PDCA is lived, but where and how deeply.
Our take: Across more than 50 Mittelstand projects we have made the same observation — the methodological bottleneck almost never lies in understanding the four letters, but in how the Check step is run. Anyone running Check as a status review is doing project management under the label of improvement.
Plan, Do, Check, Act — the four phases in ERP practice
To the point: The phases are quickly explained — the difficulty lies in anchoring them to a concrete process, not in understanding the terms. Plan and Check together cost about 60 percent of the time, Do and Act roughly 20 percent each.
Phase one is Plan. Name the problem, back the current state with data, describe the target state in quantified terms, formulate a hypothesis, set the metrics. In ERP projects this means: one concrete process chain (for example "purchase-order creation to goods receipt in division A") is measured over four to six weeks. With the process owner we define a lead KPI (lead time, error rate, rework rate) and a complementary quality KPI. No target state, no plan.
Phase two is Do. The planned change is implemented on a small scale — one division, one plant, one ordering channel. In the Mittelstand "small" often means the whole department, because larger pilots are not feasible. What matters is that the pilot runs with a defined start time, a defined data set, and a defined abort criterion. Anyone starting Do as "let's see what happens" gets no usable data in Check — only anecdotes.
Phase three is Check. Here the hypothesis from Plan is held against the result of Do — not project progress against the plan. If the hypothesis was "activating mandatory field X reduces error Y by 30 percent in four weeks", the Check question is: did the error rate drop by 30 percent? If not, the hypothesis was wrong or the execution sloppy — both are useful findings. If yes, the solution moves into Act. Anyone documenting only activity in Check is turning the cycle without learning.
Phase four is Act. The confirmed solution is standardised — not in a workshop minute, but in the process documentation, the ERP customising, the training matrix, and the onboarding of new staff. Without these four anchor points the improvement regresses with the next personnel change. Then the next cycle starts on the next bottleneck.
Our take: Effort is asymmetric across the four phases. Anyone wrapping up the Plan in 30 minutes extends the total cycle, because Check is unusable without a clean hypothesis. A solid process analysis of the starting point is the investment that carries the rest of the cycle.
Practical example: south German kitchen manufacturer, 320 employees
To the point: The same south German kitchen manufacturer (€80M revenue, 320 employees) we describe in our process analysis entry reduced the material-master complaint rate in one division from 11.4% to 3.1% across four PDCA cycles — in 18 weeks. The lever was not the ERP, but mandatory-field logic and multiplier support.
The manufacturer saw a rise in complaint rate in one product division after migrating to a new ERP. The root-cause analysis showed: incomplete material master data — missing care indicators on surfaces, wrong units of measure in sales, inconsistent variant configurations. IT had implemented the system cleanly; the problem sat in the maintenance process of the operating department.
Plan (cycle 1). Hypothesis: activating four mandatory fields in material-master creation reduces the complaint rate below 5 percent within six weeks. Lead KPI: complaint rate per order. Complementary KPI: share of incompletely created material masters. Pilot: one product division with around 1,200 active material masters.
Do. Mandatory fields activated in customising, the creation path extended by a plausibility check, three multipliers from product management trained. Duration: two weeks.
Check. After a four-week measurement window the complaint rate sat at 6.8 percent — an improvement, but below target. Analysis showed that two mandatory fields were filled but with substantively wrong values ("dummy" entries to release the master record quickly). The hypothesis had been framed too narrowly.
Act. The plausibility check was extended with range checks; the multipliers took over a weekly spot-check audit. The change was carried into the customising document and into the onboarding materials for new product managers. Three further cycles followed — each triggered by a fresh bottleneck observation in the weekly board. After 18 weeks the complaint rate sat stably at 3.1 percent.
Our take: The case is typical — the ERP works correctly, the bottleneck is in the data-maintenance process. Without a weekly Check meeting under a named process owner, the second loop (the range check) would never have been triggered. The first improvement from 11.4% to 6.8% would have counted as "success" enough to close the initiative.
PDCA + train-the-trainer: anchoring through multipliers
To the point: Mittelstand firms do not have a twenty-strong OpEx department. PDCA has to scale through a handful of multipliers, otherwise the cycle dies with the first personnel change. Three multipliers across 250 employees is enough — if the executive team takes the quarterly review seriously.
In large corporates PDCA runs through a dedicated continuous-improvement department with Black Belt structures and Hoshin Kanri cascades. In the Mittelstand that infrastructure does not exist — and would not be appropriate. Instead we recommend pairing PDCA with the train-the-trainer methodology: two to five internal multipliers are trained as PDCA coaches who in turn support teams. This scales without overhead and binds the method to people who are already present in day-to-day work.
Choosing the multipliers is more critical than the method training itself. In our projects three selection criteria have proven their worth: first, operational credibility in their own line; second, willingness to put uncomfortable data in front of colleagues; third, stability in the role for at least 18 months. Anyone failing one of those three should not become a multiplier — the method gets administered rather than carried.
The sustainment ritual is the heart of it: a weekly shopfloor board with three columns (active PDCAs, wins, escalations), a fortnightly multiplier circle, a quarterly review with the executive team. That is not reporting overhead, but a deliberately light cadence that prevents the yo-yo effect.
Our take: Three multipliers across 250 employees is enough — if the executive team takes the quarterly review seriously and does not let it degrade into a status duty. Five multipliers without executive anchoring will not carry the method.
PDCA vs. DMAIC vs. OODA vs. A3 — which tool, when
To the point: The four methods solve different problems. Anyone who knows only PDCA will tackle problems with PDCA that DMAIC or OODA would resolve more efficiently. In the Mittelstand we typically start with PDCA because it has the lowest entry barrier.
PDCA suits continuous, small-step improvement on stable processes. Effort per cycle: low. Data demand: moderate. Typical duration: two to eight weeks per loop. Mittelstand applications: master data quality, lead times, complaint rates, onboarding speed.
DMAIC (Define, Measure, Analyze, Improve, Control) is the Six Sigma sibling of PDCA for problems whose causes are not obvious and that justify statistical depth. Effort: high. Data demand: high (samples, variance analysis, hypothesis testing). Typical duration: four to six months. Applications: complex quality problems with multiple possible causes, such as scrap rates in series production.
OODA (Observe, Orient, Decide, Act) was developed in a military context by John Boyd and fits decision situations under high uncertainty and time pressure. PDCA is too slow when the market shifts in days. OODA is the right tool in crisis cells, during cyber incidents, or in response to supply-chain disruption.
A3 is less a method than a format — a single-page problem-solving document in DIN-A3 size that forces the core PDCA steps onto one sheet. It is the most compact variant and particularly useful in coaching settings where a multiplier walks a staff member through problem-solving.
Our take: In the Mittelstand we typically start with PDCA because it has the lowest entry barrier. We introduce DMAIC selectively, when a problem has not moved after two PDCA cycles. OODA belongs in crisis communication, not in the standard continuous-improvement stack.
Six anti-patterns: when Check becomes blame-shifting
To the point: The most frequent PDCA traps are cultural, not methodological — and they are remarkably predictable. Four of the six are organisational in nature.
- Check as blame-shifting. The moment the data round is used to identify a culprit, participants switch their filter on — data gets polished, problems get hidden, the Check step collapses. The room rule must be explicit: in Check we show problems, in Act we solve them, in neither do we assign blame.
- Plan without hypothesis. A plan that only says "we want to get better" is not a plan. A hypothesis reads: "If we activate mandatory field X, error Y drops by Z percent in four weeks." Without that form no Check is possible.
- Do as disguised roll-out. When Do already represents the target roll-out, the learning window has closed. Keep pilot size deliberately small.
- Act without standardisation. Working solutions must be fed into the process documentation, the ERP customising, the onboarding, and the training matrix. Otherwise the improvement regresses with the next personnel change.
- PDCA as an annual project. Putting the cycle on an annual cadence misses the essence of the method. The loop lives on a weekly rhythm.
- PDCA without a process owner. Without a named person accountable for the cycle, Check becomes a committee meeting without consequence.
Our take: Four of the six traps are organisational. The method itself is robust — the firms where it does not carry rarely have a method problem; they have an accountability problem.
Frequently Asked Questions
PDCA stands for Plan, Do, Check, Act and describes a repeatable four-step improvement cycle. Walter A. Shewhart formulated the logic as early as 1939 at Bell Labs; W. Edwards Deming carried the methodology to Japan in the 1950s and later adapted it into the PDSA variant (Plan, Do, Study, Act), in which "Study" deliberately replaces the weaker "Check". PDCA is today anchored in ISO 9001:2015 as the structural principle of the quality-management system and forms the basis of practically all modern continuous-improvement approaches, from Kaizen through Lean to agile methods.
PDCA and PDSA differ in the third step: "Check" measures whether a plan was carried out, "Study" examines whether the original theory behind the plan holds. From the 1980s onwards Deming himself preferred PDSA because in English-language practice "Check" was too quickly read as pure status verification. In the German-speaking Mittelstand we recommend the common label PDCA but the content of PDSA — explicit hypothesis testing in the third step. The label matters less than the question actually asked in the Check meeting: "What did we learn about the problem?" rather than "Is the project on plan?".
In our projects a single cycle typically runs four to eight weeks. Shorter cycles make sense for data-quality topics (two weeks is enough to measure mandatory-field effects); longer cycles suit complaint or service topics with higher variance. Three to five consecutive cycles are enough to achieve a measurable process improvement and to anchor it in the standard processes. Anyone scheduling a cycle to a quarter or even a year has methodologically left PDCA behind for annual planning with an improvement label — the learning rhythm dies at that cadence.
A named process owner carries responsibility for the cycle, not the executive board and not IT. Operational support comes from internal multipliers qualified in train-the-trainer logic — two to five people are enough for a firm of 200 to 500 employees. The executive team belongs in the quarterly review, not in the weekly meeting; otherwise Check turns into a status review and the learning effect disappears. The multiplier role must be explicitly written into the job description, otherwise it ranks behind day-to-day work.
Three tool classes are useful but none is required: first a lightweight board (physical on the shopfloor or digital in Jira, Confluence, Asana) for active cycles, wins, and escalations; second a standardised A3 template for structured problem description per cycle; third an analysis tool that pulls at least the lead KPI weekly from the ERP — that can be a built-in ERP report, a Power BI dashboard, or a simple Excel sheet. We recommend starting with the simplest available means and only switching tools once the cycle is demonstrably running. Tools do not replace discipline.
Next steps
PDCA is not a textbook project — it is an operational rhythm that starts with a named process, a process owner, and a weekly meeting. If you are considering an ERP rollout, a master-data consolidation, or a train-the-trainer programme and want to anchor PDCA as an operational steering tool, a 90-day pilot on one clearly bounded process is the pragmatic entry point. Three building blocks are enough: one end-to-end process with a measurable lead KPI (preferably one that already causes visible friction today); one process owner with mandate and protected time for the weekly Check meeting; two to three multipliers from the line. The first conversation is free and leads to an honest assessment — not to a proposal weighed down with method overhead.
