There is a note taped to a filling line. Handwritten, laminated, yellowed at the corners: “On fault 217, do not just acknowledge. Check valve 4 first. Otherwise the tank drains.” Underneath it, a set of initials and a year.
The colleague who wrote it retired two years ago. It is not in the manual. It is not in the system either. That piece of knowledge exists in exactly one place in the plant, and that place is a sheet of paper stuck to a piece of metal.
Notes like this hang in almost every plant. They are not a sign of poor organization; quite the opposite: somebody thought ahead and passed on what they knew. What they show is where the system ends and the individual person begins.
In short: Knowledge transfer in maintenance means capturing asset-specific experience, context, and reasoning so other technicians can find it, assess it, and apply it in the right situation, even when the original expert is unavailable.
What knowledge transfer actually means
Knowledge transfer in maintenance means passing on practical asset knowledge so that other people understand it and can apply it in the right context. That includes documented experience, decisions someone can follow after the fact, and time spent working alongside experienced technicians.
Because not every useful detail is in the manual. Why was a particular cause ruled out during an earlier incident? What is different about this specific asset that does not apply to the identical machine two bays over? As long as that kind of information sits with individuals, it effectively does not exist for the rest of the team.
Fraunhofer IFF’s work on experience transfer focuses on identifying tacit experience, preparing it digitally, and integrating it into the work process, especially knowledge people apply confidently but cannot always fully explain.
Which knowledge should be captured first?
The sensible place to start is knowledge that gets used often, or that becomes hard to reach whenever one particular person is away. Typical candidates are recurring fault patterns, the quirks of individual assets, and the reasoning behind important decisions.
A short priority list, put together with the team, is enough to begin with. Three questions usually get to the heart of it quickly. Which topics send people to the same colleague every time? Which answers are new team members missing in their first weeks? And where do documents exist without any explanation attached to them?
How can experience be captured in practice?
1. Talk through one specific case
This works best when an experienced technician walks through a closed case: what the situation looked like, what information was available, and why one approach was chosen over another. A concrete event gives the conversation a frame. Asking someone to write down what they know, in general, almost always leads nowhere.
2. Separate observation from conclusion
Both belong in the record, but separately: what was actually observed, and what was inferred from it. It is just as useful to note which assumptions were later confirmed and which were not. The discarded theories are often what saves the next person the most time.
3. State the scope
Every entry belongs to a specific asset, component, and document revision. Similar symptoms are not sufficient reason to transfer an earlier fix to a different machine without checking. That distinction is what separates a useful knowledge entry from a trap.
4. Review and keep it alive
Someone has to own the technical review and the updates. And it is worth asking new team members to report back on which explanations they were missing. That is how a one-off collection of knowledge turns into a working resource that grows with the plant.
What role can AI play in knowledge transfer?
AI can support the capture and structuring of knowledge. Fraunhofer IESE’s work on AI-supported model building and knowledge transfer, for example, describes AI-based approaches for making expert knowledge available and usable. Tools of this kind support an organizational process. They do not supply expertise that nobody in the building has.
When choosing a solution, one simple test question helps: can the team see where a piece of information came from, which asset it applies to, and who reviewed it? A system that produces plausible sounding answers without provenance has only moved the problem somewhere else.
Example: turning a question into a knowledge entry
A fictional case: a new colleague asks about the background to an earlier maintenance decision. The experienced technician explains the situation at the time and which documents played a part in it. The team records that explanation against the relevant job and links the documents that were used.
The entry does not replace a current assessment. It does make it possible to follow why the decision made sense under the conditions of the day. And it means the same question does not get asked again six months later.
Frequently asked questions
Does a knowledge base replace hands-on onboarding?
No. It makes information available and makes preparation easier. Practical experience, guided exercises, and the ability to ask follow-up questions are still what turns information into something a person can apply safely.
How do you stop knowledge entries from going stale?
By tying maintenance of the content to concrete triggers: changes to the asset, new manufacturer documentation, corrected findings. Outdated content should be clearly marked as such, and it should be settled who reviews changes. A wrong entry dated yesterday does more damage than no entry at all.
What is tacit knowledge in maintenance?
Tacit knowledge is practical know-how that experienced technicians use in context but may never have written down. Examples include how a specific asset behaves under a recurring fault, which checks rule out a likely cause, or why a past maintenance decision was made. Capturing that context is a core part of knowledge transfer.
Conclusion
Knowledge transfer starts with experience that is written down in a way other people can follow. Capturing the context and the reasoning alongside the result creates a far better basis for collaboration and onboarding.
The laminated note on the filling line is not a counterexample here. It is the template. It is short, it sits exactly where it is needed, and it explains not just what to do but what happens otherwise. It has only one flaw: it hangs on one machine and exists nowhere else.