“Management should already be looking to new business models that reduce the risk of stranded assets destroying shareholder value, In future, capital allocation should emphasise shareholder returns rather than investing for growth.”
The inventory system is at the heart of an OSS. Let’s have a quick look at the downstream impacts of a stranded asset (ie a device or service or other asset that doesn’t correlate between what is recorded in the inventory system and what is in the field):
- Assets are tightly linked with your BSS’s billing system, so any customer asset that is wrongly listed in your OSS but doesn’t exist in the network will cause inadvertent charges to the customer
- Inadvertent charges will generate extra support effort and a degraded customer experience
- Any asset that is in the network but not listed in the inventory will not be an available resource for provisioning by the planning department, thus reducing design integrity
- If surrounding devices have reached utilisation thresholds then new equipment expenditure will be required unnecessarily. I have heard of instances where tens of millions of dollars of stranded assets were powered up but not identified for use so network expansion required significant expenditure that wouldn’t have otherwise been needed
- Ongoing vendor maintenance fees are being charged on kit that is not being used
- Designs reach field operators that don’t match the true situation in the field, causing designs to be sent back for revision, costing the CSP more designer effort and delaying the customer commission date
- If devices are in the network but not being monitored, there are possibly faults that are going undetected and unmanaged, possibly even propagating spurious problems into the visible parts of the network
- Assets that are chargeable to the customer but not in your inventory are also unlikely to be billed, leading to revenue leakage
Identification of stranded assets requires carefully thought-out continual improvement processes through creation of a feedback loop. Some of these processes could be automated (eg network discovery, reconciliation between multiple data sources, etc) whilst others could be manual (eg field work force providing updates from the field each time they visit an asset).
Stranded assets usually stem from gaps in process, allowing devices to be installed without being logged for management by your OSS, or sometimes from lifecycle management of an asset (eg replacement of faulty kit with spares and not then managed after remedy).
The costs of reconciliation and improvement can usually be justified by the results, which include:
- Better CAPEX efficiency (ie billing of all devices)
- Better OPEX efficiency (ie reduction in re-work)
- Customer delivery times and fault resolution times are reduced
What techniques have you used to overcome data integrity problems on your OctopOSS?
Nice Post Ryan, dont forget that the other best things you get from Asset knowledge is good planning and driving value.