Definition
FinOps (Financial Operations, cloud financial operations) is a set of practices that combines financial accountability with the use of cloud/IoT resources, aimed at optimizing costs and improving resource efficiency through data-driven decisions. In the ICMP scenario, FinOps works with TCO (Total Cost of Ownership), Usage Analytics (usage analysis), and Volume Discount (tiered discounts) to help customers achieve visibility, control, and optimization of IoT connection costs.
Core Principles
FinOps emphasizes: Team Collaboration — technology, finance, and business jointly participate in cost decisions; Data-Driven Approach — analysis based on Usage Analytics, CDR, and billing data; Continuous Optimization — establish cost visibility, set budgets, and conduct regular reviews. IoT connection costs include SIM monthly fees, data usage fees, roaming fees, platform service fees, etc. FinOps helps customers identify high-cost areas, optimize data plan selection, and negotiate Volume Discounts.
Application in ICMP
SimtoLink ICMP provides the data foundation for FinOps: Usage Analytics usage analysis, KPI Dashboard dashboard, Unified Invoice unified billing, TCO analysis tools. Customers can view cost distribution by card, region, or project; identify idle cards, abnormal consumption, and high roaming costs; evaluate the cost-effectiveness of data plans like Pooled Data and Shared Bucket; and optimize procurement strategies by combining Volume Discount and Tiered Pricing.
Best Practices
FinOps best practices include: establishing cost attribution (by project, department, product); setting budgets and alerts; regularly reviewing idle resources and abnormal usage; using Volume Discount and long-term contracts to reduce costs; optimizing Roaming Policy and PLMN Selection to lower roaming expenses. The ICMP platform provides data and tools to support customers in implementing FinOps practices.
Connectivity cost components financial operations must be able to see
Connectivity cost is not the total on one invoice. It is several kinds of spend that can be split apart: recurring fees for SIMs or profiles, local usage fees, roaming usage fees, platform service fees, and resources that have been committed but not yet used. Financial operations needs the quantity and amount of these classes in the same billing period, and a path back to the SIM, project, or department. Without the split, there is nothing to optimize, because it is unclear whether to reduce SIMs, reduce roaming, or change the plan.
The data comes from usage, detail records, and invoices that have been confirmed, not from an estimate on the device side. An estimate can remind people mid-month. It cannot replace month-end close. Cost allocation has to be set before usage is generated: which project this SIM belongs to. Allocating afterward by share of traffic produces only an approximation, and it cannot explain why one device was expensive. Idle SIMs have to be visible on their own. They have a recurring fee and no usage, and they disappear from a report that looks only at the price per unit of traffic.
Data conditions required before budgets and allocation can be applied
A budget can be applied only when every cost object has a stable identifier, usage can be accumulated inside the billing period, and the price version is unchanged in that period or the point of change is recorded. The object can be a project, a product line, or a customer contract. It cannot be three overlapping definitions producing three “official” budgets at once. Alert thresholds should sit on the object, for example notifying when one project’s roaming charges cross a band of that month’s budget, rather than noticing only when the company total is over.
Allocation data should use the same identifier for the same SIM as usage analytics. If a SIM changes project mid-way, record the effective date. Charges before that date stay with the original project. When this is read together with total cost of ownership, keep non-connectivity costs such as device installation and field maintenance separate, so labor is not folded into the traffic unit price. When currencies differ, collect in the original currency first, then convert at a locked rate. Each report must not take the price of the day on its own. Without these conditions, a budget comparison is only two summary tables that cannot be compared.
Watching only the invoice total and missing idle SIMs and the roaming mix
A falling total is not necessarily better efficiency. Business volume may have fallen. A rising total is not necessarily waste. Devices may have gone into service as planned. Looking only at the total treats those two cases as the same conclusion. A more common structural skew is that roaming charges on a few SIMs are most of the amount, while local usage on the rest is cheap. The average shows “cost per SIM is normal,” and the roaming SIMs stay on a high-price network the whole time.
Idle SIMs skew the other way. They pull average traffic down, which looks like the plan is too large, so capacity is cut. SIMs that are busy then run short, and the idle SIMs are still there. List SIMs with zero usage that still incur a monthly fee, then decide whether to suspend, terminate, or switch them to charging on first use. Another error is judging success by the discount on the list price, without checking whether the usage the discount applies to has actually occurred. Unused committed volume does not become a saving because the discount rate looks good. A review should give usage, amount, idle count, and roaming share together, and name the price version. Do not summarize whether the whole connectivity spend is reasonable with one percentage. The data itself has not been split yet.
A mid-month view and a month-end view should say whether the data is complete. If late roaming detail records are missing mid-month, the roaming share is understated and the budget alert does not fire. When the detail records arrive, the amount jumps, which looks like sudden waste at month end. The report should show “open” or “closed.” An open figure cannot be used to judge savings. List SIMs with no allocation on their own. Do not spread them evenly across projects by headcount. In a month when the price version changes, split the period before and after the change. Otherwise it is impossible to tell whether the amount moved because of usage or because of the new unit price. A review meeting should discuss only figures that can be traced back to detail records. Estimates are reminders only.