去年第三季度，我帮一家做五金工具出口的贸易商做数据平台诊断。他们的BI看板上线了八个月，销售总监每周一早上都会打开看，但看了三个月之后就不再打开了。原因很朴素：看板上的"单品毛利率"和他自己用Excel算出来的数字对不上，差了将近9个百分点。我花了两天时间倒查数据链路，最后发现问题既不在BI工具，也不在ERP，而在于同一个产品在三个系统里有三套编码，ERP里是"WJ-2023-A017"，阿里国际站后台是"SKU20230817001"，客户订单PDF上写的是客户自己的料号"TLS-556"。
三套编码之间没有任何映射关系，BI工程师只能用"产品名称模糊匹配"来做关联，遇到"6寸钢丝钳"和"6寸钢丝钳（镀镍）"这种命名差异就直接匹配失败，数据在关联环节被静默丢弃。这不是个例。我前后接触过二十多家做外贸的中小企业，凡是数据分析平台"上了但用不起来"的，十有七八根子上都是商品编码没统一，而不是平台功能不够强。
如果你正在为"数据分析平台怎么管"发愁，我的核心判断是：绝大多数外贸企业的数据分析平台不是败在可视化能力、不是败在报表数量、也不是败在用户不会用，而是败在商品编码这个底层主键没有治理。平台只是把结果呈现出来，如果输入的数据本身就是碎的、对不上的，再贵的平台也只能把错误算得更快。
我用一个简单的比喻来解释这个判断。数据分析平台像是一台精密的榨汁机，商品编码就是水果的品种标签。如果苹果、梨、橙子都混在一个筐里没有标签，榨汁机功率再大，你也倒不出一杯纯苹果汁。很多企业花钱升级了榨汁机（换了更贵的BI工具），却没有人去给水果贴标签（治理商品编码），结果自然还是一杯混汁。
这篇文章要解决的，不是"选哪个平台"，而是"平台选完之后怎么管"。我会把商品编码作为整个管理逻辑的轴心，从主数据治理的角度，给出一套可以直接落地的增长策略方案。这套方案我在实际项目里跑过，也踩过坑，下面把判断逻辑、操作步骤、取舍原则都摊开讲。
和内贸企业相比，外贸企业的数据源复杂度高一个量级。一个年出口额三千万左右的贸易商，日常要打交道的系统通常包括：ERP（管库存和采购）、阿里国际站或中国制造网后台（管询盘和订单）、独立站Shopify或Shopline（管零售和流量）、货代系统（管物流和报关）、财务系统（管收汇和退税），再加上一个或几个客户的供应商门户。这些系统由不同厂商在不同年份上线，每个系统都有自己的商品编码逻辑。
问题的关键在这里：这些编码逻辑之间没有天然的对应关系。ERP的编码是内部定的，平台SKU是平台生成的，客户料号是客户定的，HS编码是海关定的。四套编码指向同一个物理商品，但彼此之间没有"翻译"。这就是数据分析平台一开始就被架空的根本原因。
我做诊断时最喜欢问一个问题："你们看板上那个'单品贡献利润'，是怎么算出来的？"如果对方的回答里出现了"用产品名称去匹配"或者"用Excel手动拼表"这两个词，基本可以判定这个看板的数据链路是脆弱的。用名称匹配，遇到规格后缀、中英文混写、供应商改名就会断；用手动拼表，意味着这个分析动作无法自动化，无法高频次刷新，也就无法支撑日常决策。
更隐蔽的问题是"静默失败"。很多BI工具在做多表关联时，匹配不上的记录会被直接丢弃而不报错。你看到的总销售额看起来正常，其实已经悄悄少了一部分订单。这种错误最难发现，因为它不报错，只是数字偏低，而人往往倾向于相信系统给出的数字。
说到这里，很多人会想到HS编码。HS编码（海关商品编码）确实是外贸场景里唯一一个跨企业、跨平台、跨国境通用的编码体系，这是它作为"锚点"的价值。但我要提醒的是：HS编码适合做映射桥梁，不适合做企业内部主编码。原因有三：一是粒度问题，同一个HS编码下可能对应几十个SKU，无法区分具体商品；二是版本问题，HS编码每几年会调整一次，各国还有本国子目，直接当主键会导致历史数据断裂；
三是业务属性缺失，HS编码不包含供应商、成本、包装规格这些内部管理需要的信息。
正确的用法是：把HS编码作为编码映射表里的一个字段，用来连接报关数据、关税数据和跨境统计，而不是让它承担唯一标识的职责。这一点下面讲方案时会再展开。
这是最常见的一种状态，尤其在年出口额一千万到一亿之间的贸易商身上。ERP里有一套内部编码，阿里国际站后台有平台SKU，每个大客户又有自己的料号体系。三套编码之间没有系统级的映射，全靠运营或跟单人员在中间"人肉翻译"。
我见过最夸张的一个案例，一家做户外用品的公司，运营主管的电脑里有一个叫"对照表_最终版_不要再改了.xlsx"的文件，里面有四千多行，把内部编码、平台SKU、五个主要客户的料号硬拼在一起。这个文件是整家公司做跨平台销售分析的唯一依靠。它的风险显而易见：只有她一个人维护，她请假的时候没人敢改，而且每加一个新品就要手动加一行，出错只是时间问题。
第二种困境来自历史。企业往往已经用旧编码跑了好几年，历史订单、库存记录、财务凭证都绑定在旧编码上。这时候如果有人提出"我们重新统一编码吧"，业务部门的第一反应是恐惧，怕影响历史订单查询，怕系统报错，怕对不上账。
这种恐惧是合理的，所以很多企业选择了最省事的办法：新商品用新编码规则，老商品不动。结果就是编码体系变成了"地层"，越往下越乱，新老编码之间还缺乏映射，几年之后连内部员工都说不清某个旧编码对应哪个现行商品。历史包袱不是不能碰，而是不能用"推倒重来"的方式碰。
第三种困境最根本，也最难解决。编码管理这件事，在大多数外贸企业里落在"三不管"地带：运营觉得这是IT的事，IT觉得这是业务的事，业务觉得这是平台自动生成的。结果是新增商品时，编码随便填；修改商品时，编码没人记录变更历史；发现重复编码时，没有专门的流程去合并。
我统计过自己接触过的十几家企业，只有两家有明确的"主数据责任人"这个角色，而且都是规模过亿、有专职数字化团队的企业。绝大多数中小企业，商品编码的质量完全取决于当初录数据的那个人当天的心情。
很多企业选型时会问"你们平台支不支持主数据管理"，得到肯定答复后就放心了。但平台提供的是"能力"，不是"内容"。平台可以给你提供编码校验、映射表、变更审批的功能，但编码规则怎么定、谁来维护、历史数据怎么迁移，这些是管理问题，平台解决不了。
我的判断是：平台的主数据管理能力，只在你有明确的治理规则之后才产生价值。没有规则的治理能力，就像一个功能齐全的编辑器给到一个不知道要写什么的人，最终还是写不出一篇好文章。
第二种误区是完美主义。有些企业一上来就宣布"从下个月起全公司统一用新编码"，结果业务部门发现历史订单查不到了、客户催货时找不到对应商品、报关资料对不上，怨声载道，最后项目被叫停。
我在项目里总结的经验是：编码治理要"先映射、后统一、再优化"，三步走，而且第一步不能省。先建立映射关系，让新旧编码并存且可翻译；等映射稳定运行半年，业务部门习惯了，再逐步收敛主编码；最后才是编码规则的优化和简化。跳过第一步直接统一，几乎必败。
第三种误区来自技术人员的"洁癖"。IT或数据团队在设计编码规则时，喜欢把所有信息都编进去，品类、材质、规格、尺寸、颜色、供应商、年份、批次，一个编码三十几位。听起来很规范，实际上没有人记得住，录入时出错率极高。
我见过一个案例，编码规则是"品类两位+材质两位+规格三位+颜色两位+供应商三位+年月四位"，一共十六位。上线三个月后，业务人员开始偷偷用简写，简写规则五花八门，最后编码体系比治理前更乱。编码规则的第一原则不是信息完整，而是"人记得住、愿意填"。我通常建议核心码控制在8-12位，把其他信息放到属性字段而不是编码里。
第四种误区是把治理当项目做。项目有开始有结束，但编码是会持续新增和变更的。新品上市、供应商更换、客户料号调整、HS编码版本更新，每一个变化都会影响编码体系。
如果一个企业只在项目期内认真治理，项目结束半年后编码又开始混乱，这不是执行力问题，而是把"运营"错当成了"项目"。编码治理必须嵌入到新品录入、订单处理、平台上传这些日常动作里，才有生命力。
第五种误区最隐蔽。数据分析师发现数据对不上，第一反应通常是"我写个更复杂的SQL"或者"我加个ETL清洗规则"，在分析层做各种补救。但如果源头编码就是不统一的，任何分析层的补救都只是打补丁，补丁越多，系统越脆。
我的判断很直接：如果你的数据团队超过30%的时间花在"清洗和匹配"而不是"分析和洞察"上，说明问题不在分析层，在源头主数据。这是一个很实用的自检指标。
第一步的核心动作是建立一张编码映射表，把企业内部编码、平台SKU、客户料号、HS编码、品名规格、供应商等信息横向对齐，但不动任何系统的原始数据。这一步的目的是"建立翻译能力"，而不是"统一"。
映射表至少应包含以下字段：
映射表的建立不需要专门工具，一张结构化的在线表格就能起步。规模超过两千个SKU时，我建议用专门的数据工具来管理，比如以"数跨境"（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）为代表的跨境电商数据管理平台，它本身内置了多维度的商品档案管理能力，编码映射可以直接在产品里维护，省去自己搭表格的功夫。
很多企业的映射表做完一年就废了，就是因为没有时间维度。当客户更换料号、当平台调整SKU规则、当HS编码版本更新时，旧映射关系如果被直接覆盖，历史订单就再也关联不上了。加上生效和失效日期，映射表就变成了"编码的历史档案"，任何时间点的数据都能还原当时对应的编码。
不要一上来就追求全量覆盖。我的做法是按"销量贡献度"排序，先把贡献前80%销量的商品完成映射，用最少的工作量覆盖最大的分析价值。剩下的长尾商品可以在日常业务中自然补齐。这个策略让小规模团队也能在两周内启动治理，而不是等三个月后才有产出。
映射表稳定运行一段时间后，就可以着手定义企业自己的唯一主编码。这一步的关键取舍是：主编码要规范，但不能复杂到没人愿意用。
我建议的主编码设计方案是"三段式"：品类段（2-3位字母或数字）+ 序列段（4-6位流水号）+ 校验位（1位）。总长度控制在8-12位。其他所有信息（材质、规格、颜色、供应商）都不进编码，而是作为商品档案的属性字段存在。
这么做有几个理由。第一，编码短则记忆成本低，业务人员录入不易错；第二，属性与编码分离后，属性变更不需要改编码，避免了编码爆炸；第三，序列段保证唯一性，不会因为商品描述微调而产生新编码。
主编码选定后，原ERP编码、平台SKU、客户料号都不废除，而是作为"别名"继续存在，通过映射表与主编码连接。这就实现了"一套主码、多套别名、统一治理"的格局。
我在一个五金工具出口项目里对比过两个方案。第一版方案是"品类+材质+规格+颜色+供应商+年月"，共18位，上线三周后发现录入错误率超过15%，业务部门抵触明显。第二版方案简化为"CT（品类）+-24001（序列）+-X（校验）"共10位，错误率降到3%以内，业务部门接受度大幅提升。这个对比让我更加确信，编码规则的简洁性远比信息承载量重要。
HS编码不进主编码，但在映射表里占据重要一列。当企业需要做跨境统计、关税测算、市场机会分析时，可以通过映射表快速聚合出按HS编码组织的视图。HS编码的角色是"对外接口"，主编码的角色是"对内主键"。两者分工明确，不要混用。
主编码规则确定后，如果只是挂在文档里，过几个月就会失效。真正有效的做法是把编码治理嵌入到三个日常动作里：新品录入、订单处理、平台上传。
具体做法是在这三个环节设置编码校验点：
这套机制的本质是把"编码质量"从一个抽象的治理目标，变成了三个具体的、每天都会发生的动作。当编码校验成为流程的一部分，而不是额外的负担时，编码治理才真正有了持续性。
我见过三种比较有效的责任分配模式。第一种是专人模式：设一个"主数据专员"岗位，通常由运营或数据岗位的人兼任，负责映射表的日常维护和异常处理。第二种是流程内嵌模式：不设专人，但在新品录入和订单审核流程里设置强制校验点，编码质量由流程保证。第三种是系统自动模式：依赖平台自动匹配能力，只处理系统无法匹配的异常。
我的建议是：年出口额三千万以下的企业，用流程内嵌模式就够；三千万到一亿的企业，建议专人+流程双管；一亿以上的企业，必须要有系统化的主数据管理平台支撑。规模不到却强上专人模式，成本高且招不到合适的人；规模到了却还想靠流程硬撑，很快就会崩。
前面讲的是治理方法，治理成果要有地方落地。这里以我在项目里实际接触过的"数跨境"平台为例，说明一个数据分析平台如何承接编码治理的成果。数跨境是九数云旗下针对跨境电商和外贸场景的数据分析平台，它的产品逻辑本身就围绕"商品档案"这个中心展开，这一点和我讲的"以商品编码为核心"思路是契合的。
具体来说，在数跨境里，商品档案可以维护内部编码、平台SKU、客户料号、HS编码等多个编码维度，平台层面自动维护这些编码之间的对应关系。当企业做跨平台销售对比、单品利润分析、库存联动预警时，底层的关联逻辑可以直接调用商品档案里的编码映射，不需要分析师每次手动拼表。
我在测试它的商品档案功能时，特意用了一个"一码对多SKU"的场景，同一个内部编码的商品，在阿里国际站、独立站和两个客户平台上有四个不同的SKU。数跨境的商品档案可以一次录入多码对应关系，之后在多平台数据合并时自动识别为同一个商品。这种"一次维护、多处复用"的设计，正是编码治理成果在平台侧最需要的承接方式。
需要说明的是，任何平台都不能代替企业自己定义编码规则。数跨境提供的也是"管理能力"，最终填进去的映射关系、生效日期、主码规则，还是要企业自己定。工具能加速治理，但不能代替治理。
编码治理的最终目的不是为了整齐好看，而是为了打通业务分析场景。编码统一后，能解锁三类此前做不到或做不准的分析场景，这三类场景直接对应业务增长动作。
第一类，单品全链路利润分析。同一个商品，从采购成本、国际运费、平台佣金、支付手续费、汇兑损益到最终利润率，全部通过主编码串联起来。此前因为编码不通，这些数据分散在采购系统、货代系统、平台后台和财务系统里，无法自动汇总；编码统一后，一份真实的单品利润报表可以做到按周刷新。
第二类，跨平台销售对比。同一个商品在阿里国际站、独立站、亚马逊、客户平台上卖了不同的价格和数量，通过主编码可以一键对比各平台的转化率、客单价、退货率，指导企业把资源往高效渠道倾斜。没有编码统一，这个对比只能靠人工估算，估出来的数字没人敢用。
第三类，库存与订单联动预警。编码统一后，库存数据和订单数据可以自动关联。当某个商品库存低于安全线而订单还在增长时，系统可以提前预警补货；当某个商品库存高企而询盘量下滑时，可以提醒运营做促销动作。这类场景是把数据分析从"事后看"变成"事前提醒"的关键。
我通常建议客户在做完编码治理后，优先把这三个场景中的一个做成"样板场景"，用三个月时间把它跑顺，让业务部门实实在在感受到数据好用，再推广到其他场景。一开始就铺开五个场景，往往一个都做不深，最后变成"看板很多但没人看"。
在一个户外用品项目的落地过程中，我们选择的就是单品全链路利润分析作为样板场景。通过主编码打通后，发现原本认为毛利最高的两款产品，扣掉平台佣金和退货损失后实际利润排到了中后段；而此前被忽视的一款配件产品，因为退货率极低、复购率高，实际贡献的利润排到了前三。这个发现直接推动了客户的选品策略调整，效果远比看板上的"总销售额增长"更有价值。
这个规模的企业系统少、人员少，最忌讳的就是上大项目。我的建议是：先用一张结构化的在线表格，由一位懂业务的运营人员牵头，把贡献前80%销量的商品映射关系录进去。用两周时间跑起来，能解决大部分"看板数字对不上"的问题，成本几乎为零。
这个阶段不要急着定义主编码，先把"翻译能力"建立起来。等映射表稳定运行三到六个月，再考虑是否要引入主编码。
这个规模的企业通常系统已经比较多，人工拼表的方式已经开始撑不住。我的建议是：设立一个主数据责任岗（可以由现有数据或运营岗位的人兼任），同时引入具备商品档案管理能力的数据平台（例如以数跨境为代表的跨境电商数据平台），把映射表从在线表格迁移到平台里维护。
这个阶段的关键动作是"嵌入流程"，把编码校验点嵌入新品录入、订单处理、平台上传三个动作，让治理不依赖个人自觉，而依赖流程强制。这个阶段的治理周期通常是三到六个月。
这个规模的企业，编码治理已经不是某个岗位的事，而是需要跨部门协调的系统工程。我的建议是：建立由业务、IT、财务、数字化部门代表组成的主数据治理小组，明确编码规则制定权和变更审批权，同时引入专业的主数据管理能力，并且每季度做一次编码质量审计。
这个阶段要特别注意避免"制度空转"，制度文件写得漂亮，但没人执行，或者执行了但没有人检查。审计机制是保证制度落地最后一道防线，不能省。
这是最常被问到的问题。我的判断是：如果现有ERP编码规则基本清晰、没有严重的历史混乱、且ERP系统短期内不会更换，直接用ERP编码作为主编码是最省事的。这样可以避免一套额外的主码体系，减少维护成本。
但如果现有ERP编码本身就混乱，或者企业有计划在两年内更换ERP系统，我建议新设一套独立主编码，让主编码与任何系统脱钩。这样在系统更换时，主编码体系不受影响，只需重新建立映射关系即可。这个决策看起来麻烦一点，但长期更稳。
历史数据要不要全部清洗，是第二个纠结的问题。我的建议是：只清洗影响当前决策的历史数据，其余的历史数据做"冻结处理"，保留原样，但不再参与新分析。
理由是，清洗历史数据的成本极高，收益却随着时间递减。三年前的订单数据对今天的选品决策参考价值有限，为它花大量人力去清洗并不划算。真正需要清洗的是那些还在影响当前库存、当前客户关系、当前定价策略的历史数据。判断标准很简单：这条历史数据如果不处理，明天会不会影响我做一个决策？会，就清洗；不会，就冻结。
MDM（主数据管理）系统是专业解决方案，功能强大但成本也高。我的判断是：年出口额一亿以下的企业，绝大多数不需要专门的MDM系统。用数据平台内置的商品档案功能加上明确的治理规则，覆盖80%以上的需求。
专业MDM系统的价值在多组织、多品牌、多语言、多系统的复杂场景下才充分体现。中小企业强行上MDM，往往是"大炮打蚊子"，投入产出比很低。等到企业真的感受到内置功能撑不住的时候，再上MDM也不迟。
最后，我把一个完整项目的过程拆开来讲，让前面的方法论有一个具体的落点。这家企业是做家居收纳用品的出口商，年出口额大约六千万，团队规模三十多人，主要渠道是阿里国际站加两个欧美大客户的OEM订单。
项目启动的契机是，他们的销售总监发现BI看板上的"客户A销量"和客户对账单上的数字差了12%。这个差异大到无法用汇率或时间差解释，销售总监要求数字化部门给个说法。数字化负责人是我的朋友，他找到了我。
我们用三天时间把数据链路倒查了一遍，发现问题出在三处。第一处是客户A的料号在订单系统里有两套写法（带不带后缀字母S），被系统识别为两个不同的商品。第二处是阿里国际站的SKU和内部ERP编码在商品名称上有细微差异（"收纳盒"和"收纳箱"），模糊匹配时错配。第三处是部分历史订单的编码在ERP升级时被自动改写，导致与新版映射表无法关联。
我们用了六周时间完成了治理。第一周建立映射表，把贡献前80%销量的商品（约两百个SKU）的内部编码、平台SKU、两个客户的料号、HS编码横向对齐。第二到三周定义主编码规则，采用"品类两位+序列五位+校验一位"共八位的简洁规则。第四到六周建立流程校验点，在ERP的新品录入和订单审核环节加入编码校验。
治理完成后三个月，BI看板上的客户A销量与对账单差异降到0.5%以内。单品利润分析从"季度做一次、每次花三天"变成"周度自动刷新"。更重要的变化发生在业务层面：通过单品利润分析，他们发现客户A的一款主力产品因为包装成本和退货率双高，实际利润已经跌到5%以下，而此前在总销售额的掩盖下完全看不出来。销售部门据此和客户A重新谈判了这款产品的价格和包装方案，第二年该产品的利润率回升到11%。
这个案例让我更加确信：数据分析平台的价值不在于它显示了多少数字，而在于它显示的数字能不能被业务动作直接使用。而数字能否被使用，前提是编码能不能对上。
回到开头那个五金工具客户的例子。他们后来用两个月时间做了编码映射和主编码治理，BI看板上的单品毛利率终于和Excel能对上，销售总监重新开始每周一早上打开看板。这不是平台的胜利，是编码治理的胜利。
我一直认为，外贸数据分析平台管不好的核心问题，从来不是平台的能力边界，而是企业有没有把商品编码这个"隐形地基"打扎实。平台是上层建筑，编码是地基，地基没打牢，上面盖得越高越危险。很多企业在选型上花了大量精力，却在主数据治理上省了功夫，最后钱花了、工具换了，问题依旧。
如果你读完这篇文章，我只希望你做一件事：打开你的数据分析平台，找到一张你经常看的报表，随便挑三个商品，用人工方式核对一遍它在ERP、平台后台、客户订单里的编码是否一致。如果三个商品都能对上，恭喜你，你的编码地基是扎实的，接下来可以考虑把分析场景做深；如果对不上，那么编码治理就是你现在最该启动的第一优先级动作，而不是再去比较哪家BI工具更好用。编码统一了，平台的价值才会像水流一样自然涌现出来。
我们公司现在ERP里有一套自编料号，阿里国际站和独立站后台又有各自的SKU，业务员报价时还习惯用客户给的料号。每次想让数据分析平台把同一款产品的销量、利润、库存拉到一张表里，就要人工对一遍，我一直在纠结到底该认哪一套编码当主编码，还是干脆重新编一套。
判断依据不是哪套编码看起来最规范，而是哪套编码的覆盖率和录入强制性最高。实操上建议分两层：主编码层选你内部ERP自编料号，因为它是订单、库存、成本、出库动作的必经节点，业务不录入就走不完流程；映射层保留平台SKU、客户料号、HS编码作为外部标识。
如果ERP料号本身混乱到品类都分不清，才考虑新设主编码，但新码必须和旧码建立一对一映射表后再切换，不能直接推翻。判断标准很简单：选那套漏录率最低、被业务动作强制约束的编码，而不是选那套最好看的。
我们老板一直问我，花力气去治理编码到底值不值。现在平台上线了，报表也能出，就是每个报表都要人工核对口径。我想具体说清楚统一编码之后到底能解锁什么场景，不然很难说服业务部门配合改录入习惯。
最直接的三类场景是单品全链路利润、跨平台同款对比、库存与订单联动预警。单品全链路利润，是把同一主编码下的采购成本、头程运费、平台佣金、退货损失归集到一条记录上，算出来的才是真实毛利，而不是拍脑袋的毛利率；
跨平台同款对比，是同一主编码在阿里国际站、独立站、线下展会的曝光、询盘、成交放在一起看，判断哪条渠道对这款产品更划算；库存与订单联动预警，是按主编码把在途、在库、已下单未发货串起来，避免业务员一边接单一边发现没货。
这三类分析的共同前提只有一个：所有源系统的记录都能落到同一个主编码上，否则平台只能出汇总数，出不了可追溯的明细。
我们做了十几年外贸，历史订单、老客户档案、老供应商记录里全是旧编码，很多已经停产了。现在上新平台，IT说要么全部迁移要么全部保留，但全部迁移怕出错，全部保留又解决不了数据打架。我很想知道有没有折中的做法。
折中做法就是只做映射、不做替换。建一张编码映射表，字段至少包含主编码、旧编码、旧编码所属系统、生效时间段、映射状态。历史订单里的旧编码原样保留，不改动原始数据；分析平台查询时通过映射表把旧编码翻译成主编码后再聚合。
这样做的判断依据是：历史数据的主要用途是统计和追溯，不是日常下单，对它做原地篡改风险高、收益低。唯一需要额外注意的是映射表要有人维护，停产编码可以标记为失效但不删除，新编码新增时必须同步补映射记录，否则两年后又会积累出一批孤儿编码。
我们正在选型，看了几家平台，演示时看板都很漂亮，但一问到多套编码怎么关联、编码规则怎么校验，销售就开始绕开话题。我不想买回来才发现底层主数据管不了，只能当个报表工具用。
选型时别看演示看板，直接让对方现场做三件事：第一，导入两张表，一张是ERP料号表，一张是平台SKU表，问它能不能在不写代码的前提下建立多对多映射关系；第二，模拟新增一条商品，问编码字段有没有格式校验、重复校验、必填校验；第三，问一个主编码对应多个外部编码时，分析查询默认走哪条链路、能不能切换。
三件事里只要有一件做不到或者要靠定制开发，就说明这个平台的主数据管理能力偏弱，后期编码治理的成本会转嫁到你们自己的运营团队身上。判断标准可以记成一句话：能管住编码新增和映射的平台，才配谈增长分析。
读者评论
这个案例很真实，编码不统一导致数据对不上，我们公司也遇到过，BI看板看了几周就没人信了。
文章提到先映射后统一，这点很关键。我们之前想一步到位，结果业务部门强烈反对，项目直接搁置。
维护真空说到痛处了，我们新增商品编码全靠运营随手填，没有校验，重复了也没人管。
HS编码不能当主键的分析很到位，我们曾经想用HS编码做关联，结果颗粒度太粗，一个编码对应几十个SKU。
三十多位编码规则那个例子太典型了，我们IT设计的编码没人记得住，最后业务自己搞简写，更乱了。