Der naheliegende erste Schritt in einem IoT-Projekt ist die Bestellung eines Development Kits und einiger Sensoren. Das fühlt sich nach Fortschritt an, kostet wenig und gibt dem Team etwas zum Anschließen. So starten die meisten Projekte.
Der Haken: Hardware, die Sie kaufen, bevor der Umfang steht, entscheidet für Sie. Ein LoRaWAN-Sensor bindet Sie an ein Netz, das an Ihren Standorten vielleicht gar keine Abdeckung hat. Seine Firmware legt das Payload-Format fest und damit die Variablen, die Sie je bekommen werden. Sein voreingestelltes Meldeintervall bestimmt Batterielaufzeit, Datenvolumen und die Höhe Ihrer Plattformrechnung für die nächsten drei Jahre. Hardware trifft all diese Entscheidungen auf einmal, und sie sind am schwersten rückgängig zu machen. Ein Development Kit zurückzuschicken ist einfach. Vierhundert installierte Sensoren, die auf dem falschen Funkstandard laufen, auszutauschen ist ein Projektneustart.
Die Lösung ist eine Schrittfolge, die vor jeder Bestellung einen Projektumfang auf einer Seite ergibt und ihn dann auf der Plattform mit einem simulierten Gerät überprüft. Hardware kommt zuletzt, und bis dahin wissen Sie, was Sie bestellen müssen.
Schritt 1: Benennen Sie die Entscheidung, die sich durch die Daten ändern soll
Jedes IoT-Projekt, das sich rechnet, verändert eine Entscheidung, die heute jemand ohne Daten trifft. Schreiben Sie sie in einem Satz auf, mit einer benannten Rolle: “Der Standortleiter entscheidet, welche Kühlräume er jeden Morgen prüft” oder “Der Instandhaltungsleiter entscheidet, wann Pumpendichtungen getauscht werden”. Wenn der Satz das Wort “Insights” braucht, ist er nicht fertig.
Dieser Schritt entscheidet über alles Weitere. Eine Entscheidung, die einmal am Tag fällt, verträgt einen Sensor, der stündlich meldet. Eine Entscheidung, die eine Produktionslinie stoppt, braucht Sekunden. Teams, die den Schritt überspringen, landen bei einem Dashboard, das niemand öffnet.
Schritt 2: Listen Sie Variablen, Einheiten und das Meldeintervall auf
Arbeiten Sie von der Entscheidung rückwärts zum Minimum an Daten: welche Variablen, in welchen Einheiten, in welchem Intervall, mit welcher Genauigkeit. Temperatur auf 0,5 C genau alle 15 Minuten bedeutet einen anderen Sensor, ein anderes Batteriebudget und ein anderes Datenvolumen als Temperatur auf 0,1 C genau jede Minute.
Das Intervall ist die Zahl, in der die Kosten stecken. Ein Sensor, der jede Minute meldet, produziert 60-mal so viele Daten wie einer im Stundentakt, leert seine Batterie in einem Bruchteil der Zeit und schiebt eine Flotte bei jeder Plattform in die höheren Preisstufen für die Datenaufnahme. Legen Sie das Intervall anhand der Entscheidung aus Schritt 1 fest, nicht anhand der Voreinstellung des Sensors.
Schritt 3: Prüfen Sie die Standorte und ihre tatsächliche Konnektivität
Listen Sie jeden Standort auf, an dem ein Gerät stehen wird, und beantworten Sie für jeden einzelnen: Welcher Funkstandard kommt dort wirklich an? LoRaWAN braucht ein Gateway mit einem realen Pfad zum Sensorstandort, und Keller, Metallgehäuse und dichter Beton drücken die Reichweite aus dem Datenblatt weit nach unten. Mobilfunk braucht Netzabdeckung im Gebäude, nicht davor. Wi-Fi braucht ein schriftliches Ja der IT-Abteilung des Kunden für ein Netz, das Sie nicht kontrollieren.
Ein Abdeckungstest kostet einen Nachmittag und ein geliehenes Gateway. Wer ihn überspringt, spezifiziert sein Projekt für LoRaWAN und landet am Ende bei Mobilfunk zum dreifachen Stückpreis. Lesen Sie LoRaWAN-Reichweite in der Praxis, bevor Sie eine Zahl annehmen.
Schritt 4: Zählen Sie die Geräte im Pilotprojekt und im dritten Jahr
Zwei ehrliche Zahlen: wie viele Geräte im Pilotprojekt und wie viele, wenn das Pilotprojekt funktioniert und über drei Jahre ausgerollt wird. Die Zahl für das Pilotprojekt bestimmt die Größe Ihrer ersten Bestellung. Die Zahl für das dritte Jahr bestimmt alles andere: welches Preismodell sinnvoll ist und welche Plattformgrenzen Sie zuerst erreichen (Datenaufnahme, Datenausgabe, Speicher, Benachrichtigungen).
Ein Preismodell, das bei 30 Geräten günstig ist, kann bei 3.000 das teure sein. IoT-Preismodelle im Vergleich geht die Varianten durch. Schreiben Sie die Zahl für das dritte Jahr auf, auch wenn sie geraten ist. Eine geratene Zahl auf Papier wird korrigiert, eine geratene Zahl im Kopf nicht.
Schritt 5: Legen Sie fest, wer die Nutzer sind und was sie sehen
Trennen Sie die Leute, die die Anwendung bauen, von den Leuten, die sie nutzen. Bei TagoIO arbeiten die Entwickler in Admin: Geräte anlegen, Payload Parser schreiben, Dashboards bauen, Actions konfigurieren. Die Endnutzer, der Standortleiter aus Schritt 1, melden sich in einem TagoRUN-Portal unter Ihrer Marke an, im Web oder in der mobilen App, und sehen nur, was ihre Access Management Policy freigibt.
Schreiben Sie für jede Nutzerrolle auf, was sie sieht und was sie tun darf: welche Standorte, welche Dashboards, welche Alarme auf dem Handy und ob sie Schwellenwerte ändern kann oder nur lesen darf. Braucht eine Rolle Push-Benachrichtigungen auf der Baustelle, gehört die mobile App ab Tag eins zum Umfang, und das ändert den Aufbau der Dashboards.
Schritt 6: Listen Sie die Integrationen auf, die es geben muss
Die meisten IoT-Projekte enden in einem anderen System. Der Alarm muss zu einem Ticket werden. Die Tagessummen müssen im ERP landen. Notieren Sie jede Integration mit ihrer Richtung (eingehend oder ausgehend), ihrem Auslöser (bei Ereignis, nach Zeitplan) und ihrem Protokoll (Webhook, REST API, Dateiablage). Auf der Plattform wird daraus eine Action, die an einen Webhook sendet, oder eine geplante Analysis, die die externe API aufruft.
Eine fehlende Integration ist der häufigste Grund, warum ein fertiges Pilotprojekt nie in Produktion geht: Die Daten waren richtig, sie erreichten aber nie das System, das darauf reagiert.
Schritt 7: Schreiben Sie die Abnahmekriterien für das Pilotprojekt
Einigen Sie sich vor der Hardware darauf, was “das Pilotprojekt hat funktioniert” bedeutet. Verfügbarkeit der Datenlieferung pro Gerät. Alarmlatenz von Ereignis bis Benachrichtigung. Batterieverbrauch im Vergleich zur prognostizierten Laufzeit. Die Entscheidung aus Schritt 1, über eine festgelegte Anzahl von Wochen tatsächlich am Dashboard getroffen, von der benannten Person.
Jetzt aufgeschriebene Kriterien sind günstig. Kriterien, die nach einem halb gelungenen Pilotprojekt verhandelt werden, sind teuer, denn jeder Beteiligte erinnert sich an ein anderes Versprechen. Setzen Sie sie in den Projektumfang, neben den Namen der Person, die abnimmt.
Bilden Sie den Umfang auf Plattformobjekte ab, dann simulieren Sie das erste Gerät
Zu jeder Zeile des einseitigen Projektumfangs gibt es etwas, das Sie heute schon auf der Plattform bauen können, ohne einen Sensor in der Hand zu haben:
- Variablen und Einheiten (Schritt 2) werden ein Device mit benannten Variablen. Sein Connector oder Payload Parser dekodiert den Payload, den die infrage kommende Hardware senden wird.
- Standorte und Konnektivität (Schritt 3) werden das Network für das Gerät und die Tags, die Geräte nach Standort gruppieren.
- Nutzer und Ansichten (Schritt 5) werden Dashboards und eine Access Management Policy, die jedem TagoRUN-Nutzer nur seine Standorte zeigt.
- Integrationen (Schritt 6) werden Actions mit einer Bedingung und einem Webhook als Ziel oder eine geplante Analysis.
- Abnahmekriterien (Schritt 7) werden die Alarmschwellen und die Widgets, an denen Sie das Pilotprojekt messen.
Legen Sie dann ein Gerät an, nehmen Sie den Beispiel-Payload aus dem Datenblatt des infrage kommenden Sensors und senden Sie ihn über die API im Intervall aus Schritt 2. Innerhalb einer Stunde haben Sie ein Dashboard mit den Entscheidungsdaten, einen Alarm auf dem Handy über die TagoRUN-App und einen Webhook, der einen Testendpunkt aufruft. Sie wissen außerdem, ob der Payload die Variablen enthält, die Sie brauchen, ob sich das Intervall in einem Diagramm gut liest und ob der Endnutzer den Bildschirm versteht.
Erst jetzt bestellen Sie die Hardware. Sie kaufen nach einer Spezifikation, die das Team schon laufen gesehen hat, und wenn das erste echte Gerät der Simulation widerspricht, merken Sie es an Tag eins statt beim Rollout.
