{"id":26716,"date":"2026-10-17T09:00:00","date_gmt":"2026-10-17T09:00:00","guid":{"rendered":"https:\/\/evaluationshub.com\/?p=26716"},"modified":"2026-09-29T15:42:20","modified_gmt":"2026-09-29T15:42:20","slug":"supplier-site-part-data-model","status":"publish","type":"post","link":"https:\/\/evaluationshub.com\/supplier-site-part-data-model\/","title":{"rendered":"Supplier, Site, Part: The Data Model That Answers Product-Level Questions","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"\n

Here is a question worth trying on your own systems this week.<\/p>\n\n\n\n

A customer emails to ask which of the products you sell them contain material from one named factory. Not one named supplier. One named factory, out of the four that supplier operates.<\/p>\n\n\n\n

Most teams can answer the supplier version of that question in about a minute. The factory version tends to take somewhere between three days and a working group, and the reason is rarely that the information is missing. Someone in quality knows. The purchase orders know. The certificates in the shared drive say it on the front page. The information exists, and it is simply not shaped in a way that lets anyone query it.<\/p>\n\n\n\n

This is one of the most solvable problems in supplier management, and solving it pays off across every compliance regime at once. This article sets out the data model that makes product-level questions answerable, and a path to get there that does not involve replacing anything.<\/p>\n\n\n\n

The five-question test<\/h2>\n\n\n\n

Before designing anything, it helps to see the shape of the problem. Work through these five questions and note how long each one would take you today.<\/p>\n\n\n\n

    \n\n
  1. Which suppliers do we buy from? Entity-shaped.<\/strong><\/li>\n\n\n
  2. Which of our parts does supplier A make, and at which of their plants? Site-shaped.<\/strong><\/li>\n\n\n
  3. If plant B goes offline tomorrow, which of our finished products stop? Site-shaped, and time-sensitive.<\/strong><\/li>\n\n\n
  4. Which of our products contain a commodity produced on a given piece of land? Product-shaped, all the way upstream.<\/strong><\/li>\n\n\n
  5. Where was part 4471 manufactured in March, as opposed to where it is manufactured now? Historical.<\/strong><\/li>\n\n<\/ol>\n\n\n\n

    Almost every organisation answers question one instantly and the rest slowly. That pattern is the diagnosis. The gap is not effort or headcount, it is that the questions being asked and the data being held have different shapes.<\/p>\n\n\n\n

    Why the vendor list is entity-shaped, and why that was correct<\/h2>\n\n\n\n

    It is worth being fair to the existing design. The supplier master in an ERP was built to do a specific job extremely well: decide who gets paid, on what terms, against which tax registration and bank account. For that job, the right unit is the legal entity. A legal entity signs contracts, carries a VAT number, owns a bank account and can be sued. Organising supplier data around it was not an oversight. It was the correct answer to the question being asked at the time.<\/p>\n\n\n\n

    What changed is that the questions multiplied. Supplier information management<\/a> grew up next to the vendor master rather than inside it, for good reason. The finance question is still entity-shaped, but quality, continuity and compliance questions mostly are not, and they now arrive with deadlines attached. Rather than a flaw to fix, this is a scope extension to design for: the vendor master keeps doing its job, and a supplier data model grows around it to answer the questions it was never meant to.<\/p>\n\n\n\n

    What the regimes actually ask for<\/h2>\n\n\n\n

    The clearest way to see which layers you need is to look at what the major frameworks attach their requirements to. They are remarkably consistent, and remarkably unlike a vendor list.<\/p>\n\n\n\n

    \n\n\n\n\n\n\n\n
    Framework<\/th>\nWhat it attaches to<\/th>\nThe unit you need<\/th>\n<\/tr>\n<\/thead>
    IATF 16949<\/td>\nThe manufacturing site. Certification is issued per location, not per company: “Each manufacturing site and each standalone remote support location shall be audited and certified by only one IATF-recognized certification body”<\/td>\nSite<\/td>\n<\/tr>\n
    CBAM<\/td>\nThe installation where the goods were produced. Operators report the “identification of the installation where it was produced” along with specific embedded emissions and production route<\/td>\nSite<\/td>\n<\/tr>\n
    EUDR<\/td>\nThe plot of land where the commodity was produced, plus every establishment where cattle were kept<\/td>\nUpstream location, below your supplier<\/td>\n<\/tr>\n
    ESPR digital product passport<\/td>\nA “persistent unique product identifier”, with data referring to “the product model, batch or item as specified in the delegated act”<\/td>\nProduct, and sometimes batch or item<\/td>\n<\/tr>\n
    EU Forced Labour Regulation<\/td>\nA named product under investigation, not a named vendor<\/td>\nProduct<\/td>\n<\/tr>\n<\/tbody><\/table><\/figure>\n\n\n\n

    Neighbouring due diligence regimes point the same way. The CSDDD agenda<\/a> and the ESG and CSRD questions that now arrive during onboarding<\/a> both get much easier to answer once you can say which site made which part.<\/p>\n\n\n\n

    Four different frameworks, four different owners inside your business, and one shared conclusion: the vendor is the wrong grain for most of it. Two of them want the site, two want the product, and none of them want the legal entity on its own.<\/p>\n\n\n\n

    That shared conclusion is the good news. Because these frameworks converge on the same two units, building those units once serves all of them, which is the strongest argument available for doing this properly rather than four times in four spreadsheets.<\/p>\n\n\n\n

    The four layers<\/h2>\n\n\n\n

    A supplier data model that answers the five questions has four layers. The first three are things. The fourth is the one that does the work, and it is the one most often left out.<\/p>\n\n\n\n

    Layer 1: the legal entity.<\/strong> Who you contract with and pay. Identified by a registration number and tax ID. This is your existing vendor master, and it does not need to change. It answers ownership, sanctions screening, financial risk and contractual liability. Group structure belongs here too: parent, subsidiary, and the fact that three of your vendor numbers are actually one counterparty. Organisations buying across borders will recognise this from multi-entity onboarding<\/a>, where the same group appears differently in every country.<\/p>\n\n\n\n

    Layer 2: the site.<\/strong> A physical place where something happens: a plant, a mill, a warehouse, a laboratory, a smelter. Sites have addresses and coordinates, they hold certificates, they get audited, they flood, and they are what continuity planning actually runs on. Crucially, sites do not map one to one onto entities. One entity commonly operates several sites, and one site sometimes serves several entities within a group.<\/p>\n\n\n\n

    Give sites their own identifier rather than reusing the vendor number. The GS1 Global Location Number exists for exactly this purpose and is defined as the key “used for any location (physical, operational or legal) that needs to be identified for use in the supply chain”, distinguishing physical locations such as warehouses from legal entities and from operational locations such as a receiving department. You do not have to adopt GS1 to borrow the discipline: a location is a different kind of object from a company, and it deserves its own key.<\/p>\n\n\n\n

    Layer 3: the part or product.<\/strong> What you actually buy, at your own item number. This layer usually already exists in purchasing, but it typically lives in a different system from supplier data and is joined only through purchase order history, which is a weak and slow join.<\/p>\n\n\n\n

    Layer 4: the assignment.<\/strong> This is the layer that turns the other three from a filing cabinet into an answer engine. An assignment records that a given part is supplied by a given entity, produced at a given site, and it is valid between two dates.<\/p>\n\n\n\n

    If you build only the first three layers, you have a better address book. The assignment is what lets you traverse: from a site to the parts made there, from a part to the finished goods it goes into, from a finished good back to every site in its history.<\/p>\n\n\n\n

    \n\n\n\n\n\n\n
    Layer<\/th>\nAnswers<\/th>\nTypical identifier<\/th>\nWhat breaks without it<\/th>\n<\/tr>\n<\/thead>
    Legal entity<\/td>\nWho we pay and contract with<\/td>\nRegistration number, tax ID<\/td>\nNothing. You already have this<\/td>\n<\/tr>\n
    Site<\/td>\nWhere it is actually made, audited and certified<\/td>\nLocation ID such as a GLN, plus coordinates<\/td>\nCertificates float free of any place; continuity planning is guesswork<\/td>\n<\/tr>\n
    Part or product<\/td>\nWhat we buy<\/td>\nYour item number, plus the supplier’s<\/td>\nCompliance data cannot be attached to anything a customer asks about<\/td>\n<\/tr>\n
    Assignment, with dates<\/td>\nWhich part, from which entity, made where, when<\/td>\nComposite<\/td>\nYou can describe your supply base but cannot query it<\/td>\n<\/tr>\n<\/tbody><\/table><\/figure>\n\n\n\n

    Time is the fourth dimension, and the one people forget<\/h2>\n\n\n\n

    Notice the dates on the assignment. They matter more than they look.<\/p>\n\n\n\n

    Almost every hard question in supplier management is a backwards question. A recall asks which units shipped between two dates. A forced labour investigation asks about goods placed on the market in a past period. A customer complaint asks what changed. An auditor asks you to show the control was operating last year, not today.<\/p>\n\n\n\n

    If your part-to-site assignment simply overwrites itself when a supplier moves production from one plant to another, you can answer where a part is made and you can never again answer where it was made. The information is not wrong, it has just been quietly destroyed by an update. Adding a valid-from and valid-to date to the assignment, and writing a new row rather than editing the old one, costs almost nothing at design time and is close to impossible to reconstruct later.<\/p>\n\n\n\n

    This single decision is probably the highest-return choice in the whole model. Every audit trail<\/a> question you will ever face is a question about the past.<\/p>\n\n\n\n

    Getting there without replacing anything<\/h2>\n\n\n\n

    The instinct at this point is to scope a master data programme. That is usually the slowest available route, and it is not necessary. The model can be built incrementally, in an order that pays back at each step, alongside the supplier master data governance<\/a> and wider procurement data management<\/a> you already run.<\/p>\n\n\n\n

    Step 1: add sites for your top suppliers only.<\/strong> Not all of them. Take the suppliers that a risk-based segmentation<\/a> already tells you matter, usually somewhere between thirty and eighty names, and capture their production sites. Name, address, coordinates, and what happens there. This is a short data request and most suppliers answer it readily, because unlike an ESG questionnaire it asks nothing sensitive.<\/p>\n\n\n\n

    Step 2: attach certificates to sites instead of to companies.<\/strong> This is a filing change more than a data change, and it immediately makes one thing visible that was previously invisible: the supplier with a valid certificate covering only two of their four plants, one of which is the one making your part. Quality teams tend to find this step pays for the whole exercise on its own, and it makes remote and digital audits<\/a> far easier to scope, because you know what you are auditing.<\/p>\n\n\n\n

    Step 3: link your top parts to sites.<\/strong> Start with the parts that carry regulatory exposure or single-source risk rather than trying to cover the catalogue. Ask the supplier to confirm the producing site per part number. Record it with a valid-from date.<\/p>\n\n\n\n

    Step 4: ask for site-level data in onboarding<\/a> from now on.<\/strong> Every new supplier arrives with the right shape, so the gap stops growing while you close it. This is far easier than retrofitting, and it means the problem has an end date.<\/p>\n\n\n\n

    Step 5: make the site field mandatory on anything that asserts a fact about production.<\/strong> Audit reports, capability assessments, corrective actions<\/a> and non-conformance records should all name a site. A corrective action raised against a company rather than a plant is very hard to verify as closed.<\/p>\n\n\n\n

    Each step is independently useful. If the programme stalls after step two, you are still better off than you were, which is the property you want in any data initiative.<\/p>\n\n\n\n

    Collect the site once, use it everywhere<\/h2>\n\n\n\n

    The argument that usually unlocks budget is not the compliance one. It is the duplication one.<\/p>\n\n\n\n

    Today the same supplier is frequently asked for their plant list three or four times: once by quality for audit planning, once by sustainability for emissions or due diligence data, once by procurement for continuity planning, and once by whoever is running the newest regulatory project. Each team stores the answer in their own file. Each file ages at a different rate. The supplier, who is not enjoying this, answers more slowly every time<\/a>.<\/p>\n\n\n\n

    A shared site layer collapses those four requests into one. The supplier maintains their site list once, in a supplier portal<\/a> where they can see and update it, and four internal teams read the same record. That is what centralising supplier data<\/a> is actually for. It is a better experience for the supplier, a faster answer for everyone internally, and it removes the most common source of contradictory data, which is four stale copies of the same list.<\/p>\n\n\n\n

    It also makes cross-department collaboration<\/a> practical rather than aspirational, because collaboration between teams that keep separate copies of the same facts is mostly reconciliation work.<\/p>\n\n\n\n

    What good looks like<\/h2>\n\n\n\n

    A few concrete design targets to aim at, useful as a checklist when you review whatever you build:<\/p>\n\n\n\n