Reinigung eines Wartungs‑Backlogs mit über 200 Arbeitsaufträgen: eine 30‑Tage‑Methode Wichtigste Erkenntnisse - Ein Backlog von über 200 Arbeitsaufträgen ist fast nie ein Kapazitätsproblem. Es ist ein Klassifizierungsproblem: Der Backlog enthält echte Arbeit, tote Arbeit, doppelte Arbeit und Arbeit, die nie ein Arbeitsauftrag hätte sein dürfen, und auf den ersten Blick kann niemand die Einträge unterscheiden.
- Eine 30‑Tage‑Bereinigung ist eine Triage‑Übung, kein Sprint. Ziel ist nicht, 200 Arbeitsaufträge zu schließen; Ziel ist, im Backlog pro Zeile einen Status, pro Zeile eine Priorität und pro Zeile einen echten Eigentümer zu haben, damit die nächsten 30 Tage echte Behebungen liefern statt weiterer Triage.
- Die größte Löschkategorie in den meisten Werken sind „Geister‑Arbeitsaufträge“: Einträge, die eröffnet, teilweise bearbeitet und dann aufgegeben wurden, weil das zugrundeliegende Asset geändert, stillgelegt oder bereits von jemand anderem repariert wurde. Dies ist in einem gealterten Backlog meist die einzelgrößte Löschkategorie.
- Nach der Bereinigung ist die richtige Backlog‑Größe für ein Werk mit 100 Assets in der Regel 30, 60 offene Einträge, nicht null. Null bedeutet, dass das System die echte Nachfrage nicht erfasst; 200+ bedeutet, dass das System die Nachfrage erfasst, sie aber nicht abbaut. Warum Backlogs explodieren Wartungs‑Backlogs wachsen aus banalen Gründen.
Ein Arbeitsauftrag wird für „Vibration am Motor von Linie 3“ eröffnet, der Bediener meldet es, der Techniker tauscht ein Lager, das Symptom ist weg, aber der ursprüngliche Arbeitsauftrag wird nie geschlossen, weil das Schließen das Öffnen des CMMS, das Finden der richtigen Zeile und drei Klicks erfordert.
Eine Woche später meldet ein anderer Bediener dasselbe Symptom und eröffnet einen neuen Arbeitsauftrag. Jetzt sind es zwei. Multipliziert man das mit 200 Assets und 18 Monaten, ist der Backlog nicht mehr wiederzuerkennen. Die zweite Quelle sind Duplikate von verschiedenen Meldenden.
Die Produktion eröffnet „Verpacker Linie 3 langsam.“ Die Instandhaltung eröffnet „Verpacker Linie 3 Lager.“ Die Qualität eröffnet „Verpacker Linie 3 Ausschuss erhöht.“ Alle drei betreffen dasselbe Asset, möglicherweise dieselbe Fehlerursache, sitzen aber als drei getrennte Zeilen. Ohne einen Deduplication‑Durchlauf bläht sich der Backlog auf, ohne dass tatsächlich mehr Arbeit anfällt.
Die dritte Quelle ist das Fehlen eines klaren Abschlusskriteriums. Ein Arbeitsauftrag ist „in Arbeit“, weil jemand daran arbeitet; er bleibt „in Arbeit“, weil niemand definiert hat, was „fertig“ für diesen Arbeitsauftragstyp bedeutet. Der Artikel zu Systemen zur Verwaltung von Arbeitsaufträgen behandelt die Lifecycle‑Zustände, von denen diese Methode abhängt.
Tage 1, 10: jede offene Zeile triagieren Schritt 1: Den gesamten Backlog in eine Ansicht ziehen Der gesamte Backlog wird in eine Tabelle exportiert und nach Alter sortiert. Ganz oben die älteren als 90 Tage.
Dies ist der einzige Schritt, bei dem die CMMS‑UI nicht primäres Werkzeug ist: Sortieren und Massenbearbeitung in einer Tabelle geht für die Triage schneller, und die Ergebnisse werden wieder importiert. Schritt 2: Jede Zeile in einen von fünf Behältern klassifizieren Für jede Zeile eine der folgenden Kategorien: - Real: Arbeit, die noch erledigt werden muss.
- Geister: Arbeit, die bereits erledigt wurde oder obsolet wurde, weil das Asset geändert oder stillgelegt wurde. Geister sind in gealterten Backlogs meist die größte Löschkategorie. - Duplikat: Dasselbe Problem wie ein anderer offener Eintrag. Zusammenführen. - Falscher Typ: Hätte niemals ein Arbeitsauftrag sein dürfen. Gehört in einen PM‑Plan, eine Ersatzteilanforderung oder eine Betriebsanfrage. Verschieben.
- Unklar: Benötigt eine Begehung der Anlage, bevor klassifiziert werden kann. Der Großteil der 30‑Tage‑Arbeit findet hier statt. Ein zwei‑köpfiges Triage‑Team, eine Führungskraft aus der Instandhaltung, eine Produktionsvertretung, kann in einer Woche 300 Zeilen durchgehen, wenn sie nicht gleichzeitig die Arbeitsaufträge selbst schließen.
Widerstehen Sie der Versuchung, Triage mit Ausführung zu verschmelzen; das erfordert unterschiedliche Köpfe. Schritt 3: Geister massenhaft schließen und Duplikate zusammenführen Geister werden mit dem Grundcode „nachträglich verifiziert, bereits erledigt“ geschlossen. Duplikate werden in die älteste Zeile zusammengeführt. Falsche Typen werden an das richtige System weitergeleitet (PM‑Plan für wiederkehrende Arbeit, Ersatzteilanforderungssystem für reine Teilebestellungen).
Am Ende des Tages 10 sollte der Backlog 40, 60 % kleiner sein als die Anfangszahl, bevor irgendwelche echten Reparaturen durchgeführt wurden. Tage 11, 20: Priorisieren, was übrig bleibt Schritt 4: Jeder verbleibenden Zeile eine echte Priorität zuweisen Die meisten CMMS‑Prioritäten sind falsch.
Sie wurden vom ursprünglichen Meldenden gesetzt, der nur Kontext für diesen einen Arbeitsauftrag hatte. Jetzt, wo der Backlog halbiert ist, kann der Instandhaltungsleiter die Überlebenden gegeneinander neu bewerten: - P1, Sicherheit / gesetzliche Anforderungen / Produktion stoppend: Behebung noch in derselben Woche. - P2, erheblicher OEE‑Einfluss, wiederkehrend: innerhalb des Monats.
- P3, geringfügig / kosmetisch / einmaliges Vorkommnis: wartet im Backlog auf verfügbare Kapazität. Eine einfache Faustregel: Hat das Werk 100 Assets, sollte P1 unter 10 Zeilen liegen. Wenn P1 40 Zeilen hat, bedeutet „P1“ nichts mehr und das ganze Prioriätssystem ist zusammengebrochen. Neu einstufen, bis P1 der Regel entspricht.
Schritt 5: Jede Zeile mit einem Besitzer versehen Jede überlebende Zeile erhält einen namentlich benannten Besitzer, eine einzelne Person, nicht eine Abteilung. Ohne das bleibt P1‑Arbeit liegen, weil jeder annimmt, jemand anderes kümmert sich. Dies ist der zweithöchste Hebel der Methode.
Siehe die Einordnung in unserem Beitrag zu KPIs in der Fertigung dafür, wie Besitz in Trend‑Metriken einfließt.
Tage 21, 30: P1 abbauen und die Gewinne sichern Schritt 6: P1 mit einem jeden Tag namentlich benannten Ausführenden abbauen In den letzten 10 Tagen ist an jedem Arbeitstag ein namentlich benannter Techniker verantwortlich für das Schließen von zwei P1‑Zeilen. Nicht „das Team schließt“, sondern eine Person, zwei spezifische Zeilen‑IDs.
Das ergibt 20 geschlossene P1s in 10 Tagen, was meist den größten Teil des verbliebenen P1‑Stacks ausmacht. Schritt 7: Die dauerhaften Regeln einführen, die ein Wiederaufblähen verhindern Das sorgt dafür, dass die Bereinigung von Dauer ist.
Drei dauerhafte Regeln, um das Ergebnis zu sichern: - Abschlusskriterium pro Typ: Jeder Arbeitsauftragstyp hat eine schriftliche Definition von „erledigt“. Kein Typ ohne eine solche Definition. - Automatisches Schließen nach Verifizierung: Wenn ein Techniker auf „fertig“ setzt, verifiziert der Vorgesetzte innerhalb von 24 Stunden und der Eintrag schließt automatisch. Kein „in Arbeit“ für immer mehr.
- Duplikaterkennung bei Neueröffnung: Wenn ein neuer Arbeitsauftrag auf einem Asset eröffnet wird, zeigt das System offene Einträge auf demselben Asset an und fragt den Meldenden, zu bestätigen oder zusammenzuführen. Die Verbindung zur Ursachenanalyse ergibt sich hier natürlich, weil die Duplikate auf dieselbe Ursache hinweisen.
Schritt 8: Ein Ziel für die Backlog‑Größe setzen und wöchentlich überwachen Für ein typisches mittelständisches Werk mit 100 Assets ist ein gesunder Backlog 30, 60 offene Zeilen. Größer bedeutet, die Nachfrage überfordert die Kapazität (oder Duplikate schleichen sich wieder ein). Kleiner bedeutet, das System erfasst die reale Nachfrage nicht mehr.
Die Anzahl wöchentlich beobachten; der Trend ist wichtiger als die absolute Zahl. Die Backlog‑Zählung mit dem übergeordneten Wartungsplan koppeln, damit das Team weiß, welcher Anteil der Arbeit reaktiv vs. geplant ist.
Wie die Zahlen typischerweise aussehen Ein Werk, das mit 220 offenen Arbeitsaufträgen startet, landet typischerweise bei: - 40 Geister geschlossen (nachträglich verifiziert) - 25 Duplikate zusammengeführt - 15 falsch‑typisierte Zeilen in PM‑Plan oder Ersatzteilanforderungen verschoben - 10 P1‑Zeilen in Tagen 21
30 abgearbeitet - ~130 P2/P3‑Zeilen verbleiben als neuer Arbeitsbacklog Der „reale“ Backlog ist deutlich kleiner als die Zahl der offenen Zeilen vermuten ließ. Das Werk hat keine Kapazität hinzugefügt. Es hat nur aufgehört, so zu tun, als würden 220 Zeilen 220 voneinander getrennten Arbeitsaufträgen entsprechen.
Wie Fabrico ins Bild passt Die oben beschriebenen Triage‑Schritte sind werkzeug‑agnostisch und funktionieren in jedem CMMS, sogar in einer Tabelle. Was sich ändert, wenn das CMMS auf einer einheitlichen OEE+CMMS‑Basis aufgebaut ist, ist die Vermeidungsseite: Cluster‑Schwellwertregeln und OEE‑Ereignisverknüpfungen fangen die wiederkehrenden Ursachen ein, die ursprünglich die Duplikate erzeugen. Fabrico ist für diesen Workflow gebaut.
Um zu sehen, wie eine Bereinigung an Ihren Live‑Daten aussieht, buchen Sie eine Demo. Häufig gestellte Fragen Was, wenn unser Backlog über 500 Zeilen hat? Skalieren Sie das Triage‑Team. Die Methode bleibt dieselbe, aber die Phase Tage 1, 10 benötigt mehr Personen.
Ein Backlog mit 500 Zeilen und zwei Triage‑Mitgliedern benötigt ~3 Wochen; mit vier passt es in 10 Tage. Lassen Sie die Methode nicht auf 60+ Tage ausdehnen, die Frische des Kontexts nimmt ab. Sind Geister‑Arbeitsaufträge wirklich die größte Löschkategorie?
Ja, in Werken, die seit über 18 Monaten keine Bereinigung durchgeführt haben, sind Geister meist die größte Löschkategorie. Je länger die Zeit seit der letzten Bereinigung, desto höher der Geisteranteil. Werke mit vierteljährlicher Bereinigungs‑Cadenz halten ihn gering. Zählen offene PM‑Aufgaben zum Backlog dazu? Offene PM‑Aufgaben sind eine separate Population.
Sie haben eigene Fälligkeiten und eine eigene Erfolgsmetrik (Termintreue). Sie in den reaktiven Backlog zu mischen verschleiert das Bild beider. Halten Sie sie getrennt, auch wenn sie im selben CMMS leben. Sollten wir Backlog‑Zahlen dem weiteren Team veröffentlichen? Ja, mit Vorsicht.
Die Zahl kann in den ersten 30 Tagen dramatisch fallen und wie ein Wunder aussehen. Dann stabilisiert sie sich im Bereich 30, 60 und sieht aus, als würde nichts passieren. Koppeln Sie die Zahl an den Trend der P1‑Zeilen speziell, das ist das aussagekräftigere Signal. Was ist die häufigste Ursache für Rückfall?
Das Nachlassen der Duplikaterkennung. Wenn der Meldende bei jeder Neueröffnung nicht aufgefordert wird zu bestätigen oder zusammenzuführen, tauchen Duplikate innerhalb eines Quartals wieder auf und der Backlog bläht sich erneut. Die Regel zur Duplikaterkennung hat die geringsten Implementierungskosten und die höchste Langzeitwirkung.
Anmeldung
Blog