The Expert Who Retires in 2027: What Your Plant Knows That Your Data Does Not

Here is the short version. In most plants, a few long-serving people know how the older lines behave: the setpoint that is never where the drawing says, the sound a bearing makes three weeks before it fails, the order in which a line has to come back after a power cut. Little of that is in a system. It was never written down because it never had to be.

Germany's largest birth cohort, the one born in 1964, turns 63 in 2027. That is the first year it can legally draw an old-age pension. The outflow does not end there; it peaks around the end of the decade. This article is about what leaves with those people, how to tell which parts of it can be moved into data and documents and which cannot, and the methods that work while the person is still on site.

Listen — audio overview

Industrial Reality Check

A hydraulic press line in a mid-sized supplier trips on a Sunday night after a short grid dip. The night shift follows the restart procedure in the binder. The pumps come up, the press tries to close, and a pressure fault stops it again. They try twice more. At six in the morning they call the one maintenance technician who has looked after that line since 1991.

He asks a single question on the phone: did you let the accumulator charge before you released the press? They did not. The binder does not mention it. The line has run that way since a hydraulic modification in 2004, and the step has been in his head ever since. Nine hours of downtime turn on a step that takes four minutes.

Nobody did anything wrong. The procedure was correct when it was written. The machine changed, the man adapted, and the paperwork stayed where it was. In the review the plant asks how to make sure this does not happen again. The honest answer is that it will happen again, at a worse moment, about a year after he retires.

Why the Problem Exists Structurally

Plant knowledge accumulates in people for good reasons. A machine is commissioned with documentation that describes the machine as built. Over twenty or thirty years it is repaired, modified, re-tuned for new materials and kept running through supplier changes. Each change is small. Each one is solved by someone on the floor, often at night, and the solution works. Writing it down is a second task with no deadline, so it waits.

The people who make those changes stay for a long time. In many Mittelstand plants a maintenance lead or senior setter has been on the same equipment for most of a career. Their knowledge is current because they have lived through every change. That is why the plant trusts them and calls them at six in the morning. It is also why nobody notices how much depends on them until they are gone.

Two other structural factors make this worse. First, the systems that do record plant behaviour were built to record values, not reasons. A historian stores that a setpoint changed from 182 to 176 at 03:40. It does not store that the operator lowered it because the new granulate batch was wetter than usual. Second, the documentation duty sits with the machine builder at handover and with nobody in particular afterwards. A plant that bought a machine in 1998 often has the 1998 manual and three decades of undocumented reality on top of it.

None of this is a failing of the people involved. It is the normal way a plant learns. The problem appears only when the learning walks out of the gate.

Why Now: What Actually Changes in 2027

The baby-boomer generation in Germany is usually counted as the birth cohorts 1954 to 1969, more than 19 million people. According to the Institut der deutschen Wirtschaft, 14.1 million of them are still below the statutory retirement age today. By 2030 it will be 7.6 million. By 2036 the whole generation will be past it. Over the same period only 9.8 million young people reach working age. The institute expects the labour-force potential to fall from about 55 million in 2025 to about 51.2 million in 2036.

Inside that wave, 1964 is the largest single year, with about 1.4 million births. Under the German pension law, people with 35 insurance years may draw an old-age pension from age 63, with a permanent deduction. The 1964 cohort turns 63 in 2027. Many people born in 1962 reach the age at which they can retire without a deduction after 45 insurance years, 64 years and 8 months, during 2027 as well. In the institute's projection, 2027 is also roughly the year in which the cumulative number of boomers reaching statutory age overtakes the number of young people entering working age.

So 2027 is not a cliff. Nobody is forced out that year, and the statutory age for the 1964 cohort is 67, in 2031. 2027 is the year the door opens for the largest group, and the decade that follows is when most of them walk through it. The institute describes the peak of boomer retirement as only a few years away.

