IoT-Sichtbarkeit ohne Capex-Disziplin

25.07.2026

6 Min. Lesezeit

Visibility-Programme starten oft als Pilot mit Hardware und enden als ungedeckte Betriebs- und Lizenzlast. Wer Geräte kauft ohne getrennte Freigabe für Konnektivität, Plattform und Integration, finanziert Skalierung aus dem Betriebsbudget. CIOs und CDOs im DACH-Raum brauchen deshalb vor dem Rollout eine Capex-Logik, die laufende Kosten und Investitionslinien sauber trennt.

Das Wichtigste in Kürze

Vier Kostenblöcke trennen. Hardware ist nur der Capex-Einstieg; Konnektivität, Plattform und Integration laufen oft als OPEX und wachsen mit der Flotte linear oder überproportional.
Pilot belegt Funktionsfähigkeit. PoC-Hardware im Feld und fehlende Gesamt-TCO-Verantwortung erzeugen Inseln und bremsen die Skalierung über Werke und Partner.
Make-or-buy steuert Ownership. Eigenbau bindet 18 bis 24 Monate Kapazität; der EU Data Act sichert Wechsel mit höchstens zwei Monaten Vorlauf und Exportpflichten.
Drei Budget-Gates steuern den Rollout. PoC, Skalierungsentscheidung und Wellenausbau brauchen getrennte Capex- und OPEX-Pfade sowie vorab verabschiedete Abbruchkriterien.

VerwandtGeopolitik sprengt Supply Chains: CIOs unter Druck

Kostenblöcke: Hardware, Konnektivität, Plattform, Integration

Die Hardware ist der sichtbare Einstieg und oft der einzige Posten mit klarer Bestellposition. Tracker, Sensoren und Gateways erscheinen in Capex-Anträgen und lassen sich über die Anlagenbuchhaltung abschreiben. Der Fehler beginnt dort, wo dieser Block als Proxy für das Gesamtprogramm gelesen wird. Gerätepreise decken weder Datenübertragung noch Plattformnutzung noch die Anbindung an ERP, WMS oder TMS ab.

Konnektivität ist der zweite Block und strukturell anders gelagert. SIM-Tarife, Roaming-Profile, eSIM-Management und Datenkontingente laufen über Carrier-Verträge und häufig über OPEX. Preislisten und Vertragsmodelle unterscheiden sich nach Länderkorridor, Datenvolumen und Vertragslaufzeit. Die Deutsche Telekom listet in der IoT-Business-Tariffamilie (Stand der öffentlichen Tarifseiten) unter anderem IoT Business Classic ab 1,43 Euro monatlich je SIM mit flexiblem Datenvolumen in Europa, IoT Business Data Best ab 26,50 Euro monatlich je Datenpool für bis zu 50 SIM sowie den LPWA-Tarif mit einmalig 14,50 Euro für zehn Jahre je SIM und 6,5 MB monatlich in Europa. 1NCE bewirbt die IoT Lifetime Flat mit einmalig 12 Euro für zehn Jahre Konnektivität inklusive 500 MB und 250 SMS; die SIM-Hardware kommt je nach Typ mit etwa 1 bis 2,50 Euro hinzu. Ohne solche Bandbreiten und ohne die konkreten Roaming- und Laufzeitbedingungen des eigenen Korridors bleibt die Skalierungsrechnung eine Schätzung aus dem Pilotmonat.

Der Plattformblock umfasst Lizenzen, Nutzerkonten, Geräteverwaltung, Regelwerke und oft nutzungsabhängige Datenhaltung. Visibility- und Tracking-Plattformen rechnen häufig über Geräteanzahl, Events oder API-Calls ab. Ein TCO-Rahmen, den IoT Business News im März 2026 zusammenfasst, modelliert diese Schicht als Kosten pro Gerätejahr. Darin fließen Konnektivität, Plattform, Geräteverwaltung und Support ein. Microsoft rechnet Azure IoT Central gerätebasiert in drei Standard-Stufen ab, gestaffelt nach Nachrichtenkontingenten von 400 bis 30.000 Nachrichten pro Gerät und Monat. Was im Pilot mit wenigen Assets unauffällig bleibt, wächst mit der Flotte linear oder überproportional.

Integration ist der Block, den Capex-Anträge am häufigsten unterschätzen. Schnittstellen zu Bestands- und Transportsystemen, Stammdatenpflege, Ereignislogik und Betrieb der Middleware erzeugen einmalige und laufende Kosten. Interne Personalkapazität und externe Systemhäuser landen selten in derselben Freigabezeile wie die Geräte. Wer Integration als Nebenposition behandelt, produziert später Wartungsrückstände und Schattenbudgets in den Fachbereichen.

Pilot-Fallen und Skalierungsbremsen

