Lean Six Sigma · 7 min read
Lean Six Sigma Without the Silos: One Platform for DMAIC, SPC, and CAPA
The DMAIC method is not broken. The tooling around it is. We keep meeting teams whose charter lives in a shared doc, whose capability study lives in a Minitab file on one laptop, whose action tracker lives in a spreadsheet nobody trusts, and whose corrective action lives in an email thread. Each artifact is fine on its own. The problem is that the analysis detaches from the improvement it belongs to, and once detached, it goes stale.
This is a Kanso perspective. See how Kanso runs ISO 9001 and Lean Six Sigma on one platform →
The silo tax nobody puts on the project charter
Walk into most improvement programs and you will find the same archaeology. A project charter in a slide deck. A SIPOC drawn in a whiteboarding app. A Gage R&R run six months ago in a desktop stats package, exported as a PNG and pasted into a report. A control plan in a spreadsheet. A CAPA record in the quality inbox, referenced by a number that means nothing to the person who ran the capability study. Every one of these was correct the day it was made.
The cost is not that the tools are bad. Minitab is excellent at what it does. Spreadsheets are the most successful software category in history. The cost is the gaps between them. When your Cpk lives in a file and your process change lives in a CAPA and your monitoring lives in a third place, nothing knows that the other two exist. The statistics stop pointing at the improvement. And a number that no longer points at anything is just decoration.
We built Kanso around one refusal: the analysis does not leave the project. The charter, the SIPOC, the CTQ tree, the hypothesis test, the MSA, the control chart, the FMEA, the control plan, and the CAPA are all attached to the same improvement, reading the same data. Let us walk DMAIC phase by phase and show where the silo bites, and what "in one place" actually changes.
Define: the charter that knows what it is measuring
Define is where the silo is easiest to ignore, because Define produces documents, and documents feel harmless. A problem statement, a goal, a scope, a SIPOC, a voice-of-customer capture that becomes a CTQ tree. In a siloed setup these are prose. The goal says "reduce scrap by 40%" and the CTQ says "flatness within 0.2mm," and neither is connected to a single measured value anywhere.
So three weeks in, someone asks the honest question: 40% of what baseline? And the room goes quiet, because the baseline was a number somebody remembered from a meeting. In Kanso the charter is a live record inside the project, and the CTQ links to the actual characteristic you will measure. The goal is not a sentence you retype into a report later. It is the thing the Measure and Control phases read from.
This is unglamorous and it matters more than the fancy statistics downstream. A capable Analyze phase built on a charter whose baseline nobody can reproduce is a very rigorous way to be confidently wrong.
Measure: an MSA that stays attached to the measurement system
Here is where we will plant a flag. A capability study exported as a screenshot is a lie waiting to happen. Not because the math was wrong the day it was run, but because a screenshot cannot tell you the gauge drifted, the operators rotated, or the sampling plan changed underneath it. It freezes a Cpk of 1.47 in amber and lets everyone quote it for a year while the real process wanders off.
Measure is the phase the silo damages most, because Measure is where you establish whether you can trust your numbers at all. You run a Gage R&R. Suppose the study returns 28% study variation. That gauge is marginal, and every downstream conclusion inherits that uncertainty. In the siloed world the Gage R&R is a one-time artifact. It gets run, it passes or it does not, and then it is forgotten. The capability study that follows never mentions it.
In Kanso the MSA is attached to the measurement system, not to a moment. The Gage R&R sits inside the project next to the data it validated. When you later run the capability study on that same characteristic, the measurement-system result is right there — not a screenshot from a folder, the actual record. If the gauge was marginal, the capability number carries that caveat with it instead of shedding it the instant it becomes inconvenient. The statistics stay honest because they stay connected.
Analyze: hypothesis tests that read the project's own data
Analyze is where teams reach for the stats package, and it is where the copy-paste tax gets expensive. You export the data, clean it in a spreadsheet, paste it into Minitab, run a two-sample t-test or an ANOVA, get your p-value, screenshot the output, and paste it back into the report. Every hop is a chance for the dataset to diverge from what the project actually contains. By the third export, the numbers in the report and the numbers in the project are cousins, not twins.
Kanso runs the hypothesis tests against the project's own data. The DPMO and sigma level, the t-tests, the ANOVA, the correlation work — they read what the project holds, so there is no separate cleaned copy drifting away from the source. When the data updates, the test is re-run against the real thing, not against a frozen paste from last month.
For the analysis that no menu-driven tool covers, we did not pretend a fixed set of buttons is enough. Kanso includes SQL, Python, and R for bespoke work, on the same platform, against the same data. A custom Weibull fit, a mixed-effects model, a resampling routine — you write it where the data lives instead of shipping a CSV to a laptop and shipping a chart back. The bespoke analysis is a project record like everything else, not an orphaned notebook on someone's machine.
Improve: a DOE whose result becomes the control
Improve is where you change the process, and in Six Sigma that often means a designed experiment. You run a factorial DOE, find the significant factors and interactions, and settle on new settings. So far the siloed toolchain limps along fine, because a DOE is a self-contained study. The silo bites at the handoff. The DOE proved that factor B at its high level and the B-by-C interaction drive the response. Now that finding has to become a standard: a new setpoint, a new procedure, a control limit.
In the disconnected world, that translation is done by hand. Someone reads the DOE output, types the new target into a control plan spreadsheet, and the causal link between "the experiment proved this" and "so we control that" survives only in the memory of whoever did the typing. Six months later a new engineer asks why the setpoint is 4.2, and the answer is lost.
When the DOE lives in the project alongside the control plan and the SPC that will watch the improvement, that chain stays intact. The experiment that justified the setting, the setting itself, and the chart that guards it are the same record. The rationale does not evaporate at the handoff. That is the whole point of Control, and it is the phase silos quietly sabotage.
Control: SPC that reads live data and a plan wired to the CAPA
Control is where improvements go to die, and the silo is usually the murder weapon. The classic pattern: the project closes, the control chart becomes a monthly manual export, and nobody applies the Nelson rules because nobody is looking. A run of eight points on one side of the mean — a textbook signal of a shifted process — sits unread in a spreadsheet tab. By the time scrap climbs back to the pre-project level, the improvement is a slide in an old review deck.
SPC only earns its keep when it reads live data. In Kanso the control chart is fed by the project's data as it arrives, and the Nelson rules run against it continuously — point beyond three sigma, runs, trends, the full set — instead of waiting for a human to notice a pattern in a static screenshot. A signal is a signal when it happens, not when someone gets around to exporting.
And a signal has to go somewhere. This is the join that siloed tooling cannot make: the control chart is in one system and the corrective action is in another, so a special-cause point and the CAPA it should trigger never meet. On our platform the control plan links to the CAPA, and the CAPA is a record on the same platform as the audits and the controlled documents. When the process throws a signal, the path from "chart flagged it" to "corrective action opened" to "procedure updated" is one continuous thread, not four systems and an email. The improvement stays governed because the governance is attached to it.
Why the category is "attached," not "assembled"
The honest objection is that you can already do all of this. You can. Minitab plus a spreadsheet plus a document repository plus a CAPA inbox will, with enough discipline, produce a complete DMAIC project. We are not claiming the individual tools are inadequate. We are claiming that the seams between them are where improvements decay, and that no amount of discipline fully closes seams — it just delays the decay.
The difference is where the statistics live. In the point-tool world, the analysis is assembled at report time from artifacts that have already started drifting apart. In Kanso, the analysis is attached to the improvement and to the records for the life of the project. The MSA stays with the measurement system. The capability study carries its caveats. The SPC reads live data and the control plan is wired to the CAPA, which sits next to the audit and the document it changed.
That is why we treat this as a category above disconnected point tools rather than a nicer point tool. Kanso is a shipped QMS for ISO 9001 and Lean Six Sigma, built by eClips (eclips.tech), and its Six Sigma toolkit lives inside the improvement project on purpose. Keep the stats attached to the improvement and to the records, and DMAIC does what it was always supposed to do: hold.
See Kanso in action
One platform for ISO 9001 and Lean Six Sigma — with the analytics to query and model your quality data in SQL, Python, and R.
Book a walkthrough