消费品企业选主数据平台，可以先问八个问题：能不能同时管款色码和一品多规格，能不能开一家店就一次建档，能不能支撑多品牌多组织，能不能和 ERP、POS、电商、仓储实时分发。
每个问题下面分三段：为什么问、合格的答案是什么、现场怎么验证。验证一律用企业自己的数据，请厂商现场操作，不看方案演示文稿。文末附一张打分表，可以打印出来带进选型会。
消费品为什么要单独讨论
建模、审批、编码、分发，这些基本功能几乎每家主数据平台都有。消费品企业的难处在别处：
- 商品层级多：鞋服有款、色、码，食品饮料有规格和包、盒、箱；
- 门店变化快：开店、关店、迁址，每次都牵动 ERP、收银、财务；
- 组织结构杂：一个集团多个品牌、多家公司；
- 下游系统多：ERP、POS、电商、仓储、运输、财务共享，都要用同一套数据。
通用选型清单问不出这些。下面 8 个问题，专门对着这几处难点。
问题一：款色码与一品多规格能否一起管
为什么问：商品模型是地基。鞋服按款、色、码三层，食品饮料是一个规格下挂包、盒、箱。模型定错了，编码、库存、分发全跟着错。多品类集团往往两种都有。
好的答案：商品层级能按品类自己配，主表、子表随品类扩展；款下挂色，色下挂码；规格下挂包装单位，换算和条码一起维护；改模型不用改代码。
怎么验证：带一个真实款号和一个真实食品规格过去，请厂商现场把层级建出来，录好换算；再把箱规改一次，看下游收到的是不是新值。
问题二：开一家新店能否一次建档
为什么问：门店信息散在拓展、运营、财务手里，各系统各建一遍，一个字段填错，开业当天就可能收不了钱。
好的答案：开店走一个流程，拓展、运营、财务按顺序补齐信息；审批一过，平台生成门店编码，连同对应的客户编码和财务编码，一起分发给 ERP、收银和财务系统。关店也走流程，下游同步停用。
怎么验证：现场走一遍开店，审批通过后，到下游系统里查这家店；再走一遍关店，看下游状态有没有跟着变。
问题三：多品牌多公司能否一套平台分开管理
为什么问：集团要看全局，就得共用一套主数据；可各品牌分类不同，各公司财务口径不同，权限也要隔开。
好的答案：分类体系能按品牌扩展；同一家供应商在集团只有一个身份，在每家公司下有各自的扩展信息；权限按品牌、公司、事业部隔离；审批流程能按品牌或事业部分支。
怎么验证：拿两个品牌、两家公司现场演示：同一家供应商，A 公司维护的银行账户，B 公司是否看不到；改了品牌 A 的商品分类，品牌 B 是否不受影响。
问题四：客户与供应商能否一套档案多入口查重
为什么问：同一家供应商，采购准入录一遍，合同录一遍，财务再录一遍，付款都可能付重。消费品企业的客户和供应商，还常常是同一家公司。
好的答案：客户和供应商能合并成业务伙伴来管；不管从哪个入口进来，都按税号查重；平台统一赋码，再回写来源系统。
怎么验证：现场从两个不同入口，录同一个税号的供应商，看第二次能不能被拦下，两个来源系统拿到的编码是不是同一个。
问题五：编码、命名、查重规则能否自行配置
为什么问：品类会扩，规则会变。每改一次规则都要厂商开发，平台很快就跟不上业务。
好的答案：编码的分段、流水号、校验规则可以配置；名称由特征项自动拼出来，不让人手写；查重按"分类＋关键特征"判断，不只比名称。
怎么验证：现场录两条名称写法不同、特征完全相同的物料，看平台能不能认出是重复；再请你们自己的管理员，在厂商指导下改一条编码规则。
问题六：数据负责人与质量规则能否落进流程
为什么问：不少平台上线一段时间后数据又乱了，根子是没人对数据负责。商品、物料、客户、供应商、科目，各有各的源头部门。
好的答案：每类主数据指定一个数据负责人，谁负责谁审批；必填、唯一、格式这些规则写进平台，不合规的提交不了；质量按唯一性、一致性、完整性、准确性定标准，定期检查，自动出报告。
怎么验证：现场提交一条缺必填字段的数据，看能不能被挡住；请厂商展示一份质量报告样例，看问题能不能定位到具体数据和负责人。
问题七：能否实时分发到 ERP、POS、电商与仓储
为什么问：主数据建得再准，下游收不到、收错了，业务照样出错。消费品企业的下游最多：ERP、POS、电商、仓储、运输、财务共享。
好的答案：审批通过后按订阅关系自动分发；常见系统有现成连接器；每次分发都有日志，失败能告警、能重发；下游生成的编码能回写到平台。
怎么验证：现场故意断开一个下游系统，看平台怎么告警，恢复后怎么重发，日志里能不能查到哪条数据、什么时间、发给了谁。
问题八：存量数据如何清洗，旧系统如何切换
为什么问：消费品企业的存量商品、门店、客商量大、重复多；切换期间，收银和配送一天都不能停。
好的答案：先按规则清洗、合并重复，旧编码做映射，不推倒重来；按域分批上线，下游分发分步切换，旧系统有明确的停用时间点；厂商讲得出同行业已上线项目的切换时间线。
怎么验证：拿一份你们的存量数据样本，请厂商现场跑一次查重和清洗；再请他们讲一个同行业已上线项目：先上哪个域，什么时候切下游，什么时候停旧系统。
三个已上线项目的实践记录
下面三个项目都已在生产环境运行，客户信息做匿名处理：
- 某运动品牌集团：门店、客户、商品、财务四个域收到一个平台。财务域先上线，13 个模型、21 条下游链路；门店、仓库建档时自动生成对应客户并统一编码；研发系统一来数，平台自动生成物流码和国标码。切换后，旧主数据系统停用。
- 某零食量贩连锁：2025 年 4 月启动，6 月底商品和供应商主数据上线。商品以最小包装为准，一个规格一个码，换算和条码一起维护；供应商不管从哪个入口来，都按税号查重，平台统一赋码再回写；主数据统一分发给财务和物流系统。
- 某调味品企业（与合作伙伴共同交付）：客户和供应商合并为业务伙伴，统一分组编码，覆盖 13 家公司代码；物料按四级分类，用 877 个特征项自动拼接描述，按相似度查重。
选型会现场打分表
（打印建议：A4 横向。评分标准和权重均为示意，可按企业情况调整。）
企业名称：＿＿＿＿＿＿＿＿ 评估日期： 评估人：＿＿＿＿＿＿＿＿
评分标准（示例）
| 分值 | 含义 |
|---|---|
| 0 分 | 不能做 |
| 1 分 | 要定制开发才能做 |
| 2 分 | 能配置，现场演示部分完成 |
| 3 分 | 用我方数据现场完整演示 |
权重（示例）：核心项 ×2，一般项 ×1；单项得分 = 评分 × 权重。
| 序号 | 问题 | 现场验证动作 | 权重（示例） | 厂商 A | 厂商 B | 厂商 C |
|---|---|---|---|---|---|---|
| 1 | 款色码和一品多规格，能不能都管 | 用真实款号、食品规格现场建层级，再改一次箱规 | ×2 | |||
| 2 | 开一家店，能不能一次建档 | 现场走开店、关店流程，到下游系统查结果 | ×2 | |||
| 3 | 多品牌、多公司，能不能分开管 | 用两个品牌、两家公司演示共享与隔离 | ×1 | |||
| 4 | 客户和供应商，能不能一套档案、多入口查重 | 从两个入口录同一税号，看是否拦下、编码是否一致 | ×1 | |||
| 5 | 编码、命名、查重规则，能不能自己配 | 录两条名称不同、特征相同的物料；我方管理员改一条规则 | ×1 | |||
| 6 | 数据负责人和质量规则，能不能落进流程 | 提交缺字段数据；查看质量报告样例 | ×1 | |||
| 7 | 能不能实时分发、出错可追 | 断开一个下游，看告警、重发和日志 | ×2 | |||
| 8 | 存量数据怎么洗、旧系统怎么切 | 用我方样本现场查重；讲同行业切换时间线 | ×1 | |||
| 合计 | 按示意权重，满分 33 分 |
| 检查项 | 厂商 A | 厂商 B | 厂商 C |
|---|---|---|---|
| 演示是否用了我方数据 | （ ）是 （ ）否 | （ ）是 （ ）否 | （ ）是 （ ）否 |
| 有无同行业已上线项目 | （ ）有 （ ）无 | （ ）有 （ ）无 | （ ）有 （ ）无 |
| 主要风险 | |||
| 总体意见 |
评估人： 日期：
附：八问的通过判据与验证样本清单
打分表解决记在哪张纸上，还需要一列什么算通过。下面这版判据把八个问题换成可观察的动作和结果，选型会当天照着核对即可。
| 问题 | 验证样本 | 通过判据 | 不通过时的表现 |
|---|---|---|---|
| 款色码与一品多规格 | 3 个真实款号，每款 2 色 3 码；另取 5 个食品规格，含一组近期改过箱规的 | 三层结构一次建成；箱规变更后下游收到新版本 | 款色码靠命名区分；规格变更要人工重发 |
| 开店一次建档 | 1 个筹开门店、1 个闭店门店、1 个纯线上店 | 一张主表加子表；门店码与客户码、成本中心码同批生成 | 线上店要另建模型；关联码手工回填 |
| 多品牌多公司 | 2 个品牌、3 个法人主体 | 一套模型按品牌与主体隔离，色卡、尺码组等字典共享 | 靠权限遮数据；字典重复维护 |
| 客户与供应商查重 | 存量 5 万客户，事先自己查出 3 组重复 | 提交时按税号命中并拦截，可选复用或申请合并 | 只在批量清洗时暴露；新建照常放行 |
| 规则自行配置 | 现场把编码从 13 位改 12 位；新增一个特征项并加进命名模板 | 配置态生效，不发版、不改代码 | 需要原厂开发介入 |
| 负责人与质量规则 | 选 3 个域，各配 2 条规则并挂到审批节点 | 规则命中走该域负责人，问题清单按人分派 | 质量报告能出，但无人认领 |
| 实时分发 | ERP、POS、电商、WMS、财务各开一个测试库 | 分发有回执；失败可重发且幂等 | 只能定时批量推送，失败靠人工比对 |
| 存量清洗与切换 | 抽 1 万条老物料，跨两套系统 | 映射表可导入导出；切源后老编码仍按映射查到 | 清洗一次性，映射关系散在表格里 |
验证样本准备清单
样本提前一周向业务部门要，现场用企业自己的数据，不接受厂商自带的演示库。
- 商品侧：3 个在售款（含一个多颜色多款尺码）、5 个多规格食品（含一组箱规近期变更过的）。
- 门店侧：1 个筹开新店、1 个已闭店老店、1 个纯线上店，闭店老店带上老编码。
- 客户侧：导出 5 万条，自己先查出 3 组重复并记住税号，现场提交这一组看拦截。
- 物料侧：1 万条真实物料，来自两套系统、各带自己的旧编码。
- 组织侧：两个品牌、三个法人、两级大区，标出跨品牌调拨的实际情况。
- 下游侧：ERP、POS、电商、WMS、财务各准备一个可查数的测试库。
分发幂等性的两条断言
实时分发是八问里最容易讲浑的一项。让厂商现场把一条数据推失败，再点重发，然后用两条 SQL 断言结果。
sql
-- 断言一：同一条主数据在同一下游不重复落地
SELECT target_sys, object_code, COUNT(*) AS cnt
FROM dist_receipt
GROUP BY target_sys, object_code
HAVING COUNT(*) > 1;
-- 断言二：状态非成功的分发必须查得出来，且重试次数可见
SELECT target_sys, COUNT(*) AS pending, MAX(retry_cnt) AS max_retry
FROM dist_receipt
WHERE status <> 'SUCCESS'
GROUP BY target_sys;第一条有结果，说明重发是追加而不是覆盖，下游会出现重复单据。第二条查不出东西，说明回执没落库，所谓实时监控只是页面上的一个绿点。两条都通过，分发这一段才可以签字。
说明：本文按企业主数据项目的实施经验整理，客户信息已做匿名处理，文中表结构、报文、编码和数字均为技术示意，仅作同行交流，不构成采购建议。