Teams verkaufen den Pilot oft als Techniktest und missverstehen ihn als Geschäftsentscheidung. Ein Proof of Concept mit begrenzter Asset-Zahl und begleitender Projektmannschaft zeigt Funktionsfähigkeit, nicht Betriebsreife. Erfolg im Pilot bedeutet lediglich, dass Sensorik und Dashboard unter kontrollierten Bedingungen Daten liefern. Für den Netzausbau fehlen dann Verbindlichkeitskriterien zu Datenqualität, Alarmgenauigkeit und Prozessbindung.

Eine typische Falle vermischt Pilot-Hardware und Zielarchitektur. Geräte aus dem PoC bleiben im Feld, obwohl Tarif, Firmware und Plattformvertrag nicht für den Breiteneinsatz freigegeben sind. So entstehen Inseln mit abweichenden Supportwegen und uneinheitlichen Lebenszyklen. Die Skalierungsbremse greift, sobald IT und Fachbereich parallel betreiben und keiner den Gesamt-TCO verantwortet.

Eine zweite Bremse liegt in der Datenpipeline. Visibility erzeugt Ereignismengen, die in Analytics, Regelwerken und Archivierung landen. Ohne klaren Datenbesitzer und ohne Betriebsmodell für Regelpflege wächst der manuelle Nachbearbeitungsaufwand mit jedem zusätzlichen Korridor. Die Organisation merkt das erst, wenn der Pilot in mehrere Werke oder Logistikpartner erweitert wird.

Make-or-buy bei Tracking-Plattformen

Die Make-or-buy-Frage bei Tracking-Plattformen ist keine reine Technologieentscheidung. Eigenbau oder stark angepasste Plattformen versprechen Kontrolle über Datenmodell und Integrationsschnittstellen. Sie binden jedoch Entwicklerkapazität, Security-Review und Release-Management über Jahre. Particle beschreibt den typischen Inhouse-Pfad bis zur Marktreife mit etwa 18 bis 24 Monaten und verweist auf indirekte Kosten für Security, Change Management und Time-to-Market, die in frühen TCO-Tabellen oft fehlen. Für viele Industrie- und Handelsunternehmen liegt der Engpass in der Fähigkeit, Plattformbetrieb und Geräteflotte parallel zu steuern. Sensorik ist dort meist ausreichend verfügbar.

Buy-Optionen verschieben Komplexität in den Vertrag. Lizenzmodelle, Exit-Klauseln, Datenexport und SLA-Definitionen bestimmen, ob der Anbieterwechsel später möglich bleibt. Seit September 2025 gelten die Switching-Vorgaben des EU Data Act für Datenverarbeitungsdienste einschließlich SaaS und PaaS. Kunden können mit höchstens zwei Monaten Vorlauf den Wechsel verlangen. Anbieter müssen exportierbare Daten und digitale Assets in gängigen Formaten bereitstellen. Wechselentgelte entfallen nach der Übergangsphase ab Januar 2027. Wichtig bleibt die Trennung von Geräte-Hardware und Softwareplattform: ein gekoppeltes Bundle kann den Capex-Einstieg verbilligen und den OPEX-Pfad verengen.

Eine pragmatische Zwischenform ist die Standardplattform mit klar begrenzten Eigenanteilen an der Integrationsebene. Dabei bleibt die Kernplattform im Lieferantenmodell, während Ereignislogik und Systemanbindung intern oder über einen Systemintegrator gesteuert werden. Entscheidend ist, dass Ownership für Stammdaten, Alarmregeln und Kostenstellen vor dem Rollout benannt wird. Sonst wandert die Verantwortung zwischen IT, Logistik und Einkauf hin und her.

Budget-Gates vom Proof of Concept zum Netz

Capex-Disziplin braucht Gates, die Finanzfreigaben sind. Meilensteine steuern den Zeitplan, Freigaben das Budget. Das erste Gate prüft, ob der PoC ein definiertes Geschäftsproblem mit messbarer Prozesswirkung adressiert. Ohne Zielgrößen zu Lieferzuverlässigkeit, Suchzeiten, Schwund oder Transportabweichungen bleibt Visibility ein Technikprojekt. Freigabe bedeutet hier: begrenztes Budget, begrenzte Asset-Zahl, festes Enddatum.

Das zweite Gate trennt Pilotabschluss und Skalierungsentscheidung. Hier müssen Hardware, Konnektivität, Plattform und Integration jeweils mit eigenen Kostenpfaden vorliegen. OPEX-Folgen für die nächsten Budgetjahre gehören in denselben Entscheidungsunterlagenblock wie die Geräteinvestition. IoT- und OT-Programme sind analog zu IT-Investitionen mit sichtbaren OPEX-Folgen freizugeben. Der TCO-Rahmen mit Kosten pro Gerätejahr und getrennten Capex- und OPEX-Schichten bleibt die belastbare Arbeitslogik für den Lenkungskreis.

