Die große Erwartungslücke: Warum IoT- und IIoT-Projekte im Kundenkontakt scheitern

Autor: DerSchneider

Einleitung

Die Versprechen sind gewaltig. Das Internet der Dinge verspricht vernetzte Intelligenz, Echtzeittransparenz und eine nie dagewesene Effizienzsteigerung – in der Fabrikhalle ebenso wie im Smart Home. Marketingabteilungen zeichnen Bilder einer Zukunft, in der Maschinen selbstständig kommunizieren, Ausfälle vorhersagen und Prozesse sich wie von Zauberhand optimieren. Die Erwartungen der Kunden sind entsprechend hoch.

Doch die Realität sieht anders aus. Untersuchungen von Cisco und Beecham Research zeigen, dass rund 74 Prozent der IoT-Projekte entweder komplett scheitern oder hinter ihren ursprünglichen Zielen zurückbleiben. Diese Zahl ist seit Jahren hartnäckig hoch. Die Gründe dafür sind vielfältig, aber ein Muster zieht sich wie ein roter Faden durch nahezu jedes gescheiterte Vorhaben: das Missverhältnis zwischen Kundenerwartung und technischer Umsetzung – und die fehlende interdisziplinäre Betrachtung der Gesamtsysteme.

Im Zentrum dieses Spannungsfeldes steht der Umgang mit Kunden, ihren Wünschen und Bedürfnissen. Kaum ein anderes Technologiefeld ist so sehr von großen Versprechungen geprägt und gleichzeitig so anfällig für Komplexität, Unübersichtlichkeit und schleichende Fehleranreicherung durch Nachbesserungen und erweiterte Kundenwünsche. Dieser Artikel beleuchtet die strukturellen Ursachen dieser Diskrepanz, zeigt die typischen Fallstricke auf und skizziert, wie ein gelungenes Erwartungsmanagement in der IoT- und IIoT-Praxis aussehen kann – mit besonderem Fokus auf die übergreifende, interdisziplinäre Projektanalyse, die in der Praxis allzu oft vernachlässigt wird.

Die Anatomie der Erwartungslücke

Versprechen versus Machbarkeit

Die Kluft zwischen dem, was Kunden versprochen wird, und dem, was technisch leistbar ist, beginnt bereits in der Angebotsphase. Vertrieb und Marketing operieren oft mit ambitionierten Visionen, während die Entwicklung mit den realen Randbedingungen kämpft. IIoT-Projekte sind in der Regel deutlich komplexer, als es der bisherige Erfahrungshorizont der Anwenderunternehmen vermuten lässt.

Ein Lastenheft mag zu Beginn alle relevanten Anforderungen erfassen – doch was passiert, wenn der Kunde während der Umsetzung neue Ideen entwickelt? Wenn die ursprünglich definierten Use Cases sich als zu eng oder zu weit gefasst erweisen? Die Praxis zeigt: Systeme von der Stange gibt es kaum. Jeder Anwendungsfall hat seine spezifischen Pain Points, und jede kundenspezifische Anpassung zieht eine Kette von Folgeänderungen nach sich.

Die Kosten der Nachbesserung

Ein besonders häufiges Phänomen in IoT- und IIoT-Projekten ist die massive Unterschätzung des Integrationsaufwands. Was auf der Präsentationsfolie wie eine elegante Lösung aussieht, entpuppt sich in der Umsetzung als komplexes Geflecht aus Payload-Parsern, Network-Server-Konfigurationen, API-Mappings und Datennormalisierung. Untersuchungen beziffern die Überschreitungen bei der IoT-Integration auf durchgängig 25 bis 40 Prozent über den ursprünglichen Schätzungen.

