Definition
BI (Business Intelligence) refers to a system that collects, analyzes, and visualizes business data. Monitoring data from the Device Management Platform can be integrated with Grafana, custom-built BI, or Tableau, Power BI to support operations and business decision-making.
Value in Device Management
BI can perform multidimensional analysis on device Telemetry data, alarm statistics, OTA success rates, device health metrics, and other indicators to generate reports on device distribution, fault trends, and operational efficiency. It supports drilling down by product, region, and time dimensions, helping managers identify high-failure devices, optimize maintenance strategies, and assess supplier quality.
Data Flow and Integration
The Device Management Platform typically pushes data to BI systems through Event Stream events, data exports, or APIs. BI tools connect to Time-Series DB time-series databases or data warehouses, perform ETL processing, and build data marts to support dashboards, reports, and self-service analysis.
Typical Applications
Including dashboards for device online rate, fault rate trends, OTA upgrade success rate, device lifecycle distribution, regional maintenance work order statistics, etc. Combined with the Report & Analytics reporting and analysis capabilities, BI provides data-driven decision support for device operations.
What a metric passes through from a point to a report
In device management, business intelligence means summarizing telemetry, events, and job results that have already been stored, under one definition, to answer how a set of devices behaved over a period. It does not answer what the raw value of one device is at this moment. From a point to a metric there must be time alignment, unit conversion, a rule for missing values, and dimensions. Dimensions are usually product, firmware version, region, and group. Without those agreements, one chart adds second-level samples and hourly totals together. BI fits when data is already stored in a stable way and the question needs a side-by-side comparison. To investigate one device on site, go back to the raw curve in the device detail.
Before use, confirm the metric’s statistical window and time zone. If a daily metric is cut at the server’s local midnight, the “day” of devices across regions will not match the site shift. Alarm counts must say whether they count occurrence or recovery. Upgrade results must say whether the denominator is devices in the job or devices that actually received the package. Once a definition is published, later reports should keep it, rather than each board writing its own query. Split from the dashboard, the dashboard emphasizes the current situation and BI emphasizes comparison that can be traced back. Binding a BI query directly to the live stream on the access layer slows aggregation once the device count rises.
Treating an instantaneous value as a period conclusion
A likely mistake is to let the last telemetry stand for the whole day’s state. A device offline at noon and recovered in the evening shows normal on the last point, and a daily report built from the “current value” erases the interruption during the day. Another mistake is to ignore sparse sampling. A sensor reports once an hour, but the chart connects points by the minute, and the blank in between is drawn as steady. Mixed units are equally common. The same property is sometimes degrees Celsius and sometimes tenths of a degree, and the extremes after aggregation drift away from the site. If a filter is written on the chart and not in the dataset note, another person opening the report will not get the same number.
“No data” and “the data is zero” must be kept apart. Filling zeros during a communication break understates energy and output. Carrying the previous value forward draws a stop as continued running. Neither fill should hide in a default with no explanation. Live alarm counts in device monitoring also cannot be compared directly with historical alarm counts in BI, unless both sides use the same rules for merging chatter, acknowledgement, and clearing. When the numbers differ, check the window, the time zone, and the filter before suspecting the device itself.
How to compare history after a definition changes
Once a metric is cited, the way it is calculated becomes part of that report. If alarms later change from counting occurrence to counting recovery, if missing samples during offline are changed to filled zeros, or if devices not yet activated are removed from the denominator, the new number cannot be compared up or down with the old chart. Each change of definition should leave an effective time, and the old period should still be recomputable under the old definition, or a date should be declared after which earlier charts are withdrawn. Quietly editing the query makes screenshots and meeting notes disagree, and people will think the site got better or worse. Adding or removing a dimension works the same way. After a new region filter, a lower total may only mean a smaller scope, not fewer devices.
If self-service analysis lets each person save their own filter, a public metric and a private filter need different names, so two reports both called online status are not discussing different sets of devices. The unit, sample interval, and missing-value rule of the raw point should be written in the dataset note, not only in the memory of the person who drew the chart. When the same metric disagrees in two places, compare window, time zone, filter, and definition version first, then decide whether to run it again. BI is credible when those constraints can be reviewed. When the constraints cannot be stated, it is another attractive chart and cannot be used to overrule the site record. A review should also keep the filter and the definition version used at the time. Otherwise there is no way later to reproduce which devices and which period produced the number on that chart, and the discussion falls back to each person holding a different screenshot.