One clarification matters for how a plant should read this. The general skills gap in Germany eased in 2025. The competence centre for skilled labour at the same institute counted about 370,000 vacancies for which there were no suitably qualified unemployed people, a fall of about a quarter on the year before. The difficulty this article describes is not mainly a hiring difficulty. A plant can hire a qualified technician and still lose the knowledge, because what leaves is not the qualification. It is thirty years of history with one specific line.

Where Plant Knowledge Lives

Before deciding how to capture anything, it helps to ask where a given piece of knowledge actually sits. In practice there are three places.

Recorded and understood. Data the plant already collects and can interpret without the expert: production counts, motor currents, temperatures, alarm logs, maintenance orders. This part does not leave when a person retires, as long as the systems that store it are kept.

Recorded but readable by one person. Data that exists, but whose meaning sits in someone's head. A tag called `TMP_07B` that everyone else ignores. A trend that looks like noise to a data engineer and like an early warning to the shift lead. An alarm that fires every day and that one person knows to take seriously only on Mondays after a long stop. Here the raw material is already in the system. What is missing is the label, the context and the reason.

Not recorded at all. Knowledge with no data trace: what a bearing sounds like, how a casting feels when the mould is too cold, which supplier's material needs a slower first stroke, the order of steps that is never logged because it happens on a manual panel. This part can sometimes be moved into the second category by adding a sensor or a log entry. Often it cannot.

The split matters because the methods are different. The second category is the cheapest to capture and the one most plants neglect. Its value is already sitting in the historian, waiting for a sentence of explanation. The third category is the hardest, and here the honest answer sometimes is that only working side by side transfers it.

For more on why data without its context misleads any analysis that comes later, see Why AI Without Context Fails in Manufacturing.

Where plant knowledge lives: recorded and understood, like a filed trend; recorded but readable by one person, like a hand-written note pinned to a waveform; and not recorded at all, like a technician listening to a gearbox.

An Illustrative Calculation

The numbers below are an assumption for a plant of about 250 people, not a measured case. They show how the risk adds up; your own figures will differ.

Assume the maintenance and process team has twelve people. Four were born between 1962 and 1966. Each of those four is the person the plant calls for two or three specific machines. That is ten machines where the answer to an unusual fault depends on one person.

Assume each of those machines has one abnormal situation a year that the documentation does not cover. In the past, the expert solved it in an hour, on the phone or in person. Without the expert, assume the first occurrence takes a day of trial and error, with the line down or running at reduced speed. That is ten lost line-days in the first year after the four have gone, at whatever a line-day costs your plant, before counting scrap, rework and missed deliveries.

Now the other side. Assume a structured capture programme takes two hours a week of each expert's time for eighteen months, plus the same time from a younger colleague. That is about 600 hours of experts and 600 hours of successors. Spread over eighteen months, this is less than one person's time on top of normal work.

The comparison is not exact, and the plant does not need it to be. The point is the shape: a small, steady cost spread over time against a large, lumpy cost that arrives at the worst moment. The calculation also shows the deadline. If the capture starts after the farewell party, the 600 hours are not available at any price.

The Named Failure Modes

These are the patterns that come up again and again when long-serving people leave. Each has a name, because a problem with a name gets onto an agenda.

The undocumented setpoint. The drawing says 182 degrees. The machine has run at 176 for twelve years, because the heater band was replaced with a slightly stronger one and 182 burnt the material. The setpoint is in the controller, so the value is recorded. The reason is not. The first new engineer who restores the drawing value to tidy things up creates a scrap problem nobody can explain.

The ear-only bearing. A senior technician walks past a gearbox, stops, listens and writes a work order. Three weeks later the vibration level crosses its limit and confirms what he heard. The plant has a vibration sensor, but its alarm threshold sits where it does not fire until late. The early stage of the failure is in the data as a small change in the signal; only one person knows what that change means.

The restart choreography. After a power loss, a line comes back in an order nobody wrote down: this pump first, wait for the pressure, then the heaters, then reset the safety relay on the second panel, not the first. The steps happen on manual panels and leave no trace in any log. The procedure in the binder is the original one and is now wrong.