Hinzu kommen die laufenden Betriebskosten, die in der Euphorie des Projektstarts oft ignoriert werden: Konnektivitätsgebühren, Cloud-Speicherkosten, Firmware-Updates, Batteriewechsel – sie summieren sich über eine Flotte von Hunderten oder Tausenden Geräten zu beträchtlichen Summen. Ein Projekt, das bei 100 Geräten profitabel erscheint, kann bei 1.000 Geräten plötzlich kippen.

Die interdisziplinäre Herausforderung: Wenn Fachbereiche aneinander vorbeiarbeiten

Der blinde Fleck in der Projektplanung

Die größte, aber am häufigsten übersehene Stolperfalle in IoT- und IIoT-Projekten ist die mangelnde interdisziplinäre Abstimmung zwischen den beteiligten Fachbereichen. Moderne IoT-Projekte sind per Definition Querschnittstechnologien – sie berühren Elektrotechnik, Informationstechnologie, Mechanik, Logistik, Betriebswirtschaft, Datenanalyse und oft noch viele weitere Disziplinen.

In der Praxis sieht das jedoch häufig anders aus: Jede Fachabteilung plant und entscheidet in ihrem eigenen Silo. Die Logistikabteilung bestellt Sensoren für die Lagerüberwachung, ohne zu prüfen, ob im geplanten Einsatzbereich überhaupt WLAN verfügbar ist. Die Elektroplanung verbaut robuste IP67-gekapselte Sensoren, während die IT-Abteilung erst im Nachhinein erfährt, dass die erzeugten Datenformate nicht mit den bestehenden Systemen kompatibel sind. Die Serverstruktur wurde nie thematisiert – sie muss nun nachgerüstet werden, was Zeit und Budget verschlingt.

Ein exemplarischer Fall aus der Praxis

Besonders eindrücklich wird dieses Problem an einem typischen Beispiel:

Ein produzierendes Unternehmen plant die Einführung eines Zustandsüberwachungssystems für kritische Maschinen. Die Logistikabteilung, die für die Beschaffung zuständig ist, bestellt auf Empfehlung des Maschinenherstellers hochwertige Vibrationssensoren mit IP67-Schutzklasse – völlig korrekt für den rauen Produktionsumgebung. Was jedoch nicht bedacht wurde: Im Maschinenpark gibt es kein flächendeckendes WLAN, und die bestehende Verkabelungsinfrastruktur ist an den vorgesehenen Messstellen nicht vorhanden. Die Sensoren verfügen über keinen alternativen Funkstandard wie LoRaWAN oder NB-IoT.

Die IT-Abteilung wird erst hinzugezogen, als die ersten Datenpakete ankommen – und stellt fest, dass das verwendete Protokoll nicht mit der firmeneigenen MQTT-Broker-Infrastruktur kompatibel ist. Ein Gateway-Konzept existiert nicht. Die Sensordaten lassen sich nicht in das bestehende SCADA-System integrieren, da die Datenstruktur (Payload-Format, Unit-Konvertierung, Timestamp-Format) nicht abgestimmt wurde.

Als schließlich ein provisorisches Dashboard aufgesetzt wird, zeigen die Vibrationsdaten vermeintlich alarmierende Werte an – doch bei genauerer Analyse stellt sich heraus, dass die Frequenzanalyse im Dashboard auf einer anderen Sample-Rate basiert als die Sensor-Hardware liefert. Die Interpretationsunterschiede zwischen den Systemen führen zu völlig falschen Schlussfolgerungen. Ein Gespräch zwischen Logistik, Elektroplanung, IT und Datenanalyse hätte all diese Probleme bereits in der Planungsphase aufdecken können.

Die Kosten fehlender Interdisziplinarität

Die wirtschaftlichen Auswirkungen dieser mangelnden Abstimmung sind beträchtlich. Eine Studie des Fraunhofer-Instituts zeigt, dass bis zu 40 Prozent der Gesamtprojektkosten in IIoT-Projekten auf nachträgliche Integrationsaufwände und Korrekturen aufgrund fehlender interdisziplinärer Planung entfallen.

Der Kunde im Fadenkreuz der Komplexität