Das dritte Gate gilt dem Netzausbau in Wellen. Jede Welle braucht eine Nachkalkulation der vorherigen: tatsächliche Geräteausfälle, Tarifabweichungen, Integrationsaufwand und Datenqualität. Ohne dieses Gate wird der Rollout zur Fortschreibung des Piloten mit wachsender Kostenbasis. CIOs sollten hier explizit prüfen, ob die ursprüngliche Business-Case-Annahme noch trägt oder ob der Scope zu korrigieren ist.

Abbruchkriterien die im Lenkungskreis greifen

Abbruchkriterien wirken nur, wenn der Lenkungskreis sie vor dem ersten Geräteinkauf verabschiedet. Technische Kriterien betreffen Datenverfügbarkeit, Fehlalarmrate und Integrationsstabilität unter Last. Wirtschaftliche Kriterien betreffen die Abweichung von geplanten Konnektivitäts- und Plattformkosten sowie den Integrationsaufwand pro angebundenem System. Organisatorische Kriterien greifen, wenn Fachbereiche keine Prozessverantwortung für Alarme und Ausnahmebehandlung übernehmen.

Der Lenkungskreis braucht Schwellen, die automatisch eine Pause auslösen und keine längere Debatte erzwingen. Sinnvolle Ankerpunkte sind eine vorab festgelegte Abweichung vom geplanten OPEX-Pfad, ausbleibende Prozessnutzung nach einer definierten Stabilisierungsphase oder fehlende Datenexportfähigkeit im Plattformvertrag. Letzteres stützt der EU Data Act mit konkreten Switching- und Exportpflichten.

Ebenso wichtig ist die Trennung von Projektabbruch und Geräteweiterbetrieb. Ein gestoppter Rollout kann einen begrenzten Bestand im Feld belassen, wenn Support und Kostenstelle geklärt sind. Unkontrolliertes Weiterlaufen ohne Programmstatus erzeugt dagegen stille Verpflichtungen in Lizenzen und Tarifen. Der Lenkungskreis sollte deshalb Abbruch, Einfrieren und geordneten Rückbau als drei unterschiedliche Entscheidungen führen.

Visibility ohne Capex-Disziplin erzeugt keine Transparenz in der Supply Chain. Sie erzeugt Intransparenz im IT-Budget. Wer Hardware, Konnektivität, Plattform und Integration vor dem PoC trennt, skaliert nur das, was betriebswirtschaftlich und organisatorisch tragfähig ist. Die Konsequenz für CIO und CDO: Visibility-Programme wie Investitionsvorhaben mit OPEX-Folgen steuern, nicht wie Geräteprojekte mit Dashboard-Demo.

Häufig gestellte Fragen

Wie landen die vier Kostenblöcke in einer gemeinsamen Freigabe?

Hardware bleibt der Capex-Antrag mit Abschreibung über die Anlagenbuchhaltung. Konnektivität und Plattformlizenzen gehören als OPEX-Pfade in dieselbe Entscheidungsunterlage, inklusive Tarifbandbreiten und Kosten pro Gerätejahr. Integration mit interner Kapazität und Systemhausaufwand erhält eine eigene Freigabezeile. So finanziert der Geräteinkauf die Skalierung nicht still aus dem Betriebsbudget.

Darf PoC-Hardware im Zielnetz weiterlaufen?

Weiterbetrieb setzt freigegebene Tarife, Firmware und Plattformverträge für den Breiteneinsatz voraus. Abweichungen erzeugen Inseln mit getrennten Supportwegen und uneinheitlichen Lebenszyklen. Bei Abbruch oder Einfrieren bleibt ein begrenzter Bestand nur mit geklärtem Support und fester Kostenstelle im Feld.

Was ändert der EU Data Act am Plattformvertrag konkret?

Seit September 2025 können Kunden den Wechsel von SaaS- und PaaS-Diensten mit höchstens zwei Monaten Vorlauf verlangen. Anbieter müssen exportierbare Daten und digitale Assets in gängigen Formaten bereitstellen. Wechselentgelte entfallen nach der Übergangsphase ab Januar 2027. Das stützt Abbruchkriterien zur Datenexportfähigkeit und hält Geräte-Hardware vom Plattformexit prüfbar getrennt.

Wann greift Abbruch statt Einfrieren oder geordnetem Rückbau?

Abbruch stoppt das Programm, wenn technische, wirtschaftliche oder organisatorische Schwellen verletzt sind – etwa OPEX-Abweichung, ausbleibende Prozessnutzung oder fehlende Exportfähigkeit. Einfrieren hält den Bestand kontrolliert, Rückbau räumt Feld und Verträge geordnet ab. Der Lenkungskreis führt die drei Optionen als getrennte Entscheidungen, damit Lizenz- und Tarifverpflichtungen nach dem Stopp sichtbar und zuordenbar bleiben.

Weiterlesen auf Digital Chiefs

Digital ChiefsContainer-Tracking liefert Daten, keine Steuerung Digital ChiefsVerwaiste Zugänge: die stille Cyber-Lücke Digital ChiefsWarum die Cloud-Rechnung nie kleiner wird

Mehr aus dem MBF Media Netzwerk