The trusted-ignored alarm. An alarm fires several times a shift. Everyone acknowledges it without reading it. One person knows that on one of those machines it means something real, but only when it appears together with a second, quieter alarm. That knowledge never reaches the alarm system, so the alarm list looks like noise to everyone else.

The comment-free control block. A section of controller code was changed during a breakdown fifteen years ago. A timer was lengthened, an interlock was bridged under a condition. There is no comment, or the comment says "do not touch". The person who wrote it knows why. Nobody else will change it, and nobody else can safely change anything around it.

The offset notebook. A setter keeps tooling offsets, die heights and correction values in a pocket notebook or a private spreadsheet, one per tool and machine combination. The controller stores the current value. The notebook stores the history and the exceptions: tool 14 needs plus 0.2 after regrinding, for the first fifty parts.

The batch recipe tweak. Raw material varies by supplier and by batch. An experienced operator adjusts temperature, speed or dosing when a new batch arrives, based on how the first parts look and feel. The adjustment shows up in the data as a change. The trigger, the judgement that this batch behaves differently, does not.

Most plants recognise several of these at once. Seen together they share a structure: the value is often in a system, the reason almost never is.

Why This Is a Capture Problem Before It Is an Analytics Problem

A reasonable reaction to the list above is to look for a technical answer: more sensors, a better historian, a model that learns normal behaviour and flags deviations. Some of that helps. None of it replaces the step before.

Software that analyses machine data can only work with what the data contains. If the historian shows that a setpoint moved, a model can report that it moved. It cannot report why, and it cannot tell a deliberate correction from a mistake, unless someone has recorded which was which. If the restart order happens on manual panels, there is nothing to analyse. If a deviation in a vibration signal was confirmed by a technician's ear three weeks earlier, that confirmation is the most valuable label the plant has, and in most plants it exists only as a work order with a free-text field that says "noise, check".

This is why capture comes first. Recorded context turns past events into examples that later analysis, human or automated, can learn from. A plant that annotates its historian, rationalises its alarms and records the reason behind each manual intervention ends up with data that a new engineer can read and that any later analysis can use. A plant that skips this step has a large archive of values with the meaning missing.

There is also a timing argument. Sensors can be added in five years. The people who know what the existing signals mean cannot be. For a related look at which maintenance strategy fits which failure, see Predictive Maintenance in 2026: Most of What Works Is Not Prediction.

Choosing a Capture Method, and Its Limits

Five methods produce usable records in a plant setting. None of them is new. What makes them work is that each is tied to a machine, an event or a signal, not to a general request to write down what you know.

Interviews anchored to events. Do not ask the expert to describe a machine. Pick a real event from the last two years, a stop, a quality deviation, an unusual restart, put the data from that event on the screen and ask what happened, what they noticed first and what they did. An hour per event, recorded and summarised, produces material a successor can use. People recall far more about a specific night than about a machine in general.

Annotating the historian. Walk through trends with the expert and attach short notes to the moments that matter: setpoint changed because of material batch, vibration rise here is the early sign, this spike is a sensor fault and can be ignored. The notes live next to the data, with a timestamp. This is the cheapest method for the second category of knowledge and is often skipped because nobody owns it. It only works if the timestamps line up; see Whose Clock Is Right?.

Alarm rationalisation as capture. The alarm management standards IEC 62682 and ISA-18.2 describe rationalisation: for each alarm, record its cause, the consequence of not responding, the correct response and the time available. Done with the expert in the room, this is a structured interview about every alarm on the machine. It also removes noise, so the alarms that matter stand out for the next person.

A refreshed FMEA. A failure mode and effects analysis, as described in IEC 60812, asks for each component how it fails, how the failure shows itself and what is done about it. Many plants have an FMEA from commissioning that nobody has updated. Revisiting it with the people who have seen those failures adds what the original authors could not know: the failure modes that actually occur, the early signs that actually work.

