When an expert leaves, the machine’s history goes with them

Packaging line, Tuesday, 2:22 p.m. The operator changes the workstation status to “mechanical failure.” The on-call technician, who has been with the company for three months, opens the work order and sees: the machine’s name, category, and date. There is no history of previous interventions, comments, or documentation. He asks who last repaired this machine. It turns out to be Marek, who left two months ago.

MTTR for this failure: 4 hours and 20 minutes.
A previous, very similar breakdown repaired by Marek: 55 minutes.

The difference of three hours and 25 minutes is often not solely due to the employee’s competence. In many cases, the problem is a lack of access to the machine’s history, previous observations, proven hypotheses, and procedures that remain in the mind of an experienced technician.

This is where knowledge management in maintenance begins. Not with the mere purchase of a system, but with the answer to one question: does the knowledge critical to production exist within the organization, or only in the minds of a few employees?

Technical Knowledge in Maintenance: Explicit, Tacit, and Difficult to Recover

In the theory of knowledge management, a distinction is made between explicit knowledge—that which can be recorded, communicated, and reproduced—and tacit knowledge, which is acquired over years of observation, trial, and error while working with a specific machine.


Knowledge in maintenance is a vital organizational resource, and capturing it depends on a systematic approach to knowledge management within the company [1].

In maintenance practice, tacit knowledge most often takes three forms.

Diagnostic knowledge

A technician recognizes the characteristic sound of a worn bearing in the feeder drive before vibrations exceed the alarm threshold. They also know that a specific vibration during startup does not necessarily indicate a failure, as it results from the oil temperature in the first minutes of operation.

Knowledge of exceptions

This is knowledge of what does not work exactly as described in the manufacturer’s technical documentation for a given machine. For example: when changing the supplier of the sealing tape, the pressure parameters must be adjusted by 0.3 bar. Or: the position sensor on line 4 gives inaccurate readings at humidity levels above 70%.

Historical Knowledge

This refers to information about what has already happened with a specific machine and how the problem was resolved. Example: Two years ago, a similar failure on Line 3 was not caused by a sensor malfunction, but by a loose terminal in the control cabinet.

Operating manuals, electrical diagrams, and technical documentation are usually available. The problem arises when diagnostic knowledge, knowledge of exceptions, and failure history are not recorded in the system. In that case, they exist on a personal level but not at the organizational level.

Employee turnover in the HR department: a cost that isn’t immediately apparent

The literature on knowledge management describes the phenomenon of expert knowledge loss, which occurs when experienced employees leave an organization and their knowledge has not been previously captured in procedures, documentation, or information systems. In knowledge-intensive organizations, the departure of experts can mean the loss of knowledge that is difficult to quickly recreate [2]. In maintenance, this mechanism is particularly significant because service knowledge is deeply contextual: it depends on a specific machine, production conditions, and a history of failures that is often not recorded anywhere. The economic mechanism is simple: the longer a technician diagnoses a problem from scratch, the higher the cost of downtime and the greater the risk of delays in the production schedule. In an example scenario, a highly experienced technician repairs a recurring failure in 55 minutes, while a new employee without access to the history needs 4 hours and 20 minutes. Not because they are incompetent, but because they have to start the diagnostic process from scratch: check documentation, ask others, and test hypotheses that their predecessor had already ruled out.

With three similar incidents per month and a downtime cost of 5,000 PLN per hour, the difference in diagnosis time can amount to tens of thousands of PLN per year. The specific figure will vary from plant to plant, as it depends on the cost per hour of downtime, the frequency of failures, production capacity, and the criticality of the line in question. The mechanism, however, remains the same: lack of access to knowledge prolongs the diagnosis.

Digitization is one of the key factors supporting knowledge transfer during generational transitions within an organization [3]. Companies without a digital repository of intervention histories, procedures, and technical observations are more vulnerable to knowledge loss with each staff turnover.

