Warum sich ein IoT-Pilotprojekt nicht immer skalieren lässt und wie man diesen Fehler vermeidet

Warum ein Pilot nicht gleich Skalierung ist

Ein Pilot überprüft eine Hypothese, aber nicht immer das gesamte System. Auf einer Testfläche wählt das Team häufig die bequemsten Punkte aus: zugängliche Räume, Zähler mit klarer Schnittstelle, Bereiche mit guter Abdeckung, eine begrenzte Zahl von Nutzern und manuelle Kontrolle jedes einzelnen Geräts. Unter solchen Bedingungen lassen sich schnell erste Daten gewinnen und ein Ergebnis präsentieren.

Bei der Skalierung ändern sich die Bedingungen. Geräte befinden sich in Metallschränken, Kellern, Schächten, entfernten Gebäuden oder an Standorten mit instabilem Signal. Es kommen unterschiedliche Zählermodelle, verschiedene Plombierungsbedingungen und verschiedene Zugangsszenarien für Monteure hinzu. Die Zahl der Ereignisse wächst, Integrationen werden kritisch, und die manuelle Prüfung jedes einzelnen Punktes ist nicht mehr möglich.

Deshalb sollte ein Pilot keine Technologiedemonstration sein, sondern ein Test des zukünftigen industriellen Modells. Wenn im Pilotprojekt keine schwierigen Punkte, Montagerichtlinien, Verbindungsqualität, Datenformate, Plattformarbeit und Zuständigkeiten für den Betrieb geprüft werden, kann das Projekt zu Beginn gute Ergebnisse zeigen, aber der Erweiterung nicht standhalten.

Fehler 1: Der Pilot wird ohne klares Geschäftsziel gestartet

Einer der Hauptgründe, warum IoT-Projekte stagnieren, ist ein unklar definiertes Ziel. Das Team installiert Geräte, sammelt Daten, zeigt Diagramme, beantwortet aber nicht die Frage, welches Problem der Kunde auf Geschäfts- oder Betriebsebene löst.

Für einen Ressourcenanbieter kann das Ziel darin bestehen, Kontrollgänge zu reduzieren, die Genauigkeit der Abrechnung zu verbessern, Manipulationen zu überwachen, Streitfälle zu verringern oder regelmäßige Daten für die Abrechnung zu erhalten. Für eine Verwaltungsgesellschaft kann es um die Überwachung von Kellern, Überschwemmungen, Technikräumen und Notfallereignissen gehen. Für eine Kommune kann das Ziel darin bestehen, eine einheitliche Infrastruktur für verschiedene Dienste zu schaffen: Erfassung, Monitoring, Beleuchtung, technische Anlagen oder Umweltsensoren. Für einen Bauträger kann es darum gehen, die Betriebsbereitschaft eines Gebäudes zu erhöhen und zukünftige Kosten für manuelle Prozesse zu senken.

Vor dem Pilotprojekt muss ein messbares Ergebnis formuliert werden: wie viele Punkte angeschlossen werden, welche Daten eingehen sollen, in welcher Periodizität, wohin sie übertragen werden, welche Aktionen durch ein Ereignis ausgelöst werden und welcher Effekt nach der Skalierung erwartet wird. Ohne dies wird der Pilot schnell zu einem technischen Experiment, das sich vor Finanz-, Betriebs- oder Managementteams nur schwer begründen lässt.

Fehler 2: Für den Test werden nur „bequeme“ Punkte ausgewählt

Wenn ein Pilot nur Punkte mit gutem Zugang und stabiler Verbindung umfasst, erhält das Team ein zu optimistisches Bild. In einem realen Projekt werden zwangsläufig schwierige Bereiche auftreten. Dazu zählen beispielsweise Keller, dicke Wände, Metallschränke, Schächte, Räume mit hoher Luftfeuchtigkeit, entfernte Objekte, schwache Mobilfunkabdeckung oder ungeeignete Standorte für Basisstationen.

