Network Equipment Asset Tracking: Fault Classification, Regional Transfer Locations, and POS Courier Management for IT Deployment

When Faulty Equipment Disappears Into the Region

Network equipment deployments across multiple states and hundreds of sites create an asset management problem that standard warehouse systems don't handle well: equipment is in five simultaneous states simultaneously. Some units are deployed at site. Some are in transit via Poslaju courier. Some are at regional warehouses as spare. Some have been returned from site as faulty and are waiting on the repair queue. Some have been sent back to KKH subcontractors for on-site servicing. And some are sitting in a batch that hasn't been staged yet.

Every one of those states represents a physical object that has value, represents a service liability, and represents a procurement decision. A Cisco 2901 HSEC that shows as "STOCK" when it's actually been sent out as a site deployment and never had its record updated is a ghost unit that will cause a false order when the stock count triggers a reorder threshold. A Fortigate that's been sitting in FAULTY status for 90 days without a FAULTY TICKET assigned to the repair queue is a unit that nobody is fixing because nobody has formal ownership of the resolution.

The PROJECT STOCK Field as the Operational Spine

PROJECT STOCK with 15 states — STOCK, SPARE, FAULTY, ITEM_RETURN, SPARE-RGS, STOCK-RGS, SPARE-KKH, STOCK-KKH, FAULTY-RGS, FAULTY-KKH, ITEM_RETURN-RGS, ITEM_RETURN-KKH, SITE, REPAIR, DISPOSE — is the operational taxonomy that eliminates ambiguity in equipment location and accountability.

The RGS/KKH suffixes are the accountability split. RGS is the primary deployment contractor. KKH subcontractors (Fiberlinks Resources, Duta Jasa) handle East Malaysia. An equipment record that says SPARE-KKH is physically in a KKH-controlled location and is KKH's responsibility to account for. FAULTY-KKH means the fault was identified at or by KKH, and the repair chain starts with them. Without this split, faulty equipment that crosses the KKH/RGS boundary disappears into a joint accountability problem that nobody resolves.

DISPOSE is the terminal state that removes equipment from the active inventory while maintaining the historical record. An ASR1002 that fails after a lightning strike at a remote Sarawak site may be worth shipping back for attempted repair or may be a write-off. The record staying alive in DISPOSE status means the asset number, serial number, and fault history are preserved for insurance, warranty, and lifecycle tracking purposes even after the physical unit is gone.

What Three Barcode Fields Accomplish

Serial Number, Asset Number, and POS Number (the Poslaju courier tracking number) as three separate barcode-scanned fields solve three distinct tracking problems that a single "tracking number" field cannot.

Serial Number ties the record to the manufacturer's identity for warranty tracking, firmware management, and EOL tracking. A Cisco 2901 with a serial number inside an active SmartNet contract has a warranty claim path. The same unit without a serial number in the record has no path.

Asset Number is the internal company identifier — the tag that appears in the internal CMDB and in the project billing records. The two numbers are different objects and cannot be treated interchangeably.

POS Number is the courier tracking number for the Poslaju shipment moving the unit from one location to another. This number is only relevant for the transit period, but it's critical during transit: if a unit doesn't arrive at the regional warehouse in Penang within the expected window, the POS number is what you use to track the shipment and determine whether it's delayed, misrouted, or lost. Without the POS number in the asset record, a missing shipment requires calling the courier with nothing but a rough ship date.

The FAULTY SELECT classification — Noisy Fan, Port Faulty, Hardisk Failure, Motherboard Faulty, Power Failure, Cannot Console/Webui, RAM Faulty, Fire/Burnt, Lightning Strike, Firmware, Natural Disaster, Accident, Vandalism — produces a fault taxonomy that drives repair routing decisions. A firmware fault goes to the technical team. A lightning strike goes to insurance. A vandalism case goes to the site security report and may require a police report number in the FAULTY TICKET field. The classification field makes the routing automatic rather than judgment-dependent at each fault event.