Every plant I have worked in had a lessons learned register, usually born after a painful customer escape or a failed audit, filled enthusiastically for six weeks, then quietly abandoned. The entries sit in a shared drive folder while the organisation repeats the same mistakes on the next programme. I have watched the same bolt-torque issue surface on three consecutive launches because the write-up from the first one was a three-line email pasted into a spreadsheet cell.
The failure is not a lack of good intentions. Engineers genuinely want to capture knowledge. The failure is structural: the knowledge is stored where nobody looks, in a format nobody can act on, with no forcing function that brings it into the design or process decision at the moment it matters.
Fixing those three things — capture format, searchability, and forced consultation — turns a graveyard into a working tool. Each one is a discrete, auditable mechanism, not a cultural aspiration, and each can be implemented with the tools most plants already own.
How Not to Capture a Lesson
Most entries are written by whoever closed the issue, at the moment they least want to write anything. The result is narrative prose: "We had a problem with the bracket in the paint shop, engineering looked at it, it was resolved." Six months later nobody can tell whether the lesson applies to their bracket, their paint shop, or their failure mode at all.
A lesson entry needs a structured header, not a story. The minimum fields are: the failure mode in functional terms (what function was lost, not which part broke), the root cause mechanism, the detection method that existed at the time and why it missed it, the escape point, the fix, and the applicability conditions — part family, process, material, environment.
The applicability conditions are the part everyone skips and the part that matters most. A lesson about zinc embrittlement of high-strength fasteners does not apply to low-carbon sheet metal, and the entry must say so explicitly. Without that boundary, the database returns noise and engineers stop trusting it.
Keep the narrative, but as a footnote to the structured fields, not the other way round. Cap it. If the lesson cannot be summarised in one paragraph under the structured header, the author does not yet understand it well enough to publish.
Searchability: Treat It Like a Parts Catalogue
A lessons database that cannot be searched by the conditions of the new problem is a filing cabinet with the key thrown away. Engineers do not browse; they search when they have a specific question. If the entry does not contain the vocabulary they will use in that moment, it does not exist.
This means disciplined tagging against controlled vocabularies, not free text. A working taxonomy has four axes: failure mode category (fracture, leakage, dimensional drift, contamination, software logic), process step, material class, and mechanism keyword — fatigue, galvanic corrosion, stress relaxation, hydrolysis, weld porosity.
Controlled vocabularies matter because an engineer searching "cracking after e-coat" will never find an entry tagged "brittle fracture — hydrogen embrittlement" unless someone has mapped the colloquial term to the technical one. Synonym mapping is maintenance work, and it must be assigned to a named owner, not left to hope.
The other half of searchability is retrieval testing. Once a quarter, pick three real past issues and ask someone outside the authoring team to find the relevant lessons using only the search function. Time it. If they cannot find the entry in a few minutes, or find three irrelevant ones first, the taxonomy is failing and needs revision. Treat this like gauge calibration under MSA logic: unverified search is unverified data.
Forced Consultation at Gate Reviews
Voluntary use of a lessons database is a fantasy. People under launch pressure will not go looking; the schedule does not reward it. The only reliable mechanism I have found is hard gating: no design review or process readiness review closes until the applicable lessons have been retrieved, read, and dispositioned in writing.
Concretely: at each gate, the responsible engineer runs the query against their part family, process, and materials, attaches the resulting lesson list to the review pack, and records a disposition for each — applied, with evidence of where, or not applicable, with a reason.
The "not applicable" justification is where the real work happens, because it forces the engineer to actually read the entry rather than click past it. I have sat in reviews where a young engineer's dismissal was challenged by a quality lead who remembered the original issue, and the design changed on the spot.
The gate review lesson loop
- 01QueryRun the taxonomy search against part family, process and material for the gate in question
- 02RetrieveAttach the resulting lesson list to the review pack as evidence
- 03DispositionRecord applied with location, or not applicable with technical reason
- 04ChallengeReviewer tests the justifications against the original entries
- 05CloseGate signs off only when all dispositions are complete
Keep the burden proportionate. If a gate review generates forty applicable lessons, the query is too broad and the tagging too loose. Ten to fifteen well-targeted entries per gate is manageable; beyond that, people start bulk-approving, which is worse than not asking because it creates false evidence of diligence.
Review the disposition records during internal audits. A pattern of identical one-line justifications is the signal that the forcing function has decayed into rubber-stamping, and it is easier to correct early than after an escape traced to an unread lesson.
Where the Database Should Live
Placement determines usage more than any software feature. A standalone lessons system, separate from the tools engineers open every day, will not be visited. The knowledge must sit where the work happens, surfaced automatically.
In practice this means embedding lesson retrieval into the engineering change and process documentation workflow itself. When someone creates a new process flow for a machined housing, the system should push applicable lessons onto the working page — a panel next to the flowchart, not a separate portal requiring a login and a mental context switch.
Where tooling budgets do not allow that integration, the fallback is a standing agenda item in the weekly engineering meeting: five minutes, one lesson read aloud, one discussion of whether it touches anything currently in the pipeline. It is primitive, it is cheap, and it works because it puts the knowledge in front of people who would never have searched for it.
Physical placement matters on the shop floor too. The best implementations I have seen print the top applicable lessons and post them at the workstation or in the launch war room during ramp-up. A laminated sheet describing the exact coolant contamination issue that scrapped a batch last year, hanging above the machine, gets read. The same text in row 847 of a database does not.
Keeping the Content Honest and Alive
A database with stale entries destroys its own credibility. If an engineer retrieves a lesson, follows it, and discovers the fix described no longer matches current practice — the supplier changed, the material spec was revised, the process moved to another line — they will not trust the next entry. One bad experience poisons the well for the whole system.
Assign ownership by domain, not centrally. The welding engineer owns welding lessons; the coatings engineer owns coatings lessons. Each owner reviews their entries annually: confirm the applicability conditions still hold, retire entries rendered obsolete by design or standard changes, and merge duplicates.
Duplicate entries are a particular plague when capture is decentralised — the same hydrogen embrittlement lesson entered four times by four plants, each with different wording, which then splits the search results and dilutes retrieval. Consolidation is not optional housekeeping; it is retrieval performance.
Measure how many gate dispositions cited a lesson as applied, and how many repeat failure modes had a matching entry at the time. The second number tells you whether the system prevents recurrence or merely documents it.
The metric that matters is not "number of lessons captured" — that incentivises quantity over usefulness. Measure the loop instead: dispositions citing lessons applied, and repeat failure modes that had a matching entry in the database when they recurred. The second number is the brutal one, and it belongs on the management review agenda next to cost of poor quality.
Institutional Memory That Outlives Turnover
The quiet killer in manufacturing is turnover. When the engineer who lived through the difficult launch leaves, twenty years of scar tissue walks out with them, and the successor rediscovers every lesson at full price. I have seen a supplier repeat a tooling mistake within eighteen months of the original because the person who understood it had retired and the database entry was a two-sentence note nobody could parse.
A functioning lessons system is the antidote, but only when all three disciplines hold together. Structured capture makes the entry interpretable years later by someone with no context. Controlled-vocabulary search makes it findable at the moment of decision. Gate enforcement makes it consulted even when the schedule screams. Remove any leg of that tripod and the database reverts to a graveyard.
What separates a living system from a graveyard
Graveyard register
- Narrative prose entries written under closure pressure
- Free-text search that misses every colloquial phrase
- Voluntary consultation that never happens under launch pressure
- Entry count celebrated as the headline metric
Working institutional memory
- Structured header with explicit applicability conditions
- Controlled taxonomy with synonym mapping and quarterly retrieval tests
- Hard gate: no review closes without written dispositions
- Recurrence-with-matching-entry measured and reviewed
Start small if you must. Take your last five significant escapes, rewrite them into the structured format, build the taxonomy around the failure modes you actually see, and gate the next design review against just those five. When an engineer catches a repeat because the entry was in front of them at the right moment, you have the internal evidence to build the rest.
The tool is not complicated. The discipline is. And unlike most quality investments, this one costs almost nothing beyond the discipline itself — which is precisely why plants keep failing at it and why the ones that succeed hold a compounding advantage every launch cycle.