Event plus why. The lightest method, and the one that keeps going after the project ends. Every manual intervention, setpoint change or unusual work order gets one extra sentence: why. Not a report, a sentence. Over a year this builds the record the plant never had. It needs a place to put the sentence that is next to the data, and a shift culture where writing it is expected.

Two limits apply to all five.

First, some knowledge does not survive being written down. The philosopher Michael Polanyi put it in 1966: we can know more than we can tell. An experienced technician can describe what a failing bearing sounds like, but the description does not let a newcomer hear it. That kind of perception transfers by standing next to the machine together, many times. The only plan that works for it is time with a successor, and that has to be scheduled, not hoped for.

Second, recording people has rules. In a German plant, a programme that records interviews or links notes to named employees can fall under the works council's co-determination right on technical systems that can monitor performance (section 87 of the Works Constitution Act). Involve the works council at the start. Most capture programmes are welcomed when their purpose is clear, and run into trouble when it is not.

Most plants will use all five methods, in a different mix for each machine. The knowledge map below decides the mix.

Governance: Who Owns the Knowledge Transfer

Knowledge transfer usually fails for the same reason documentation did: it is everyone's second task. Somebody has to own it.

In practice the owner is a plant manager or head of maintenance with authority over working time, because the main cost is hours: expert hours, successor hours and the time of someone who turns interviews and annotations into usable records. The owner needs a list of people, a list of machines and a date for each.

The management system standard ISO 30401 treats knowledge as something an organisation manages deliberately, with defined roles, processes and reviews. A plant does not need to certify against it to borrow its main idea: knowledge transfer is a process with an owner, not a farewell gift.

The pension rules have also changed in ways that make keeping an expert part-time cheaper than many plants assume. Since 2023, people who draw an early old-age pension in Germany can earn without the pension being reduced. Since 2026, employees who keep working after the standard retirement age can earn up to 2,000 euros a month tax-free under the so-called Aktivrente, although social contributions still apply. Both open the option of an expert who retires on paper and stays two days a week for a year to train a successor. Check the details with payroll and the pension insurer before planning around them; individual cases differ.

Finally, the owner should report progress the same way as any other operational risk: how many critical machines have a named successor, how many have current annotated data and alarm records, and how many still depend on one person.

Decision Framework: Three Questions Before the Farewell Party

For each long-serving person, ask three questions.

Who calls them, and about what? Ask the shift leads and the maintenance planner. The answers produce a list of machines and situations where this person is the fallback. If the list is empty, the risk is low. If it is long, it is the scope of the capture plan.

Where does that knowledge live: recorded and understood, recorded but readable only by them, or not recorded? The answer decides the method. Annotation and alarm rationalisation for the second category; interviews, an FMEA refresh and side-by-side time for the third.

How long until they can leave, and how long does the transfer need? Use the earliest legal date, not the planned one. People decide later than they expect, and also earlier. If the transfer needs eighteen months and the earliest date is in twelve, the plan starts this quarter, and the retention options above are worth a conversation.

Three questions before the farewell party: who calls them, and about what; where that knowledge lives; and how long until they can leave. Below, an older and a younger technician at a machine share one red thread.

Executive Summary: Board-Level Interpretation

Experience is leaving German plants faster than it is rebuilt, and the knowledge that keeps older lines running is mostly not in a system. The skills market eased in 2025, so hiring is not the main constraint; the specific history of specific machines is. The largest birth cohort may start leaving in 2027, and the outflow continues for the rest of the decade.

The exposure can be measured: count the machines where an unusual fault depends on one person, and the date that person can leave. The response is a programme with an owner, a budget in hours and a deadline per person. Some knowledge can be moved into data and documents through annotation, alarm rationalisation, FMEA and event-anchored interviews; this also makes the plant's data more useful for any analysis that follows. Some knowledge can only be passed on by working together, which needs scheduled time and, in some cases, a retention arrangement that recent rule changes make cheaper.