Wenn der Kundenfokus verloren geht

In komplexen IoT-Projekten kommt es häufig vor, dass die technischen Anforderungen mehr Beachtung finden als die Kundenbedürfnisse. Der Fokus auf den Kundennutzen geht verloren, weil zu viel Zeit für technische Aspekte verbraucht wird. Dabei ist genau dieser Mehrwert der eigentliche Grund für das Projekt.

Die entscheidenden Fragen – Welches Problem lösen wir mit unserem Produkt? Was ist der Nutzen für unseren Kunden? – werden im Projektverlauf oft nicht mehr gestellt. Stattdessen versinkt das Team in technischen Detailfragen: Welches Protokoll ist das richtige? Wie wird die Latenz minimiert? Welche Sicherheitsarchitektur ist angemessen? Alles wichtige Fragen – aber sie dürfen den Blick auf das Wesentliche nicht verdecken.

Unterschiedliche Erwartungshaltungen

Ein weiterer Stolperstein ist die unterschiedliche Erwartungshaltung der Beteiligten. In IoT- und IIoT-Projekten wirken Menschen aus den unterschiedlichsten Fachgebieten zusammen: Mechanik, Elektrotechnik, IT, Datenanalyse, Betriebswirtschaft. Jede Disziplin bringt ihre eigene Sprache, ihre eigenen Prioritäten und ihre eigenen Vorstellungen davon mit, was „Erfolg“ bedeutet.

Wenn der Vertrieb von „KI-gestützter Echtzeitoptimierung“ spricht, der Entwickler an „stabile API-Schnittstellen“ denkt und der Kunde „einfach nur eine zuverlässige Fernwartung“ möchte, sind Konflikte vorprogrammiert. Einfache und gut verständliche Formulierungen ohne unnötige Buzzwords sind der beste Weg zu einem gemeinsamen Zielbild.

Das Problem der sich verschiebenden Anforderungen

Die größte Herausforderung im Kundenkontakt ist jedoch die dynamische Natur der Anforderungen. Kaum ein Kunde weiß zu Beginn eines IoT-Projekts genau, was er wirklich braucht. Die Technologie eröffnet Möglichkeiten, von denen er vorher nichts wusste – und plötzlich entstehen neue Wünsche. „Könnten wir nicht auch noch…?“ ist der gefürchtetste Satz in jedem IoT-Projekt.

Jede Erweiterung zieht jedoch Konsequenzen nach sich: neue Sensoren, zusätzliche Datenpunkte, angepasste Algorithmen, erweiterte Dashboards. Der ursprünglich klare Use Case verwässert, das Budget steigt, der Zeitplan gerät ins Wanken. Die schleichende Fehleranreicherung durch ständige Nachbesserungen führt zu einem technischen Schuldenberg, der irgendwann nicht mehr tragbar ist.

Die strukturellen Fehler im System

Fehler 1: Kein klares Geschäftsziel

Der häufigste und teuerste Fehler in IoT-Projekten ist der Start ohne klar definiertes Geschäftsziel. Ein Team kauft Sensoren, Gateways und Cloud-Abonnements, bevor es sich darauf geeinigt hat, wie Erfolg aussieht.

„Wir wollen unsere Anlagen überwachen“ ist kein Ziel.
„Wir wollen ungeplante Ausfallzeiten in 12 Monaten um 15 Prozent senken, indem wir Temperaturanomalien an Motoren früh erkennen“ ist ein Ziel.

Die Genauigkeit der Zieldefinition ist entscheidend, weil sie bestimmt, welche Daten benötigt werden, wie oft sie abgefragt werden müssen und was mit ihnen geschieht.

Fehler 2: Die „Lösung auf der Suche nach einem Problem“

