主数据管理中的“需求前置”成本：为什么标准

标准定完了，业务说用不了

某集团企业启动主数据管理项目，第一阶段工作是制定数据标准。项目组访谈了各业务部门，收集了几百条需求，开了十几场评审会，历时四个月，终于发布了一套涵盖客户、物料、供应商、组织架构的完整标准。标准文档印刷精美，装订成册，分发到各部门。

分发后的反馈陆续传来。销售部说客户分类太细，很多选项用不上，填起来费时。采购部说物料属性字段太多，供应商根本不提供这些信息。仓库说编码规则太复杂，记不住，扫码枪也不支持这么长的编码。技术部说BOM中的物料分类和生产部的分类对不上，同一个物料两套归类。

项目组很困惑：需求是你们提的，评审是你们参加的，标准是你们确认的，为什么用的时候又说不行。业务部门的回答是：提需求的时候不知道系统里是这么实现的，评审的时候不知道实际操作是这么麻烦的。

这就是主数据管理中的“需求前置”困境。标准在脱离实际操作的条件下制定，业务部门在缺乏实操体验的情况下确认需求，等标准落地到系统中、业务人员开始实际使用时，问题才真正暴露出来。标准定完了，业务说用不了。

需求前置为什么经常失效

需求前置的逻辑是：在设计阶段把需求搞清楚，避免后期返工。这个逻辑在技术实现层面成立，在主数据标准层面经常失效。因为数据标准的最终用户是业务操作人员，而业务操作人员在标准制定阶段通常不在场。参加需求访谈和标准评审的是业务部门的负责人或骨干，他们了解业务流程，但不一定了解一线操作的具体细节。客户分类有十几个选项，负责人觉得分类细致有利于分析，一线销售觉得选起来太麻烦。物料属性有二十多个字段，技术主管觉得信息完整有利于追溯，仓库文员觉得每天要多花半小时录入。

决策者和执行者的需求错位，在标准制定阶段很难被发现。决策者倾向于追求信息的完备性，执行者倾向于追求操作的简便性。标准制定阶段决策者主导，标准落地阶段执行者主导。两拨人不是同一拨人，标准在制定时满足了决策者的需求，在执行时满足不了执行者的需求。

需求前置失效的另一个原因是业务部门在标准制定阶段缺乏实操体验。评审标准文档时，业务部门看到的是抽象的规则描述。编码规则第1-2位是大类、3-4位是小类、5-8位是流水号。评审时没人觉得有问题。等到真正要编编码时，才发现记不住大类和小类的对应关系，每次都要翻手册。抽象规则的评审和具体操作的体验之间存在认知差距。标准在评审阶段看起来没问题，用起来全是问题。

标准制定的迭代成本

主数据标准不是一次设计出来的，是在使用过程中逐步收敛出来的。这个认识在很多企业中还没有建立起来。主数据管理项目通常被当作一次性工程来管理。立项、调研、设计、开发、上线、验收，验收后就转交运维。标准在项目阶段一次性定稿，运维阶段只负责执行，不负责修改。这种项目管理模式与主数据标准的演进规律不匹配。

标准第一次定出来，一定有问题。业务场景没有覆盖全，分类粒度不合理，属性字段过多或过少，编码规则太复杂或区分度不够。问题只有在实际使用中才会暴露，使用三个月后暴露一批，使用半年后又暴露一批。标准定稿时认为的“完美”，在使用过程中会被不断挑战。

标准的迭代成本随迭代轮次递减。第一次迭代改动最大、成本最高，涉及规则重构、历史数据迁移、下游系统适配。第二次迭代改动量减少，第三次进一步减少。标准收敛到稳定状态后，迭代频率大幅降低。但很多企业在第一次迭代时就放弃了，理由是“项目已经验收了，没有预算再改了”。标准收敛的过程被中断，标准停留在“能用但不好用”的状态，使用部门的抱怨持续存在。

