It's Monday morning, and the EDI feed to your largest customer is down. Not a connection error — a data mismatch. The customer's system is rejecting line items because the units of measure don't match what lives in their catalog. Your team is now scrambling to fix a taxonomy that lives entirely in a spreadsheet, and in the mind of the person who built it.
Digging in, you find a bigger problem. Three separate SKUs, but only one base part: one raw, one plated, one plated and patched. All three carry the same description, "Hex Head Cap Screw, Grade 8." No finish listed, and no way to tell which process step a given part is even at. A customer ordering off that description has a one-in-three shot at the right part. A distributor trying to map it into their own catalog has no shot at all.
This isn't a one-off. The same issue pops up over and over, in different flavors, across the catalog. The instinct is to blame the software, or patch this one issue and go hunting for the rest another day.
The EDI feed didn't fail because the software's bad, and the three SKUs didn't collide because someone typo'd a spreadsheet cell. They collided because the part data was never built the way the part itself was built: as a sequence of steps, each one adding something specific and traceable.
You already know how to run a process with defined inputs and defined steps. You do it on your floor every day. Most shops never let that discipline carry over into how they run their data, and the EDI failures, the taxonomy fire drills and the duplicate SKUs all trace back to that gap.
Ask a process engineer how a hex head cap screw gets made and you'll get the same answer every time. Wire rod comes in on a coil. Cut to blank length, cold-headed into shape. Threads get rolled. Heat treat to hit the grade. Plated with whatever the spec calls for. Sometimes a patch goes on after plating. Then it's counted, packaged, labeled.
Nobody would start at the last step. Nobody would dump wire rod and finished, plated, patched parts in the same bin. Every step of the manufacturing process takes an input, does an action to it, and generates a known output. At any point in the process, you know what's been done to a given lot and what hasn't.
Your product data should be manufactured the same way, whether you've set it up that way or not. It needs raw inputs: a base part number, a material spec, a thread callout. It goes through steps that add characteristics: a finish gets applied, a UOM gets defined, a cert gets attached. It should have a routing too, where each step adds something specific and you can tell where in that sequence a given record sits.
Most manufacturers and distributors don't store it that way. There's often no routing for a description. No intermediate identities, nothing that marks "post-heat-treat, pre-plate" the way the physical inventory system does. No spec for what a finished, correct part record actually contains. You always have an inspection sheet for the physical part, but you almost never have one for the data.
Pull up a legacy item master and you'll find this sitting in a single field: "Hex Head Cap Screw, Grade 8, Zinc Plated, Blue Nylon Patch, Drilled Hole." It probably reads fine to you as a person. The issue is that it was built for a person to read, not a system to use. Sometimes the molecule is over-stuffed like this one, and sometimes it's missing pieces entirely, like Monday morning's three identical SKUs. Either way, the failure is the same: the attributes were never stored on their own.
The string can't be searched reliably, because a search needs to know where one attribute ends and the next begins, and a long single sentence doesn't guarantee that. It can't be matched against another system's catalog, because that system almost certainly orders or phrases its attributes differently. It can't be handed to a distributor portal or a customer feed, because there's no way to pull out just the finish or just the drive style without a person reading the whole thing and re-typing the piece they need.
Think of a part description field as a molecule. What you need underneath it is the elements: material, head style, thread size and pitch, finish, patch, drive type, hole feature — each one its own unique value, stored separately.
There's a discipline that makes this easier than it probably seems. Cap the category tree at four levels. Any deeper than that and you're optimizing for engineers, not for customers trying to find a part. Where two categories share the same attribute set, collapse them into one and use a "Type" attribute to carry the difference. This is how eCommerce experts like McMaster-Carr run their site to make parts easily searchable. Create one hex nut category, with "Type: Jam Nut" as an attribute rather than its own branch of the tree. Normalize values against pre-determined lists instead of free text, so "Zinc," "Zinc Plated," and "Zinc Clear" resolve to one value instead of three.
If you think about a periodic table, the number of base elements is finite, and the same goes for part attributes. Every customer requirement, every distributor catalog format, every internal spec is a combination of the same table. Your Grade 8, zinc-plated, patched screw and your Grade 5, plain, unpatched screw share most of their elements and differ by exactly two. If you store elements, that difference is obvious to both humans and computers. If you store molecules, it's buried in two sentences that look overall very similar.
Elemental data also makes substitution possible, which a flat, sentence-style description never could. If a customer is looking for corrosion resistance, you can safely offer a galvanized coating as an upgrade for zinc when zinc's out of stock — but you'd never offer the reverse. That kind of ranked substitution only works if finish is its own attribute with its own defined relationships; otherwise your team and customer will be searching endlessly for substitutes.
Once data is elemental, any new combination isn't a total rewrite. It becomes trivial: you swap two attribute values on the same base part and you're done, allowing the taxonomy to scale with your business. One built as sentences needs a person to redo it by hand every time a new part shows up.
Lay the data on top of the physical routing, step by step, and the same logic holds.
At raw component stage you have material spec, dimensional spec, thread callout — the facts that are true of the part before anything else happens to it. This is its own distinct data state, and it deserves its own identity instead of a placeholder that just gets overwritten three more times as the part moves along.
Plating is a process step, so it should be a data step too. A finish attribute gets set and a new identity gets created — this is the plated version of that base part, instead of just writing over the original record. Patch works the same way one step later: another attribute, another identity sitting on top of the plated one.
This is exactly where Monday morning's EDI mess came from. The raw part, the plated part, and the plated and patched part were three different physical things moving through three different steps on the floor, but the data never once caught up to that. All three kept the exact same description because nobody had ever bothered to build an identity for post-plating or post-patch. The routing existed in the plant. Nothing underneath it in the data ever reflected it.
Really, this is just a bill-of-materials failure; it's just showing up in your data instead of on the shop floor. If a BOM said add plating and no plated-part identity ever got created, everyone would call that a broken BOM without thinking twice. This is the same mistake, and it gets fixed the same way: by building the routing.
Units of measure hide a version of this same problem, but it's usually the last place people look, and often what causes the most headaches when interfacing with customers.
A manufacturer stores everything at master carton level: one record, one attribute set, one UPC, all at the carton. No weight or dimensions existed below that anywhere in their system. That can be totally fine for years while distributors buy up the cartons and repack them downstream.
Then one day the manufacturer starts working with Fastenal or Grainger, and they start asking for the same thing: product data at the lowest sellable unit. A single box of 100 or a single each. They're looking for weight, dimensions and a UPC at each level, because that's how their systems transact against that exact unit. This is the unit they price a listing at, slot warehouse space for, and calculate freight on.
The fix isn't creating a new field for "distributor requirements." It's having a UOM structure that should have existed the whole time: UOM1 as each, UOM2 as a box of 100, UOM3 as a carton of 10 boxes — each level carrying its own weight, dimensions and identifier, rolling up cleanly into the level above it.
Systems transact on quantities, not descriptions. A distributor's ERP doesn't care how well your description reads. It cares whether it can pull a weight and a UPC at the exact unit it's moving. This is, more often than not, where "taxonomy" fights with big distributors actually live — not in the descriptive attributes, but in a UOM structure that only ever got built one level deep. If your EDI problem looks like a taxonomy problem, it's worth checking here first.
The same molecule-vs-element split shows up again inside a single UOM record, and it's easy to miss because it looks like one field instead of the two that it is. "12 pack" reads fine to a person. However, a system needs to see the "12" on its own, as a number it can multiply and divide, and also the "pack" on its own, as a label a person reads on a screen. Store them together and you've built a small molecule right inside the part of your data that's supposed to be the most structured. Split them up correctly — UOM Quantity and UOM Description — and now both the math and the label work the way they're supposed to.
Once the elements and the routing exist, the rest falls into place. There are a handful of modules any part record rolls up from:
The part that most manufacturers don't consider when setting up their systems is that customers mostly don't want this data structured differently from each other. A distributor's portal, a customer's EDI spec and your own ERP screen all want the same underlying elements. They differ in format, field names, ordering and delimiters, but not in substance. One maybe wants pipe-delimited, another wants an API payload, but the material spec, the thread callout and the finish are identical either way.
Store the elements once, correctly, and meeting a new customer's spec stops being an ongoing project. It's a mapping exercise: the same values in a different shape. The work that used to need "one guy" in a spreadsheet can easily become a simple query.
When people confront this problem, their first answer is usually to go find a PIM. But a PIM is a warehouse, not a routing. It's a fine place to keep and update elements once they exist in discrete, structured form, but buying one doesn't create the routing, and it definitely won't turn a molecule back into elements on its own. A PIM holds the structure. It will never build it.
So do this before any software conversation happens. Pull up your top-selling SKU. Skip past the description field and count how many genuinely discrete, structured attributes you can produce for that part right now: material, finish, thread, each UOM level with its own weight and dimensions, compliance data — all of it separately identifiable and separately queryable.
Whatever number you land on is where your product data actually stands today.
And if the answer is one long description, what you've got is a finished molecule with no BOM behind it. Nobody would run a plant that way. You wouldn't accept a finished part with no record of the material it started as, the steps it went through, or the spec each step was held to. Your data deserves the same standard.
The fix isn't a purchase. It's a build. Define your elements, give each process step its own data identity and let every customer requirement roll up from the same base components, the same way every finished part rolls up from wire rod. You already run this discipline on your floor every day. The bill of materials for your product data is the one BOM you haven't written yet. Start there, and then find software to support your production process.
This article was co-authored by Cole Weiler, CEO & Founder of BoltWise, and Sam Aldinger, Founder of Highland Consulting LLC. It originally appeared in the August 2026 issue of Fastener Technology International.
Want help building the bill of materials for your own product data? Book a demo with the BoltWise team.