Zu viele IoT-Initiativen beginnen mit der Technologie: „Hier ist eine Plattform, was können wir damit machen?“ Dieser anbietergetriebene Ansatz scheitert fast immer. IoT sollte geschäftsorientiert sein – nicht umgekehrt. Wenn das Problem, der ROI und der greifbare Nutzen nicht von Anfang an klar definiert sind, ist das Projekt bereits zum Scheitern verurteilt.

Fehler 3: Das „Proof-of-Concept-Laufband“

Endlose PoCs sind eine bekannte Geschichte. Teams bauen beeindruckende Prototypen, präsentieren Innovationen und feiern frühe Erfolge – und skalieren dabei nie. PoCs sind sicher: Sie kreuzen das Kästchen „Innovation“ an, ohne dass ein struktureller Wandel oder ein langfristiges Engagement erforderlich wäre. Das Ergebnis sind teure Experimente, die nie einen geschäftlichen Nutzen bringen.

Fehler 4: Das „Instant Gratification“-Syndrom

Industrial IoT ist ein Marathon, kein Sprint. Während einige Quick Wins möglich sind, zeigt sich der wahre Wert – optimierte Abläufe, vorausschauende Erkenntnisse, neue Umsatzmodelle – erst im Laufe der Zeit. Wenn die Geschäftsleitung einen vierteljährlichen ROI erwartet und zu früh den Stecker zieht, haben vielversprechende Projekte nie die Chance, ihren Wert unter Beweis zu stellen.

Fehler 5: Planung im Fachsilo – das Kardinalproblem

Der wohl am häufigsten unterschätzte Fehler ist die isolierte Planung innerhalb einzelner Fachabteilungen. Die Logistik denkt in Lieferketten und Beständen, nicht in Datenformaten und Funkstandards. Die Elektroplanung denkt in Schutzarten und Leistungsdaten, nicht in API-Schnittstellen und Serverkapazitäten. Die IT denkt in Netzwerken und Sicherheitsrichtlinien, nicht in mechanischen Einbaubedingungen und Umgebungstemperaturen.

Ein funktionierendes IIoT-System erfordert jedoch interdisziplinäre Entscheidungs- und Informationsstrukturen, die alle relevanten Fachbereiche von Beginn an einbeziehen. In großen Betrieben muss über den eigenen Fachbereich hinaus gedacht werden – ein Verantwortungsbewusstsein für das Gesamtsystem, das in der Praxis oft fehlt.

Der Kontext als Schlüssel zum Erfolg

Den Kunden abholen, wo er steht

Die wichtigste Erkenntnis für den erfolgreichen Umgang mit Kunden in IoT- und IIoT-Projekten ist: Der Kontext ist entscheidend. Jeder Kunde bringt seine eigene Ausgangssituation mit: bestehende IT-Infrastruktur, vorhandene OT-Komponenten, spezifische Branchenanforderungen, regulatorische Vorgaben, kulturelle Besonderheiten.

Ein Projekt, das bei einem global agierenden Automobilzulieferer funktioniert, kann bei einem mittelständischen Maschinenbauer scheitern – nicht wegen der Technologie, sondern wegen des unterschiedlichen Kontexts. Die Kunst liegt darin, die Lösung an den Reifegrad und die spezifischen Bedürfnisse des Kunden anzupassen, statt mit einer Standardlösung zu kommen.

Klare Use Cases als Kompass

Eine der größten Herausforderungen bei IIoT-Projekten ist die Definition eines klaren Anwendungsfalls. Der Fokus sollte dabei auf dem Mehrwert liegen, den das Projekt für das Unternehmen und seine Kunden generiert. Klarheit bringen Fragen wie:

• Welche Probleme soll der Einsatz von IIoT lösen?
• Welche Prozesse sollen optimiert werden?
• Wie lässt sich der Erfolg des Projekts kontinuierlich messen?

Ein gut definierter Use Case hilft, den Umfang und Ablauf des Projekts klar zu umreißen und alle Beteiligten auf ein gemeinsames Ziel auszurichten.

