7 Fehler, die Fabriken bei der Einführung von IoT machen
DBR77 Team · Veröffentlicht am
Die sieben häufigsten Fehler, die Fabriken bei der Einführung von IoT machen, sind: keine definierte Entscheidung, Verantwortung allein bei der IT, zu viele Linien gleichzeitig, keine Ausgangsbasis, Alarme ohne Verantwortliche, Gründecodes aus dem ERP und ein Programm, das an einem einzigen Fürsprecher hängt. Keiner davon betrifft Sensoren oder Software.
Jeder dieser Fehler macht IoT zu einem teuren Berichtssystem. Im Folgenden: wie Sie jeden Fehler erkennen und was Sie stattdessen tun sollten.
Die Frage, die zeigt, ob IoT funktioniert
Wenn ein Kunde Paweł Dera, CTO von DBR77 IIoT, sagt "wir haben schon IoT", stellt er eine Frage: "Was haben Sie im letzten Monat im Prozess auf Basis von Daten aus dem System geändert?" Oft kann niemand etwas nennen.
Die Dashboards sehen beeindruckend aus, aber Entscheidungen werden weiterhin nach Erfahrung getroffen. Meist hat zu Beginn niemand drei Fragen beantwortet: Welche fünf Kennzahlen zählen, wer handelt bei jeder einzelnen und welcher Schwellenwert löst eine Maßnahme aus.
In einer Umfrage von McKinsey unter mehr als 700 Experten der Fertigung hatte weniger als ein Drittel kritische Anwendungsfälle in den großflächigen Einsatz überführt. Das Weltwirtschaftsforum beschrieb 70 % der Hersteller als im "Pilot-Purgatorium" festsitzend.
Fehler 1: Keine Entscheidung ist definiert
Auf dem Panel der ITM Industry Europe 2026 zu der Frage, warum KI in Fabriken im Pilotstadium endet, führte Paweł Dera die meisten festgefahrenen Projekte auf dieselbe Lücke zurück: Niemand hatte aufgeschrieben, welche Entscheidung das Modell verbessern sollte. Die Aufzeichnungen sind auf Polnisch verfügbar.
"Wir wollen datengetriebener werden" nennt weder Auslöser noch Verantwortlichen noch Zeitrahmen, und eine Entscheidung braucht alle drei. Schreiben Sie vor dem Start einen kurzen Entscheidungsvertrag für die Linie:
- Fünf Kennzahlen, die zählen, zum Beispiel Verfügbarkeit, Reaktionszeit, häufigste Stillstandsgründe, Ausbringung je Schicht und Ausschuss.
- Eine Rolle, die je Schicht bei jeder Kennzahl handelt.
- Einen Schwellenwert je Kennzahl, der eine konkrete Maßnahme dieser Rolle auslöst.
Wenn Sie das nicht ausfüllen können, ist das Projekt noch nicht bereit, Maschinen anzubinden. Unser Leitfaden zur Auswahl des ersten IoT-Anwendungsfalls zeigt, wie Sie eine Entscheidung finden, mit der es sich lohnt zu starten.
Fehler 2: Die IT verantwortet die Einführung allein
IoT berührt Netzwerke und Sicherheit, deshalb landet es oft bei der IT. Die IT liefert vernetzte Maschinen und Dashboards, und auf dem Shopfloor ändert sich niemandes Arbeitsweise.
Die IoT-Forschung von McKinsey zeigt, dass viele Einführungen von der IT betrieben werden statt als unternehmerische Veränderung und dass erfolgreiche Unternehmen einen klaren Verantwortlichen benennen.
Teilen Sie die Verantwortung stattdessen auf. Die Produktion verantwortet die Einführung und die Ergebnisse: ein Linienverantwortlicher, der entscheidet, was zählt, und wer handelt. IT und OT verantworten Netzwerk, Zugriff und Sicherheit. Die Instandhaltung verantwortet die Reaktion auf technische Stillstände.
Sehen Sie, wie Entscheidungen, Verantwortliche und Alarme in der Praxis aussehen
In einer 30-minütigen Online-Demo zeigen wir, wie DBR77 IIoT jeden Stillstand auf einer laufenden Linie mit einem Grund, einem Verantwortlichen und einer Reaktionszeit verbindet.
Fehler 3 und 4: Zu viele Linien und keine Ausgangsbasis
Das ganze Werk auf einmal anzubinden wirkt effizient. In der Praxis verteilt sich der Aufwand dünn, und keine Linie bekommt genug Aufmerksamkeit, um Gewohnheiten zu ändern.
Der vierte Fehler tritt meist zusammen mit dem dritten auf: Es fehlt eine Ausgangsbasis, und ohne Zahlen aus der Zeit "vorher" wird das Projekt nach Meinung beurteilt. Zwei Wochen Daten an einer Linie reichen aus. Messen Sie die Minuten von Stillstand bis zur ersten Reaktion, den Anteil der Stillstandszeit ohne Grund und die drei größten Verluste in Minuten.
Fehler 5 und 6: Alarme ohne Verantwortliche und Gründe aus dem ERP
Alarme, die an "die Instandhaltung" oder an eine Gruppe im Chat gehen, haben keinen einzelnen Empfänger, und nach einer Woche stellen die Leute sie stumm. Jeder Alarm braucht eine Rolle in der laufenden Schicht und eine Eskalationsregel, zum Beispiel: Keine Bestätigung innerhalb von 5 Minuten, dann wird der Schichtführer informiert.
Aus dem ERP kopierte Gründecodes wurden für die Kostenrechnung geschrieben, und ein Bediener an einer stehenden Maschine denkt in anderen Worten. Vor Dutzenden Codes in Finanzsprache wählen Bediener "sonstiges". Führen Sie 10 bis 15 Gründe je Maschinentyp, in den Worten, die auf dem Shopfloor verwendet werden. Die Empfehlung von Vorne zu den sechs großen Verlusten nennt ein Beispiel für eine klare Regel: Jeder Stillstand länger als zwei Minuten bekommt einen Grund.
An einer Wellpappverpackungslinie, an der Alarme zu Aufgaben mit Verantwortlichem wurden und die Bediener den Grund am Automaten in etwa zwei Sekunden wählten, sank die durchschnittliche Reaktionszeit von 24 auf 9 Minuten. Die Bediener-App zeigt, wie die Erfassung der Gründe funktioniert, und welche Daten Sie an Maschinen erfassen sollten beschreibt, mit welchen Signalen Sie beginnen.
Fehler 7: Das Programm hängt an einem einzigen Fürsprecher
Viele IoT-Programme laufen über eine einzige begeisterte Person. Wenn diese Person das Werk verlässt, enden die Besprechungen, und das System wird zu einem Bildschirm an der Wand. Machen Sie das Programm unabhängig von einzelnen Personen:
- Dokumentierte Standards: Definitionen, Grundlisten, Alarmwege und Schwellenwerte schriftlich festgehalten und versioniert.
- Benannte Rollen: Linienverantwortlicher, Datenverantwortlicher und Reaktionsverantwortlicher je Schicht, mit einer Vertretung für jeden.
- Ein fester Rhythmus: eine 10-minütige Besprechung zu Beginn jeder Schicht und eine monatliche Überprüfung von Schwellenwerten und Gründen.
Diese drei Elemente machen aus einem Pilotprojekt außerdem einen Werksstandard.
Die sieben Fehler auf einen Blick
| Fehler | Symptom auf dem Shopfloor | Behebung |
|---|---|---|
| Keine Entscheidung definiert | Niemand kann eine Änderung vom letzten Monat nennen, die auf den Daten beruht | Entscheidungsvertrag: fünf Kennzahlen, je ein Verantwortlicher, Maßnahmen-Schwellenwerte |
| Verantwortung nur bei der IT | Maschinen vernetzt, Dashboards aktiv, Arbeit unverändert | Die Produktion verantwortet die Ergebnisse; IT und OT verantworten Netzwerk und Sicherheit |
| Zu viele Linien gleichzeitig | Viele Bildschirme, keine Linie mit nachgewiesenem Ergebnis | Zuerst eine Linie, dann ein wiederholbarer Rollout |
| Keine Ausgangsbasis | Ergebnisse werden in Besprechungen diskutiert | Zwei Wochen Daten aus der Zeit "vorher" an der Pilotlinie |
| Alarme ohne Verantwortliche | Benachrichtigungen werden innerhalb weniger Wochen stummgeschaltet | Eine Rolle je Alarm, dazu eine Eskalationsregel |
| Gründecodes aus dem ERP | "Sonstiges" und "unbekannt" führen das Pareto an | 10 bis 15 Gründe in der Sprache der Bediener je Maschinentyp |
| Ein einziger Fürsprecher | Das Programm verliert an Schwung, wenn diese Person geht | Dokumentierte Standards, benannte Rollen mit Vertretung, fester Überprüfungsrhythmus |
Häufige Fragen
Woran erkennen wir, ob unser IoT-System nur ein Berichtswerkzeug ist?
Fragen Sie, was Sie im letzten Monat aufgrund der Daten im Prozess geändert haben. Wenn niemand eine Änderung nennen kann, beginnen Sie mit einem Entscheidungsvertrag für eine Linie.
Wer sollte eine IoT-Einführung im Werk verantworten?
Die Produktion sollte die Ergebnisse verantworten, über einen Linienverantwortlichen, der entscheidet, was zählt, und wer handelt. IT und OT verantworten Netzwerk, Zugriff und Sicherheit. Ohne einen Verantwortlichen in der Produktion liefert das Projekt Dashboards und wenig mehr.
Können wir diese Fehler in einem bereits laufenden System beheben?
Ja. Die meisten Korrekturen betreffen Entscheidungen, Verantwortliche und Gründelisten. Die Hardware bleibt meist unverändert. Wählen Sie eine Linie, definieren Sie den Entscheidungsvertrag, erfassen Sie eine zweiwöchige Ausgangsbasis und erstellen Sie die Gründeliste mit den Bedienern neu.
Wie viele Linien sollte eine erste IoT-Einführung umfassen?
Eine. Weisen Sie dort das Ergebnis nach, dokumentieren Sie den Standard und rollen Sie ihn dann Linie für Linie aus.
Fazit
Wenn IoT in Ihrem Werk bereits läuft, gehen Sie die Tabelle oben für eine Linie gemeinsam mit dem Linienverantwortlichen durch. Beginnen Sie mit der ersten Zeile: Wenn niemand eine Prozessänderung aus dem letzten Monat nennen kann, schreiben Sie den unter Fehler 1 beschriebenen Entscheidungsvertrag, bevor Sie irgendetwas anderes ändern.
Prüfen Sie Ihre IoT-Einführung anhand dieser sieben Fehler
Buchen Sie eine 30-minütige Demo. Wir zeigen, wie DBR77 IIoT Entscheidungen, Verantwortliche und Gründe abbildet, und wo Ihre aktuelle Einführung womöglich Wert verliert.
Quellen
- DBR77, ITM Industry Europe 2026 conference recordings (auf Polnisch), 2026
- McKinsey & Company, How digital manufacturing can escape "pilot purgatory", 2018
- McKinsey & Company, IoT value set to accelerate through 2030, 2021
- World Economic Forum, These 10 new 'Lighthouse' factories show the future of manufacturing is here, 2020
- Vorne, The Six Big Losses, 2026
- DBR77 IIoT-Pilotdaten, Wellpappverpackungslinie (Kunde anonym), 2026