很多业的数据问题，看起来是报表对不上，实际上往往从更前面就乱了。同一个客户，在CRM里一个名字，在ERP里一个编码，到了财务系统又变成另一套说法。人知道它们是同一个客户，系统不知道。
于是，销售额重复计算、客户利润对不上、库存和订单也越查越乱。问题的根源，通常绕不开三类数据：主数据、元数据、参考数据。
简单来说： 主数据管“是谁、是什么”； 元数据管“数据怎么理解、从哪里来”； 参考数据管“按照什么标准分类和取值”。
下面就把主数据、元数据、参考数据一次讲清。
一、先用三个问题，快速区分三类数据
遇到一项数据，不知道它属于哪一类，可以先问三个问题。
1、它是不是企业反复使用的核心业务对象？
比如：客户、供应商、商品、物料、员工、组织、设备、门店。如果是，它大概率属于主数据。
2、它是不是在描述另一项数据？
比如：字段名称、字段类型、数据来源、更新时间、指标口径、负责人、加工关系。如果是，它大概率属于元数据。
3、它是不是一套用于分类、判断或约束的标准值？
比如：国家代码、币种代码、订单状态、客户等级、计量单位、行业分类。如果是，它大概率属于参考数据。
可以先记住一句话： 主数据是业务对象，元数据是数据说明书，参考数据是标准词典。
二、主数据：企业反复使用的核心业务对象
主数据，是企业在多个系统和业务流程中反复使用的核心实体数据。常见的主数据包括：客户、供应商、商品、物料、组织、员工、设备、门店和账户。
比如一张销售订单中包含：订单编号；客户；商品； 销售人员；订单金额；下单时间。
订单金额和下单时间，是这笔交易产生的数据。而客户、商品、销售人员会被大量订单反复引用，它们就是典型的主数据。
主数据通常有4个特点
1、跨系统使用
客户信息不仅存在于CRM它还会出现在ERP、财务、合同、客服和仓储系统中。商品数据也一样。销售要用，采购要用，生产、库存和物流同样要用。
2、相对稳定
订单每天都在新增，交易状态不断变化。但客户、供应商和商品不会每分钟创建一次。它们也会发生变化，只是变化频率通常低于交易数据。
3、被大量业务引用
一条客户主数据，可能关联几千张订单、合同和发票。一条物料主数据，可能贯穿采购、生产、库存和成本核算全过程。
4、必须具有唯一身份
同一个客户，最好只有一个统一编码。同一个物料，也应该只有一个标准物料号。否则，一个对象被系统识别成多个对象，后面的销售额、采购额、库存量和利润都会出现重复或遗漏。
主数据治理的核心，不只是统一名称，而是确认“同一个对象就是同一个对象”。
三、主数据为什么会越管越乱？
主数据问题通常不是突然出现的。它是在企业不断增加系统、部门和业务的过程中，一点点积累起来的。
以客户数据为例。销售在CRM里新建一次。财务开票时又建一次。ERP上线后再导入一份。电商平台按照店铺账号识别客户。售后系统则按照手机号识别客户。
时间一长，同一个客户可能有多个名称、多个编码。有些记录名称相同，实际却不是同一家企业。有些记录名称不同，实际反而属于同一客户。
企业想统计客户销售额时，就容易出现：销售部门算出来是1000万元。财务部门算出来是920万元。经营分析又算出1050万元。
表面看，是报表口径不一致。实际上，问题可能更早就发生了：客户主数据根本没有统一。
商品和物料也一样。销售系统按照商品编码管理。生产系统按照物料编码管理。仓库按照SKU管理。财务则按照存货编码核算。
如果这些编码没有建立映射关系，企业就很难回答：这个商品到底卖了多少？它对应消耗了哪些物料？目前还有多少库存？最终贡献了多少利润？
所以，主数据治理通常要经过：识别、去重、匹配、合并、编码、补全、审核、发布和持续维护。
真正落地时，第一步往往不是急着制定新编码，而是先把分散的数据集中起来。只有先把不同系统中的“客户”放到一起，企业才有机会判断哪些记录属于同一个客户。
但这里要特别注意：工具可以执行规则，不能替企业决定规则。 哪个系统是客户数据的权威来源？两条客户记录是否应该合并？客户编码应该按照什么规则生成？这些仍然需要业务、财务和数据部门共同确认。
四、元数据：不是业务数据，而是“关于数据的数据”
元数据经常被解释为：描述数据的数据。 听起来有点绕，但举个例子就明白了：
一张销售订单表里记录：客户A购买了10件商品；订单金额为5万元；下单时间为7月10日。这些属于业务数据。
而下面这些信息，则属于元数据： 这张表叫什么？ 存在哪个数据库？多久更新一次？订单金额是什么字段类型？金额是否含税？销售额按照什么公式计算？数据来自哪个系统？经过了哪些清洗步骤？由谁负责维护？元数据不直接描述客户买了什么。
它描述的是：这些数据应该怎么理解、怎么找到、怎么使用。
元数据通常可以分成三类
1、技术元数据
技术元数据主要描述数据在技术系统中的形态。
例如：数据库名称；表名称；字段名称；字段类型；字段长度；主键和外键；存储位置；上下游依赖关系。
技术人员通过它判断：数据存在哪里？应该查询哪张表？修改一个字段，会影响哪些任务和报表？
2、业务元数据
业务元数据主要解释数据在业务上的含义。
例如：指标名称；业务定义；计算公式；统计范围；数据负责人；适用部门；更新频率。
比如“销售额”这个指标，至少要说清楚：按下单时间还是支付时间统计？
是否含税？是否扣除退款？取消订单算不算？跨月退款怎么处理？
没有业务元数据，同一个指标就可能出现多个版本。 销售部门有一个销售额。财务部门有一个销售额。
老板驾驶舱里又出现第三个销售额。大家使用同一个名字，算的却不是同一件事。
3、运行元数据
运行元数据主要记录数据任务运行过程中发生了什么。
例如：任务什么时候开始？什么时候结束？ 是否执行成功？处理了多少条数据？出现了多少异常记录？ 哪个节点执行失败？数据最后更新到了几点？这类信息非常重要。
因为企业经常遇到一种情况：报表看起来没有报错，数字也正常展示，但实际使用的还是昨天的数据。
这时就要继续判断：源系统今天有没有产生数据？同步任务是否完成？清洗任务有没有失败？下游汇总任务是否按时执行？
所以，元数据不仅告诉我们“数据是什么意思”。它还要告诉我们：数据从哪里来，经过了什么处理，现在是否正常。
五、参考数据：统一分类和取值的标准词典
参考数据，是用于分类、描述和约束其他数据的一组标准值。它通常以代码表、字典表或枚举值的形式存在。
常见的参考数据包括：国家和地区代码；币种代码；计量单位；订单状态；客户等级；行业分类；付款方式；证件类型。
比如，不同系统对订单状态的表达可能完全不同。
CRM里是：1：待处理；2：处理中；3：已完成。ERP里是：A：新建；B：已审核；C：已关闭。电商平台则是：WAIT_PAY；WAIT_SEND；FINISHED。
这些值不是客户、商品这样的具体业务对象。它们是一组用于描述订单状态的分类标准，所以属于参考数据。
参考数据治理要解决的是：代码是否统一？不同系统如何映射？ 哪些代码已经停用？新增代码由谁审批？标准变化后，怎么同步给下游系统？
再比如币种。有的系统写“人民币”、有的写“RMB”、有的写“CNY”。业务人员都能看懂，但系统汇总时，可能把它们识别成三种不同币种。
这时，就需要建立统一标准：标准代码：CNY；中文名称：人民币；英文名称：Chinese Yuan；历史编码：RMB；启用时间； 适用范围。
标准确定以后，还要解决一个很现实的问题：不同系统里的旧代码，怎么转换成统一代码？ 这时，可以在数据开发流程中建立转换和映射规则。
比如：RMB统一转换成CNY；01、A、WAIT_PAY统一映射为“待付款”；VIP、A类、重点客户统一映射为“重点客户”。
源系统可以暂时保留原来的编码。数据进入数仓或分析平台时，再统一转换成企业标准值。这样不需要一次性改造所有历史系统，也能保证后续分析使用同一套口径。
如果参考数据发生变化，还可以通过定时任务或数据服务，将新的标准数据同步给下游系统。参考数据看起来只是一张小小的代码表，却决定了不同系统能不能使用同一种语言。
六、主数据和参考数据，最容易混在哪里？
主数据和参考数据都相对稳定，也都会被大量业务数据引用，所以最容易混淆。判断方法其实很简单：主数据描述具体业务对象，参考数据描述这些对象所属的类别、状态和规则。
例如：客户A，是主数据；客户等级“战略客户”，是参考数据。商品X，是主数据；商品类别“办公设备”，是参考数据。
供应商B，是主数据；供应商状态“合格”，是参考数据。设备C，是主数据；设备类型“数控机床”，是参考数据。员工D，是主数据；员工状态“在职”，是参考数据。
再看一个完整场景：“浙江省杭州市的某个客户”中，客户本身属于主数据；浙江省、杭州市等行政区划代码属于参考数据；客户表名称、字段定义和数据来源属于元数据。三类数据会同时出现在一项业务里，但承担的职责不同。
七、用一张销售订单，看懂三者的关系
假设系统里产生了一张销售订单：客户：华东机械有限公司；商品：工业设备A；币种：CNY；客户等级：重点客户；订单状态：已发货；订单金额：10万元。
在这张订单中：
主数据包括什么？
华东机械有限公司；工业设备A；负责销售的员工；负责发货的仓库；订单所属的销售组织。它们是被订单引用的核心业务对象。
参考数据包括什么？
币种CNY；客户等级“重点客户”；订单状态“已发货”；计量单位“台”；付款方式“银行转账”。它们用于分类、描述和约束订单内容。
元数据包括什么？
订单表存在哪个数据库；客户编码字段叫什么；订单金额是否含税；销售额怎么计算；数据来自哪个系统；订单数据经过了哪些加工步骤。它们负责解释整套数据。
所以，三者之间的关系可以概括为： 主数据构成业务对象，参考数据提供标准分类，元数据负责解释数据及其加工过程。
八、为什么三类数据必须放在一起治理？
只管主数据，不管元数据，会出现什么？ 客户编码虽然统一了，但业务不知道应该使用哪个字段。商品记录虽然合并了，却说不清数据来自哪个系统。指标出现异常，也无法追溯加工过程。
只管元数据，不管主数据呢？ 表、字段和血缘关系登记得很清楚。但同一个客户依然有多个编码。
数据链路虽然能追溯，追到的却是一堆重复和错误的数据。
只管参考数据，同样不够。客户等级代码统一了，但同一个客户仍然存在三条记录。
所以，三类数据解决的是三个不同层面的问题：主数据解决对象统一； 参考数据解决规则统一； 元数据解决认知和过程统一。
它们共同决定企业的数据是否能够做到：找得到； 看得懂； 对得上； 追得回； 用得准。
九、三类数据治理，可以按照这6步落地
第一步：盘点核心对象
先梳理企业到底有哪些核心主数据。常见的包括：客户、供应商、商品、物料、组织、员工、设备和门店。同时明确，这些数据分别存在于哪些系统中。
第二步：明确权威来源
每一类主数据都要回答：由哪个部门负责？哪个系统可以创建？哪个系统是权威来源？谁有权审核和修改？不能让所有系统都随意新增同一类数据。否则，重复数据会不断产生。
第三步：统一标准
明确：编码规则；字段名称；必填内容； 命名规范；去重逻辑； 合并规则；状态规则；参考代码。
标准不清楚，工具跑得再快也没有意义。错误的数据自动化流转，只会让错误扩散得更快。
第四步：统一接入和清洗
利用FineDataLink等数据集成工具，将分散在数据库、系统和文件中的数据统一接入。
再按照已经确定的规则，完成： 字段转换；名称清洗； 空值处理；编码映射； 数据关联；重复记录识别。
一开始不必铺得太大。可以优先治理问题最多、影响最大的三类数据：客户、供应商和商品。
第五步：形成标准记录并分发
完成清洗和审核后，形成统一的标准数据。再将这些数据同步给数仓、分析平台和业务系统。避免每个部门继续维护自己的版本。
比如标准客户数据形成后，可以同步给： CRM； ERP； 财务系统； 合同系统； 数据仓库。这样，企业各系统看到的才是同一个客户。
第六步：持续监控和运营
数据治理不是做完一次就结束。新客户会不断增加。商品信息会持续调整。供应商会被停用。参考代码也会发生变化。
因此，需要持续检查：客户编码是否重复？统一社会信用代码是否缺失？商品分类是否为空？参考代码是否超出允许范围？停用客户是否仍然产生新订单？数据任务是否按时执行？标准数据是否已经同步到下游？
数据治理不是一次数据清洗，而是一套长期运营机制。
十、三类数据治理最容易踩的5个坑
1、一上来就给所有数据重新编码
企业还没盘点清楚现有数据，就急着设计一套全新编码。结果旧系统无法改，新系统又不接受，最后反而多出一套编码。主数据治理首先要识别和映射，再判断哪些编码需要保留、替换或停用。
2、只做一次性清洗
找团队集中清洗三个月，数据看起来终于干净了。半年后，重复客户和错误商品又全部回来。
因为入口没有控制，规则也没有持续运行。一次清洗解决的是历史问题，持续治理解决的才是未来问题。
3、只让IT部门负责
主数据标准、指标口径和参考代码，本质上都来自业务。IT可以建设系统、执行规则，却不能单独判断哪个客户应该合并、哪个订单状态最合理。数据治理必须有业务参与。
4、把工具当成治理本身
工具能够同步、转换、调度和监控数据。但它不能替企业划分责任、定义标准和审批规则。工具是治理规则的执行载体，不是治理规则本身。
5、只管数据进入，不管数据输出
标准数据清洗完成后，只留在数据平台里。业务系统仍然使用自己的旧数据。结果是分析端统一了，业务源头却继续制造混乱。治理后的标准数据，必须能够重新分发和共享。
十一、写在最后
主数据、元数据和参考数据，看起来是三个技术概念。背后对应的，却是三个非常实际的管理问题。
主数据回答：企业到底在管理哪些核心对象？ 元数据回答：这些数据是什么意思、从哪里来、经过了什么加工？ 参考数据回答：这些数据按照什么标准分类和取值？
客户、供应商、商品属于主数据。字段定义、指标口径、数据来源和加工关系属于元数据。币种、地区、状态、等级和计量单位属于参考数据。
它们不是互相替代的关系。而是共同构成企业数据治理的基础。
没有统一主数据，同一个客户会被计算很多次。没有统一参考数据，同一种状态会出现多种表达。没有完整元数据，数据出了问题，也不知道应该从哪里排查。
数据集成和数据开发工具，解决的是治理规则确定以后的落地问题：把分散数据接进来，把清洗转换流程跑起来，把标准数据同步出去，把整条任务链路监控起来。
但工具只是手段。工具决定数据能不能顺畅流动，治理规则决定流动的到底是不是正确数据。
真正成熟的数据治理，不是接了多少系统，也不是建了多少张表。而是能够做到：主数据统一对象，参考数据统一规则，元数据统一认知。
