Hi, and welcome to my new channel. My name is Tomasz Kaczorowski. I'm a PhD chemist by training, I spent over seven years running projects in regulated pharma, and I'm a certified Six Sigma Green Belt. Today I run Smart-Suited Tech, where we build AI automation for companies that live in documents and care about quality.

On this channel, I'll teach the classic tools of quality and process improvement, and show how they work when part of the process is run by AI. If you find it useful, please like the video and subscribe. It helps the channel reach more people, and it helps me make more of these.

Today we start with the fundamentals of Six Sigma. We'll cover what it means, how a project is structured, and how teams use data to improve a process. You don't need a statistics background to follow along.

The central idea is simple. Understand what matters to the customer, measure how the process performs, find the causes of bad results, and make improvements that last. And along the way, we'll ask a newer question. What changes when one of the workers in your process is an AI agent?

Let's start with the word process. A process is a series of connected steps that turns an input into an output. The customer may be an outside buyer, a patient, or another team inside the company. Six Sigma begins by asking what that customer needs.

We translate that need into a measurable requirement, called a critical-to-quality characteristic, or CTQ. For a delivery service, a CTQ might be that an order arrives by the promised date. And that it contains every item the customer ordered.

Now an AI example. Picture an agent that reads a supplier's certificate of analysis and updates a cosmetics company's ingredient record. Its customer is the regulatory specialist who relies on that record. One CTQ could be this: every value in the record matches its source, and the record shows exactly where it came from.

Before we count defects, we need to define them. A unit is the thing we evaluate, such as one order, one application, or one lab result. A defect is a failure to meet a stated requirement. An opportunity is one specific way a unit could fail.

These definitions matter more than they seem. If one person counts late orders and another counts late line items, they'll report very different numbers for the same process. So agree on the unit, the requirement, and the counting rules before you collect any data.

This is exactly where AI accuracy numbers get slippery. Say a supplier document has 40 fields, and an agent reads 99 percent of the fields correctly. Counted by field, that sounds excellent. Counted by document, if errors land at random, only about two documents in three come out fully correct.

Same agent, same work, two very different numbers. Neither is wrong, but they answer different questions. So when anyone quotes you an accuracy figure, for a person or for a machine, ask first: per what unit?

Six Sigma pays close attention to variation. Even when people follow the same process, the results differ. Some of that variation is built into the process as it normally runs. We call it common-cause variation.

Other variation comes from a specific event, like a machine breaking down, a supplier change, or an unusual staffing gap. That's special-cause variation. The difference tells you how to respond.

If a special event caused the problem, investigate that event. But if the process varies the same way day after day, coaching one employee won't fix it. The process itself has to change.

AI agents show both kinds of variation. Run the same agent on the same document twice, and the output can differ slightly. That's common cause, built into how these models work. A model update from the vendor, or a supplier switching to a new document template, is special cause.

And the same lesson applies. When an agent misreads one document, the tempting fix is to patch the prompt for that one case. That's the AI version of retraining one employee. If the errors are common cause, change the process: the instructions, the checks, the review step.

A process also has two different kinds of limits. Specification limits are set by the customer or the organization: the acceptable range for an output. Control limits are calculated from the process's actual performance over time, and they show whether it's stable.

A process can be stable and still fail the customer's specification. It can also meet the specification on average while producing unpredictable results. So you need to understand both, stability and capability, before you decide what to do.

For an AI agent, the specification is what the business agrees to accept, written down before any results come in. In our pilot with RCMA Makeup, a professional cosmetics company, the accuracy floors and targets were set before a single pilot document was processed. Then the question was simple. Does real performance hold inside those limits, week after week?

You may hear Six Sigma described as 3.4 defects per million opportunities. Treat that as a conventional benchmark, not a promise every project must reach. The figure comes from one particular way of relating a process to its specification limits, including an assumed long-term drift in the process average.

In practice, what matters is to define the measure, use it consistently, and improve what the customer actually cares about. A project can create real value without reaching a textbook sigma level. The same goes for AI. You don't need a perfect agent. You need one that measurably beats today's process, and keeps doing it.

The best-known Six Sigma framework is DMAIC: Define, Measure, Analyze, Improve, and Control. These aren't just labels for a slide. Each phase answers a different question, and produces evidence for the next one. We'll walk through them with two running examples: a classic delivery problem, and an AI agent reading supplier documents.

In Define, the team describes the problem, the customer, the scope, and the goal. A useful problem statement says what is happening, where it's happening, and why it matters. It avoids guessing at the cause.

If we say, orders are late because employees are careless, we've already picked a cause without evidence. A stronger start is: last quarter, 18 percent of West Coast orders shipped after the promised date, increasing complaints and expediting costs. From there, the team sets a goal, names who is affected, and agrees what's in scope and out.

The AI version of the careless employee is, the AI hallucinates. It sounds like a diagnosis, but it's a guess. A stronger statement would be: last month, reviewers corrected at least one field on 12 percent of the certificates the agent processed, mostly in the heavy-metals section.

A common Define tool is the SIPOC map: suppliers, inputs, process, outputs, and customers. In the RCMA pilot, we mapped the manual workflow this way before the pilot began. Then we wrote the acceptance criteria against that map.

In Measure, the team checks that the data can be trusted, and establishes a baseline. It may map the current process, decide exactly how each measure will be collected, and check whether different people record results the same way. A baseline lets you compare performance before and after a change.

