Vendor Data Quality in DCIM: Why Manufacturer Names Matter More Than You Think
"Dell", "Dell Inc.", "Dell EMC", "Dell Technologies" — four names, one company, and a data quality problem that will break your DCIM import. Here is how to fix it.
The Many Names of One Vendor
Open any enterprise asset inventory and count how many different ways the same manufacturer appears. Dell alone typically appears as "Dell", "Dell Inc.", "Dell Inc", "Dell EMC", "Dell Technologies", "DELL", "Dell Technology", and occasionally "Dell Computers" — a name the company stopped using in 2003. Each variation was entered by a different person, at a different time, using a different source document.
This is not carelessness. It is the natural result of manual data entry without a controlled vocabulary. When an engineer is recording a new asset, they write the manufacturer name as they see it — on the device label, in the vendor's documentation, or from memory. Without a lookup table that enforces canonical names, every person makes a locally correct decision that creates a globally inconsistent dataset.
The consequences are significant. DCIM platforms match devices against manufacturer records. If your platform has "Dell Technologies" as a manufacturer and your import CSV has "Dell EMC", the import will either fail or create a second manufacturer record. Over time, your DCIM database accumulates dozens of manufacturer duplicates, making vendor concentration reports meaningless and capacity planning by vendor impossible.
The Scope of the Problem
The vendor name problem is larger than most teams expect. A typical enterprise data centre inventory with 1,000 to 2,000 assets will have 40 to 80 unique manufacturer name variants in the raw data. After normalisation, that number typically consolidates to 15 to 25 canonical vendors. The gap — 25 to 55 duplicate or variant names — represents real data quality debt that will cause problems in every DCIM workflow that depends on manufacturer data.
The most commonly fragmented vendors in DC asset inventories are:
| Canonical Name | Common Variants |
|---|---|
| Dell Technologies | Dell, Dell Inc., Dell EMC, DELL, Dell Computers |
| Hewlett Packard Enterprise | HPE, HP, Hewlett-Packard, H.P.E., HP Enterprise |
| Cisco Systems | Cisco, Cisco Systems Inc., CISCO, Cisco Systems, Inc. |
| Vertiv | Liebert, Emerson Network Power, Emerson, Geist |
| Schneider Electric | APC, APC by Schneider Electric, American Power Conversion |
| Lenovo | Lenovo Group, LENOVA, Lenovo Inc. |
Why It Matters for Reporting
Vendor data quality is not just an import problem. It affects every report that aggregates data by manufacturer. A vendor concentration report — showing what percentage of your estate each vendor represents — is meaningless if "Dell" and "Dell Technologies" are counted separately. A warranty expiry report filtered by vendor will miss records if the vendor name does not match exactly.
For organisations that track vendor concentration as a risk metric — limiting exposure to any single vendor to a maximum percentage of the estate — inaccurate vendor data can produce false compliance. The report shows 25% Dell when the actual figure, after consolidating all Dell variants, is 35%.
Building a Vendor Alias Library
The solution to the vendor name problem is a vendor alias library — a lookup table that maps every known variant to its canonical form. The library needs to be comprehensive enough to cover the variants that actually appear in your data, and it needs to be applied consistently to every data source before import.
A practical alias library has three components. First, exact match aliases: "Dell EMC" → "Dell Technologies", "APC" → "Schneider Electric". These cover the most common variants. Second, prefix/suffix stripping rules: remove ", Inc.", ", Ltd.", " Group", " Corporation" from vendor names before matching. Third, fuzzy match rules for handling typos and abbreviations: "LENOVA" → "Lenovo", "Cisco Sys" → "Cisco Systems".
The alias library should be maintained as a living document. Every time a new variant appears in source data, add it to the library. Over time, the library becomes comprehensive enough that new data sources require minimal manual intervention.
Preserving Special Cases
Not every vendor name should be normalised to a single canonical form. Some vendors have distinct product lines that are tracked separately in DCIM platforms. "Cisco Meraki" is a distinct product line from "Cisco Systems" and may need to be tracked separately. "HPE Aruba" is distinct from "Hewlett Packard Enterprise" for the purposes of network equipment management.
The alias library needs to handle these cases explicitly — mapping "Meraki" to "Cisco Meraki" rather than to "Cisco Systems", and "Aruba" to "Aruba Networks" rather than to "HPE". The rule is: normalise to the most specific canonical form that your DCIM platform's device type library uses.
Automating Vendor Normalisation
Manual vendor normalisation is feasible for small datasets but impractical at scale. For inventories with hundreds or thousands of records from multiple sources, automated normalisation is essential. The automation needs to apply the alias library, handle case-insensitive matching, strip common suffixes, and flag records where no match is found for manual review.
Struktive's normalisation engine applies vendor alias matching across the most common DC hardware vendors and their variants. Every record processed by Struktive goes through vendor normalisation before export, ensuring that the DCIM platform receives consistent manufacturer names regardless of what the source data contained.