Transparente Kommunikation als Erfolgsfaktor

Die vielleicht wichtigste, aber am häufigsten vernachlässigte Disziplin ist die transparente Kommunikation mit dem Kunden. Das bedeutet:

1. Ehrliche Einschätzung der Machbarkeit: Nicht alles, was technisch möglich ist, ist auch sinnvoll oder wirtschaftlich.
2. Klare Darstellung der Risiken: Jedes IoT-Projekt birgt Unsicherheiten – von der Funkreichweite bis zur Datenqualität.
3. Regelmäßige Statusupdates: Keine Überraschungen, sondern kontinuierliche Information über Fortschritt und Hindernisse.
4. Gemeinsame Priorisierung: Wenn der Zeitplan unter Druck gerät, muss gemeinsam entschieden werden, welche Features wirklich essenziell sind.
5. Interdisziplinäre Abstimmungsrunden: Regelmäßige Termine mit allen beteiligten Fachbereichen – von der Logistik über die Elektroplanung bis zur IT – um frühzeitig Konflikte zu erkennen und zu lösen.

Standardisierte Schnittstellen als Brücke zwischen den Welten

Ein wesentlicher Erfolgsfaktor für die interdisziplinäre Zusammenarbeit ist die Verwendung standardisierter Schnittstellen und Datenformate. OPC UA, MQTT, Sparkplug, BACnet – diese Standards schaffen eine gemeinsame Sprache zwischen den Gewerken und reduzieren die Interpretationsunterschiede, die zu fehlerhaften Dashboard-Anzeigen führen.

Die Festlegung eines gemeinsamen Datenmodells bereits in der Planungsphase – mit definierten Einheiten, Abtastraten und Metriken – verhindert, dass später unterschiedliche Systeme verschiedene Interpretationen derselben Sensordaten liefern. Einheitliche Namenskonventionen, klare Timestamp-Formate und dokumentierte Umrechnungsfaktoren sind keine technischen Spielereien, sondern Grundlage für ein gemeinsames Systemverständnis.

Interdisziplinäre Entscheidungsgremien etablieren

In großen Unternehmen hat sich die Einrichtung interdisziplinärer Entscheidungsgremien für IIoT-Projekte bewährt. Diese Gremien, besetzt mit Vertretern aller betroffenen Fachbereiche, treffen verbindliche Entscheidungen zu:

• Technologieauswahl (Funkstandard, Protokoll, Cloud-Plattform)
• Systemarchitektur (Hardware, Software, Netzwerk)
• Datenmodell und Metriken
• Sicherheitsanforderungen und Zugriffsrechte
• Budget- und Ressourcenallokation

Diese Gremien verhindern, dass Entscheidungen im Fachsilo getroffen werden, die später zu kostspieligen Korrekturen führen. Sie schaffen Verantwortlichkeit und fördern das Verständnis für die Gesamtsystemzusammenhänge über die eigenen Fachgrenzen hinaus.

Iterative Entwicklung statt Big Bang

IIoT-Projekte – insbesondere jene mit erheblichen Hardware-Komponenten – profitieren von agilen Methoden. Ein Pilotprojekt ermöglicht es, in kleinem Maßstab zu testen und Erkenntnisse für die breitere Implementierung zu sammeln. Diese frühzeitige Risikominderung hilft, potenzielle Probleme zu identifizieren und zu beheben, bevor skaliert wird.

Im Rahmen eines Piloten lassen sich insbesondere die interdisziplinären Schnittstellen – der Übergang von der Sensorhardware über das Netzwerk bis zur Cloud und dem Dashboard – unter realen Bedingungen testen. Erst wenn diese Kette funktioniert und die Interpretation der Daten zwischen allen Beteiligten abgestimmt ist, sollte skaliert werden.

Fazit und Ausblick