Without clear definitions and dependable data, later analysis can sound precise while answering the wrong question. With AI, the measuring stick deserves extra suspicion. An agent grading its own work is not a measurement system.

In the RCMA pilot, every data point was scored by the client's own reviewers, against what they would have entered by hand, and then audited line by line. That's how the headline figure was earned: 99.3 percent extraction accuracy across 140 supplier documents. It's a single pilot, but the number means something because of how it was measured.

In Analyze, the team looks for the causes behind the gap between current and desired performance. It might use a process map, a cause-and-effect diagram, or a Pareto chart to organize what it learns. Then it tests the leading explanations against evidence.

For example, if late shipments seem to cluster around one step, the team checks timestamps and order details to see whether that step really drives the delay. A brainstorming list is a source of hypotheses. It's not proof.

Here's a real AI example. In the second week of the RCMA pilot, document classification fell below the floor we had agreed in advance. We traced the cause instead of guessing. The agent wasn't reliably telling whose voice a supplier's regulatory statement represented, so it put those documents in the wrong category.

In Improve, the team develops and tests changes that address verified causes. It may run a small pilot before changing the process for everyone. Then it compares the results with the baseline, and checks for unwanted side effects.

In the delivery example, suppose orders wait for a manual address review, even when the address is already valid. A pilot could send only the flagged addresses to manual review. If waiting time drops without more delivery errors, the team has evidence for a broader change.

For the RCMA classification problem, the fix was not a quick patch. We screened candidate prompts, models, and settings against the exact documents that had failed. Then we confirmed the best combination on that same set before going back to full volume. In Six Sigma terms, that's a designed experiment.

One more lesson from that week. The later weeks looked better, but that alone couldn't prove the fix, because later batches might simply have been easier. The real evidence was the test against the documents that had failed. That's the difference between a good result and a proof.

In Control, the team makes the improvement part of normal work. It documents the new process, assigns owners for the key measures, and decides what to do if performance starts to slip. A control chart helps separate ordinary variation from a real signal that needs investigation.

Training, updated work instructions, and a response plan may be needed too. The goal is a process that stays improved after the project team moves on. For RCMA, the plan to hold the gain was human review before any record is used, plus targeted spot-checks. Not a one-time fix.

One more rule that's specific to AI. When the underlying model changes, treat it like a new machine on the production line. Re-check performance against the same criteria before you trust the old control limits.

There are many familiar tools in this work, but no tool should be picked just because it's popular. Process maps show the flow of work. Check sheets help collect consistent observations. Pareto charts show which categories account for most of a problem.

Cause-and-effect diagrams organize possible causes. Control charts show how a measure changes over time. Statistical tests help judge whether a difference is likely to be real. The question decides the tool, not the other way around.

That includes AI. An agent is one more tool in the box, and it should be chosen for a question, not because it's fashionable. Map the process first. Then you'll see which steps are worth automating, and which ones are worth removing altogether.

People also ask who does Six Sigma. In many organizations, executives sponsor projects, process owners keep improvements in place, and team members bring knowledge of the work. Belts describe levels of training and project responsibility.

A Green Belt may lead a focused project alongside other duties. A Black Belt often leads more complex projects and coaches teams. Titles vary by organization, and results depend on the people who run the process, not on the belt.

AI adds a new question here. Who owns the agent's output? It should be the same process owner who owned the work before. An agent can do the work, but it can't carry the accountability.

Six Sigma is often used alongside Lean. Lean focuses on removing delays and steps that don't add value for the customer. Six Sigma focuses on reducing defects and unwanted variation. Many problems involve both, so teams combine the two.

AI can serve either side. Cutting hours of manual reading down to minutes is a Lean gain. Catching a value that conflicts with the record on file is a Six Sigma gain. Either way, the shared discipline is the same: test the idea, and verify the result.

A few cautions are worth remembering. Don't start with a favorite solution and search for data to support it. Don't improve one measure in a way that makes the customer's experience worse somewhere else. And don't confuse a local success with a lasting result.

Don't make a project so broad that the team can't finish it. A well-scoped project, with a clear measure and a committed process owner, beats a large and vague transformation. And today, the most common favorite solution is simply, let's add AI. Start from the requirement and the evidence instead.

Let's recap. Six Sigma is a structured way to improve processes: define customer requirements, measure performance, understand variation, and act on evidence. DMAIC takes a team from a clear problem, through a tested improvement, into ongoing control.

The tools help answer questions, but the team's judgment and the quality of the data matter just as much. None of that changes when an AI agent joins the process. If anything, it matters more, because an agent can repeat the same mistake a thousand times before lunch.

So when you meet a process that frustrates customers or wastes time, start with three questions. What requirement is not being met? How will we measure the gap? And what evidence would show us why it's happening?

Those questions are a strong start for a Six Sigma project, whether the work is done by people, by AI agents, or by both. They're also how we build AI at Smart-Suited Tech. Our engine, Elara, reads supplier documents, interprets each field against the client's own definitions, and reconciles them against the record on file.

Elara flags what needs attention, and people decide. If your team is buried in supplier paperwork, the RCMA case study is linked below. If this video was useful, like it and subscribe, so you don't miss the next one. And tell me in the comments which topic you'd like next. Thanks for watching.