--- slug: tls-integration type: concept summary: "The integration in which TOC supplies the focusing logic, Lean removes waste at the few places that matter, and Six Sigma reduces throughput-limiting variation; sequence is decisive." created: 2026-05-21 updated: 2026-06-02 related: five-focusing-steps: relation: uses note: "TOC supplies the focusing sequence that decides where Lean and Six Sigma work should be applied first." poogi: relation: implements note: "TLS is a POOGI specialization: it uses constraint-relative feedback to decide which improvement work belongs in the next cycle." throughput-accounting: relation: depends-on note: "The integration needs the T-I-OE frame to judge whether a Lean waste-removal or Six Sigma variation-reduction project improves the system rather than a local measure." continuous-improvement-auditing: relation: supported-by note: "The audit discipline checks whether focused improvement at the constraint raised throughput, protected inventory or investment, and controlled operating expense." drum-buffer-rope: relation: complements note: "DBR is the production-flow architecture TLS often protects: Lean and Six Sigma tools are focused where they improve the drum, buffer, rope, or supporting non-constraints." buffer-management: relation: uses note: "Buffer status supplies the fast signal that tells a TLS team which delay causes deserve Lean or Six Sigma attention." local-optimization: relation: prevents note: "TLS prevents improvement projects from drifting toward local waste or variation reductions that do not move the system constraint." improving-non-constraints: relation: prevents note: "The sequence refuses Lean or Six Sigma projects at good-enough non-constraints when the work would only consume improvement capacity." toc-healthcare: relation: specializes note: "Healthcare TOC uses TLS when Lean tools such as complete-kit discipline and Six Sigma tools such as statistical process control are focused at the patient-flow constraint." --- # TLS Integration (TOC + Lean + Six Sigma) [Supply Chain & Operations (SCL Practitioner)](learning-tracks.md#scl-pom): [prev: Dynamic Buffer Management](dynamic-buffer-management.md) -> TLS Integration (TOC + Lean + Six Sigma) -> [next: DDMRP and TOC](ddmrp.md) > **Concept:** Vocabulary that names a phenomenon. *The integration pattern in which TOC supplies the focusing logic, Lean removes waste at the few places that matter, and Six Sigma reduces variation that starves, blocks, or destabilizes the constraint.* *Also known as: TOCLSS; Theory of Constraints, Lean, and Six Sigma; iTLS; Velocity.* TLS is easy to misread as a peace treaty between three improvement communities. It is not. Its load-bearing claim is sequence: first use TOC to identify the system constraint and the non-constraints that keep the constraint from being exploited or elevated; then use Lean and Six Sigma tools on those places. A Lean team can remove waste everywhere it sees it. A Six Sigma team can reduce variation wherever data is available. TLS asks the prior TOC question: which work would raise throughput, protect the right inventory or investment, or control operating expense? ## Understand This First - [Five Focusing Steps](five-focusing-steps.md) — the sequence that decides where improvement work belongs. - [Throughput Accounting](throughput-accounting.md) — the global measurement frame for judging the work. - [Continuous Improvement Auditing](continuous-improvement-auditing.md) — the feedback discipline that checks whether the improvement held. - [Local Optimization](local-optimization.md) — the trap TLS is designed to prevent. ## Context TLS belongs in Complex Environments and Change because it is less a tool than a boundary rule for using toolsets together. Lean, Six Sigma, and TOC all improve flow, but they start from different questions. Lean asks where waste is being created. Six Sigma asks where variation is creating defects, rework, or unstable output. TOC asks what limits the whole system's goal-unit production right now. The practical conflict appears when an organization already has Lean facilitators, Six Sigma belts, a portfolio of local projects, and a TOC practitioner insisting that most of those projects should wait. That objection can sound political if it is argued from methodology preference. TLS turns it into an operating rule. Use the [Five Focusing Steps](five-focusing-steps.md) to name the constraint, use [Buffer Management](buffer-management.md) or equivalent feedback to locate delay causes, then spend Lean and Six Sigma effort where the system can feel it. The *TOC Handbook* carries two adjacent treatments. Blackstone surveys the TOC, Lean, and Six Sigma combination in the DBR literature and reports the Pirasteh and Farah comparison of Lean-only, Six-Sigma-only, and TLS plants. Barnard makes the management argument: without a focusing mechanism, strong tools get spent on the largest local gap, the easiest solvable problem, or the team's preferred toolkit. ## What It Is TLS is the sequenced use of TOC, Lean, and Six Sigma in one improvement system. TOC supplies the focusing mechanism. It identifies the system constraint, decides how to exploit it, subordinates the rest of the system to that exploitation, and elevates only when exploitation and subordination are insufficient. When the constraint moves, the sequence returns to Step 1. In TLS, that sequence is the project-selection rule, not background philosophy. Lean supplies waste-removal tools once the focus is known. Value-stream mapping, 5S, standard work, setup reduction, visual controls, mistake-proofing, one-piece flow, and kanban are not rejected. They are constrained. A setup-reduction project at the constraint is usually high-value. The same project at a good-enough non-constraint may only create faster production of work the constraint can't absorb. Six Sigma supplies variation-reduction tools once the focus is known. DMAIC, control charts, capability studies, root-cause analysis, mistake-proofing, and design-of-experiments work are useful when variation at the constraint, or at a supporting step that starves or blocks the constraint, is limiting throughput. The same tools can waste months when they improve a process whose variation has no measurable system effect. AGI-Goldratt Institute's Handbook chapter gives the combined architecture as Strategy, Design, Activate, Improve, and Sustain. Strategy names the system objective and the constraint-relative path. Design configures policies, measurements, roles, and operating rules around that path. Activate puts the constraint-based system into use. Improve applies Lean and Six Sigma tools in a focused way. Sustain records the changed logic so the method does not decay into disconnected projects. ## How It Is Measured or Recognized A TLS implementation is recognizable by the order of its decisions. First, the project portfolio is constraint-relative. A proposed improvement has to say whether it exploits the constraint, subordinates a non-constraint to the constraint, elevates the constraint, or removes a delay cause that prevents exploitation or elevation. Projects that do none of those things are not automatically bad. They are not first in line. Second, the feedback signal points to the work. In production, that often means buffer-penetration reasons. If red and black buffer statuses recur because material is missing at the constraint, Lean work may target kitting, setup, workplace organization, or supplier handoff. If the recurring cause is process variation at the constraint, Six Sigma work may target capability, defect modes, or control limits. The signal chooses the tool, not the other way around. Third, the measurement frame is global. TLS work is judged by the joint move in throughput, inventory or investment, and operating expense. A Lean project that lowers local labor hours while starving the constraint is not success. A Six Sigma project that improves a non-constraint's defect rate while throughput stays flat is not success. The local measure may move; TLS asks whether the system moved. Fourth, the architecture protects deliberate imbalance. The AGI chapter is explicit about the balanced-line conflict: a Lean design that tries to remove every visible excess-capacity point can erase the protective capacity TOC needs at non-constraints. TLS treats some idle capacity as a design feature when it protects the constraint. This is one of the places where TOC is not merely "added to" Lean; it changes the design judgment Lean would otherwise make. ## Why It Matters TLS matters because improvement capacity is itself constrained. The organization has a finite number of people who can run projects, a finite amount of management attention, and a finite tolerance for operational disruption. If that capacity is spent on local waste and local variation, the system may become cleaner and more controlled while the constraint continues to set the same output rate. The Sanmina comparison reported by Pirasteh and Farah is the standard field exhibit. Across 21 factories, the plants using TLS accounted for most reported savings despite being a minority of the sample. The important point is the Handbook's causal explanation: TOC selected the few improvement points where Lean and Six Sigma effort could change system performance. The toolsets did not become more powerful. Their aim improved. TLS also gives a TOC practitioner a constructive answer to "we already do Lean" or "we already do Six Sigma." The answer is placement, not dismissal. Lean and Six Sigma are treated as strong methods for waste and variation once the system has named where those reductions matter. TOC supplies the focusing and measurement layer those methods do not carry by themselves. The pattern is especially important where the old measures fight the new design. If a non-constraint has protective capacity, a cost-world measure reads the idle time as waste. If a constraint needs time protection, an inventory-centered reading may push to reduce the buffer. TLS needs [Throughput Accounting](throughput-accounting.md) and [Continuous Improvement Auditing](continuous-improvement-auditing.md) because otherwise the organization will slowly convert the sequence back into ordinary local project selection. ## Common Misunderstanding **"TLS means run all three methods everywhere."** It doesn't. That is the toolbox mistake the AGI chapter warns against. TLS is not a permission slip to add TOC vocabulary to an existing Lean Six Sigma portfolio. It is a rule for choosing the few improvement projects that matter now. **"Lean removes waste, so TOC's protective capacity must be waste."** That misread breaks the integration. In a constrained system, protective capacity at non-constraints is what lets the system recover when variation starves or blocks the constraint. Removing it can make a local report look better while making due-date performance worse. **"Six Sigma should start with the largest variation source."** Not unless that source constrains the system or prevents exploitation of the constraint. A large local variation source can be irrelevant to throughput. A smaller variation source at the constraint can dominate the system result. **"TOC replaces Lean and Six Sigma."** It doesn't. TOC decides where and when the other tools are worth using. In a TLS system, Lean and Six Sigma specialists still do the detailed waste-removal and variation-reduction work. The difference is that their project queue is subordinated to the constraint. **"TLS is settled doctrine."** It isn't. Practitioners broadly agree that TOC can focus Lean and Six Sigma work. They disagree on how prescriptive the sequence must be and how much of Pirasteh's iTLS or AGI's Velocity architecture should be treated as canonical. The conservative position is the one this entry takes: TOC supplies the focusing rule; Lean and Six Sigma supply focused improvement tools; specific deployment architectures are named variants, not the whole concept. ## Sources - AGI-Goldratt Institute, "Combining Lean, Six Sigma, and the Theory of Constraints to Achieve Breakthrough Performance," in Cox and Schleier, [*Theory of Constraints Handbook*](https://openlibrary.org/works/OL18346923W) (2010), Ch. 36 — the main Handbook treatment of the TOCLSS / Velocity architecture, the balanced-line versus unbalanced-line design conflict, time-based versus inventory-based release, and the Strategy-Design-Activate-Improve-Sustain deployment sequence. - Barnard, A., "Continuous Improvement and Auditing," in Cox and Schleier, [*Theory of Constraints Handbook*](https://openlibrary.org/works/OL18346923W) (2010), Ch. 15 — the management-audit treatment of using TOC as the focusing mechanism for Lean and Six Sigma projects, including the three common project-selection mistakes and the Sanmina, Delta, Warner Robins, and Seagate examples. - Blackstone, J. H. Jr., "DBR, Buffer Management, and VATI Flow Classification: A Review of the Literature," in Cox and Schleier, [*Theory of Constraints Handbook*](https://openlibrary.org/works/OL18346923W) (2010), Ch. 7 — the literature-review placement of TOC, Lean, and Six Sigma together, including Pirasteh and Farah's APICS Magazine report on TLS. - Cox, J. F., *TOCICO Dictionary* (2nd ed., 2012), entries "lean manufacturing management philosophy," "theory of constraints manufacturing management philosophy," "five focusing steps," "buffer management," "throughput accounting," and "local optimum" — the certification vocabulary this entry cross-checks against. Distributed through TOCICO membership; no Open Library record. - Goldratt, [*What Is This Thing Called Theory of Constraints and How Should It Be Implemented?*](https://openlibrary.org/works/OL4186015W) (1990) — the formal source for the Five Focusing Steps and the implementation sequence TLS uses as its focusing rule. - Womack and Jones, *Lean Thinking* (1996), and Ohno, *Toyota Production System* (English translation 1988) — the Lean lineage AGI summarizes before distinguishing waste removal from TOC's constraint-relative project selection. --- - [Next: ToC in Complex Organizations](complex-organizations.md) - [Previous: Complex Environments and Change](complex-environments-change.md)