โ†
AI for Manufacturing
Visionary ยท M5 ยท lesson 5 of 16 ยท queued
Preview โ€” browse every lesson free. Enroll to mark lessons complete, open partner links and save your progress. Login & enroll โ†’
Identifying Novel Manufacturing AI Applications
๐Ÿ“–
now learning

Identifying Novel Manufacturing AI Applications

15 min

A maintenance planner named Rosa kept a paper notebook for eleven years. Every time a machine went down, she wrote a line: the date, the asset, what broke, and a short phrase about what actually fixed it. Nobody asked her to do this. When the plant rolled out its shiny AI program, the vendor came in selling a predictive-maintenance platform that watched vibration sensors on the big presses. It was a good system and it caught a few bearings. But the highest-leverage AI opportunity in that plant was not on the vendor's slide. It was Rosa's notebook: eleven years of cause-and-fix pairs that, fed into a grounded retrieval system, could put thirty years of floor judgment in front of a green technician at 2 a.m. when Rosa is home asleep. The vendor never saw it because the vendor sells one thing and looks for that thing everywhere. Rosa never saw it because to her it was just a notebook. The plant's reliability engineer saw it, because she had learned the one skill this lesson is about: how to find the next high-leverage AI application on your own floor before a competitor or a vendor finds it for you, and usually in a place no demo will ever point you. The talent cliff makes this a survival skill, not a nice-to-have. With roughly 2 million workers needing reskilling, about 500,000 roles unfilled, and 85% of manufacturers saying staffing shortages are hurting quality, the plants that win are the ones that keep finding new ways to let a thinner, greener crew do more, and most of those ways are hiding in plain sight.

Why the Best Cases Are the Ones Nobody Is Selling

There is a structural reason the most valuable AI application in your plant is rarely the one in the brochure. A vendor builds a product, and a product has to be the same for many customers to be worth building. So vendors gravitate to the use cases that generalize: vibration-based predictive maintenance on rotating equipment, cosmetic defect detection on a conveyor, demand forecasting. These are real and often worth buying. But by definition they are the cases that look the same across plants, which means they are also the cases your competitors are buying. Buying the same generalized tool as everyone else does not create an advantage. It just keeps you from falling behind.

The cases that create an advantage are the ones rooted in something specific to your plant: your process, your products, your defects, your tribal knowledge, your particular loss chart. A vendor cannot sell you a model trained on Rosa's notebook because Rosa's notebook does not exist at any other plant. That specificity is exactly why it is high-leverage and exactly why no salesperson will ever bring it to you. The novel application is, almost by definition, the one that depends on an asset only you have.

Consider the economics with a number. A generalized vision system that cuts a common cosmetic-defect escape might save a plant $200,000 a year, and every competitor running the same line can buy the same result, so it becomes table stakes. A knowledge-capture system built on your retiring tool-and-die maker's thirty years of "this die means the upstream punch is dulling" might save less in raw dollars at first, say $120,000 in avoided scrap and downtime, but no competitor can replicate it, and it keeps paying after the expert is gone. The first number is bigger and temporary. The second is smaller and durable. Durable beats temporary, and the only way to find the durable cases is to look where vendors never look: at what makes your plant uniquely itself.

The AI application that creates a durable advantage is the one that depends on an asset only your plant has, which is exactly why no vendor will ever bring it to you.

Four Places the Next Case Hides

Novel does not mean exotic. It means unseen. The next high-leverage case is almost always hiding in one of four ordinary places on your floor, and the skill is learning to look at each of them with fresh eyes.

The repetitive judgment a thin crew keeps redoing

Look for the decision a person makes the same way, many times a day, that depends on experience and is now being made by fewer and greener people. Disposition of a borderline part. The call on whether a slightly-off reading means stop the line or keep running. Which work order to do first when there are forty and three techs. These are repetitive expert judgments, and they are precisely where a thinning crew bleeds quality and uptime. The night-shift inspector who is new and unsure passes the part Dave would have caught. AI used as an advisor, grounded on the plant's own records, can put the experienced judgment in the room when the experienced person is not. The tell that you have found one of these: a task where the answer depends heavily on who is doing it, and the experienced person is about to retire.

The data you already collect and never use

Every plant collects mountains of data it never looks at again. The historian has fifteen years of process traces nobody has queried. The quality system has thousands of defect records with photos. The CMMS has a decade of work orders with free-text notes describing what actually fixed each failure. Rosa's notebook is the analog version of this. The tell here is a data source that is faithfully recorded and almost never read. That gap between collected and used is a map of latent AI opportunities, because the data is the expensive part and you already paid for it. A predictive model needs labeled failure history; if your CMMS free-text holds it, you are most of the way there and you did not know it.

The slow, manual workflow between systems