从“一次性定稿”到“持续收敛”

标准制定模式的转变，需要从项目管理和资源投入两个层面调整。项目管理上把标准迭代纳入项目范围，不把标准定稿作为项目验收的终点。项目计划中预留两到三个迭代周期，第一期标准上线后运行三个月，收集使用反馈，做第一次迭代优化。第二期运行三个月，做第二次迭代优化。标准收敛到稳定状态后再正式转交运维。迭代周期的长度取决于业务复杂度和使用频率。业务场景多、使用频率高的主数据，迭代周期可以缩短到一个月；业务场景相对稳定、使用频率低的主数据，迭代周期可以放宽到半年。

资源投入上需要预留标准优化的专项预算，不能把标准迭代当作“免费售后服务”依赖供应商。供应商的项目团队在验收后就会撤场，后续的迭代优化需要企业自己的数据治理团队承接。企业需要在项目阶段同步建设内部的数据治理能力，包括标准配置、规则调整、影响分析、版本管理。标准迭代的工作量需要被纳入数据治理团队的常规工作范围，不能当作“额外的”工作。

标准的持续收敛还需要配套的数据监控机制。哪些分类选项使用频率最高，哪些属性字段经常被跳过，哪些校验规则经常触发错误。使用数据的分析结果是标准迭代的输入，不是靠感觉判断哪个地方需要改。物料分类中某几个细类过去半年只被使用过三次，可以考虑合并到相邻分类或降级为属性字段。编码规则中某一段位经常填错，说明规则设计不合理或者培训不到位。

新易编码中的标准迭代支持

主数据标准在编码管理这个具体领域的迭代收敛，新易编码提供了规则配置、版本管理、使用分析三方面的支持。

编码规则在系统中可视配置，业务人员可以自己调整，不需要依赖IT开发。分类体系需要扩展，在配置界面中增加新的分类代码，不需要改代码、不需要走上线流程。调整完成后，新规则立即生效，新编码按新规则生成。标准迭代的技术门槛大幅降低。

编码规则的版本管理记录每次变更的内容、时间、操作人。标准迭代的历史可追溯，迭代过程中可以随时回退到之前的版本。编码规则调整后，新旧版本的编码可以并行运行，历史数据不需要一次性重写。版本管理支持分批、分时迁移，迭代风险可控。

编码使用数据的统计分析为标准迭代提供量化依据。分类选项的使用频率统计可以检验分类粒度的合理性，用户驳回率可以反映规则设计的友好程度，引用频率可以识别需要优先优化的数据。标准迭代的方向不是靠主观判断，是根据数据结论来定。数据支撑的迭代才能把准方向，拍脑袋的迭代只会从一个不合适改到另一个不合适。

主数据标准定不到点子上，不是因为做标准的人不专业，是因为标准制定时缺少实操体验，决策者和执行者不是同一拨人，标准迭代没有被纳入项目管理范围。需求前置的成本之所以高，是因为前置的需求不是真实的需求，是“想象中”的需求。业务部门在标准制定阶段想象不到实际操作中的问题，这些问题要到系统上线后才会浮出水面。

解决这个问题不是放弃需求前置，是在需求前置阶段就开始小范围试跑。标准定出初稿后，不急着发布全公司，选一个业务量适中的部门或一种物料类别先试跑。试跑一个月，收集问题，调整规则，再试跑一个月。标准在小范围试跑中收敛到稳定状态后，再向全公司推广。试跑阶段的投入是需求前置的一部分，这部分投入可以节省后续大范围返工的成本。

标准的每一次迭代都是对“真实需求”的一次逼近。迭代的速度决定了标准收敛的速度。标准收敛的速度决定了主数据管理的成熟速度。迭代的阻力越小，标准的演进就越快。标准的演进越快，主数据管理的效果就越早被业务部门感知到。业务部门感知到效果后，对标准迭代的配合度也会相应提升，形成正向循环。

 

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