Barriers to knowledge sharing rarely stem solely from a lack of tools. They can be individual, organizational, or technological in nature: lack of time, lack of standards, low motivation to document, insufficient process support, and incompatible information systems [4]. In maintenance, these barriers are particularly evident when technicians’ experiences are not recorded in work order histories, procedures, or inspection schedules. In practice, four problems recur: a failure history reduced to a “fixed” field, without a description of symptoms, hypotheses, or solutions, service documentation stored in folders on a network drive, inaccessible at the machine at the time of failure, preventive knowledge remaining solely in the mind of a single technician,   no procedures for recurring failures, meaning every intervention starts from scratch. Each of these issues can impact MTTR and production line availability, especially when critical machines or recurring failures are involved.  

The Work Order History as a Technical Knowledge Base

A closed work order marked as “fixed” is merely a record of events. A work order that includes a description of symptoms, tested hypotheses, actions taken, and observations for the future becomes part of a knowledge base. This is the difference between merely recording a failure and providing real support to the next technician who will be working on the same machine in a few weeks. This mechanism is similar to the concept of experience feedback, i.e., knowledge generated from previous maintenance activities and used as decision support for subsequent interventions [5]. There is one condition: the knowledge must be recorded in a place accessible to the next technician. A well-documented work order history should answer the questions that a technician actually asks when the machine is down:  

•  What were the symptoms, and how did the operator describe them?
•  What was checked first?
•  Which hypotheses were ruled out? 
• Which part was replaced? 
• Which parameter was changed? 
• What should be checked next time a similar symptom occurs? 

In the AndonCloud CMMS module, each work order can include a note, an attachment with technical documentation, a category assignment, and a procedure. This means that closing a work order doesn’t have to end with just a “completed” status. It can leave behind information that will help with the next intervention. 

After several months of systematically updating work orders, a machine history can be created, helping new employees narrow down the diagnosis more quickly and draw on the experience of previous interventions. This does not automatically guarantee a reduction in every downtime, but it does reduce the risk of repeating the same diagnostic errors.

Procedure Templates: How Expert Knowledge Becomes the Standard for Work

Hydraulic press, routine inspection of seals every 6 weeks. For three years, the same technician performed the inspection. During that time, he noticed that whenever a seal was replaced, it was worth checking the condition of the check valve at the same time, because both components wear out at a similar rate. Omitting the valve often caused the problem to recur after a dozen or so days. If this observation remains in the technician’s mind, it stays as personal knowledge. If it is added to the checklist as a required step in the procedure, it becomes a standard practice for the entire team.

Knowledge sharing between experienced and less experienced employees in maintenance departments is difficult, in part due to the tacit nature of this knowledge [6]. Procedures and checklists can mitigate this problem by incorporating some of the expert’s experience into the daily work process. In AndonCloud, a procedure template can take the form of a checklist with text fields, checkboxes, and single-select options. Fields marked as required prevent the task from being closed without being filled out, which helps maintain documentation standards and reduces the risk of omitting important steps. This does not replace the technician’s expertise. However, it provides the team with a common reference point: what needs to be checked, in what order, and what information should be recorded after the intervention is completed.  

Recurring and automatic tasks: prevention without relying solely on memory

The knowledge embedded in maintenance isn’t just about breakdowns. It’s also about the machine’s rhythm: when to lubricate the drive, when to check the clamping settings, which components wear out faster, and which inspections should be performed more frequently than the manufacturer’s documentation suggests. When a technician leaves, that rhythm often goes with them. Recurring tasks in a CMMS help transfer this knowledge into a schedule. In AndonCloud, they can be generated automatically according to a set cycle: daily, weekly, monthly, or annually. The system creates the next task according to the schedule, ensuring that maintenance does not depend solely on the memory of a specific person. The second mechanism involves automatic orders triggered by events on the shop floor. Example: an operator changes the workstation status to “mechanical failure,” and the system creates an order with the procedure template assigned for this type of failure. A different order and a different procedure may be triggered in the event of an electrical failure.

