Today, I want to discuss a significant change in our approach to automotive logistics and inventory management, highlighting how dealers are shifting from traditional nuts and bolts to digital bits and bytes.

The Dealer Management System (DMS) is no longer just a warehouse tool, vehicle sales orders, or service planner. Occasionally, I hear it is a good tool for printing invoices. 😊

In fact, a modern DMS is a dealer’s Digital Asset Management platform, and dealers should treat it accordingly.

From nuts and bolts to bits and bytes

The automotive industry is shifting from hardware to software, becoming increasingly software-driven as both vehicles and their components evolve rapidly. New electronic part types and their associated data must be effectively managed and integrated into workshop processes to enable accurate repair analysis, estimation, installation, and updates.

Robust Dealer Management Systems (DMS) are continually (blindly) evolving, adding new features and adapting and fine-tuning existing processes to meet emerging automotive needs. However, the most effective DMS is streamlined and built on modular functional frameworks, allowing features to be turned on or off as needed without altering the core codebase. This ability is the difference between a “Monolithic” and a “Composable” DMS.

DMS Modularity enables dealerships to adapt quickly to an ever-changing automotive environment.

. . .

The ability to adapt quickly is the reason I want to start my next article with Heraclitus’s quote: “The only constant in life is change.”

I want to break down how a modern composable DMS must handle new “Software (Soft) Parts” using an architectural approach, so-called functional frameworks, instead of adding new fields and functions on top of the existing core layer. Let’s answer the following question.

Does tracking software parts in dealers’ inventory make sense?

Short answer: Yes, absolutely, but not in the way we track brake pads.

Vehicle Parts are no longer just physical components you can store on a warehouse shelf; they can be a line of code, a digital certificate with an expiry date, or a license key.

What do we know about software parts?

Software parts include part numbers, associated costs, retail price, essential data (digital license key, software version, or tokens), and vehicle compatibility rules.

Let’s summarize the most common Vehicle Software Parts.

Digital Key Code to unlock Feature-on-Demand (FoD)

A customer purchases a vehicle with heated-seat hardware installed, but the software required to enable it is locked. The “part” the dealer sells is the digital unlock key.

Firmware & Calibration Files

Specific software versions are required for a hardware-based Electronic Control Unit (ECU) (e.g., a transmission control module).

Cybersecurity Keys & Digital Certificates

Modern vehicles require encrypted “handshakes” to install new parts (Gateway Security). These digital certificates are consumable and must be tracked.

Update Packages (OTA Over-the Air)

Large data packages that fix bugs or add new features.

New types of vehicle software are added daily; the list of vehicle software components is dynamic. This also reflects the need for a dynamic approach to DMS management.

. . .

We can now begin with DMS and its role.

Historically, software updates were hidden in “labor hours” (the technician’s time). But if a software update adds 50hp to an electric motor, it is a product with a retail price; it cannot be handled as a service anymore. It must be in inventory to be sold.

If dealers don’t track it, they often forget to charge for it. Tracking it ensures the dealership gets paid for the value it delivers to customers. Other reasons to track software parts in DMS are Warranty & Inventory History, Software Compatibility Rules, and Security.

In detail, Software Parts are managed in DMS under a new parts category (Digital Parts) but share the same data structure as physical parts (Parts Number, Cost, Retail Price, and Vendor Information).

See a real-life example from DMS below:

Secondly, instead of a physical shelf, dealers should use a “Virtual Bin” in their “virtual warehouse “ to store licenses for deployment.

Lastly, for me, the most interesting aspect is how software components are delivered (shipped to repair orders): when a software part is “sold,” the DMS shouldn’t print a picking ticket for a warehouse runner; instead, it should trigger an API request to the software manufacturer to release the license or download token.

Two more practical examples of software parts:

A dealer pre-purchases 50 “Full Self-Driving” licenses from the OEM. These sit in a digital inventory account on the dealer’s virtual warehouse bin until sold (deployed) to customers.

Another good example is the so-called TRP Parts (Theft-Relevant Parts), which are, in fact, a combination of a physical item (a vehicle key) and VIN-specific software that unlocks the key. I named such items and the Coded Parts; the DMS must be smart enough to handle all data properly during the repair process.

. . .

Did you find it interesting to read?

If yes, please follow my next article, scheduled for publication on 31.01.2026.

In my next article, I want to continue covering software components for vehicle systems and delve deeper into DMS configuration logic, using real DMS examples.

Dr. Juraj Hanus, hanus@taxapa.com

Data Analytics & Automotive Applications Expert for Dealerships