Ein richtiger Pilot sollte drei Arten von Punkten enthalten: typische, grenzwertige und problematische. Typische Punkte zeigen, wie das System unter normalen Bedingungen arbeitet. Grenzwertige Punkte helfen zu verstehen, wo eine Abdeckungsreserve, eine externe Antenne, eine Änderung des Installationsorts oder eine andere Übertragungsperiodizität erforderlich ist. Problematische Punkte zeigen, wo möglicherweise ein zusätzliches LoRaWAN-Gateway, NB-IoT statt LoRaWAN, ein anderes Gerätegehäuse, ein geändertes Montageszenario oder der Verzicht auf Automatisierung an einem bestimmten Punkt nötig ist.

Für Projekte auf LoRaWAN-Basis ist es wichtig, RSSI, SNR, den Prozentsatz erfolgreicher Übertragungen, Wiederholungsübertragungen und die Abdeckungsreserve zu messen. Für NB-IoT müssen Signalpegel und Stabilität der Geräteregistrierung im Netz genau am Installationsort geprüft werden, nicht nur anhand der Netzabdeckungskarte des Betreibers. Das ist besonders wichtig für Versorgungsinfrastruktur, wo sich Geräte häufig nicht im Freien, sondern in Gebäuden, Schränken und Technikräumen befinden.

Fehler 3: Der Betrieb nach der Installation wird nicht berücksichtigt

Ein Pilot lässt sich manuell betreuen: Der Ingenieur kennt jedes Gerät, prüft selbst fehlende Daten, exportiert Berichte manuell und reagiert schnell auf Störungen. Bei der Skalierung funktioniert dieser Ansatz nicht mehr.

Nach dem Start mit Hunderten oder Tausenden von Punkten müssen Batterien, Verbindungsqualität, fehlende Daten, Zustand der Basisstationen, Öffnungsereignisse, Integrationsfehler, Updates, Objektverzeichnisse und Nutzerrechte regelmäßig kontrolliert werden. Wenn diese Prozesse nicht im Voraus beschrieben sind, wird die IoT-Plattform zu einer weiteren Oberfläche, die manuell betreut werden muss.

Das Betriebsmodell sollte vor der Skalierung geplant werden. Es muss Antworten auf praktische Fragen enthalten: Wer ist für die Geräte verantwortlich? Wer betreut die Gateways? Wer reagiert, wenn keine Daten eingehen? Wer prüft die Verbindungsqualität? Wer wechselt Batterien? Wer pflegt das Objektverzeichnis? Wer ist für die Integration mit Billing, SCADA oder einem anderen System verantwortlich?

Für kommunale und Versorgungsprojekte ist es außerdem wichtig festzulegen, welche Ereignisse als Notfall gelten, wann ein Einsatz vor Ort erforderlich ist und wie schnell das Team reagieren muss.

Fehler 4: Die Plattform ist nicht auf das Wachstum der Geräteanzahl vorbereitet

Im Pilotprojekt reicht ein einfaches Dashboard aus: einige Geräte, eine Karte, eine Tabelle mit Messwerten, ein Ereignisprotokoll. Eine industrielle Einführung erfordert jedoch mehr. Die Plattform muss Objektgruppen, Nutzerrollen, Filter, Massenanbindung von Geräten, Historie, Berichte, Benachrichtigungen, Export, API und Kontrolle des Gerätestatus unterstützen.

Wenn die Plattform nicht dabei hilft, einen Gerätepark zu verwalten, erhöht die Skalierung die manuelle Arbeitslast erheblich. Mitarbeitende beginnen, problematische Punkte in Tabellen zu suchen, Daten manuell abzugleichen, separate Listen installierter Geräte zu führen und Vorfälle separat zu verfolgen.

Für solche Aufgaben kann in Jooby-Projekten das Jooby RDC Dashboard verwendet werden. Diese Plattform ist für die Erfassung, Anzeige und Verarbeitung von Daten aus Mess- und Monitoringgeräten zuständig. Zum Jooby-RDC-Ökosystem gehören außerdem LoRaWAN- und NB-IoT-Funkmodule, Sensoren, intelligente Zähler und LoRaWAN-Gateways für Projekte zur Erfassung von Wasser, Gas, Wärme und Strom sowie zur Überwachung technischer Infrastruktur.

