Guides / Operating gaps
The idea is simple enough: instead of a binder and a marked-up print, the person at the machine gets the setup, the steps and the pictures on a screen, current every time. Almost nobody argues with that. What kills it is the part nobody budgets for, which is that somebody has to write them all first.
You know which job it is. The one where the setup takes a day if the right person runs it and three days if he's on vacation. Where the fixture goes on a particular way for a reason that was explained once, four years ago, to somebody who has since left.
I run a manufacturing operation now, and I ran a machine shop for a decade before that. We had work instructions. They lived in a binder near the machine, they were three revisions behind the print, and the operators knew it, which meant they mostly asked a person instead. The binder wasn't the problem. The binder being wrong was the problem, and it was wrong because keeping it right was a job nobody owned.
Written down plainly: the steps for running a specific job, at a specific operation, on a screen at the machine instead of on paper. Usually with the things paper is bad at. A photo of the setup from the angle that matters. A short clip of the tricky part. The current revision of the print, not a copy of a copy. A note that this material moves when you clamp it there. The same shape of problem shows up as a changeover on a packaging line, or a batch that somehow runs differently on second shift.
It is not the same thing as capturing what your people know, though the two get sold together. Work instructions are the operation telling the operator how the job runs. Capturing tribal knowledge is the operator telling the next operator what he learned running it. Both are worth doing, they are different directions, and a tool built for one is usually bad at the other. If it's the second one you actually want, that's tribal knowledge capture.
Every vendor selling this knows the software is not what goes wrong. What goes wrong is upstream:
Start with one job. Not a department, not a product line. The single job where being wrong costs you the most, or where one person is the only one who can run it.
Then build the first instruction out of what you already have rather than from a blank page. Most operations have far more written down than they think: the setup sheets, the tool list, the current print, the inspection requirements, the notes somebody put on the traveler last run. Pulling those together into one screen is work a computer can do. Writing a hundred documents from scratch is work a person has to do, which is exactly why it never happens.
Then keep it current where the job actually changes. If the print revision moves, the instruction should know. If the tool list changes in the ERP, the instruction should know. An instruction that updates itself from the systems that already hold the truth is one that is still right in a year.
Where AI earns its place here is narrow. Reading a drawing, pulling the dimensions and requirements off it, turning a rough spoken note into a clear written step: that's language and document work, and it's genuinely good at it. Deciding how the job should be run is not that. That comes from your process engineer and your operators, and no model should be inventing it.
I have built the pieces this is made of, for a manufacturer, running daily: reading drawings and pulling dimensions off them automatically, generating the inspection sheet that goes with a job, and an operator-facing tool that brings up everything about a job from one scan at the machine. The first work-instruction build sits on top of those, around your job and your systems.
Something with a screen, near the machine, that survives the environment. That might be a tablet, a panel PC, or the computer that's already there. Decide it early. It's the one part with real hardware cost, and it's a decision about your floor, not about software.
If you're ISO 9001 or AS9100 certified, work instructions are already a controlled document and there are rules about revision and approval. That's a constraint to design around, not a reason to avoid the project, and it usually argues in favor: a system that controls revision automatically is easier to defend in an audit than a binder somebody was supposed to update.
No, and it matters that it isn't. The systems that run a whole floor price accordingly, with an implementation project attached. This is one job, on a screen, built onto what you already run. If a floor-wide system is what you need, buy one. Most operations asking this question don't.
Start with one and find out. If the first one saves the setup time it's supposed to and the operators use it without being told to, do the next few. If it doesn't, you've learned that cheaply. Any answer that starts with "roll it out across the plant" should make you suspicious of whoever is giving it.
I build it, host it, and keep it running for you on managed infrastructure, working on top of the systems you already run, so nothing moves to a new platform. It's a Build that's quoted up front, so you know the price before it starts. After that an ongoing care plan keeps it running: hosting, monitoring, bug fixes, and small adjustments as your work changes, with term and price by agreement. No hourly billing and no per-seat license; the ongoing cost is simply what keeps the tool running and improving.
It starts with a paid half-day, $2,500, at your place or over video. AI reads, drafts, and remembers what your people know. It is not exact, and it does not run your systems. So we go through the jobs eating your week and sort them: the reading, writing and know-how AI can genuinely help with, and the parts that need a tool built because the answer has to be right every time. Your people leave able to set those up themselves. A skill is your way of doing a job, written down so the AI follows it instead of guessing. Whether AI, a small build, or nothing at all is the honest answer, I'll say so. Written document within two working days. If a build is the answer, I confirm what you already have written down and pin down the scope before quoting. From there it's a Build that's quoted up front, the number's set before any code is written.
Related reading: ballooning drawings and building the inspection sheet, which is the piece of this that already runs, and tribal knowledge capture, which is the same problem pointed the other way.
If there's a job in your operation that goes sideways when a particular person isn't there, send a note. First call's free. About 30 minutes, a straight conversation about what's actually written down and what isn't, not a demo. If there's something worth building, I'll say so; if there isn't, I'll say that too.