Dieser Artikel wurde maschinell aus dem Englischen übersetzt. Zum englischen Original.
Dienstagnachmittag. Eine Bedienerin an einer Verpackungslinie hört an einem Antriebsmotor eine Vibration, die sie schon einmal gehört hat. Damals endete es mit einem festgefressenen Lager und elf Stunden ungeplantem Stillstand.
Was tut sie als Nächstes?
Sie kann warten, bis ein Planer vorbeikommt, die Leitwarte anfunken, eine Notiz ins Schichtbuch kritzeln oder die Linie weiterlaufen lassen und hoffen, dass sie bis Freitag hält.
Keine dieser Möglichkeiten endet mit einer sauberen SAP-Meldung, einem Foto des Motors, dem genauen Standort und einem Planer, der sich das innerhalb einer Stunde ansieht. Genau diese Lücke soll die bedienergesteuerte Zuverlässigkeit schließen.
Was bedienergesteuerte Zuverlässigkeit wirklich bedeutet.
Bedienergesteuerte Zuverlässigkeit (Operator-Driven Reliability, ODR) ist ein Ansatz im Anlagenmanagement, bei dem das Bedienpersonal eine festgelegte Rolle dabei übernimmt, die Anlagen in gutem Zustand zu halten. Die Bediener sind für die tägliche Pflege, Sichtkontrollen und die erste Eskalation zuständig. Die Instandhaltung übernimmt Diagnose, Reparatur und konstruktive Verbesserungen. Zuverlässigkeit wird zur gemeinsamen Aufgabe.
Die Idee gehört seit Jahrzehnten zum Werkzeugkasten der Total Productive Maintenance (TPM). Das Japan Institute of Plant Maintenance hat sie formalisiert, und die Society for Maintenance and Reliability Professionals (SMRP) hat sie nach Nordamerika gebracht.
Die Kernidee hat sich nicht geändert: Die Menschen, die am nächsten an der Anlage sind, merken meist als Erste, wenn etwas nicht stimmt. Ihr Zuverlässigkeitsprogramm sollte ihnen deshalb einen Weg geben, auf das zu reagieren, was sie bemerken.
ODR ist nicht dasselbe wie autonome Instandhaltung.
Die beiden Begriffe werden oft gleichbedeutend verwendet, und es ist wichtig, sie auseinanderhalten zu können. Die autonome Instandhaltung ist eine der acht Säulen der TPM. Sie überträgt dem Bedienpersonal eine breitere Palette praktischer Pflegeaufgaben, darunter Reinigen, Schmieren, Inspizieren und kleinere Einstellungen, organisiert in einem strukturierten Stufenmodell mit sieben Schritten. Gut umgesetzt erfordert sie kontinuierliche Schulung und einen vollständigen TPM-Rahmen.
ODR ist enger gefasst. Im Mittelpunkt steht der Informationskreislauf: Erkennen, Erfassen, Eskalieren und Rückmeldung. Ein glaubwürdiges ODR-Programm lässt sich ohne vollständige autonome Instandhaltung betreiben, und viele anlagenintensive Unternehmen machen genau das. Sie wollen die Zuverlässigkeitsgewinne durch die Einbindung des Bedienpersonals ohne den kulturellen Aufwand einer mehrjährigen TPM-Einführung. Für Teams, die auf SAP PM standardisieren, ist das meist der realistischere Startpunkt.
Was ODR nicht ist und warum es oft für eine Papierübung gehalten wird: dem Bedienpersonal eine Checkliste in die Hand zu drücken und das ein Programm zu nennen.
Eine Checkliste ist ein Anfang. Das eigentliche Programm ist der geschlossene Kreislauf von „Ein Bediener hat etwas bemerkt“ über „Ein Techniker hat etwas unternommen“ bis „Der Bediener hat das Ergebnis gesehen“. Fehlt ein Glied in diesem Kreislauf, verfällt das Programm.
Warum ODR 2026 wichtiger ist.
Zwei Entwicklungen machen ODR dringlicher als noch vor fünf Jahren.
Die erste betrifft die Belegschaft. Die Studie „Tradespeople Wanted“ von McKinsey stützt sich auf Daten des US Bureau of Labor Statistics und schätzt, dass zwischen 2022 und 2032 auf jede netto neu hinzukommende Fachkraft 20 offene Stellen in Handwerksberufen kommen, darunter Industriemechaniker, Maschinenschlosser, Elektriker und verwandte Berufe. Diese Lücke lässt sich nicht durch Einstellungen schließen. Ein erheblicher Teil des technischen Wissens in anlagenintensiven Unternehmen geht in diesem Jahrzehnt in Rente, und es kommen weniger Nachfolger nach als Mitarbeiter gehen.
Die zweite sind die Kosten von Fehlern. Laut dem Bericht „True Cost of Downtime 2024“ von Siemens verlieren die 500 größten Industrieunternehmen der Welt jährlich rund 1,4 Billionen US-Dollar durch ungeplante Stillstände, etwa 11 % ihres Jahresumsatzes. Zwei Drittel der Industriestandorte haben mindestens einmal im Monat einen ungeplanten Stillstand. Einen Ausfall früh zu erkennen ist bares Geld wert, und das Bedienpersonal in der Produktion ist dafür am besten aufgestellt.
Zusammen ergeben diese Entwicklungen eine Rechnung, die nicht mehr aufgeht: mehr Stillstand, der auf dem Spiel steht, weniger Techniker, um ihn zu verhindern, und ein stetiger Verlust erfahrener Mitarbeiter, die bisher alles zusammengehalten haben. Wer diese Lücke ohne zusätzliches Personal schließen will, muss die Menschen einbinden, die ohnehin acht Stunden am Tag an der Linie und neben den Anlagen stehen. Das ist Ihr Bedienpersonal, und es ist in den meisten Werken, mit denen wir arbeiten, die größte ungenutzte Ressource für Zuverlässigkeit.
Warum ODR-Programme in SAP-Umgebungen ins Stocken geraten.
Wenn Sie SAP PM einsetzen, haben Sie das Datenmodell für all das bereits:
- Eine Meldung ist der strukturierte Weg, ein Problem zu melden.
- Ein Instandhaltungsauftrag ist der strukturierte Weg, es zu beheben.
- Die Anlagenstruktur zeigt, welches Equipment wo steht.
Theoretisch bemerkt ein Bediener ein Problem, legt eine Meldung an, ein Planer prüft sie, und ein Auftrag wird erteilt. Das ist ODR in SAP.
In der Praxis bricht der Kreislauf an vier vorhersehbaren Stellen.
Wer am nächsten am Problem ist, kommt nicht ans System.
Die meisten Unternehmen vergeben SAP-Lizenzen sparsam. Instandhaltungsplaner, Disponenten und Techniker haben Konten. Bedienpersonal und andere Produktionsmitarbeiter, an einem einzigen Standort oft Tausende, haben meist keine. Selbst wo es mobile Apps gibt, laufen sie oft nur auf firmenverwalteten Geräten, die gerade die Menschen, die sie am dringendsten bräuchten, häufig nicht dabeihaben.
An einem großen europäischen Standort der Lebensmittel- und Getränkeindustrie, mit dem wir arbeiten, schätzt das Instandhaltungsteam, dass mindestens 20 % der instandhaltungsrelevanten Ereignisse nie erfasst werden. Nicht weil der Bediener oder Staplerfahrer es nicht bemerkt hätte, sondern weil er im entscheidenden Moment kein registriertes Smartphone in der Hand hatte.
Genau um diese Lücke geht es bei einem ODR-Programm. Die Frage ist, ob jemand, der direkt neben einem Problem steht, einen sauberen Weg hat, wichtige Informationen in fünf Sekunden an das richtige System weiterzugeben. Eine Checkliste auf dem Klemmbrett und ein Plakat im Pausenraum beantworten diese Frage nicht.
SAP GUI wurde nicht für die Produktion oder den Außendienst entwickelt.
Selbst wo das Bedienpersonal Konten hat, passt SAP GUI schlecht zur Arbeitsweise im Werk oder draußen vor Ort.
Eine Meldung über die Standardtransaktion anzulegen heißt, zuerst einen Computer zu finden und sich dann durch Masken zu arbeiten, die für das Büro gemacht sind. Aus einer Beobachtung von 30 Sekunden wird eine Dateneingabe von fünf Minuten, und das, während der Bediener neben laufenden Anlagen steht und sieben andere Dinge zu tun hat.
Unter diesem Aufwand bricht die Akzeptanz jedes Mal ein. Wie die Alternativen aussehen, zeigt unser Vergleich mobiler SAP-Apps für Instandhaltungsaufträge.
Papierrundgänge und Papierformulare gehen verloren.
Viele Werke greifen auf Papier zurück. Die Rundgänge werden als Heft ausgedruckt, das alles andere als kurz ist und an einem großen Standort oft viele Dutzend Seiten umfasst. Die Bediener gehen die Route ab, haken Kästchen an und geben die Formulare am Schichtende beim Vorgesetzten ab.
Diese Formulare werden dann abgeheftet, Tage später abgetippt oder gehen ganz verloren. Die Information, die eine Meldung hätte auslösen sollen, liegt in einem Ordner. Der Kreislauf ist genau an der Stelle offen, an der er sich schließen sollte. (Mehr zu diesem Problem lesen Sie in Digitale Rundgänge: vom Papierheft zu Daten in SAP (auf Englisch).)
Die Leitwarte wird zum Engpass.
Um das Papierproblem zu umgehen, leiten manche Standorte die Beobachtungen des Bedienpersonals über eine einzige SAP-geschulte Person, meist in der Leitwarte oder im Instandhaltungsbüro. Jedes Problem wird per Funk durchgegeben, notiert und erfasst. Das funktioniert, solange die Menge gering ist. Es scheitert, sobald ODR wirklich angenommen wird, denn eine Person kann die Beobachtungen von Hunderten Bedienern an einem großen Standort nicht in Echtzeit erfassen. Entweder staut sich die Arbeit, oder die Leute rufen nicht mehr an, weil sie wissen, dass so schnell nichts passiert.
Das ist kein Scheitern des ODR-Konzepts. Es ist ein Scheitern der Schnittstelle zwischen Bedienpersonal und führendem System. Beheben Sie diese Schnittstelle, und das Konzept funktioniert wie vorgesehen.
Wie Datenqualität hilft, Budget zu gewinnen.
Bessere Zuverlässigkeit ist die lange Antwort auf die Frage, warum sich ODR lohnt. Die kurze Antwort, mit der Budget genehmigt wird, lautet Datenqualität.
Wenn ein Investitionsantrag für eine neue Produktionslinie der Unternehmensleitung vorgelegt wird, stützt er sich auf Daten: wie oft die bestehende Linie ausgefallen ist, an welchen Komponenten, wie lange und zu welchen Kosten. SAP PM ist dafür gebaut, genau diese Historie zu führen. Technische Plätze bilden das Werk als Baumstruktur ab, jede Meldung und jeder Auftrag verweist auf einen Punkt in dieser Struktur, und Kosten und Historie werden von der einzelnen Anlage auf alle übergeordneten Ebenen verdichtet.
In der Praxis funktioniert das selten sauber. Bei einem unserer Kunden beschrieb der Instandhaltungsleiter das alte Muster: Ein Bediener ruft in der technischen Abteilung an, der Techniker am Telefon legt die Meldung in SAP an und bleibt unter Zeitdruck ein oder zwei Ebenen tief in der Struktur stehen, also oberhalb der Linie statt an der Linie selbst. Die Daten sammeln sich am Standort, und die Linie selbst wirkt gesünder, als sie ist. Wenn der Investitionsantrag dann in der Zentrale auf dem Tisch liegt, fehlen im System die Belege, die ihn rechtfertigen.
QR- oder Barcode-Scans ersparen die manuelle Auswahl. Wer die Meldung anlegt, scannt das Schild an der Maschine, und die App ordnet sie direkt der richtigen Anlage zu. Über Monate baut sich die Ausfallhistorie auf der Ebene auf, auf der Entscheidungen fallen. So überzeugt ODR mit den richtigen Werkzeugen Instandhaltungsleiter und Finanzverantwortliche zugleich.
Wie ein funktionierender ODR-Kreislauf in SAP aussieht.
Ein funktionierender Kreislauf hat immer dieselben sechs Schritte, egal ob ein Problem bei einem geplanten Rundgang auffällt oder zwischen den Rundgängen. Jeder Schritt hängt an einem konkreten SAP-Objekt.
1) Der Bediener erkennt das Problem. Auf einem Rundgang gibt die Route vor, welche Prüfungen anstehen. Außerhalb des Rundgangs fällt ihm etwas auf: eine neue Vibration, eine Leckage, ein Messwert außerhalb des Sollbereichs.
2) Der Bediener identifiziert das Equipment. Ein Barcode oder Schild am Equipment lädt den Kontext: welche Anlage, welche Linie, welcher Standort. Auf einem Rundgang hat das die Route bereits erledigt. Außerhalb des Rundgangs ordnet der Scan die Beobachtung dem richtigen technischen Objekt zu.
3) Der Bediener erfasst das Problem. Eine kurze Beschreibung, wahlweise mit Fotos oder einem 3D-Scan. Ziel ist, dem Planer alles zu geben, was er für die Bewertung braucht, ohne ein zweites Gespräch. Die Erstlösungsrate steigt, wenn der Planer genug Kontext hat.
4) Aus der Beobachtung wird eine SAP-Meldung. Keine E-Mail, kein Eintrag im Schichtbuch, kein Ticket in einem Parallelsystem, das später jemand abtippt. Eine echte Meldung mit verknüpftem Equipment, Schadens- und Ursachencodes, wo sinnvoll, und dem vollständigen Kontext. An diesem Schritt scheitern die meisten Werke, und er entscheidet, ob das Programm skaliert.
5) Die Meldung fließt in die Planung. Wo es sinnvoll ist, wird aus der Meldung ein Instandhaltungsauftrag. Ein Planer prüft ihn, vergibt die Priorität, terminiert ihn und weist ihn einem Techniker zu, mit den Fotos und Notizen des Bedieners. Der Techniker weiß bei seiner Ankunft, worum es geht.
6) Der Kreislauf schließt sich. Ist die Arbeit erledigt, sieht der Bediener, der das Problem gemeldet hat, das Ergebnis: was gefunden wurde, was getan wurde und wie lange es gedauert hat. Dieser Teil sorgt dafür, dass das Programm hält. Bediener, die nie etwas zurückhören, melden irgendwann nichts mehr. Bediener, die sehen, dass ihre Beobachtungen etwas bewirken, melden weiter und werden mit der Zeit besser darin.
Keiner dieser Schritte ist technisch neu. Was Werke mit funktionierendem ODR von Werken ohne unterscheidet, ist der Aufwand bei jedem Schritt. Dauert das Erfassen eines Problems 30 Sekunden, macht das Bedienpersonal mit. Dauert es länger, nicht.
So starten Sie ein ODR-Programm.
Wählen Sie eine Anlagenklasse und einen Standort. Nicht das ganze Werk, nicht jede Pumpe im Unternehmen. Beginnen Sie dort, wo mangelnde Zuverlässigkeit am meisten kostet und das Bedienpersonal am motiviertesten ist. Rotierende Maschinen an einer kritischen Produktionslinie sind ein häufiges erstes Ziel. Ebenso eine bestimmte Fahrzeugflotte oder ein einzelnes Umspannwerk.
Führen Sie das Programm nicht überall gleichzeitig ein.
Ressourcen sind begrenzt, und die Aufmerksamkeit im Unternehmen, die ein ODR-Programm braucht, ist noch knapper als das Budget. Wählen Sie den Standort, an dem Sie am ehesten ein klares Ergebnis erzielen, beweisen Sie dort, dass der Kreislauf funktioniert, und planen Sie mit diesen Erfahrungen den nächsten.
Legen Sie die Grenzen klar fest.
Halten Sie schriftlich fest, was das Bedienpersonal tun soll, was es eskalieren soll und was es nicht anfassen soll. Gehen Sie das vor der Einführung mit beiden Gruppen durch. Das schützt das Bedienpersonal davor, Technikerarbeit übernehmen zu müssen, und die Techniker vor einer schleichenden Ausweitung ihrer Aufgaben in die andere Richtung.
Machen Sie das Melden schnell.
Dauert der Weg von „Ich sehe ein Problem“ bis „Es ist in SAP“ länger als 30 Sekunden, wird das Programm nicht konsequent genutzt. Meist braucht es dafür eine mobile App für den Einsatz vor Ort, mit Scan zur Identifizierung des Equipments, Sprache-zu-Text für die Beschreibung und einer Fotofunktion, die nur einen Fingertipp entfernt ist.
Geben Sie die Daten zurück.
Veröffentlichen Sie wöchentlich oder monatlich eine Übersicht, wie viele Meldungen angelegt wurden, wie viele zu Aufträgen geführt haben und was gefunden wurde. Nennen Sie die Bediener, die Ausfälle früh erkannt haben. Zeigen Sie, welche Stillstände verhindert wurden. Diesen Schritt lassen die meisten Programme aus, und er entscheidet, ob ein Programm wächst oder nach drei Monaten stagniert.
Messen Sie zuerst die Beteiligung, dann die Ergebnisse.
In den ersten sechs Monaten zählt, wie viele Bediener aktiv melden, nicht wie viele Probleme sie finden. Steigt die Beteiligung, folgen die Zahl der Befunde und die Datenqualität. Stagniert die Beteiligung, ist im Kreislauf etwas kaputt, und das müssen Sie beheben, bevor Sie weitere Standorte hinzunehmen.
Typische Fehler, die Sie vermeiden sollten.
Jeder der folgenden Fehler kann ein Programm, das eigentlich gut aufgestellt ist, unbemerkt scheitern lassen. Es geht darum, wie Menschen behandelt werden, wenn sie etwas melden, wie die Informationen nach der Erfassung weiterfließen, für wen die Oberfläche gemacht ist und worauf die Führung achtet.
Eine Schuldkultur beendet die Beteiligung am schnellsten.
Wenn eine Bedienerin eine kleine Leckage meldet und gefragt wird, warum sie sie nicht früher bemerkt hat, lernt sie, die nächste nicht zu melden. Die kulturelle Arbeit, Beobachtung und Schuld zu trennen, muss vor der Einführung der Technik passieren, nicht danach.
Erfassung auf Papier untergräbt das Programm, egal wie gut die Schulung ist.
Liegt die Information in einem Ordner, bis jemand sie abtippt, ist der Kreislauf zu langsam, um nützlich zu sein. Das Bedienpersonal glaubt nicht mehr, dass seine Meldungen etwas bewirken, und es kommen erst weniger, dann keine Meldungen mehr.
Software für SAP-Experten verhindert Akzeptanz.
Sieht die Software des Bedienpersonals aus wie SAP GUI im Kleinformat, ist das Ergebnis dasselbe wie mit SAP GUI: Es wird nicht gemeldet. Die Oberfläche muss für jemanden gemacht sein, der nie einen Transaktionscode gesehen hat und auch keinen sehen sollte.
Wer das Falsche misst, übersieht echte Probleme.
Die Zahl der angelegten Meldungen zeigt, ob sich die Leute am Programm beteiligen. Sie zeigt nicht, ob die Meldungen brauchbar sind. Erfassen Sie auch qualitative Kennzahlen: wie viele Meldungen zu Aufträgen geführt haben, wie oft Techniker ohne Rückfrage beim Bediener bewerten können und wie viele Befunde einen Ausfall im Frühstadium erkannt haben statt erst nach dem Schaden.
Der Wandel lohnt sich, aber er braucht Zeit.
Begutachtete Studien zu ODR-Inspektionsrouten und Fallstudien aus der Prozessindustrie zeigen immer wieder deutlich weniger ungeplante Ausfälle, sobald sich das Bedienpersonal beständig beteiligt und der Kreislauf vom Erkennen bis zur Rückmeldung geschlossen ist. Die Gewinne sind real, doch gerade in großen Unternehmen kommt die Akzeptanz solcher Programme oft nur langsam in Gang: Der ROI Ihrer EAM-Software hängt an einer Sache: ob sie jemand nutzt (auf Englisch).
Die FastApp Suite von Arkyn ist Ihr Weg zu schnellerer Akzeptanz und einem erfolgreichen ODR-Programm.
Mit FastNotifications kann jeder Mitarbeiter ein Problem in Sekunden an SAP melden, ohne SAP-Schulung und ohne SAP-Lizenz, per Barcode-Scan, Foto, Sprache-zu-Text oder 3D-Scan.
FastForms digitalisiert Rundgänge, Inspektionschecklisten und Sicherheitsformulare. Jedes Formular wird mit SAP-Kontext vorab ausgefüllt, und die Einreichungen landen als strukturierte Datensätze in SAP. Eine vollständige Vorführung von FastForms finden Sie hier: Einführung in FastForms für die SAP-Instandhaltung (auf Englisch). Liegt ein Messwert außerhalb des Sollbereichs oder bemerkt ein Bediener zwischen den Prüfungen etwas, kann das Formular direkt eine Meldung, einen Auftrag oder eine Ausbauanforderung anlegen. Mehr über FastForms erfahren Sie im SAP Store.
Zusammen machen sie aus der Beobachtung eines Bedieners in der Produktion etwas, mit dem ein Planer sofort arbeiten kann.