An engineer needs the procedure for a machine. It is in a folder somewhere, or on the intranet, or attached to an email from 2023, or on the shared drive under a name that made sense to whoever saved it. Twenty minutes later they ask a colleague, who also does not know, and eventually somebody prints the version they have and hopes.
Knowledge management for manufacturing is usually sold as a search problem, and search is the easy half. The hard half is that two documents both claim to be current, and nothing in a search system can tell you which one is right.
What plain-English search actually gives you
The genuine improvement is real and worth having. Instead of guessing filenames, someone asks what the torque setting is for a particular assembly and gets the answer with the document and page it came from.
- It searches meaning rather than words, so a question phrased differently from the document still finds it. This is the main gain over keyword search on a shared drive.
- It reads inside files, including scanned drawings and PDFs, so information trapped in an attachment becomes findable.
- It cites the source. Every answer points at the document, the version and the page. Without this nobody trusts it twice, and it should be non-negotiable.
- It works across places, so the intranet, the document system, the shared drive and the email archive are one search rather than four.
- It answers the question rather than listing files, which for a person standing at a machine is the difference between useful and not.
The revision problem knowledge management cannot solve
Here is where honesty matters more than capability.
If your shared drive holds a procedure marked Rev C, another copy in a different folder also marked Rev C with different content, and a PDF called procedure-final-updated, a search system will find all three. It can tell you when each was modified and where each lives. It cannot tell you which one the shop floor should be following, because that is a fact about your business rather than about the documents.
Worse, a confident answer drawn from a superseded revision is more dangerous than no answer, because the engineer has no reason to doubt it. In a manufacturing setting that is not an inconvenience.
- Decide which location is authoritative for each document type, and say so plainly. Everything else becomes an archive.
- Search only the authoritative locations at first, even if that means covering less. Coverage without authority is the trap.
- Mark superseded documents as superseded where they sit, rather than relying on people to notice a date.
- Make the answer show the revision and the date, so a human can apply judgement when something looks off.
- Accept that tidying comes first for some document sets. This is unwelcome and it is the honest sequence.
Permissions are not an afterthought
The failure that ends these projects: a search system that dutifully answers a question using a document the person asking was never allowed to see.
Manufacturing document sets routinely include commercially sensitive drawings, customer-specific designs held under agreement, supplier pricing and personnel material. A system that indexes everything and answers everyone has quietly removed every access control you had.
- Permissions must be applied at answer time, per person, not at index time. Anything else eventually leaks.
- Test it with two accounts before anyone trusts it, using a document one of them should not see. Ask any supplier to demonstrate exactly that.
- Respect the permissions already set in the source systems rather than inventing a second scheme, because two schemes drift apart within months.
- Log who asked what. In a regulated or customer-audited environment you will need this, and it is far easier to enable at the start.
Where the documents actually live
| Source | Difficulty | Note |
|---|---|---|
| A modern document system | Easy | Permissions and revisions already exist and can be respected. The best case by a distance. |
| SharePoint or a cloud drive | Straightforward | Well supported. The work is deciding which parts to include rather than connecting. |
| A shared network drive | Moderate | Technically fine, and it is where the revision problem lives. Expect to tidy. |
| Email archives | Moderate | Genuinely valuable, because decisions often exist only in email, and the permissions question is sharper here. |
| Paper and scans | Harder | Readable, with variable quality. Worth doing for the manuals nobody has digital copies of. |
| A machine vendor's portal | Usually not possible | Frequently no way in. Plan around it rather than assuming. |
The questions worth answering first
Search projects go wrong by trying to cover everything. They go right by starting with the questions that cost the most time, which in most manufacturers fall into four groups.
- How do I do this on this machine? Procedures, settings, maintenance intervals. The highest-volume question and the one where a wrong answer matters most, which is why authority beats coverage.
- What did we do last time? Previous jobs, past changes, the reason a decision was taken. Frequently the answer exists only in an email, which is why the email archive is worth including despite the permissions work.
- What is the spec for this part? Drawings, tolerances, customer requirements. Usually well organised because somebody was made responsible for it, and therefore the easiest to search reliably.
- What are we allowed to do? Certifications, customer agreements, regulatory constraints. Lower volume, and the answers are the ones people most need to be exactly right.
Pick one group, cover it properly with authoritative sources and citations, and let people use it for a month before adding the next. A search that answers one category confidently is trusted; one that answers everything approximately is abandoned, and regaining that trust costs more than the original build.
Who keeps it working
The ongoing job that does not appear in the quote, and the reason some of these fade after a year.
Somebody has to look at what people asked and what they got, monthly at first. Not a dashboard of query volumes, the actual questions and answers. That is how you find the procedure everyone searches for that does not exist, the term your engineers use that no document contains, and the answer that has quietly become wrong because a revision changed and the old one is still indexed.
Half an hour a month from someone who knows the plant. Without it the system does not break dramatically, it decays quietly, which is harder to notice and harder to argue for fixing.
What it costs
| Scope | Build | Ongoing |
|---|---|---|
| One well-organised source, search with citations | $20,000 to $50,000 | Per-query cost, plus someone watching quality |
| Several sources, with permissions respected | $50,000 to $120,000 | The above, plus keeping connections alive |
| The above, plus a copilot answering in context | $100,000 and up | A permanent capability rather than a project |
Illustrative ranges from the kind of work we quote, not a price list. Budget separately for tidying documents, which is not our work to do and is frequently the larger job.
If what you actually need is figures pulled out of documents rather than answers found in them, that is document intelligence. If you want it answering inside the tools people already use rather than as a separate search, that is copilots. And can you trust what an AI assistant tells your customers applies here with more force, because the reader is acting on the answer.
Not for you if
The test before commissioning anything: pick the five questions engineers ask most, and try to answer them yourself using only what is on the shared drive. How long that takes, and how confident you are in each answer, is your project specification.