Menu
Warum vorbeugende Wartung scheitert: Die 82%-Regel der Zuverlässigkeit (2026)

Warum vorbeugende Wartung scheitert: Die 82%-Regel der Zuverlässigkeit (2026)

Auf einen Blick

 

  • Der Altersmythos: Die meisten Manager glauben, dass Maschinen ausfallen, weil sie altern. Sie denken: "Wenn ich das Teil jährlich ersetze, geht nichts kaputt." Für moderne Anlagen ist diese Logik falsch.

  • Die 82%-Realität: RCM-Studien zeigen, dass 82% der Ausfallmuster zufällig sind — verursacht durch Stress, Installationsfehler oder Betriebsspitzen, nicht durch Alter.

  • Das "PM-Paradoxon": Mehr Präventivwartung (Maschine öffnen) an Anlagen mit zufälligen Ausfällen erhöht das Ausfallrisiko ("Früher Tod" durch menschlichen Eingriff).

  • Die Lösung: Wechseln von zeitbasiert (Kalender) zu zustandsbasiert (Daten). Fabrico hört die Stress-Signale (SPS/Sensoren), sodass Sie nur eingreifen, wenn der Zufallsausfall sich anbahnt.

Warum vorbeugende Wartung scheitert: Die 82%-Regel der Zuverlässigkeit (2026)

Was ist die 82%-Regel der Zuverlässigkeit? (Und warum Kalender-PM echte Ausfälle versteckt)

Quick answer: 82% of preventive maintenance programs fail to reduce failures because they're time-based instead of condition-based. The Nowlan-Heap reliability research showed that only 11% of equipment shows age-related wear; the other 89% fails on random patterns that a calendar can't predict. The fix is condition-based PM driven by OEE signals or sensor data.

 

Related deep-dives: improve PM compliance · PM optimization software · eliminate PM overruns · closing the OEE-CMMS loop.

 

If you ask a Maintenance Manager why a machine broke, they often say:
"It was old. We should have serviced it sooner."

This assumes a direct link between Age and Failure.
It assumes that machines are like car tires—they wear out smoothly over time.
If this were true, Preventive Maintenance (PM)—servicing machines on a calendar—would prevent 100% of breakdowns.

But it doesn't. Machines still break the day after a service.
Why?
Because the "Age Theory" is wrong.

According to the foundational studies of Reliability Centered Maintenance (Nowlan & Heap), only 18% of assets fail due to age.
The other 82% fail randomly.

This is the 82% Rule. If you are building your maintenance strategy entirely around Calendar PMs, you are using the wrong tool for 82% of your problems.

Here is why "More Maintenance" isn't the answer, and how to fix the random failures.

 

1. The 6 Patterns of Failure

Engineering studies classify failure into 6 patterns. Only one of them looks like "Wearing Out."

  1. The Bathtub (4%): High failure at start, low middle, high at end.

  2. Wear Out (2%): Constant until a sudden increase at the end.

  3. Fatigue (5%): Slowly increasing failure probability.

    • Total Age-Related Failures: ~11-18%.

 

The vast majority (Patterns D, E, F) show Random probability.

  • What this means: A motor is just as likely to fail on Day 100 as on Day 1,000.

  • The Cause: Random failures are caused by Events, not Time.

    • A voltage spike.

    • A material jam.

    • An operator error.

    • A bad bearing installation.

 

2. Why Calendar PMs Fail the 82%

 

If a machine fails randomly (e.g., due to a voltage spike), changing the oil every month does nothing to prevent it.
In fact, Calendar PMs can hurt you.

The "Intrusion" Risk:
Every time a technician opens a machine to do a PM, there is a risk they will:

  • Strip a bolt.

  • Introduce dirt.

  • Bump a sensor.

This creates "Infant Mortality" in an old machine. You took a healthy asset, opened it up to "Maintain" it, and accidentally introduced a defect.
For random-failure assets, "Hands-Off" is often the best policy—until the data says otherwise.

 

3. The Strategy Shift: From "When" to "If"

 

For the 18% of assets that wear out (Tires, Belts, Brake Pads), keep using Calendar/Usage PMs.
For the 82% of assets that fail randomly (Electronics, Hydraulics, Pneumatics), you need Condition Monitoring.

You stop asking: "When is it due?"
You start asking: "Is it healthy right now?"

The Digital Approach:

  1. Monitor the Variables: Random failures leave clues. Heat. Noise. Vibration.

  2. Connect the Data: Use Fabrico to read the PLC tags (Amps/Temp).

  3. The Trigger: Instead of a "Monthly Service," set an alert: "If Temp > 60°C, Inspect."

 

This allows you to catch the Random Event (the voltage spike or the jam) the moment it happens, rather than waiting for next month's schedule.

 

4. How Software Manages the Mix

 

You cannot manage a complex factory with a simple calendar. You need a Hybrid System.

How Fabrico handles the 82% Rule:

  • For Wear Parts (The 18%): We use Cycle Counts. "Conveyor Belt has run 10,000 hours. Replace."

  • For Random Parts (The 82%): We use Trend Analysis. "Motor current is trending up. Something changed. Investigate."

 

 

This moves you from "Blind Maintenance" (guessing) to "Evidence-Based Maintenance."

 

Conclusion: Stop Disturbing Healthy Machines

The goal of maintenance is reliability, not activity.
If you are over-maintaining healthy machines "just in case," you are wasting money and introducing risk.

Respect the 82% Rule. Listen to the machine, don't just look at the calendar.

Switch to condition-based.


[Request a Demo] and let Fabrico help you move from Calendar to Condition.

Die 4 stillen Versagensmuster reiner Kalender-PM-Programme

Der PMO-Fix: Kalender-PM in 90 Tagen zu zustandsbasierter PM verwandeln

Software, die PMO unterstützt + Entscheidungsmatrix + FAQ

Verwandte Artikel

Das Neueste aus unserem Blog

Sind Sie noch am Überlegen?
Überzeugen Sie sich selbst!
Sind Sie noch am Überlegen?

Vereinbaren Sie ein 1-zu-1-Meeting mit unseren Experten oder melden Sie sich direkt für unseren kostenlosen Tarif an.
Keine Kreditkarte erforderlich!

Indem Sie auf die Schaltfläche „Akzeptieren“ klicken, erklären Sie sich mit der Nutzung einverstanden.Cookies beim Zugriff auf diese Website und bei der Nutzung unserer Dienste. Erfahren Sie mehrWeitere Informationen zur Verwendung und Verwaltung von Cookies finden Sie in unserem Datenschutzrichtlinie und Cookie-Erklärung