# IoT-Plattform auswählen, ohne die Entscheidung zu verkomplizieren

> Warum Bewertungen von IoT-Plattformen bei Tabellen mit 80 Zeilen stecken bleiben, welche Entscheidungen sich kaum zurücknehmen lassen und wie ein zweiwöchiges Pilotprojekt mit echten Geräten die RFP-Runde ersetzt.

![IoT-Plattform auswählen, ohne die Entscheidung zu verkomplizieren](https://tago.io/og/de/blog/avoid-overcomplicating-your-iot-platform-choice.png)

Die meisten Teams beginnen die Bewertung einer IoT-Plattform vernünftig. Eine Shortlist mit drei oder vier Kandidaten, eine Tabelle und Anforderungen aus jedem Fachbereich: SSO und Audit-Logs, Alarmierung und Firmware-Verwaltung, ein Kostenmodell, ein Portal für Kunden. Das sieht nach Sorgfalt aus, und in den ersten zwei Wochen ist es das auch.

Dann hat die Tabelle 80 Zeilen. Jeder Anbieter erfüllt die meisten Punkte, denn jede ausgereifte Plattform kann Telemetrie speichern, ein Diagramm zeichnen und einen Alarm verschicken. Die verbleibenden Unterschiede stecken in Zeilen, die niemand bewerten kann, ohne das Produkt zu benutzen. Also plant das Team weitere Demos. Nach drei Monaten hat die Bewertung ein gewichtetes Punktemodell, vier Anbieterpräsentationen und kein einziges Gerät, das irgendwohin Daten sendet.

Die Komplexität hat zwei Quellen, und keine liegt bei den Anbietern. Die erste: Sie bewerten Funktionen, die Sie im ersten Jahr nicht einsetzen. Die zweite: Sie behandeln die Entscheidung als unumkehrbar, und dann wirkt jede Zeile so, als müsste sie richtig sein. Die meisten müssen es nicht. Nur wenige Punkte sind später schwer zu ändern. Alles andere ist Konfiguration, und für Konfiguration ist das Pilotprojekt da.

![Die Bewertung auf das reduzieren, was schwer umkehrbar ist: Eine Anforderungstabelle mit 80 Zeilen, in der jeder Anbieter 82 bis 91 Prozent erreicht, schrumpft auf die schwer umkehrbaren Fragen: Massenexport der Daten, Preise beim Volumen des dritten Jahres, ein Portal im eigenen Branding für Endnutzer, die Geräte, die Sie tatsächlich haben, und eigener Code innerhalb der Plattform. Am Ende steht ein zweiwöchiges Pilotprojekt mit echten Geräten](https://tago.io/images/blog/avoid-overcomplicating-your-iot-platform-choice/cut-evaluation-to-hard-to-reverse.svg)

## Anzeichen dafür, dass Sie es verkomplizieren

Einige Muster tauchen in fast jeder festgefahrenen Bewertung auf, die ich bei Systemintegratoren und OEM-Produktteams gesehen habe.

- Die Anforderungsliste enthält Zeilen für Funktionen, für die niemand einen Einsatzzweck in den nächsten zwölf Monaten nennen kann. Digitale Zwillinge stehen in der Tabelle, während die realen Geräte 40 LoRaWAN-Temperatursensoren in einem Lager sind.
- Jeder Anbieter erreicht zwischen 82 und 91 Prozent. Wenn die Spanne so schmal ist, messen Sie nur, wie gut jeder Anbieter Datenblätter schreibt.
- Niemand im Bewertungsteam war bei einem der Kandidaten länger als eine Stunde eingeloggt.
- Das Wort "zukunftssicher" steht im Begründungsdokument, und niemand kann die Zukunft benennen, gegen die es sichern soll.
- Es wird über eine zweite RFP-Runde diskutiert, die die Antworten aus der ersten "klarstellen" soll.
- Der Starttermin für das Pilotprojekt wurde mindestens zweimal verschoben.

Wenn zwei oder mehr davon zutreffen, hilft die Tabelle nicht mehr.

## Was wirklich unumkehrbar ist

Die nützliche Frage zu jeder Zeile ist nicht "kann die Plattform das", sondern "was kostet es uns in zwei Jahren, die Entscheidung zu ändern, wenn wir hier falsch liegen?" Die meisten Zeilen fallen bei diesem Test durch. Widget-Typen, Alarmkanäle, Berichtsformate, Benutzerrollen, Dashboard-Layouts und die ERP-Integration konfigurieren Sie immer wieder neu, solange Sie die Plattform nutzen. Ein Fehler bei der Auswahl kostet Sie später einen Nachmittag.

Für eine kleine Gruppe von Entscheidungen gilt das nicht, und genau dort ist die Zeit der Bewertung gut angelegt.

**Datenhoheit und Export.** Zwei Jahre Telemetrie sind das teuerste Gut im Projekt. Ob Sie diese Daten am Stück, in einem brauchbaren Format und ohne Support-Ticket herausbekommen, entscheidet, wie stark der Anbieter bei der Vertragsverlängerung dasteht. Prüfen Sie, wie der [Datenexport](https://docs.tago.io/docs/tagoio/devices/data-management/data-export) funktioniert, ob die API Rohzugriff auf alles gibt und wo die Daten liegen. Der [Beitrag zum Vendor Lock-in](https://tago.io/blog/vendor-lock-in-in-iot-platforms) beschreibt, was Sie testen sollten.

**Preisverhalten beim Volumen des dritten Jahres.** Der Preis bei 50 Geräten sagt nichts aus. Kalkulieren Sie die Rechnung für die Gerätezahl und die Nachrichtenrate, die Sie im dritten Jahr erwarten. Finden Sie heraus, welcher Zähler den Betrag bewegt: Geräte, Datenpunkte, Speicher, Nutzer oder etwas anderes. Zwei Plattformen, die heute gleich viel kosten, können bei wachsendem Volumen um den Faktor drei auseinanderliegen. Ein späterer Wechsel bedeutet, die Daten aus dem vorherigen Absatz zu migrieren. Der [Preisvergleich über drei Jahre](https://tago.io/blog/comparing-iot-platform-pricing-over-three-years) rechnet es vor.

**Wer Ihre Endnutzer sind.** Wenn nur Ihr eigenes Betriebsteam auf die Daten schaut, reicht die Admin-Konsole. Sind es Kunden, Mandanten oder Servicetechniker, die niemals die Standorte der anderen sehen dürfen, braucht die Plattform davor ein Portal im eigenen Branding mit Zugriffsregeln pro Nutzer. Das ist Architektur, keine Kosmetik. Bei TagoIO ist diese Schicht [TagoRUN](https://tago.io/run) mit den Richtlinien aus dem Access Management. Sie im Nachhinein selbst zu bauen ist ein Projekt, keine Einstellung.

**Die Geräte und Netzwerke, die Sie tatsächlich haben.** Nicht die, die Sie 2028 vielleicht hinzufügen. Besteht die Flotte aus LoRaWAN über einen bestimmten Network Server, aus Mobilfunkgeräten, die MQTT sprechen, oder aus einem alten Modbus-Gateway, muss die Plattform diese Payloads heute dekodieren.

**Schnittstellen für Integrationen.** Kann Ihr eigener Code in der Plattform laufen, wenn eine Regel dem Menü entwächst, und können externe Systeme über eine dokumentierte API in beide Richtungen kommunizieren? Das ist der Unterschied zwischen einer Plattform, die Sie erweitern, und einer, für die Sie Umwege bauen.

Das ist die ganze Liste. Wenn ein Kandidat sie besteht, sind die restlichen Zeilen Konfiguration, die Sie im Pilotprojekt prüfen. Konfiguration ist kein Grund, die Bewertung offen zu halten.

## Ersetzen Sie die Tabelle durch ein zweiwöchiges Pilotprojekt

Die Tabelle beantwortet Fragen durch Lesen. Das Pilotprojekt beantwortet sie durch Machen, und Machen geht schneller, sobald die schwer umkehrbaren Fragen geklärt sind. Das Format, das funktioniert, ist eng und zeitlich begrenzt: ein Anwendungsfall, der für das Geschäft zählt, zehn bis zwanzig echte Geräte aus Ihrer Flotte, ein Standort, eine Nutzergruppe und ein festes Enddatum in zwei Wochen. Schreiben Sie vor dem Start auf, was "funktioniert hat" bedeutet: Geräte, die dekodiert sind und Daten senden, ein Dashboard, das der vorgesehene Nutzer lesen kann, ein Alarm, der bei einer echten Bedingung auslöst, ein Export der gesammelten Daten, den Ihr Team öffnen kann.

Bei TagoIO laufen die zwei Wochen meist so ab. Tag eins und zwei: Geräte über einen Connector für Ihr Netzwerk hinzufügen, oder einen Payload Parser schreiben, wenn das Gerät nicht in der Liste steht. Tag drei bis fünf: das Dashboard mit den Standard-Widgets bauen und es dann in ein Blueprint Dashboard umwandeln, damit ein Layout für alle Geräte reicht. Woche zwei: eine Action, die den Alarm sendet, ein Analysis-Skript, falls die Logik mehr als einen Schwellenwert braucht, und ein TagoRUN-Nutzer, der sich anmeldet und nur seine eigenen Daten sieht. Am letzten Tag exportieren Sie die Daten und lesen die Rechnung.

In diesen zwei Wochen lernen Sie, was die Tabelle nicht sagen konnte: wie lange das Dekodieren eines neuen Geräts wirklich dauert, ob der vorgesehene Nutzer das Dashboard ohne Schulung versteht, ob sich die Preiszähler so bewegen, wie Sie es gerechnet haben, und wie die Plattform reagiert, wenn Ihr Analysis-Code um 2 Uhr nachts einen Fehler wirft. Der [Einkaufsleitfaden](https://tago.io/blog/iot-platform-buyers-guide) enthält die Fragen, die Sie Anbietern vor dieser Phase stellen sollten. Im Pilotprojekt hören Sie auf zu fragen und prüfen selbst.

## Wenn die richtige Antwort ein kleiner Test ist und keine weitere RFP-Runde

Manche Varianten dieser Entscheidung brauchen überhaupt keinen Beschaffungsprozess. Wenn Sie als Systemintegrator eine Plattform für Ihr eigenes Servicegeschäft auswählen oder als Produktteam im ersten Jahr einige hundert Geräte betreiben, kostet eine falsche Wahl eine Migration, die Sie in einem Quartal erledigen. In dieser Lage ist der teuerste Teil der Entscheidung die Zeit, die Sie darauf verwenden.

Ein kostenloses Konto oder ein kleiner Tarif bei zwei Kandidaten, die gleichen zehn Geräte an beiden und zwei Wochen echte Nutzung liefern eine klarere Antwort als eine dritte Runde Anbieterfragebögen. Der Eigenbau auf AWS IoT Core oder auf einem Open-Source-Stack ist für manche Teams eine legitime Antwort, und es gilt derselbe Test: Geräte anschließen und die Wochen bis zum funktionierenden Dashboard zählen.

Dann entscheiden Sie, und schreiben Sie auf, warum. Die Gründe, die in zwei Jahren zählen, sind die schwer umkehrbaren. Alles andere ändern Sie ohnehin mindestens zweimal.

## Ressourcen

- [IoT-Plattform-Einkaufsleitfaden: Fragen, die Sie vor der Entscheidung stellen sollten](https://tago.io/blog/iot-platform-buyers-guide)
- [Vendor Lock-in bei IoT-Plattformen](https://tago.io/blog/vendor-lock-in-in-iot-platforms)
- [IoT-Plattform-Preise über drei Jahre im Vergleich](https://tago.io/blog/comparing-iot-platform-pricing-over-three-years)
- [Fünf Schritte zu einer erfolgreichen IoT-Anwendung](https://tago.io/blog/steps-to-build)

[llms.txt](https://tago.io/llms.txt)