Practical Implementation Checklist

List everyone in production, maintenance and process engineering who could legally retire by 2031, with their earliest possible date.
For each, ask the shift leads and planners who calls them and about which machines. Write the list down.
Rank those machines by the cost of a long unplanned stop.
For each ranked machine, sort the expert's knowledge into the three places: recorded and understood, recorded but readable by one person, not recorded.
Agree the approach with the works council before recording anything that is linked to named people.
Start historian annotation sessions on the top machines: one trend, one hour, one week at a time.
Rationalise the alarms on those machines with the expert present, recording cause, consequence, response and time to respond.
Run event-anchored interviews on the last two years of stops and deviations, with the data on screen.
Name a successor for each critical machine and schedule side-by-side time, not only meetings.
Introduce the one-sentence "why" for every manual change, and review after six months whether it is being written.

A note on where we stand

We make software in this space, so we are not a neutral party. Most of the checklist above needs time, a named owner and a conversation with the works council, not a product. The parts that touch data, annotating trends and recording the reason next to the value, work with whatever historian and maintenance system a plant already has.

We wrote it because, in our experience, the most useful data in a plant is often the oldest, and its meaning is often held by people about to leave. Analysis that comes later, whoever builds it, is only as good as the context recorded now.

If you would like to talk through how to sort a specific machine's knowledge into the three places, we are glad to.

Questions worth asking in your next review

Which three machines would cause the longest stop if the one person who understands them were unavailable for a month?

When was the restart procedure for those machines last tested against how the line is actually restarted?

How many of our active alarms have a recorded cause and response, and who wrote them?

Is there a place next to the data where an operator can record why they changed a value, and does anyone use it?

Who in this room knows the earliest legal retirement date of our most experienced technicians?

The part that matters

The plant will not lose its machines in 2027. It will lose the people who know where those machines deviate from their paperwork, and that loss is spread over several years, one farewell at a time. The data the plant already holds can carry much of that knowledge forward, but only if someone records the reasons while the people who know them are still there. The rest has to be passed on by working together, which takes longer than most plans allow.

For a broader view of where people stay essential in a connected plant, see The Smart Factory Still Needs Humans. For the small losses that never reach a report, see Micro-Stops: The Losses That Never Reach a Report.

Sources

Institut der deutschen Wirtschaft, IW-Kurzbericht 39/2026, "Die Babyboomer erreichen das Rentenalter", June 2026.
Institut der deutschen Wirtschaft, competence centre for skilled labour (KOFA), KOFA Kompakt 03/2026, annual review of the skills gap 2025.
German Social Code, Book VI (SGB VI), sections 36, 38, 236 and 236b, on old-age pension ages and insurance periods.
German Pension Insurance (Deutsche Rentenversicherung), information on the abolition of earnings limits for early old-age pensions from 2023.
Federal Ministry of Finance, questions and answers on the Aktivrente, section 3 no. 21 of the Income Tax Act, 2026.
Federal Statistical Office (Destatis), live births by year.
Works Constitution Act (BetrVG), section 87 (1) no. 6.
ISO 30401, Knowledge management systems: Requirements.
IEC 62682 and ISA-18.2, Management of alarm systems for the process industries.
IEC 60812, Failure modes and effects analysis (FMEA and FMECA).
Michael Polanyi, The Tacit Dimension, 1966.

If there is a machine in your plant that only one person can restart, tell us in the comments below. We reply to every comment, and the full references behind this article are yours for the asking there too. To see first whether your machine data is ready for this kind of annotation and analysis, take the free self-assessment at criussoftware.com/res/kits/readiness/. It asks for a work email, your company name and your consent to be contacted, and returns a scored result.

Pick one machine that only one person can restart. Ask that person to walk through its last unusual stop with the data on the screen, and write down every step the binder does not mention. If the list is short, the risk is small. If it is long, you have found where the capture plan starts.