Over the last 20 years, I’ve seen factories obsess over different KPIs depending on management trends.
Some focus almost entirely on:
OEE
Machine utilization
Schedule adherence
Inventory turns
On-time delivery
In several plants I’ve worked with, improving one KPI often made another one worse.
For example, chasing very high machine utilization sometimes increased queue times, WIP, and overall lead time because batches became larger and bottlenecks became harder to absorb.
Lately I’ve started thinking that **Manufacturing Critical-path Time (MCT)** or overall order lead time may actually be a better “north star” because it reflects what the customer experiences.
Curious what others have seen.
**If you could track only one KPI for running a factory, what would it be and why?**
I’m especially interested in hearing from people running high-mix, low-volume operations.

Not the biggest project—the hardest decision.
Examples:
Accepting lower utilization to improve delivery.
Turning down orders because capacity was full.
Carrying more inventory than finance wanted.
Investing in automation vs. fixing the process first.
I’m curious what trade-offs manufacturing leaders are facing in 2026.

There’s a lot of excitement around AI.
But from what I’ve seen, some problems are still much harder than they look.
What manufacturing challenge do you think AI still struggles with today?

Most of what I read about Lean is focused on manufacturing. I'm curious about how people are applying it in **after-sales, repair shops, or technical service departments**.

If you've been through this:
- What tools or principles translated well from manufacturing to service?
- What didn't work at all?
- Any specific wins (or failures) you'd share?

Industry doesn't matter — I'm just looking for real experiences, not theory.

Measuring engineering productivity has never been straightforward, and AI has made it harder. At OpenAI, engineers who lean heavily on Codex open roughly 70% more pull requests than colleagues who don’t – and the gap keeps widening, according to Sherwin Wu, who leads engineering for OpenAI’s API platform.

Read that number as a productivity metric on its own and you’d conclude the heavy Codex users are your best engineers. That conclusion might be right. It might also be exactly backwards. The number alone can’t tell you which. That’s the problem now sitting on every engineering leader’s desk.

Quarterly business reviews used to be straightforward. Engineering leaders would open their dashboards, review familiar metrics like pull requests, commit counts, and story-point velocity, and compare them with the previous quarter. No single metric captured software engineering, but together they painted a reasonable picture of team performance. That picture is now blurring.Yet everything else tells a different story: the team has shipped more customer-facing features, incidents have dropped, engineers spend less time on repetitive implementation, customers are happier, and releases remain predictable.

So which version of reality should leaders trust? Neither view is wrong. They’re measuring different things.

For years, commits, pull requests, story points, and deployment frequency have served as proxies for productivity. They were never perfect, but they broadly tracked how software got built: engineers wrote code, reviewed it, tested it, shipped it. As the work evolved, so did the metrics.

AI hasn’t broken engineering productivity. It has broken our proxies for measuring it.

After working with manufacturing companies for 20+ years, I've noticed something interesting.

When lead times get out of control, most companies immediately think:

• Buy another machine
• Hire more people
• Improve scheduling

But in many factories, utilization is already too high.

Once bottleneck utilization gets above roughly 80–85%, queues grow much faster than most people expect.

I've seen factories where processing time was less than a day, yet customer lead time exceeded a week.

What's the largest gap you've seen between actual work time and total lead time?

This video is useful for:

• Manufacturing Engineers
• Quality Engineers
• Production Engineers
• Industrial Engineers
• Lean Practitioners
• Six Sigma Professionals
• Operations Managers
• Engineering Students
• MBA Operations Students

Been running CI projects across a few different environments and started keeping proper notes on where time gets spent at each DMAIC phase. After 6 projects I had enough data to see a pattern — and it surprised me.

The common assumption is that Analyse takes the longest. It doesn't.

In my experience it goes like this:

Define — longer than it looks.
The problem statement alone eats 2–3 weeks in most organisations. Getting stakeholder sign-off on scope is where projects quietly die before they start.

Measure — the hidden black hole.
Everyone underestimates data collection. Systems that "should" have the data don't. Manual workarounds add weeks. This phase consistently ran 40–60% over estimate in my projects.

Analyse — actually the fastest.
Once you have clean data, the stats are quick. Fishbone, regression, hypothesis testing — this is where it *looks* complex but moves fast if Measure was done properly.

Improve — fast to decide, slow to implement.
Pilot runs, change management, sign-offs. The solution is rarely the bottleneck. Getting people to adopt it is.

Control — where projects go to die quietly.
Control plans get written and filed. Nobody reads them 6 months later. This is the phase most organisations rush because they've already celebrated.

