IoT Visibility without Capex Discipline

25.07.2026

6 min read

Visibility programmes often start as hardware pilots and end up as uncovered operational and licensing burdens. Buying devices without separate approvals for connectivity, platform and integration means scaling costs are financed from the operating budget. That’s why CIOs and CDOs in the DACH region need a Capex logic that cleanly separates ongoing costs from investment lines before rollout.

Key Takeaways

Split the four cost blocks. Hardware is only the Capex entry point; connectivity, platform and integration typically run as OPEX and grow with the fleet-either linearly or disproportionately.
Pilot proves feasibility. Proof-of-concept hardware in the field and a lack of overall TCO ownership create silos that slow scaling across plants and partners.
Make-or-buy shapes ownership. In-house builds tie up 18–24 months of capacity; the EU Data Act guarantees switching with at most two months’ notice and export obligations.
Three budget gates guide rollout. PoC, scaling decision and wave expansion require separate Capex and OPEX paths plus pre-agreed exit criteria.

Cost blocks: hardware, connectivity, platform, integration

Hardware is the visible entry point and often the only line item with a clear purchase order. Trackers, sensors and gateways appear in Capex requests and can be depreciated via fixed-asset accounting. The mistake begins when this block is treated as a proxy for the entire programme. Device prices do not cover data transmission, platform usage or integration with ERP, WMS or TMS.

Connectivity is the second block and structurally different. SIM tariffs, roaming profiles, eSIM management and data allowances flow through carrier contracts and are usually booked as OPEX. Price lists and contract models vary by country corridor, data volume and contract term. Deutsche Telekom’s IoT Business tariff family (as of the public tariff pages) lists, among others, IoT Business Classic from €1.43 per SIM per month with flexible data volume in Europe, IoT Business Data Best from €26.50 per data pool per month for up to 50 SIMs, and the LPWA tariff at a one-time €14.50 per SIM for ten years with 6.5 MB per month in Europe. 1NCE advertises its IoT Lifetime Flat at a one-time €12 for ten years of connectivity including 500 MB and 250 SMS; SIM hardware itself adds roughly €1 to €2.50 depending on type. Without these bandwidths and without the specific roaming and term conditions of your own corridor, the scaling calculation remains an estimate from the pilot month.

The platform block covers licences, user accounts, device management, rule sets and often usage-dependent data storage. Visibility and tracking platforms frequently bill by device count, events or API calls. An IoT Business News TCO framework summarised in March 2026 models this layer as cost per device-year, incorporating connectivity, platform, device management and support. Microsoft prices Azure IoT Central device-based in three standard tiers, scaled by message allowances from 400 to 30,000 messages per device per month. What is unremarkable in a pilot with a handful of assets grows linearly or disproportionately with the fleet.

Integration is the block Capex requests most often underestimate. Interfaces to legacy and transport systems, master-data maintenance, event logic and middleware operation generate both one-off and recurring costs. Internal staff capacity and external system houses rarely appear on the same approval line as the devices. Treating integration as an afterthought later produces maintenance backlogs and shadow budgets in the business units.

Pilot Pitfalls and Scaling Roadblocks

Teams often market the pilot as a technical test while misinterpreting it as a business decision. A proof of concept with a limited number of assets and an accompanying project team demonstrates functionality-not operational maturity. Success in the pilot merely means that sensors and dashboards deliver data under controlled conditions. For network expansion, binding criteria for data quality, alarm accuracy, and process integration are then missing.

A typical pitfall blends pilot hardware with the target architecture. Devices from the PoC remain in the field even though tariffs, firmware, and platform contracts are not approved for broad deployment. This creates isolated islands with inconsistent support paths and non-uniform life cycles. The scaling roadblock kicks in as soon as IT and the business unit operate in parallel-and no one owns the total cost of ownership.

A second roadblock lies in the data pipeline. Visibility generates volumes of events that end up in analytics, rule sets, and archiving. Without a clear data owner and an operational model for rule maintenance, manual rework grows with every additional corridor. The organization only notices this when the pilot is expanded to multiple plants or logistics partners.

Build vs. Buy for Tracking Platforms

The build-vs-buy decision for tracking platforms is not just a technology choice. In-house development or heavily customized platforms promise control over data models and integration interfaces. Yet they tie up developer capacity, security reviews, and release management for years. Particle estimates the typical in-house path to market readiness at roughly 18 to 24 months and points to indirect costs-security, change management, and time-to-market-that are often omitted from early TCO spreadsheets. For many industrial and retail companies, the bottleneck lies in the ability to manage platform operations and device fleets in parallel. Sensor technology is usually sufficiently available.

