先别急着定编码位数，主数据项目到底要怎么做

先说一个几乎每次都会重演的场景。

某制造集团启动物料主数据项目，第一次业务研讨会，议题表上写着"编码规则讨论"。会议开始不到十分钟，争论就进入了白热化：技术中心主张 12 位、含材质码；采购主张 10 位、越短越好；某板块说我们历史上就是 9 位、带产线标识，改了整条产线的标签都得重打。

两个小时过去，谁也没说服谁。会议纪要写的是"编码位数待定"。

这场会的根本问题不在于谁对谁错，而在于它把结论当成了议题。编码是方案的最后一步产物，它前面还有三个问题没有答案：什么算物料、什么算同一个物料、哪些信息该进分类哪些该进属性。这三个问题悬空，编码规则怎么定都只是暂时的。

这篇文章想说的就是一件事：主数据项目的失败，多数不是方案错了，而是顺序错了。而顺序错误的第一个信号，就是会议从"编码定几位"开始。

一、为什么编码必然排在最后

标准建模的顺序是刚性的：分类 → 属性 → 值集 → 编码。

这不是方法论上的偏好，而是依赖关系决定的：

• 编码的位段设计依赖分类层级。编码里要不要放"大类 + 中类 + 小类"，取决于你分了几层、每层多宽。分类没定，位段就是猜的。
• 分类的末级设计依赖属性的可判定性。末级分类必须"挂得住属性"，否则同一末级下的物料无法用属性区分，分类就失去了执行价值。
• 属性的取值依赖值集的标准化程度。属性写成自由文本，等于没有属性；必须是标准值集，才能参与查重和统计。

所以，凡是先定编码的项目，后面几乎必然出现两类返工：一是分类一调整，编码位段对不上，只能扩位或重编；二是唯一性判定做不出来，因为属性不可判定，只能靠人工拍脑袋"这两个是不是一个东西"。

在售前评估时，这一步也最容易被低估。分类、属性、值集这三件事通常占一期标准设计 60% 以上的时间，但它们不出界面、不出报表，看起来"没什么进度"。于是进度压力一来，最先被压缩的就是这段时间——而这恰恰是最不该省的时间。

二、先建立三个认知，再谈方法

认知一：主数据是一棵树，错误会向上扩散

把企业的数据摊开，是一棵树：

• 树干是主数据：物料、客户、供应商、组织、人员；
• 树叶是交易数据：采购订单、销售订单、发票、凭证；
• 果实是指标数据：库存周转率、销售增长率、成本差异、利润率。

这三层不是并列的，是支撑关系。树叶长在树干上，果实挂在树叶上。

一条主数据出错，会顺着树干扩散，可能造成成百上千条交易数据错误，最终让指标失真。 这是主数据项目与普通业务系统的根本区别：业务系统的缺陷影响一个流程，主数据的缺陷影响所有引用它的流程。

也正因为如此，主数据项目的验收标准不能是"平台能跑通"。跑通只是必要条件。真正的标准是：新增数据不再变脏。

认知二：物料是主线，80% 的工作量在这里

物料数量最大、属性最复杂、涉及部门最多，并且与成本、采购、生产、库存耦合最深。选择物料作为一期突破口，不是因为它简单，而是因为价值最集中——它最能检验标准体系是否真的立得住。

客户、供应商、组织这些域要不要一起做？通常建议先做透一个域。物料跑通了，方法论可以复制；物料没跑通，四个域一起上等于四处同时起火。

认知三：业务必须参与，技术方案要配管理方案

只由 IT 出方案、业务最后签字确认的项目，通常在试点阶段就会被推翻。原因很朴素：属性的语义只有业务能定义（"这个材质字段该填什么"），唯一性的技术等价只有研发和工艺能确认（"这两个件能不能互换"）。

IT 能提供的是平台、接口、权限；业务能提供的是标准与判断。缺任何一半，方案都跑不起来。

三、推动立项时，别再说"我们的数据不规范"

这句话是无效沟通。业务听不懂，也感受不到痛。

有效的做法是把数据问题翻译成业务后果，用四类动因串起来：

这张表真正的价值在于：每一行都能对应到具体的人和具体的痛。采购总监关心第一行，IT 负责人关心第二行，财务关心第三行，一把手关心第四行。项目立项会上的资源，是按"痛"分配的，不是按"重要性"分配的。

但要注意：诊断结论必须带证据。 重复编码的实际样本、属性缺失的比例、跨系统描述的差异清单、访谈记录、系统盘点结果。没有样本的诊断，只是一份意见书，在评审会上撑不过三个追问。

四、"方案对、顺序错"的三个典型症状

症状一：先定编码，再补分类

表现是编码规则做得很细，甚至做出了编码器 demo，但分类树还是三年前的旧版本，属性表空着。上线后第一件麻烦事就是"新码套不进旧分类"。

症状二：只找 IT 调研

只找 IT，拿到的是接口文档和表结构，拿不到属性的业务含义。等到配置阶段才发现"强度等级"这个字段没人能说清该填 8.8 还是 8.8 级、要不要带"级"字。这类问题出现三次以上，项目节奏就崩了。

调研必须覆盖研发、工艺、采购、计划、生产、仓储、质量、财务。而且第三步一定要"用样本暴露差异"——因为客户说"我们挺规范的"，通常只是各板块各自规范。拿同一物料跨系统一比，问题立刻现形：A 厂叫"六角螺栓 M8×30"，B 厂叫"螺栓 8*30 镀锌"，描述逻辑根本不同。

症状三：清存量不列工时、不定责任人

清洗工作量被藏在"数据治理"这个大条目下，没有单独排期、没有规则制定人、没有结果确认人。这是项目延期的头号原因——不是因为难，而是因为没有人对它负责。

五、项目立项后，先做五个判断

它不提供答案，只提供"先判断什么"。

每个判断都要留四样东西：依据、备选方案、影响范围、评审结论。

六、可以直接带走的清单

项目启动前，先确认这 6 件事：

1. 第一次业务研讨会的议题，是不是"编码规则"？如果是，改成"物料范围与分类原则"。
2. 物料范围三个含糊地带是否已经签字确认：是否含服务类采购、是否含设备备件与工装、是否含包装材料。
3. 调研名单里有没有研发、工艺、采购、计划、生产、仓储、质量、财务这 8 个角色。
4. 诊断报告里有没有至少 20 个真实样本（重复编码、属性缺失、描述差异）。
5. 存量清洗是否已单列为工作包，写明规则制定人、执行人、确认人、工时。
6. 排期里，标准设计期是否占到总工期的 1/4 以上。

一个低成本的判断方法：

在方案评审前，随便挑 3 个真实物料——一个总成、一个标准件、一个辅料，让团队当场回答四个问题：归哪个末级分类、哪些属性决定能否互换、单位和材质怎么统一、该复用旧码还是新建码。一个下午就能暴露方案里 80% 的模糊地带。

主数据项目很少有"技术难题"，多的都是"共识难题"。而共识的第一道坎，往往就是那一句"我们先定一下编码几位"。

这句话一出口，会议的方向就定了。想让它往对的方向走，就得在它出现之前，先把"什么算物料、什么算同一个物料"问出来。

这套方法的后六篇，分别处理其中一件事：分类怎么定、唯一性怎么判、字段怎么减、接口怎么对、组织怎么推、坑怎么避。