主数据管理的“冰山模型”：水面之上的问题只

显性问题和隐性问题

主数据管理出问题时，最先被注意到的是水面之上的部分。客户名称不一致，销售和财务对不上账；物料编码重复，库存数据失真；供应商信息缺失，采购下单找不到人。这些问题直接、具体、容易描述，业务部门会主动投诉。水面之下的问题更隐蔽，影响范围更广，但很少被直接提及。

数据结构的混乱，客户表里增加了十几个字段，每个字段是干什么的、谁在维护、取值规则是什么，已经没人说得清了。物料分类树被改过很多次，有些类别下面只有一个物料，有些类别名称和实际内容对不上。字段和分类是数据使用的基础，基础出问题，上层的报表和分析都会受影响。

流程设计的缺陷，新物料申请流程有五个审批节点，每个节点都可能卡住。业务人员为了不耽误生产，发明了“先用临时码，后补正式码”的工作方式。临时码越来越多，正式码和临时码之间的对应关系越来越乱。审批流程本来是保证数据质量的，流程本身却成了数据混乱的推手。

数据责任的模糊，客户数据质量有问题，应该找谁？销售说是市场部的事，市场部说是IT的事，IT说是销售录入的事。责任的模糊比数据本身的混乱更难解决。

水面下的隐性问题不容易被看见，但它们支撑着水面上的所有操作。数据结构像地基，流程像管道，责任像路标。地基松了、管道堵了、路标没了，水面上的问题就会反复出现，每次解决都是治标不治本。

为什么隐性问题更难解决

隐性问题之所以被长期忽略，有几个原因。隐性问题没有直接的业务影响。数据结构不合理，今天改明天改，系统照样能跑。流程有缺陷，业务人员可以绕过，业务还能继续。责任不清晰，出了问题时可以临时指定一个人处理。没有立即爆发的危机，就没有立即解决的动力。

隐性问题涉及多个部门。数据结构的调整需要业务部门、IT部门、财务部门一起讨论。流程的优化需要跨部门协调。责任划分需要管理层拍板。跨部门的事情天然就比部门内部的事情更难推进，不是找不到人，是找不到能拍板的人。

隐性问题解决起来周期长。改一个客户名称，几分钟就完成了。调整物料分类树，可能涉及几百个物料，需要逐条核对，需要几周时间。长期项目在短期绩效导向下容易被搁置，每个季度都要出成绩，没人愿意做半年才能出成绩的事。

隐性问题的价值难以量化。数据结构优化后，效率提升了多少？审批流程精简后，节省了多少时间？责任划分清晰后，减少了多少扯皮？这些收益很难用数字衡量，在争取资源时就很吃亏。难以量化的东西就难以被优先考虑。

从哪些隐性问题上着手

从数据结构入手，清理不再使用的字段。客户表里可能有三四十个字段，一半以上已经半年没有被查询或写入过。可以标记为“待废弃”，观察一段时间后删除。字段少了，表结构就清晰了，维护成本也降低了。

统一同义不同名的字段也是重要的基础工作。不同部门对“客户名称”的理解可能有差别，有的部门用“客户全称”，有的用“客户简称”，有的用“客户法定名称”。这些字段可以合并，或者明确各自的使用场景。字段统一了，跨部门的数据对齐就容易多了。

流程方面可以精简审批节点，把审批权限前置。不是所有的编码申请都需要三级审批。低风险、常规的申请可以由部门主管直接批，或者由系统自动批。审批层级越少，业务人员绕过系统的动力就越弱。不绕过系统，数据质量就有了基本保障。

对“例外流程”也要有明确规范，而不是允许“先这样用，后面再补”。临时方案如果没有明确的时限和责任人，就可能变成永久方案。例外流程的管理流程本身也需要设计，不能放任不管。

责任划分方面，每个核心数据实体都要指定明确的责任部门。客户数据归销售部，物料数据归技术部，供应商数据归采购部。责任部门内部再指定具体的责任人。责任到人，问题才有人解决。没有责任人，问题就会在部门之间被推来推去。

责任人的职责也要写清楚。不只是“对客户数据质量负责”这种空话，而是要列出具体动作：每月检查一次客户信息的完整率，每季度清理一次重复客户，每年评审一次客户分类规则。职责写不清楚，责任人想做也不知道该做什么。

新易编码在隐性治理中的角色

新易编码不直接解决组织架构和流程设计问题，但它提供的数据可以帮助发现隐性问题。字段使用频率统计可以看出，哪些物料属性字段很少被填写、很少被查询。使用频率低的字段，可能是多余的，也可能是分类规则不合理导致用户不知道怎么填。数据可以作为决策的依据，不是凭感觉。

流程效率分析可以统计编码申请从提交到审批通过的平均时长，以及每个节点的停留时间。某个节点经常卡住几天，说明审批人负担过重或者流程设计不合理。数据支撑流程优化的方向，不是空泛地讨论“流程太长”。

重复申请的归因统计也很重要。编码申请被驳回的原因可以分类统计，名称重复占比多少，规格不符占比多少，分类错误占比多少。驳回原因的数据可以反推培训和流程改进的重点。某种原因占比特别高，说明用户在某个环节普遍存在理解偏差。

操作行为分析能发现一些值得注意的现象。用户创建新编码前有没有执行查重操作，查重结果显示可能重复时有没有选择“仍然申请”。这些行为数据可以反映查重功能好不好用、用户的使用习惯是否需要引导。

从被动响应到主动治理

主数据管理的成熟度，可以从问题的发现方式来判断。低成熟度的状态是问题爆发了才知道。业务部门投诉了，管理层过问了，才去处理。处理完就结束了，没有复盘，没有根因分析。同样的问题过段时间还会再发生。

中等成熟度的状态是定期检查发现的问题。编码管理员每月检查一次编码表，发现重复就合并，发现缺失就补全。问题在处理，但更多是事后补救，还没有做到事前预防。

高成熟度的状态是系统主动预警的问题。编码重复率超过阈值自动告警，字段缺失率趋势异常自动推送，流程卡顿节点自动提醒。问题在影响业务之前就被发现和处理。系统在帮人发现问题，人只需要做判断和决策。

从低到高的演进，需要把越来越多的隐性问题显性化。数据结构问题、流程缺陷、责任模糊，这些冰山下面的问题，需要通过数据、分析、沟通，一层一层挖出来，一个一个解决。每解决一个隐性问题，水面上的问题就会减少一批。这不是短期的项目，是长期的演进过程。

主数据管理的重心在水面之下。数据结构、流程设计、责任划分，这些不直接产生报表指标，但它们支撑着一切数据操作。隐性问题积累多了，水面上的问题就会反复出现。每次解决一个水面上的问题，如果不解决水面下的根源，问题迟早还会再来。

与其每个月花一周时间清理重复编码，不如花一个月时间把产生重复的流程改掉。与其每季度组织一次数据质量攻坚，不如把数据责任落实到日常岗位。前者是救火，后者是防火。救火很紧急，防火更重要。

新易编码在这个过程中的作用是提供冰山下的数据视图。哪些字段从来不用，哪些节点经常卡住，哪种驳回原因最常见。这些数据是隐性问题显性化的工具，也是决策的依据，不是靠猜测和感觉。

 

如果您有物料编码相关的问题，欢迎咨询新易物料编码