Buy options shift complexity into the contract. License models, exit clauses, data export, and SLA definitions determine whether a vendor switch remains feasible later on. Since September 2025, the EU Data Act’s switching provisions for data-processing services-including SaaS and PaaS-apply. Customers can demand a switch with no more than two months’ notice. Providers must supply exportable data and digital assets in common formats. Switching fees are waived after the transition phase beginning January 2027. It remains critical to separate device hardware from the software platform: a bundled package may lower upfront capex but narrow the opex path.

A pragmatic middle ground is a standard platform with clearly defined in-house contributions to the integration layer. The core platform stays in vendor mode, while event logic and system integration are managed internally or via a systems integrator. What matters is that ownership for master data, alarm rules, and cost centers is assigned before rollout. Otherwise, responsibility bounces between IT, logistics, and procurement.

Budget Gates from Proof of Concept to Network

Capex discipline needs gates that act as financial approvals. Milestones steer the timeline; approvals steer the budget. The first gate checks whether the PoC addresses a defined business problem with measurable process impact. Without target metrics for delivery reliability, search times, shrinkage, or transport deviations, visibility remains a technical project. Approval here means: limited budget, limited asset count, fixed end date.

The second gate separates pilot completion from scaling decisions. At this point, hardware, connectivity, platform, and integration must each come with their own cost paths. OPEX implications for the next budget years belong in the same decision document block as the device investment. IoT and OT programs must be approved like IT investments, with visible OPEX implications. The TCO framework-cost per device-year with separate capex and opex layers-remains the robust logic for the steering committee.

The third gate governs network expansion in waves. Each wave requires a post-mortem of the previous one: actual device failures, tariff deviations, integration effort, and data quality. Without this gate, the rollout becomes an extension of the pilot with a growing cost base. CIOs should explicitly verify whether the original business-case assumption still holds or whether the scope needs adjustment.

Termination criteria that take effect in the steering committee

Termination criteria only come into play if the steering committee adopts them before the first device purchase. Technical criteria relate to data availability, false-alarm rate, and integration stability under load. Economic criteria concern deviations from planned connectivity and platform costs as well as the integration effort per connected system. Organizational criteria apply when departments fail to assume process responsibility for alarms and exception handling.

The steering committee needs thresholds that automatically trigger a pause without forcing prolonged debate. Meaningful anchor points include a predefined deviation from the planned OPEX trajectory, lack of process adoption after a defined stabilization phase, or the absence of data-export capability in the platform contract. The EU Data Act supports the latter with concrete switching and export obligations.

Equally important is the separation of project termination and continued device operation. A halted rollout can leave a limited installed base in the field if support and cost center are clarified. Uncontrolled continuation without a program status, by contrast, creates silent obligations in licenses and tariffs. The steering committee should therefore treat termination, freeze, and orderly decommissioning as three distinct decisions.

Visibility without capex discipline does not create transparency in the supply chain. It creates opacity in the IT budget. If hardware, connectivity, platform, and integration are separated before the PoC, only what is economically and organizationally viable will scale. The consequence for CIOs and CDOs: manage visibility programs like investment initiatives with OPEX implications-not like device projects with dashboard demos.

Frequently Asked Questions

How do the four cost blocks end up in a single approval?

Hardware remains part of the CapEx application with depreciation handled through the asset accounting system. Connectivity and platform licenses are included as OPEX paths in the same decision document, including tariff bandwidths and costs per device-year. Integration with internal capacity and system-house effort receives its own line item. This ensures device procurement does not silently scale from the operating budget.

Can PoC hardware continue operating in the target network?

Continuing operation requires approved tariffs, firmware, and platform contracts for broad deployment. Deviations create silos with separate support paths and inconsistent life cycles. If terminated or frozen, limited inventory may remain in the field only with clarified support and a fixed cost center.

What exactly does the EU Data Act change for platform contracts?

Since September 2025, customers can demand the transfer of SaaS and PaaS services with a maximum of two months’ notice. Providers must supply exportable data and digital assets in standard formats. Transfer fees will be eliminated after the transition period beginning January 2027. This supports termination criteria tied to data export capability and keeps device hardware verifiably separate from platform exit.

When does termination apply instead of freezing, or orderly decommissioning?

Termination halts the program when technical, economic, or organizational thresholds are breached-such as OPEX deviations, lack of process usage, or missing export capability. Freezing maintains the existing inventory in a controlled state, while decommissioning systematically clears field assets and contracts. The steering committee treats the three options as separate decisions so that license and tariff obligations remain visible and traceable after the stop.