Every engineer has sat in the meeting where someone says, "We should really do an FMEA on this." Everyone agrees. Nobody has a free week. The FMEA gets done after launch, by one person, so someone can say it was done.
The tools were never the problem. The cost of doing them was.
None of these tools is new. ISO processes have asked for this kind of planning and risk work for decades. As computer intelligence works out how to manage bots, it keeps rediscovering them. The tools people already know apply to bots too.
The old math
Quality people learn some version of the 1-10-100 rule. It's often credited to George Labovitz and Yu Sang Chang. A problem caught in design costs about 1 to fix. Caught in production, about 10. Caught by the customer, about 100.
The numbers are a rule of thumb, not a law. The shape is real. The later you find it, the more it costs.
So why did anyone skip the early analysis? Because the analysis had its own cost:
- A week of an engineer's time for an FMEA.
- A day in a conference room for a fault tree.
- Hours of digging through old reports for lessons learned.
When the analysis costs more than the problem you expect to find, people skip it. That's not laziness. That's a budget.
The new math
A bot can draft most of these analyses quickly, for far less than a week of an engineer's time. Not perfectly. But a complete first draft, every row filled in, ready for people to argue with.
That changes the question. It used to be "Is this worth a week?" Now it's "Is this worth a bot's draft and an hour of review?" For almost any real decision, the answer is yes.
The cost of finding a problem late didn't change at all.
The meeting changes
Here's the part people miss. The old way, the meeting was the work. Six people in a room filling in a table, row by row, for a day.
The new way:
| Old way | With a bot | |
|---|---|---|
| Who fills it in | The team, in a meeting | A bot, before the meeting |
| What the meeting does | Builds the table | Argues about the table |
| Where people spend time | Typing, scoring, copying rows | The ten rows that matter |
| How often it gets redone | Almost never | After every real change |
The experienced people stop being typists. They become reviewers. That's a much better use of the people who know the product.
How to run it
The pattern is the same for every tool in this series:
- Give the bot the real inputs. Drawings, specs, complaint logs, test results, the process map. Not a description from memory.
- Give it the tool's shape. The table, the steps, the stopping rule. Each tool page has a brief you can copy.
- Let it draft the whole thing. Every row, every branch.
- Have it mark its guesses. Anything not traced to an input gets flagged.
- A person reviews the top of the list. Not every row. The ones that rank highest and the ones marked as guesses.
- Decide, and write it down. See Write it down or it didn't happen.
The bot brief
You are running a [TOOL NAME] analysis.
Inputs: [list the files]. Use only these. Do not invent parts, steps, data or history.
Output: the [TOOL] table in the format below, complete.
For every row, cite the input it came from. If a row is your judgment and not
from an input, mark it GUESS.
At the end, list: the 5 items you'd want a person to look at first, and why;
and anything you needed but didn't have.
Do not decide or approve anything. This is a draft for review.Starting point only. Test it on your own data and model, and adjust as needed before you rely on it.
The new risk: cheap paperwork
There's a catch, and it's a real one. Paperwork used to be expensive, so there wasn't much of it. Now a bot can produce a polished hundred-row analysis in a minute. That's a new way to fail:
- Nobody reads it. A long analysis that goes in a folder isn't analysis. It's a file.
- It doesn't belong to your product. Generic rows that could be pasted onto anything. See FMEA for bots.
- It looks finished. A neat table feels authoritative even when half of it is guessed.
- People skim and approve. The faster the drafts come, the easier it is to wave them through.
The answer is the same one the old tools always had: real inputs, ranked output, and a person who decides.
Where bots differ
A team of engineers brings judgment from years on the floor. A bot brings speed and patience. It doesn't get tired at row sixty, and it doesn't mind redoing the whole thing after a change.
Neither replaces the other. The bot does the groundwork. People check it against reality and decide.
What this means for you
- Go back to the analyses you've been skipping. Most of them are now cheap.
- Give the bot real inputs, not a summary.
- Turn workshops into reviews.
- Read the top of the list and the guesses. Skip the rest.
- Keep a record of what was decided.