In practice, this means less manual information transfer and a lower risk that a ticket will get lost between the operator, the foreman, and the technician. The technician receives the work order, the context of the incident, and a procedure that may be based on the team’s previous experience. It is precisely this combination of the incident from the shop floor, the service order, and the procedure based on technical knowledge that makes knowledge management no longer a separate project. It becomes part of the daily work of the maintenance department. 

Where should you start with knowledge management in a CMMS?

The most common mistake during implementation is trying to document the entire machine fleet all at once. This can result in several weeks of work with no visible results, after which the team loses motivation and the system remains empty. A better approach is a sequence of small but consistent steps.

Step 1: Choose the machine that relies most heavily on a single person's expertise

Don’t start with the machine that has the most extensive manufacturer’s documentation. Start with the one about which new employees most often ask, “Who usually fixes this?” or “Has anyone dealt with this before?” That’s where knowledge is most personalized and most at risk of being lost.

Step 2: Talk about specific examples, not general knowledge

Don’t ask the technician, “What do I need to know about this machine?” That’s too broad a question. Ask: What do you check first when you see this symptom? When do you not replace this part right away? How do you know the problem will come back? What needs to be done before you close the job? What diagnostic errors recur most often? These answers form the basis for the first useful procedure template.

Step 3: Set a minimum standard for job descriptions

The notes field doesn’t have to be a lengthy report. In many cases, three pieces of information are sufficient: what happened, what was checked, what resolved the issue. What matters most isn’t the length of the description, but consistency. If every closed ticket includes even a brief diagnostic description, over time a realistic history of the machine begins to emerge.

Step 4: Protect your knowledge base in case an employee leaves

If you know that a technician with critical knowledge is leaving or changing roles, it’s a good idea to review their schedules, procedures, and the machines they service most frequently beforehand. Once the employee leaves, the team loses the opportunity to ask questions, which are often more important than the documentation itself. After the first phase of implementation, the goal shouldn’t be a system with hundreds of procedures. A better outcome is 5–10 well-documented templates for the most common breakdowns, a history of several dozen work orders with diagnostic descriptions, and the first recurring work orders running without reminders from a supervisor. This is enough to make the next staff change less painful for the Maintenance Department and for production.  

AndonCloud CMMS: Where Technical Expertise Stays Within the Company

The CMMS module in AndonCloud integrates with the digital Andon system. This allows an event on the shop floor to trigger a work order with a procedure, without the need to manually create a task or pass information through multiple people. This integration is important because maintenance does not operate in isolation from production. A breakdown starts at a workstation, but its consequences are reflected in OEE, on-time performance, technician workload, and scheduling of subsequent shifts. AndonCloud can support technical knowledge management by:

•  order history and comments,   
• attachments with technical documentation, 
• procedure templates and checklists, recurring orders, 
• automatic orders triggered by workstation statuses, 
• notifications for relevant personnel, 
• failure categories and change history, incident reporting and analysis of recurring issues.

The system alone does not solve the problem of knowledge loss. It only helps when the team consistently records information, establishes procedures, and uses the job history during subsequent interventions. A good first step is to identify which machines the team most often says, “Only one person knows how to handle this.” That is precisely where digital work order histories, procedures, and automated schedules can most quickly reduce the risk of technical knowledge loss.

Summary

Knowledge management in maintenance is about determining whether knowledge critical to production exists within the organization or only in the minds of a few employees. CMMS does not protect the plant from knowledge loss simply by being implemented. It does so only when every closed work order contains more than just a status, procedures reflect technicians’ experience, and maintenance schedules operate independently of the team’s composition. In mass production, the advantage lies not only in a quick response to a breakdown but also in the ability to learn from every intervention. If knowledge from repairs, inspections, and recurring issues remains in the system, new employees don’t start from scratch, and the maintenance department can operate more predictably.

FAQ

What is knowledge management in maintenance?

Knowledge management in maintenance is a method of collecting, organizing, and utilizing the technical information needed to keep machinery in good working order. It includes, among other things, failure histories, intervention descriptions, procedures, checklists, inspection schedules, and technicians’ experience. The goal is to ensure that knowledge is not dependent solely on individual people, but is accessible to the entire team.

