Koddex Beyond R&D: Why Hardware Fleet Management Belongs in the Engineering Graph
Most hardware companies operate two completely disconnected worlds. The R&D world owns the design intent: requirements, CAD, BOM, verification. The operations world owns the deployed reality: which serial number is at which customer, which firmware version is running, which spare part needs reordering. Between them sits a chasm full of CSV exports and quarterly reconciliations.
The Cost of the Chasm
The chasm has a price. ARC Advisory Group reported in October 2025 that hardware OEMs operating at fleet scale (more than 1,000 deployed units) lose between 4 and 7 percent of annual revenue to misrouted spare parts, incorrect firmware updates, and warranty claims tied to the wrong component revision. A €200M robotics company is leaving €8M to €14M on the table every year because its R&D graph and its fleet database do not talk.
The customer success team feels this every day. A field engineer dispatches to fix a malfunction. They arrive with the spare part listed in the CRM. The deployed unit, which shipped six months later than expected, actually contains the v2.4 valve, not the v2.2 listed in the system. The visit fails. The customer is unhappy. The R&D team had updated the BOM. The fleet database never received the update.
Why Two Systems Always Diverge
The technical reason for the divergence is that R&D systems and fleet systems were built to optimize different concerns. PLM optimizes for design intent and change control. ERP and field service systems optimize for transaction volume and route planning. Bridging them with batch synchronization is a maintenance nightmare. Bridging them with real-time integration is a multi-year IT project that usually delivers a fragile result.
The cultural reason is just as real. R&D treats fleet data as someone else's problem. Operations treats R&D data as untrustworthy. The reconciliation work falls on whichever junior engineer is least able to refuse it.
The Connected Graph Approach
A graph-based engineering platform changes the model. Each deployed unit is a node in the same graph as the design. The unit node references the design node it was built from, plus the actual component instances installed (with their specific revisions, serial numbers, and supplier batches). The customer node connects to the unit node. The CSM ticket connects to the unit, which connects to the design, which connects to the requirement that justified the affected component.
When a CSM opens a ticket, the engineering team can see the exact configuration of the affected unit without three days of investigation. When R&D releases a firmware update, the fleet view immediately shows which deployed units are eligible and which are not. When a supplier flags a component recall, the system identifies every customer impacted in seconds.
What This Unlocks Operationally
Three operations change. Spare part dispatch becomes accurate because the field engineer sees the actual configuration of the target unit, not the average BOM. Firmware rollouts become safer because incompatible units are identified before the rollout, not during. Warranty arbitration becomes defensible because the as-built record is queryable in real time, with the engineering rationale attached.
Koddex was built so that the same graph that holds the design intent also holds the deployed fleet. The R&D team and the operations team finally work from the same truth. The chasm closes.
