Der IIoT-ROI ist die Frage, die jeder Werksleiter stellt, bevor er ein Projekt zur Maschinenvernetzung genehmigt, und es ist die Frage, die die meisten Anträge schlecht beantworten. Dieser Leitfaden liefert Ihnen ein praxisnahes Framework, um Gewinne bei Stillstand, Energie und Qualität zu quantifizieren, jede Kostenposition ehrlich aufzuführen und das Ergebnis in eine Amortisationszeit und einen Kapitalwert zu übersetzen, die Sie in einer Budgetsitzung verteidigen können. Außerdem erhalten Sie ein kleines Python-Modell, das Sie an Ihre eigenen Daten anpassen können.
Warum die meisten IIoT-Business-Cases scheitern
Ein Industrial-IoT-Antrag scheitert meist aus einem von drei Gründen. Erstens wird der Nutzen in Adjektiven beschrieben: „bessere Transparenz", „klügere Entscheidungen", „digitale Transformation". Ein Adjektiv kann die Finanzabteilung nicht abzinsen. Zweitens umfassen die Kosten nur Hardware und Softwarelizenzen, und die Arbeit für Integration, Datenmodellierung und Change Management taucht später als unangenehme Überraschung auf. Drittens versucht das Projekt, sich für das gesamte Werk auf einmal zu rechtfertigen, sodass niemand die Zahlen überprüfen kann, bevor das Geld ausgegeben ist.
Die Lösung: Verknüpfen Sie jeden Nutzen mit einer betrieblichen Kennzahl, die Sie bereits messen (oder günstig zu messen beginnen können), mit einer Ausgangsbasis und mit einem konkreten Mechanismus, der erklärt, warum vernetzte Daten diese Kennzahl verändern. Können Sie den Mechanismus nicht benennen, lassen Sie den Nutzen aus dem Business Case heraus. Eine kleinere, glaubwürdige Zahl schlägt eine große, wacklige.
Die IIoT-ROI-Formel
Die Arithmetik ist einfach. Die Disziplin steckt in den Eingangswerten.
Annual net benefit = (downtime savings + energy savings + quality savings + labour savings)
- annual running costs
Simple ROI (%) = (annual net benefit * years - one-time costs) / one-time costs * 100
Payback (months) = one-time costs / (annual net benefit / 12)
NPV = -one-time costs + sum over years of annual net benefit / (1 + discount rate)^year
Nutzen Sie die einfache Amortisationszeit, um Aufmerksamkeit zu gewinnen, und den Kapitalwert (NPV), um die Genehmigung zu bekommen. Die meisten Finanzabteilungen haben eine Mindestrendite oder eine maximale Amortisationsdauer; fragen Sie danach, bevor Sie das Modell bauen, damit Sie das Ziel kennen.
Nutzenhebel und wie Sie sie messen
Jeder der folgenden Hebel braucht eine Ausgangsbasis, einen Mechanismus und eine konservative Verbesserungsannahme. Halten Sie alle drei schriftlich fest.
| Hebel | Basiskennzahl | Mechanismus durch vernetzte Daten | Bewertung |
|---|---|---|---|
| Ungeplante Stillstände | Stunden ungeplanter Stopps pro Maschine und Jahr | Zustandsalarme, schnellere Fehlerdiagnose, frühere Wartung | Entgangener Deckungsbeitrag pro Stunde plus Überstunden und Eilmaßnahmen |
| Kurzstopps und Geschwindigkeitsverluste | Leistungskomponente der OEE | Sichtbarkeit kurzer Stopps, die niemand manuell erfasst | Zusätzliche Gutteile pro Schicht mal Marge pro Teil |
| Energie | kWh pro produzierter Einheit, Lastspitzen | Leerlauferkennung, Erkennung von Druckluftleckagen, Lastverschiebung | Tarif pro kWh plus Leistungspreis |
| Ausschuss und Nacharbeit | Ausschussquote, Nacharbeitsstunden | Erfassung von Prozessparametern verknüpft mit Qualitätsergebnissen | Materialkosten plus Arbeit plus Entsorgung |
| Manuelle Datenerfassung | Stunden für Klemmbretter und Tabellen | Automatische Zählungen, Zustände und Berichte | Vollkostensatz mal frei gewordene Stunden |
| Qualitätsmängel beim Kunden | Reklamationen, Gewährleistungskosten | Rückverfolgbarkeit der Prozessdaten pro Charge | Vermiedene Forderungen, oft als Risikoreduktion bewertet |
Stillstand richtig bewerten
Der häufigste Fehler ist, Stillstandsstunden mit dem Umsatz pro Stunde zu multiplizieren. Umsatz geht nicht verloren, wenn das Werk die Menge später mit Überstunden oder freier Kapazität nachholen kann. Der ehrliche Wert, den auch ein Controller im Mittelstand akzeptiert, ist der Deckungsbeitrag der tatsächlich verlorenen Produktion plus die Kosten für das Nachholen des Rests (Überstunden, Expressfracht, zusätzliche Umrüstungen). Bei einer ausgelasteten Engpassmaschine sind verlorene Stunden meist verlorene Produktion. Bei einer Maschine mit Reservekapazität nachgelagert kann der Wert deutlich niedriger sein.
Energie richtig bewerten
Energieeinsparungen entstehen an zwei Stellen: beim Verbrauch (kWh) und bei Lastspitzen (kW), die viele Industrietarife separat abrechnen. Ein vernetzter Zähler an jedem großen Verbraucher zeigt Ihnen, wann Maschinen im Leerlauf stehen, während Motoren, Heizungen oder Kompressoren weiterlaufen. Bewerten Sie nur den Leerlaufverbrauch, den Sie realistisch abschalten können, und verwenden Sie Ihre tatsächliche Tarifstruktur statt eines Durchschnittspreises.
Qualität richtig bewerten
Qualitätsgewinne sind real, aber langsam nachzuweisen, weil Sie genug Chargen brauchen, um Signal von Rauschen zu trennen. Nehmen Sie sie in den Business Case auf, erwägen Sie aber, sie in eine Spalte „Phase zwei" zu stellen, die für die Amortisation nicht erforderlich ist. So bleibt der Kern des Business Case robust.
Die Kostenseite: jede einzelne Position
Ein glaubwürdiges IIoT-ROI-Modell führt Kosten auf, die Antragsverfasser gern vergessen.
- Sensoren und Nachrüstungen. Stromzangen, Vibrationssensoren, Temperaturfühler, Energiezähler sowie Montage und Verkabelung. Unser Leitfaden zum Nachrüsten älterer Maschinen für IoT zeigt die typischen Optionen.
- Edge-Gateways. Hardware, Gehäuse, Netzteile und Ersatzteile. Hier findet die Protokollkonvertierung von Modbus, OPC UA oder SPS-Treibern statt.
- Netzwerkarbeiten. Switches, VLANs, Firewall-Regeln, eventuell Mobilfunkmodems für entfernte Standorte.
- Messaging-Infrastruktur. Der MQTT-Broker, der die Edge mit den Konsumenten verbindet. Ein selbst betriebener Broker verursacht Kosten für Server, Patching, Zertifikate und Bereitschaftsdienst; ein verwalteter MQTT-Broker macht daraus ein Abonnement.
- Datenspeicherung und Visualisierung. Historian oder Zeitreihendatenbank, Dashboards, Lizenzen.
- Integration und Datenmodellierung. Zuordnung von Tags zu einer konsistenten Topic-Struktur und einheitlichen Einheiten. Das ist häufig der größte Engineering-Kostenblock. Er sinkt deutlich, wenn Sie sich früh auf einen Unified Namespace (UNS) einigen, dessen Topics der ISA-95-Hierarchie folgen (Unternehmen → Standort → Bereich → Linie → Zelle, etwa
acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur): Dann wird jede weitere Maschine nach demselben Muster eingehängt, und MES, ERP und Dashboards lesen die Daten ohne eigenes Mapping. - Interne Arbeitszeit. OT-Ingenieure, IT-Sicherheitsprüfungen, Schulung der Bediener auf neue Bildschirme.
- Laufende Kosten. Abonnements, Mobilfunkdaten, Supportverträge, Ersatzsensoren.
- Reserve. Ein Prozentsatz für Unbekanntes, besonders bei der ersten Linie, die Sie anbinden.
Wo Messaging-Kosten hingehören
Messaging ist selten der größte Kostenblock eines IIoT-Projekts, aber derjenige, der mit jeder zusätzlichen Maschine wächst, daher sollten Sie ihn von Anfang an modellieren. Drei Größen bestimmen ihn: die Anzahl gleichzeitiger Verbindungen (eine pro Gateway oder Gerät, das MQTT spricht), die Nachrichtenrate und die Nachrichtengröße.
Zwei Designentscheidungen bewegen diese Größen stark. Veröffentlichen bei Änderung statt nach festem Takt, beschrieben in unserem Artikel zu Report by Exception, senkt das Nachrichtenvolumen bei sich langsam ändernden Werten wie Temperaturen und Zuständen. Das Bündeln vieler Tags in einer Gateway-Verbindung hält die Zahl der Verbindungen niedrig, auch wenn die Zahl der Tags hoch ist.
Mit ConnectMQ dimensionieren Sie den Broker über den Plan statt über Server. Der Plan Serverless (Free) erlaubt bis zu 25 Verbindungen, QoS bis 1 und Nachrichten bis 256 KB, was für eine Pilotlinie ausreicht. Serverless (Paid) erhöht das auf 1.000 Verbindungen mit QoS 2, Nachrichten bis 1 MB und Shared Subscriptions, und Dedicated bietet einen isolierten Cluster, wenn ein Standort ihn braucht. Weil die Planlimits feststehen, ist die Messaging-Position in Ihrem ROI-Modell ein bekanntes Abonnement und keine Schätzung von Serverstunden und Engineering-Zeit. Wenn Sie Hosting-Optionen vergleichen, erklärt unser Überblick zum Cloud-MQTT-Broker die Abwägungen.
Ein Python-Modell zum Anpassen
Das folgende Skript hält alle Annahmen in einem Dictionary, sodass Sie es mit der Finanzabteilung teilen und Eingangswerte vor ihren Augen ändern können. Die Werte sind illustrative Platzhalter, keine Benchmarks; ersetzen Sie jeden durch Ihre eigenen Basisdaten.
# iiot_roi.py - ein transparentes IIoT-ROI-Modell. Ersetzen Sie jeden Eingangswert durch Ihre eigenen Daten.
inputs = {
# Stillstand
"machines": 8,
"unplanned_downtime_hours_per_machine": 120, # Ausgangsbasis aus Wartungsprotokollen
"downtime_reduction_pct": 0.15, # konservative Annahme
"margin_lost_per_downtime_hour": 400.0, # Deckungsbeitrag, nicht Umsatz
# Energie
"idle_kwh_per_machine_per_year": 9000,
"idle_kwh_avoidable_pct": 0.30,
"energy_price_per_kwh": 0.18,
# Qualität
"scrap_cost_per_year": 60000.0,
"scrap_reduction_pct": 0.05,
# Arbeitszeit
"manual_reporting_hours_per_week": 10,
"loaded_labour_rate": 45.0,
# Kosten
"one_time_costs": 85000.0, # Sensoren, Gateways, Integration, Schulung, Reserve
"annual_running_costs": 14000.0, # Broker-Plan, Speicher, Dashboards, Support
"years": 5,
"discount_rate": 0.10,
}
def annual_benefits(i):
downtime = (i["machines"] * i["unplanned_downtime_hours_per_machine"]
* i["downtime_reduction_pct"] * i["margin_lost_per_downtime_hour"])
energy = (i["machines"] * i["idle_kwh_per_machine_per_year"]
* i["idle_kwh_avoidable_pct"] * i["energy_price_per_kwh"])
quality = i["scrap_cost_per_year"] * i["scrap_reduction_pct"]
labour = i["manual_reporting_hours_per_week"] * 48 * i["loaded_labour_rate"]
return {"downtime": downtime, "energy": energy, "quality": quality, "labour": labour}
def evaluate(i):
b = annual_benefits(i)
gross = sum(b.values())
net = gross - i["annual_running_costs"]
payback_months = i["one_time_costs"] / (net / 12) if net > 0 else float("inf")
roi_pct = (net * i["years"] - i["one_time_costs"]) / i["one_time_costs"] * 100
npv = -i["one_time_costs"] + sum(net / (1 + i["discount_rate"]) ** y
for y in range(1, i["years"] + 1))
return b, gross, net, payback_months, roi_pct, npv
if __name__ == "__main__":
b, gross, net, payback, roi, npv = evaluate(inputs)
for k, v in b.items():
print(f"{k:>10}: {v:12,.0f} per year")
print(f"{'gross':>10}: {gross:12,.0f} per year")
print(f"{'net':>10}: {net:12,.0f} per year")
print(f"payback : {payback:8.1f} months")
print(f"ROI : {roi:8.1f} % over {inputs['years']} years")
print(f"NPV : {npv:12,.0f}")
# Sensitivität: Was, wenn jede Verbesserung nur halb so gut ausfällt?
pessimistic = dict(inputs)
for key in ("downtime_reduction_pct", "idle_kwh_avoidable_pct", "scrap_reduction_pct"):
pessimistic[key] = inputs[key] / 2
*_, p_payback, p_roi, p_npv = evaluate(pessimistic)
print(f"pessimistic payback: {p_payback:.1f} months, NPV: {p_npv:,.0f}")
Führen Sie es mit python iiot_roi.py aus. Der Sensitivitätsblock am Ende ist wichtiger als die Hauptkennzahl: Amortisiert sich das Projekt auch dann noch, wenn jede Verbesserung halbiert wird, ist der Business Case robust. Funktioniert es nur im optimistischen Szenario, verkleinern Sie den Umfang oder suchen Sie einen stärkeren Hebel.
Mit einem Pilot beweisen, bevor Sie skalieren
Eine Tabellenkalkulation ist eine Hypothese. Der schnellste Weg, Annahmen durch Messungen zu ersetzen, ist ein eng gefasster Pilot an einer Linie oder einer Handvoll Maschinen, der lange genug läuft, um einen repräsentativen Produktionsmix zu erfassen. Unser Leitfaden für einen IIoT Proof of Concept behandelt Umfang und Erfolgskriterien im Detail.
Halten Sie den Pilot günstig und umkehrbar:
- Wählen Sie den Hebel mit der klarsten Ausgangsbasis, meist Stillstand oder Energie an einer Engpassanlage.
- Binden Sie die Daten über ein Edge-Gateway an, das an einen MQTT-Broker veröffentlicht, mit einer UNS-Topic-Struktur nach ISA-95, die Sie auch im großen Maßstab beibehalten würden.
- Nutzen Sie für den Pilot eine kostenlose Broker-Stufe, damit die Infrastruktur keine Beschaffungsfrage wird. Den Datenfluss können Sie mit nicht sensiblen Beispieldaten auf dem öffentlichen MQTT-Broker prototypisch aufbauen und dann auf private Zugangsdaten umstellen; für Produktionsdaten ist der öffentliche Broker nicht gedacht.
- Vereinbaren Sie vorab, welches Ergebnis als Erfolg gilt und wer abzeichnet.
- Erfassen Sie die tatsächlichen Integrationsstunden. Diese Zahl verbessert Ihre Kostenschätzung für die Skalierung am stärksten.
Ein minimaler Pilot-Publisher kann so einfach sein und einen Maschinenzustand an ein eindeutiges Topic auf dem öffentlichen Broker senden:
mosquitto_pub -h broker.connectmq.com -p 1883 -i roi-pilot-7f3a \
-t "connectmq/demo/7f3a/line1/press1/state" \
-m '{"state":"running","kw":11.4,"ts":"2026-10-16T08:00:00Z"}' -q 1 -r
Den IIoT-ROI der Finanzabteilung präsentieren
Wenn Sie das Modell in die Budgetsitzung bringen, strukturieren Sie es so, dass die Prüfer Eingangswerte hinterfragen können statt der ganzen Idee:
- Zeigen Sie für jeden Eingangswert die Quelle der Ausgangsdaten.
- Trennen Sie harte Einsparungen (Energie, Ausschuss, Überstunden) von weichem oder strategischem Nutzen (Rückverfolgbarkeit, schnellere Entscheidungen).
- Zeigen Sie das pessimistische Szenario neben dem erwarteten.
- Benennen Sie, was nicht im Umfang ist und was eine Phase zwei ergänzen würde.
- Zeigen Sie die Skalierungskosten pro zusätzlicher Maschine, die meist weit unter den Pilotkosten liegen, weil Architektur, Broker und UNS-Topic-Modell bereits existieren.
Für den übergeordneten architektonischen Kontext erklärt unser Grundlagenartikel zu Industrial IoT mit MQTT, wie Gateways, Broker und Konsumenten zusammenspielen, und der Artikel zur IIoT-Architektur geht tiefer auf die Schichten ein.
Starten Sie mit ConnectMQ
Der günstigste Teil eines IIoT-Business-Cases sollte der sein, mit dem Sie heute beginnen können. Erstellen Sie unter app.connectmq.com einen Broker im kostenlosen Serverless-Plan ohne Kreditkarte, verbinden Sie Ihr Pilot-Gateway mit dem generierten Benutzernamen, Passwort und der Client-ID und beobachten Sie echte Maschinendaten im Live-Topic-Explorer, während sich Ihr ROI-Modell mit gemessenen Werten füllt. Wenn der Pilot den Business Case belegt, skaliert ConnectMQ mit kostenpflichtigen und dedizierten Plänen, ohne dass sich Ihre Topic-Struktur ändert.
Häufig gestellte Fragen
Was ist eine gute Amortisationszeit für ein IIoT-Projekt?
Es gibt keine allgemeingültige Zahl; sie hängt von der Mindestrendite und der Risikobereitschaft Ihres Unternehmens ab. Fragen Sie die Finanzabteilung nach ihrer Schwelle, bevor Sie das Modell bauen, und zeigen Sie sowohl die erwartete als auch die pessimistische Amortisation im Vergleich dazu.
Sollte ich bei der Bewertung von Stillständen im IIoT-ROI Umsatz oder Marge verwenden?
Verwenden Sie den Deckungsbeitrag der tatsächlich verlorenen Produktion plus die Kosten für das Nachholen des Rests. Der Umsatz pro Stunde überzeichnet den Nutzen immer dann, wenn das Werk die Menge später aufholen kann.
Wie stark beeinflussen MQTT-Messaging-Kosten den IIoT-ROI?
Meist sind sie im Vergleich zu Sensoren und Integration eine kleine Position, aber sie wachsen mit jedem Gerät. Modellieren Sie Verbindungen, Nachrichtenrate und Größe, und nutzen Sie Report by Exception, um das Volumen niedrig zu halten.
Kann ich den IIoT-ROI berechnen, bevor ich Sensoren installiere?
Sie können aus Wartungsprotokollen, Energierechnungen und Ausschussberichten eine Hypothese aufbauen, sollten sie aber als Ausgangspunkt betrachten. Ein kurzer Pilot ersetzt die schwächsten Annahmen durch gemessene Daten.