Why is the loss of technical expertise a problem for manufacturing?

The loss of technical knowledge can prolong fault diagnosis, increase MTTR, and complicate maintenance department scheduling. If only one technician knows how a specific machine operates, their departure means the team must rebuild that knowledge from scratch. In mass production, such a lack of information can result in longer downtime, delays, and a heavier workload for the remaining employees.

How does a CMMS help maintain a record of machine breakdowns?

CMMS allows you to record work orders, comments, failure categories, actions taken, attachments, and procedures. As a result, a machine’s history isn’t limited to the fact that a failure was resolved. A technician can review what symptoms occurred previously, what was checked, which actions didn’t help, and what solution proved effective. This makes it easier to diagnose recurring problems.

What should a well-written service request include?

A good service report should include a description of the symptoms, the context of the issue, the diagnostic steps taken, the parts replaced, the parameters adjusted, and a brief note on what resolved the problem. It’s also a good idea to note which hypotheses were ruled out. This way, others won’t have to repeat the same tests when a similar failure occurs.

How does employee turnover affect MTTR?

Employee turnover can affect MTTR if knowledge about machines, failures, and process exceptions isn’t recorded in the system. A new technician without access to this history often has to diagnose a problem from scratch. They have to ask others, search for documentation, and test hypotheses that an experienced employee would already know from previous interventions. A good knowledge base does not replace experience, but it can shorten the path to an accurate diagnosis.

How to develop maintenance procedures based on expert knowledge?

It’s best to start with specific cases rather than general instructions. It’s a good idea to ask experienced technicians what they check first when a particular symptom arises, when they don’t replace parts right away, which diagnostic errors recur, and what needs to be done before closing a work order. You can use these answers to create a checklist or procedure template in the CMMS.

Do recurring orders help reduce reliance on technicians' memory?

Yes, recurring work orders help transfer knowledge about maintenance schedules into the system. If lubrication, adjustment checks, or component inspections rely solely on one person’s memory, the risk of oversights increases during vacations, sick leave, or staff turnover. The schedule feature in CMMS allows you to generate work orders automatically and ensure the consistency of preventive maintenance activities.

How does AndonCloud CMMS support technical knowledge management?

AndonCloud CMMS allows you to create work order histories, add notes, attach documentation, assign categories, and use procedures. Thanks to integration with the Andon system, an event on the shop floor can trigger a maintenance work order using the appropriate template. This helps combine information from the operator, the technician’s response, and subsequent analysis into a single process.

Can AndonCloud automatically create work orders when a workstation's status changes?

Yes, AndonCloud can create work orders based on events such as a change in workstation status. For example, a mechanical failure can trigger a work order with a mechanical procedure, while an electrical failure can trigger one with a different checklist and assignment. This way, the request doesn’t have to be passed around to several people, and the technician receives a clearer context for the intervention.

Sources

[1] Cárcel-Carrasco, J. i in. (2020). Factors in the Relationship between Maintenance Engineering and Knowledge Management. Applied Sciences, 10(8), 2810.

[2] Joe, C., Yoong, P., & Patel, K. (2013). Knowledge loss when older experts leave knowledge-intensive organisations. Journal of Knowledge Management, 17(6), 913–927.

[3] Igoa-Iraola, E. & Díez, F. (2024). Procedures for transferring organizational knowledge during generational change: A systematic review. Heliyon. PMCID: PMC10909792.

[4] Riege, A. (2005). Three-dozen knowledge-sharing barriers managers must consider. Journal of Knowledge Management, 9(3), 18–35.

[5] Ruiz, P.P., Kamsu-Foguem, B. & Grabot, B. (2014). Generating knowledge in maintenance from Experience Feedback. Knowledge-Based Systems, 68, 4–20.

[6] Roham, H. & Gomes, J.F.S. (2024). Knowledge management and knowledge sharing in maintenance department of high-tech industries. Journal of Quality in Maintenance Engineering, 30(4), 605–623.