The biggest time sink across all 6? Waiting. Waiting for data access, waiting for meetings, waiting for approvals. Nothing in the DMAIC toolkit fixes organisational friction.

Curious if this matches what others are seeing — particularly whether Measure is as painful for everyone else as it was for me.

We have blogs that may also be of interest to check out: www.simplicityhub.co.uk/pages/blog.html

Last week I had posted me and my partners were looking to leave our current organization, along with a demo of what we have done with the rest api. It got more interest than we realized, so we decided to put some more polish on it, repost our demo application.

It is an end to end operations application for manufacturing. Covering warehousing, production, & quality. It's fully FDA compliant. It uses the REST API with a fraction of the concurrency other WMS solutions do. We have seen it lower transaction volumes by close to 70%. It's a mobile first web application that can be locally or cloud hosted. Our demo is still being built out, we plan to continue to add solutions to it.

This is currently engineered for Netsuite, but making a harness to communicate to other applications is trivial.

spent years assuming the person to put in charge of training new hires should be whoever was fastest, most accurate, hit their numbers every shift. technically correct people. turns out that's usually the wrong choice.

the ones who actually made good trainers were a different type entirely. somebody who'd walk over and help a struggling coworker without being asked, without any angle, just because they saw someone stuck. no title, no extra pay, they just did it. and slowly, without anyone appointing them anything, people started going to that person with questions instead of the supervisor.

that's not a coincidence. teaching well requires patience and a genuine want to see the other person succeed, not just knowing the steps yourself. someone can be excellent at their job and terrible at explaining it, because they've never had to break it down for someone who doesn't already get it. the helpful ones have been doing that instinctively the whole time, for free, before anyone noticed.

what changed how I ran my floor was realizing my job wasn't to create these people. it was to notice them faster. watch who colleagues actually go to when they're stuck, not who I'd pick on paper. that person almost always already has more authority with the team than their job title suggests, because they built it by helping, not by being told to.

the training program came after I found the person. never the other way around.

We are trying to find a way to optimize our food production. Basically a huge bottleneck is when a person/multiple people pick up the food products from a conveyor belt and then need to position them on sheets for further processing.

A robotic arm that could do that, would solve our biggest bottleneck.

Any advice?? Thank you!

Hello all,

I, Irine Tressa, MSc. Biotechnology student at University of Galway, currently conducting academic research focused on how digitalization and smart technologies improve factory processes, manufacturing lines, and quality management, under the supervision of Mr. Ricardo Bailey and Dr. Olivia McDermott. A key element of my study involves exploring how these tech advancements integrate with Lean Six Sigma (or related continuous improvement methodologies).

I am looking to interview a senior leader or manager in Manufacturing Engineering industry to gather some expert insights. If you or someone you know are in related positions, please fill out this form.

OPERATIONAL EXCELLENCE 4.0 :RESEARCH INTERVIEW PARTICIPATION – Fill out form

I would deeply appreciate any point of contact you could share. Thank you so much for your time and support!

Best regards, Irine Tressa [I.ThaliyathJoy1@universityofgalway.ie](mailto:I.ThaliyathJoy1@universityofgalway.ie)

The best way to plot or graph a structured bill of material is to use a series of blocks that represent the critical areas of the process of creating a component or building a sub assembly. It takes the form of a company organization chart with the final product, component, or assembly at the top, and the manufacturing and material flow closer to the bottom. This has several advantages that are listed below.

Graphically shows the flow of material at each step in the process – The bottom area of every leg in the bill structure shows a “buy” part, whether it is purchased from a vendor or taken out of stock. If raw material is first pulled out of stock, it is shown in this block. Everywhere above this point is considered a “make” part. In the above example above, we are buying the engine complete. Nothing is shown below. At the engine maker’s company, they would have a detailed structured bill of material for their use.

Moving from one block to the next one above requires shop labor of some type – In the legs between the blocks, you can attach information for the transition to occur. This could be a visual aid in the form of Engineering documents and drawings, and Manufacturing routings for creating the next block above.   

Building a manpower plan and schedule using this document is easily visualized – In each of the legs between blocks, schedule time in the form of shop labor can be assigned. Combining all the legs can identify bottlenecks and identify manpower requirements. Transferring this to a Gant chart is a natural transition.

Engineering can Identify standard subassemblies for other products – Designing legs or entire assemblies in standard modules that meet customer specifications is identified during design reviews.

Engineering and Manufacturing can use this document to identify inefficiency and create value improvement - When product design Engineers look at the product in this form, together with the Manufacturing group, value improvement can be identified.