Watch for the place where a person spends an hour every day being a human bridge between two systems that do not talk: copying numbers from the historian into a spreadsheet, retyping a tech's scribbled notes into the CMMS, assembling a containment report from a paper traveler and three operators' memories. These manual bridges are slow, error-prone, and a quiet tax on a crew that has no spare hours. They are also some of the easiest high-value cases, because AI is good at reading messy input and producing structured output, and the human stays in the loop to verify. The tell: a recurring task everyone hates that involves moving information by hand from one place to another.

The loss bar that has resisted every traditional fix

Go back to the loss chart, the Pareto of where the plant bleeds money: unplanned downtime, scrap and rework, quality escapes, changeover. Find the bar that lean projects and kaizen events have failed to move for years. A bar that resists traditional improvement is often resisting because the root cause is buried in patterns too complex or too scattered for a human to see, which is exactly the kind of problem pattern-finding AI can sometimes crack. The tell: a stubborn loss that has survived multiple improvement attempts. That stubbornness is a clue that the problem is information-shaped, and information is what AI is for.

The Three Questions That Separate Real From Shiny

Finding a candidate is the easy half. The hard half is killing the bad ones fast, because a plant has limited bandwidth and a thin crew, and chasing a shiny case that cannot survive a real line is how transformation programs lose credibility. Three questions, asked honestly, filter most candidates.

Question one: is there data, and is it labeled? AI learns from examples. A vision model needs labeled images of good and bad parts. A predictive model needs failure history tagged with what failed. A knowledge system needs the records to retrieve from. The single most common reason a promising case dies is that the data does not exist, exists but is not labeled, or is too sparse to learn from. If you want to predict a failure that has happened four times in ten years, you do not have enough examples, no matter how painful those four failures were. Ask first: what would the model learn from, and is that data real and labeled today? If the answer is "we would have to start collecting it," the honest timeline just got a year longer, and that is fine to know up front.

Question two: can a human verify the output, and will they? The cardinal rule of floor AI is that the customer audits you, not the vendor, and accountability for an AI-touched decision stays with the plant and the human who signs the record. So every candidate has to answer: when the AI produces an answer, can a person on the floor check it against the drawing, the standard, or the historian before it counts? A case where the output cannot be verified, or where verification takes longer than just doing the task by hand, is not a good case. And there is a human-trust layer underneath: an operator who has been burned by a false alarm will disable the green light, so a case that floods the crew with false positives will fail in the field no matter how good the demo looked.

Question three: does it touch control or safety? This is the kill switch. If the candidate puts AI in direct control of something that moves, or anything that can hurt a person, it goes to the back of the line or off the list. Keep AI advisory and out of direct control unless it is properly governed, because 78% of OT networks lack centralized monitoring and you cannot safely automate inside a plant you cannot fully see. The highest-leverage early cases are advisory: the AI recommends, a human decides. That is not a limitation to apologize for. It is the design that lets a thin crew move fast without betting safety on a model.

Worked example of the three questions doing their job. A plant CI lead gets excited about using AI to automatically adjust an injection-molding machine's parameters in real time to chase first-pass yield. Question one: is there labeled data linking parameter settings to outcomes? Some, in the historian, but messy. Question two: can a human verify a real-time auto-adjust before it acts? Not at machine speed; by the time a human checks, the shot is made. Question three: does it touch control of something that moves? Yes, directly. The case is not dead, but the honest version is reframed: instead of AI auto-adjusting the machine, AI flags drifting parameters and recommends an adjustment to the process technician, who makes the call. Same data, same yield target, but now it passes all three questions because the human stayed in control. The reframe is the skill.

Scoring Candidates: Impact Times Feasibility

Once a handful of candidates survive the three questions, you need a way to rank them that a thin team can actually act on. The trap is to rank by impact alone, which sends the team chasing the biggest prize regardless of whether it can be built this year. The better frame is impact times feasibility, because a medium-impact case you can ship in three months beats a huge-impact case that takes two years and may never land.

Impact is measured against the loss chart in real units: dollars of avoided downtime, yield points, scrap reduction, hours of skilled labor freed. Resist the vanity version. "It would be cool" is not impact. A logged CMMS save and a first-pass-yield delta are impact. Put a defensible number on each candidate, even a rough one, tied to the two bars that dominate every plant: unplanned downtime and scrap or rework.

Feasibility is mostly the three questions turned into a score: how good and labeled is the data, how cleanly can a human verify it, how far is it from control and safety, and how much brownfield drag will it hit. Brownfield drag is real. A case that needs data from a 1990s PLC that does not expose the right tags is less feasible than one built on a modern historian, and pretending otherwise is how timelines slip. Greenfield plants deploy AI 40 to 60% faster precisely because they lack this drag, so a reshored or newly instrumented line may make a case feasible that would be a slog on an old one.

The honest scoring move is to plot candidates on impact against feasibility and start in the high-impact, high-feasibility corner, not the high-impact, low-feasibility one that the excitement always pulls toward. The first win should be feasible enough to actually ship and impactful enough to matter, because the first deployed case is what buys credibility and budget for the harder ones. A novel case that never ships teaches the floor that AI is hype. A novel case that ships and logs a real save teaches the floor that AI is a tool they can trust, and that lesson is worth more than the save itself.

