Knowledge management in an industrial company: a practical start
When a senior engineer with thirty years of drive commissioning experience retires, something leaves the building that no exit interview captures: the unwritten map of which relay chatters on humid mornings and which vendor actually answers the phone. Industrial companies call the attempt to keep this knowledge management, and most attempts fail for predictable reasons. This article is about starting one that survives contact with reality.
Why knowledge programs die in industrial companies
The classic failure is the portal project: a document management system is purchased, departments are told to upload their knowledge, and eighteen months later the search returns scanned circulars from 2009. The tool was never the problem. Knowledge that matters in a plant is tied to equipment, incidents and people, and it only moves when there is a reason to write it down and a person who reads it. A database without a use case is a graveyard with a login screen. The fix is to start from a recurring event — a failure review, a design freeze, a retirement — and let the capture habit grow around it.
The second failure is confusing documents with knowledge. A commissioning report is a document; the knowledge is the paragraph explaining why the team set the protection pickup at that value against the consultant's recommendation. Capture systems that collect files but strip context produce archives, not memory.
Start with the losses, not the library
A working program begins by asking where the company repeatedly pays for the same lesson. Repeat equipment failures, warranty disputes lost for lack of records, tenders priced wrongly because the last similar job's costs live in one person's head — these are the business cases. Pick two or three, and build capture around them. A root-cause analysis database that gets consulted before every repeat failure pays for itself the first time it prevents one.
| Knowledge type | Where it lives today | Practical capture method |
|---|---|---|
| Failure lessons | Emails and memory of senior staff | Structured RCA reports, indexed by equipment tag |
| Commissioning settings | Loose test sheets | As-left parameter records in the asset register |
| Vendor performance | Anecdote | Short post-order scorecards per purchase order |
| Design decisions | Meeting minutes, if any | One-page decision notes filed with the drawing |
The people mechanics that make it stick
Knowledge moves between people before it moves into systems. Structured handovers work: a departing engineer spends defined sessions with a successor walking through open issues, and the notes from those sessions get filed against the equipment tags they concern. Communities of practice work too — a quarterly meeting where the drive specialists from three plants compare failures generates more usable knowledge than a year of database uploads. The system's job is to preserve what these human processes produce, indexed so a stranger can find it.
- Index everything by equipment tag and product line, not by department.
- Give every RCA and decision note an owner and a review date.
- Make the search good enough that engineers find answers faster than phoning a colleague.
- Measure use: a record nobody opens is decoration.
Technology: just enough, not more
A practical sequencing note: most successful programs run a six-month pilot on one product line or one plant before scaling. The pilot exposes the indexing mistakes and the authorship resistance while the stakes are small, and it produces the internal success story that convinces the next department. Scaling a broken taxonomy across five plants just multiplies the cleanup.
The tool question comes last. A disciplined shared drive with a naming standard beats an expensive platform used carelessly, and a modest knowledge portal that engineers actually search beats a sophisticated one they route around. What the tool must do is full-text search across attached documents, tagging by equipment and topic, and version control so yesterday's parameter sheet does not masquerade as today's. Everything else is negotiable.
Risks and red flags
The first red flag is a program owned by IT or HR alone: knowledge capture is an engineering discipline problem and dies without an engineering owner. The second is volume worship — counting uploads as success, which fills the system with circulars and starves the signal. The third is neglecting the legal angle: incident reports written carelessly become exhibits, so RCA documents need a clear, factual writing standard and a review step. And the quietest risk is retirement arithmetic: count how many of your critical specialists leave within five years, because that number is your real project deadline.
Knowledge management is not a library project. It is insurance against paying tuition for the same lesson twice.