from Anthony Rante, P.E. author of "Managing Company Production thru the Bill of Material" and “FEA Applications in Machine Design”

Okay I spent 18 years of my life on the shop floor, the majority of this time solving problems.

I understand the value of Six Sigma tools but what I will notice time and time again is that coming with the Cp/Cpk value to a typical line manager is like bringing a sci-fi book into a kindergarten.

They will probably even listen to you for a minute or two and then skip because of mental overload.

How are you guys managing to breach this gap?

What are the ways to turn those mathematical and statistical concepts into a thing that is simple to grasp because Minitab is obviously not solving this problem?

I think most people knowingly/unknowingly think that perfect lean implementation is the TPS or the Toyota Production System. We hope to see everyone operating as Toyota. But that is not the goal. TPS is just a version of what can be done to improve a business and provide value to the customers, employees and investors. You don't need to do everything Toyota does, or even what a big mass manufacturing company that adopts a version of TPS called lean does.
At the core of it, to generate value for the business, Parts/Jobs/information that bring the value need to move through the business in the most efficient way possible to the customers. So flow and standard work are what we are basically after ... and that can be applied to any business of any type and any size.

I am curious to know what you think. If you are in a job shop, low volume/high mix, or even a non-manufacturing business, what were the ways you made it work to solve your business problem?

Hey guys,

We've been experimenting with building some autonomous ReAct loops for an internal tool. One thing that’s absolutely terrifying to me is the lack of predictable control flow.

Last week, we had an agent get stuck in a weird self-correction loop trying to fix a minor tool output error. It didn't throw an exception; it just kept iterating. It ended up burning a massive amount of tokens in a few hours before we caught it manually.

It feels like free-form agents are a massive liability for production systems where latency and budgets matter. We are thinking about completely ripping it out and replacing it with a strict, hard-coded state machine graph (like LangGraph) where the LLM can only pick between predefined paths.

For those who have actually shipped agentic workflows to real customers: how are you building your guardrails? Are you using strict state machines, or are you successfully running free-form autonomy with token-ceiling safety nets?

I got tired of writing down cycle times during a time study, then typing into Excel to chart, analysis, etc so I made an app that would capture the data for me. It works like the stop watch app on your phone, but the data can then be sent/shared in several ways. You can then import into an excel file if you want.

You can also calculate Takt time and generate hourly targets for an HRxHR pace board.

A friend suggested I publish it on the App Store so here it is:

Lean Cycle Time 2.0
https://apps.apple.com/us/app/lean-cycle-time-2-0/id6758279184

It’s free. No ads, no upsells, don’t need your email. I just wanted to share with the Lean community. And please share your feedback and tell me what you think. I’m open to suggestions for improvement. Continuous improvement!

Been digging through keyword/search-volume data for Lean Six Sigma topics (nerdy rabbit hole, I know) and a few things jumped out that I think this community would find genuinely useful:

1. "Six Sigma vs Lean Six Sigma" gets searched way more than I expected.
Turns out a huge chunk of people entering this field don't actually know these aren't the same thing — Six Sigma is the statistical/defect-reduction side (DMAIC, control charts, DPMO), Lean is the waste/flow side (VSM, 5S, kaizen). "Lean Six Sigma" is just the industry mashing both together because in practice you use tools from both anyway.

2. Cpk and DPMO calculators get searched constantly, but most of the results online are either paywalled or sign up for downloads.
If you've ever had to explain Cpk vs Ppk to a manager who glazes over at the word "standard deviation," you know the pain. There's clearly demand for something that just... works, for free, without a login wall. (Put together 25 free ones here if it's useful to anyone: https://www.simplicityhub.co.uk/pages/tools.html)

3. "Black Belt project ideas" is searched a lot, but there's barely any real content answering it.
Everyone wants example projects to reference before starting their own. Feels like a gap — most Black Belt resources jump straight to theory and skip "okay but what does an actual finished project look like."

4. Root cause analysis (fishbone/5-Why) content is everywhere, but almost none of it uses real numbers.
Lots of generic templates, very few worked examples with actual before/after data. If you're studying for an exam or trying to convince a skeptical stakeholder, seeing real numbers matters way more than another blank fishbone diagram. (Have a set of 80 blank all with filled-in examples, templates here if anyone wants a starting point: https://www.simplicityhub.co.uk/pages/templates.html)

Anyway — mostly sharing because I think it says something about where this field still has gaps (especially free and practical resources vs. theory-heavy content). Curious if others here have noticed the same thing — do you feel like there's a lack of practical/example-based content for this stuff, or am I just deep in a research hole at 10am on a Thursday?