Der Jooby-Katalog umfasst Geräte für verschiedene Ressourcenarten und Anschlussszenarien, und die Integratorlösungen von Jooby sind darauf ausgerichtet, Zähler, Sensoren, Plattform und externe Systeme in einer einheitlichen Architektur zu verbinden.

Fehler 5: Integrationen werden „auf später“ verschoben

Viele Pilotprojekte enden nach dem ersten Erfolg: Daten gehen in der Plattform ein, Diagramme werden angezeigt, Geräte sind sichtbar. Dann stellt der Kunde jedoch die wichtigste Frage: Wie gelangen diese Daten in Billing, Leitstelle, SCADA, ERP, CRM, BI-System oder persönliches Kundenkonto?

Wenn Integrationen nicht im Voraus geplant wurden, muss das Projekt umgebaut werden. Es stellt sich heraus, dass die Systeme unterschiedliche Objektverzeichnisse, Zählerkennungen und Anforderungen an das Datenformat, sowie eine unterschiedliche Logik für die Ereignisverarbeitung haben. Dadurch existiert die IoT-Lösung getrennt von den Arbeitsprozessen des Kunden.

Um diesen Fehler zu vermeiden, sollte bereits im Pilotprojekt festgelegt werden, welche Systeme Daten in welchem Format, mit welcher Periodizität, über welche Schnittstelle erhalten und wer für Austauschfehler verantwortlich ist. Für manche Projekte reichen API oder regelmäßiger Export. Für andere sind MQTT, Webhooks, OPC UA, Modbus TCP oder eine zwischengeschaltete Integrationsschicht erforderlich.

Wichtig ist außerdem, technische Meldungen und Geschäftsereignisse zu trennen. Ein Dispatcher oder Operator benötigt nicht immer den gesamten Datenstrom der Geräte. Wichtiger sind verständliche Statusmeldungen: „Zähler überträgt keine Daten“, „Batterie benötigt Aufmerksamkeit“, „Manipulation erkannt“, „Schwellenwert überschritten“, „Objekt muss geprüft werden“. Eine solche Logik macht IoT für den Betrieb nützlich, nicht nur technisch korrekt.

Fehler 6: Die Wirtschaftlichkeit des Lebenszyklus wird nicht berücksichtigt

Die Kosten eines Pilotprojekts wirken normalerweise aufgrund weniger Geräte, begrenzter Montage, minimaler Integrationen und manueller Betreuung akzeptabel. Doch die Skalierung verändert die Wirtschaftlichkeit. Es entstehen Kosten für zusätzliche Geräte, Basisstationen, SIM-Profile, Montage, Untersuchung schwieriger Punkte, Batteriewechsel, Support, Mitarbeiterschulung, Integrationen und Netzbetrieb.

Wenn im Pilotprojekt die jährlichen Kosten pro Punkt nicht berechnet werden, kann das Projekt teurer werden als erwartet. Besonders wichtig ist das für Kommunen und Ressourcenanbieter, bei denen das System über Jahre funktionieren muss — nicht nur bis zur Demonstration des Ergebnisses.

Die Berechnung sollte nicht nur CAPEX, sondern auch OPEX umfassen. Es muss klar sein, wie viel der Anschluss eines Punktes kostet, wie sich die Kosten bei steigender Geräteanzahl verändern, wie viele Vor-Ort-Einsätze sich reduzieren lassen, welche Prozesse automatisiert werden können, wie oft Batterien gewartet werden müssen und was die Unterstützung der Integrationen kosten wird. In IoT-Projekten entsteht die tatsächliche Effizienz nicht nur durch den Kauf von Geräten, sondern durch die Reduzierung manueller Arbeit und eine bessere Steuerbarkeit der Prozesse.

Wie man einen skalierbaren Pilot erstellt

Ein Pilot sollte von Anfang an als erste Phase einer industriellen Einführung geplant werden. Das bedeutet, dass nicht nur Verbindung und Gerät geprüft werden müssen, sondern das gesamte zukünftige Modell: Montage, Daten, Plattform, Integrationen, Betrieb und Wirtschaftlichkeit.