A worked scoring example

Say a reliability team has three survivors. Case A: vibration predictive maintenance on the main presses, high impact (the presses cause the tallest downtime bar at roughly $300,000 a year) but medium feasibility because the data exists. Case B: turning the CMMS free-text history into a grounded troubleshooting assistant for the green night crew, medium impact (maybe $120,000 in faster repairs and avoided repeat failures) but high feasibility because the data is already collected and the output is advisory and easily verified. Case C: an AI that auto-schedules the whole plant, huge claimed impact but low feasibility because it touches control, needs data the plant does not have, and is hard to verify. Impact times feasibility ranks B first as the credibility-building first win, A second, and C last or off the list. The biggest claimed prize, Case C, is the one to resist. The unglamorous Case B, built on data the plant already owns and a green crew that desperately needs it, is the one that proves the program and funds the rest.

Building a Habit, Not a One-Time Hunt

Finding novel applications is not a workshop you run once. It is a standing habit, because your plant keeps changing: new products, new defects, new data sources, and every November another expert walks out the door carrying knowledge nobody captured. The plants that stay ahead build a lightweight, repeatable way to keep surfacing candidates rather than waiting for a vendor to tell them what is possible.

The simplest version is an idea pipeline that lives close to the floor. Operators, techs, and engineers are the ones who see the repetitive judgments, the unused data, the manual bridges, and the stubborn loss bars every day, because they live in them. A standing way for them to flag "this is the same annoying thing I do every shift" turns the whole crew into scouts. Most of the best novel cases in any plant are already known to somebody on the floor as a daily frustration; they just were never framed as AI opportunities. The reliability engineer who found Rosa's notebook did not invent it. She noticed it.

Two failure modes kill the habit. The first is the vendor-led trap: letting the salesperson's roadmap define what is possible, which guarantees you only ever consider the generalized cases everyone else is buying. The second is the moonshot trap: a team that only gets excited about the huge, hard, control-touching cases and never ships the unglamorous high-feasibility ones, so the program produces impressive slides and no logged saves. The discipline that beats both is the same: keep a running list of candidates from the four hiding places, score them on impact times feasibility, kill the ones that fail the three questions fast, and ship the feasible ones to build the credibility that funds the rest.

There is one more reason to make this a habit rather than an event, and it is the reshoring tailwind. With roughly 45% of executives citing reshoring as a demand driver, new domestic capacity is being stood up by a workforce that does not yet exist. A plant that has built the muscle of finding and shipping novel, floor-specific AI cases can stand up a new line with that capability baked in, capturing the greenfield speed advantage instead of starting the hunt from zero. The habit compounds. The one-time hunt does not.

Key Takeaways

  • The highest-leverage AI case in your plant is rarely the one a vendor is selling. Vendors sell generalized cases that look the same across plants, which means your competitors are buying them too, so they are table stakes, not advantage. The durable cases depend on an asset only your plant has, which is exactly why no salesperson will bring them to you.
  • The next case hides in four ordinary places: the repetitive expert judgment a thinning crew keeps redoing, the data you already collect and never use (the unqueried historian, the CMMS free-text, Rosa's notebook), the slow manual workflow where a person bridges two systems by hand, and the loss bar that has resisted every traditional fix.
  • Three questions kill bad candidates fast: is there real, labeled data to learn from; can a human verify the output (and will they, given that a false-alarm-burned operator disables the green light); and does it touch control or safety. The third question is a kill switch, since 78% of OT networks lack centralized monitoring and AI should stay advisory unless properly governed.
  • Reframing, not rejection, is often the move. An AI that auto-adjusts a molding machine fails all three questions; an AI that flags drifting parameters and recommends an adjustment to the technician passes all three with the same data and the same yield target. Keeping the human in control is the design, not a limitation.
  • Rank by impact times feasibility, not impact alone. A medium-impact case you can ship in three months beats a huge-impact case that takes two years and may never land. Start in the high-impact, high-feasibility corner; the first deployed case buys the credibility and budget for the harder ones.
  • In the worked scoring example, the unglamorous CMMS-troubleshooting assistant (about $120,000, high feasibility, advisory) beats the press predictive-maintenance case and crushes the auto-scheduler moonshot, because it is built on data the plant already owns and a green crew that needs it, and it ships.
  • Make it a standing habit, not a one-time hunt. Build an idea pipeline close to the floor so operators and techs become scouts for the four hiding places, since most of the best cases are already known to somebody as a daily frustration that was never framed as an AI opportunity.
  • Beat the two habit-killers: the vendor-led trap (only ever considering generalized cases everyone buys) and the moonshot trap (only chasing huge control-touching cases that never ship). The plant that builds this muscle can stand up a new reshored line with the capability baked in, capturing the 40-to-60% greenfield speed advantage instead of starting the hunt from zero.