Die IoT- und IIoT-Branche hat ein strukturelles Erwartungsproblem. Die großen Versprechungen der vergangenen Jahre haben bei Kunden ein Bild gezeichnet, das die technische Realität oft nicht einhalten kann. Die Komplexität der Systeme, die Vielzahl der beteiligten Disziplinen und die dynamische Natur der Kundenanforderungen führen zu einer schleichenden Erosion von Zeitplänen, Budgets und Vertrauen.

Doch die eigentliche Wurzel des Übels liegt tiefer: Es ist die mangelnde interdisziplinäre Denkweise, die in der Planungs- und Entscheidungsphase von IoT- und IIoT-Projekten allzu oft fehlt. Ein Sensor, der verbaut wird, ohne dass das WLAN ausgebaut ist. Sensordaten, die nicht in bestehende Systeme integriert werden können. Eine Serverstruktur, die nie bedacht wurde. Dashboard-Anzeigen, die aufgrund unterschiedlicher Interpretationsgrundlagen falsche Schlüsse zulassen. Und nicht zuletzt: eine Logistikabteilung, die Schutzarten wie IP67 nicht kennt, weil niemand mit ihr gesprochen hat.

All diese Fehler sind vermeidbar – durch eine von Beginn an interdisziplinär angelegte Projektstruktur, durch regelmäßige Abstimmungsrunden, durch standardisierte Schnittstellen und durch ein gemeinsames Verständnis für das Gesamtsystem.

Dennoch wäre es falsch, aus dieser Erkenntnis Resignation abzuleiten. Die Technologie funktioniert – wenn sie richtig eingesetzt wird. Der Schlüssel liegt nicht in noch mehr Technik, sondern in einem radikal kundenorientierten Ansatz, der den Kontext des Kunden in den Mittelpunkt stellt, klare und messbare Ziele definiert und eine transparente Kommunikation über alle Projektphasen hinweg pflegt.

Die Zukunft gehört nicht den Unternehmen, die die ausgefeilteste Technologie anbieten, sondern denen, die es verstehen, die Erwartungen ihrer Kunden zu managen – ohne sie zu überhöhen, ohne sie zu enttäuschen, und mit dem nötigen Fingerspitzengefühl für die spezifischen Gegebenheiten jedes einzelnen Projekts.

In der Praxis bedeutet das: Interdisziplinarität ist keine Option, sie ist eine Überlebensvoraussetzung. Wer in IIoT-Projekten erfolgreich sein will, muss die Sprachbarrieren zwischen den Fachbereichen überwinden, Silodenken abbauen und eine gemeinsame Entscheidungs- und Informationsstruktur etablieren. Nur so können aus großen Versprechungen tatsächlich große Erfolge werden.

Denn am Ende zählt nicht, was technisch möglich ist. Sondern was dem Kunden wirklich hilft – und das funktioniert nur, wenn alle Beteiligten an einem Strang ziehen.

Quellen

• Cisco & Beecham Research: Studien zur IoT-Projekt-Erfolgsquote (zitiert nach TagoIO, 2026)
• eco – Verband der Internetwirtschaft: „7 Erfolgsfaktoren für IIoT-Projekte“, 2025
• eco – Verband der Internetwirtschaft: „Seven Success Factors for IIoT Projects“, 2025
• Fraunhofer-Institut: Studien zu Integrationskosten in IIoT-Projekten (zitiert nach IT&Production)
• IT&Production: „Anforderungen für IoT-Plattformen entwickeln“, 2024
• TagoIO: „Warum IoT-Projekte scheitern und was Sie dagegen tun können“, 2026
• Computerwoche: „5 Faktoren: Darum scheitern IoT-Projekte“, 2023
• Michael Goh (LinkedIn): „Jenseits des Hypes: Warum IoT- und IIoT-Projekte scheitern“, 2025
• IDC-Studie: IIoT-Implementierungspläne in der Industrie (zitiert nach Hilscher)
• VDI-Richtlinien zur interdisziplinären Projektplanung in der Automatisierungstechnik