Im ersten Schritt sollte das Objekt oder Gebiet untersucht werden. Bei einem Gebäude sind das Eingänge, Etagen, Keller, Technikräume, Zählerknoten, Schränke und Installationsorte der Zähler. Bei einem Gebiet sind es Wohnhäuser, Wärmepunkte, Pumpstationen, Schächte, Trafostationen, Gewerberäume und kommunale Gebäude.

Im zweiten Schritt müssen repräsentative Punkte für den Pilot ausgewählt werden. Er sollte verschiedene Zählertypen, unterschiedliche Verbindungsbedingungen, verschiedene Wand- und Schrankmaterialien, unterschiedliche Zugangsebenen und mehrere problematische Standorte umfassen. So lassen sich reale Einschränkungen frühzeitig erkennen.

Im dritten Schritt muss die Architektur beschrieben werden: Geräte, Sensoren, Funkmodule, LoRaWAN oder NB-IoT, Serverebene, Plattform, Integrationen, Nutzer und Betriebsprozesse. Für Jooby-Lösungen kann eine solche Architektur Funkmodule für Zähler, Sensoren für analoge Messgeräte, intelligente Zähler, LoRaWAN-Basisstationen und das Jooby RDC Dashboard zur Datenerfassung und Weitergabe umfassen.

Im vierten Schritt müssen Erfolgskriterien definiert werden. Zum Beispiel: Anteil erfolgreicher Übertragungen, zulässiger Datenverlust, Ereignislieferzeit, Datengenauigkeit, autonome Laufzeit, Anzahl problematischer Punkte, Integrationsbereitschaft und erwartete Reduzierung manueller Prozesse.

Im fünften Schritt sollte ein Implementierungsstandard festgelegt werden: Montageregeln, Signalanforderungen, Liste kompatibler Zähler, Übertragungseinstellungen, Wartungsszenarien, Nutzerrollen, Berichtsformat und Integrationsschema. Danach sollte die Skalierung in Chargen erfolgen, mit Prüfung jeder Zone und Qualitätskontrolle der Installation.

Was in der Checkliste vor der Skalierung stehen sollte

Vor dem Übergang vom Pilotprojekt zur Masseneinführung sollte das Team über ein kurzes, aber praktisches Dokument verfügen. Darin sollte festgehalten werden:

1. Ziel des Projekts und erwarteter Effekt
2. Liste der Objekte und Anschlusspunkte
3. Typen von Geräten, Zählern und Sensoren
4. Ergebnisse der Verbindungsprüfung
5. Problemzonen und Lösungswege
6. Anforderungen an Plattform und Integrationen
7. Nutzerrollen und Zugriffsrechte
8. Regeln zur Ereignisverarbeitung und Handlungsalgorithmus bei fehlenden Daten
9. Modell für Geräte- und Batteriewartung
10. Kosten eines Punktes bei Skalierung

Eine solche Checkliste hilft zu verstehen, ob das Projekt bereit für die Erweiterung ist. Wenn einige Punkte unbeschrieben bleiben, ist es besser, den Pilot zu überarbeiten, als ungelöste Probleme auf Tausende Geräte zu übertragen.

Ein IoT-Pilotprojekt lässt sich nicht skalieren, wenn es nur die Funktion eines Geräts anstatt die Bereitschaft des gesamten Systems prüft. Die Datenübertragung auf einem Testabschnitt und ein bequemes Dashboard bedeuten noch nicht, dass die Lösung einer industriellen Einführung standhält.

Damit ein Pilot zur Grundlage einer skalierbaren IoT-Infrastruktur wird, müssen die realen Bedingungen des zukünftigen Projekts im Voraus geprüft werden: Verbindungsqualität, Montage, Zählerkompatibilität, Datenkorrektheit, Plattform, Integrationen, Betriebsprozesse und Wirtschaftlichkeit des Lebenszyklus. Je näher der Pilot an der realen Last und Objektumgebung liegt, desto geringer ist das Risiko, dass das Projekt nach der Demonstration stoppt.