简介这份Word文档是神华集团公司主数据管理规定的完整正式文本面向大型企业集团的信息化管理、数据治理及业务部门人员用于解决主数据标准不统一、质量参差、安全管控缺失等实际问题。资源包内仅含1个doc文件大小约348KB内容为可编辑的规章制度全文便于企业内部参照制定或修订自身的主数据管理细则。文档系统阐述了主数据管理组织与职责、主数据标准、维护与使用、质量及安全管理等核心章节明确了CIO领导下的联席会工作机制并给出业务标准与技术标准的划分方式以及公开级、普通商密级、核心商密级三级安全分级框架。目前已有75人学习浏览适合需要搭建主数据管理体系、厘清跨部门职责边界或编写数据管理制度的从业者参考可快速获取权威的流程模板与术语定义。1. 主数据管理规定落地从一份制度文档到可执行的数据治理规则很多团队拿到一份主数据管理规定第一反应是“制度文件而已归档了事”。但真正做过主数据治理的一线工程师都清楚这类文档如果只停留在纸面后面等着你的就是各业务系统里客户编码重复、物料名称五花八门、组织架构对不上号等到要做经营分析时才发现数据根本没法拉通。主数据管理规定的核心价值是把“谁在什么时间、按什么规则、对哪类数据、做什么操作”这件事定义清楚让数据从源头就是一致的、可信的。这份规定通常覆盖主数据的定义与分类、管理组织与职责、标准与编码规则、申请与变更流程、质量管理与考核这几个板块。它适合正在推进数据治理的数据管理员、IT负责人、业务系统对接人以及需要跨系统拉通数据的分析师。如果你所在的组织已经有多套业务系统各自维护客户、物料、组织数据那这份规定的落地就是刚需不是可选项。2. 主数据管理规定拆解五类核心对象与职责矩阵怎么定2.1 先搞清楚哪些数据算主数据主数据不是所有数据而是那些在多个业务系统之间共享、相对稳定、一旦出错影响面很大的核心实体数据。常见的主数据对象包括客户、供应商、物料、组织架构、人员、科目、银行账户等。判断一条数据是不是主数据可以问三个问题它是否被两个以上系统引用它的变更是否需要跨部门协调它的错误是否会导致业务中断或报表失真三个问题有两个答“是”基本就可以纳入主数据管理范围。在实际操作中我一般会先做一轮数据资产盘点把各系统里的核心实体列出来然后按“共享度”和“影响度”两个维度打分。共享度高、影响度大的优先纳入。这一步不需要工具一张表格就能搞定数据对象涉及系统数变更频率错误影响是否纳入主数据客户信息5中高是物料编码4低高是组织架构6低高是员工通讯录2高低否项目编号3中中待定这张表的价值在于它让“哪些数据要管”这件事从主观判断变成可讨论的决策依据。注意不要试图一次把所有数据都纳入主数据管理那会让项目周期无限拉长先管住最痛的两三类数据跑通流程后再扩展。2.2 职责矩阵谁申请、谁审核、谁维护主数据管理规定里最容易写得含糊的就是职责部分。很多制度写“数据管理部负责主数据管理”但具体到一条客户数据的新增谁提申请、谁做初审、谁做终审、谁负责录入、谁负责质量监控往往没有说清楚。落地时我建议用RACI矩阵把每类主数据的每个操作环节都定到岗位操作环节业务部门数据管理岗IT支持岗数据Owner新增申请RI—A标准审核CR—A编码分配—RCA系统录入RCRA质量检查IRCA变更审批RC—AR是执行、A是最终负责、C是被咨询、I是被通知。这张矩阵定下来之后每个环节卡住都能找到对应的人不会出现“我以为你会审”的情况。数据Owner通常是业务侧的分管负责人不一定是IT的人这一点很关键——主数据的标准应该由业务定IT负责实现和保障。2.3 编码规则别让“唯一标识”变成新的混乱源主数据编码是整个管理规定里技术含量最高、也最容易翻车的部分。常见做法是分段编码比如物料编码用“大类2位中类2位小类2位流水号4位”的10位结构。但这里有个血泪经验编码规则一旦发布就不要轻易改。我见过一个项目物料编码从8位升到10位结果所有历史系统的映射关系全部要重做花了三个月才收拾干净。编码规则设计时要考虑三个约束唯一性、可扩展性、无含义或弱含义。唯一性是底线可扩展性是指未来新增品类时不用推翻重来无含义是指编码本身不承载太多业务信息——因为业务分类会变编码如果嵌入了分类信息分类一调整编码就废了。如果非要用有含义编码建议把含义部分控制在2到3位其余用流水号。# 物料主数据编码生成示例大类2位 中类2位 流水号6位 # 大类和中类来自标准分类表流水号按大类中类维度自增 import sqlite3 def generate_material_code(category_major, category_minor, db_path): category_major: 大类代码2位字符串如 01 category_minor: 中类代码2位字符串如 03 db_path: SQLite数据库路径存储已分配的流水号 返回10位物料编码如 0103000001 conn sqlite3.connect(db_path) cursor conn.cursor() # 查询当前大类中类下的最大流水号 cursor.execute( SELECT MAX(seq_no) FROM material_code_seq WHERE major? AND minor?, (category_major, category_minor) ) row cursor.fetchone() next_seq (row[0] or 0) 1 # 更新流水号表 cursor.execute( INSERT OR REPLACE INTO material_code_seq (major, minor, seq_no) VALUES (?, ?, ?), (category_major, category_minor, next_seq) ) conn.commit() conn.close() # 拼接编码大类2位 中类2位 流水号6位 return f{category_major}{category_minor}{next_seq:06d} # 调用示例 code generate_material_code(01, 03, mdm.db) print(code) # 输出类似 0103000001这段代码的关键在于流水号是按“大类中类”维度独立自增的而不是全局自增。这样做的好处是编码前4位能看出品类后6位是流水既保留了弱含义又保证了唯一性。参数说明category_major和category_minor必须来自已发布的标准分类表不能随意填db_path指向存储流水号的数据库生产环境建议用独立的主数据管理库而不是业务库。注意并发场景下需要加锁或改用数据库序列否则可能生成重复流水号。3. 从规定到系统主数据申请与变更流程的落地实现3.1 申请流程的四个状态与流转条件主数据管理规定里写的流程通常是“申请→审核→发布→生效”但落到系统里需要更细的状态定义。我一般会设计六个状态草稿、待初审、待终审、已发布、已生效、已冻结。草稿是申请人还在编辑待初审是提交后等数据管理岗做标准符合性检查待终审是初审通过后等数据Owner做业务合理性审批已发布是审批通过但还没同步到目标系统已生效是已经同步到所有消费系统已冻结是数据不再使用但保留历史记录。状态流转的条件必须写死在系统里不能靠人工判断。比如“待初审→待终审”的条件是必填字段完整、编码符合规则、附件齐全。“已发布→已生效”的条件是所有目标系统返回同步成功。任何一个条件不满足状态就不能流转并且要给出具体的失败原因。-- 主数据变更申请表结构示例 CREATE TABLE mdm_change_request ( request_id BIGINT PRIMARY KEY AUTO_INCREMENT, data_domain VARCHAR(32) NOT NULL COMMENT 主数据域customer/material/org, operation_type VARCHAR(16) NOT NULL COMMENT 操作类型create/update/freeze, request_data JSON NOT NULL COMMENT 申请数据内容, status VARCHAR(16) NOT NULL DEFAULT draft COMMENT 状态, applicant VARCHAR(64) NOT NULL, submit_time DATETIME, first_reviewer VARCHAR(64), first_review_time DATETIME, final_reviewer VARCHAR(64), final_review_time DATETIME, publish_time DATETIME, effective_time DATETIME, INDEX idx_status (status), INDEX idx_domain (data_domain) ) COMMENT主数据变更申请主表; -- 变更明细表记录每次字段级修改 CREATE TABLE mdm_change_detail ( detail_id BIGINT PRIMARY KEY AUTO_INCREMENT, request_id BIGINT NOT NULL, field_name VARCHAR(64) NOT NULL, old_value TEXT, new_value TEXT, FOREIGN KEY (request_id) REFERENCES mdm_change_request(request_id) ) COMMENT主数据变更字段明细;这两张表的设计要点主表用JSON字段存申请数据灵活适配不同主数据域的字段差异明细表记录字段级变更方便审计和回溯。status字段的取值要在应用层做枚举约束不要用数据库的ENUM类型因为状态可能会增加。data_domain加索引是因为按域查询是最常见的操作。注意JSON字段虽然灵活但不要把所有查询条件都压在JSON里关键字段还是要单独建列。3.2 审核环节的自动化校验规则审核环节如果全靠人工看效率低且容易漏。我一般会把能自动化的校验规则前置到提交环节审核人只看自动化规则无法判断的部分。常见的自动校验规则包括编码格式是否符合标准、必填字段是否完整、名称是否与已有数据重复、银行账号是否符合校验规则、统一社会信用代码是否合法等。# 主数据提交前的自动校验规则示例 import re def validate_customer(data): data: dict包含客户主数据的各字段 返回(是否通过, 错误信息列表) errors [] # 规则1客户名称不能为空且长度不超过100 name data.get(customer_name, ).strip() if not name: errors.append(客户名称不能为空) elif len(name) 100: errors.append(客户名称长度不能超过100字符) # 规则2统一社会信用代码为18位符合GB 32100格式 uscc data.get(uscc, ).strip() if uscc: pattern r^[0-9A-HJ-NPQRTUWXY]{2}\d{6}[0-9A-HJ-NPQRTUWXY]{10}$ if not re.match(pattern, uscc): errors.append(统一社会信用代码格式不正确) # 规则3客户类型必须在枚举范围内 valid_types [企业, 个人, 政府机构, 事业单位] if data.get(customer_type) not in valid_types: errors.append(f客户类型必须是{valid_types}之一) # 规则4如果客户类型是企业统一社会信用代码必填 if data.get(customer_type) 企业 and not uscc: errors.append(企业客户必须填写统一社会信用代码) return (len(errors) 0, errors)这段校验代码的逻辑是分层校验先校验必填和长度再校验格式最后校验字段间的依赖关系。参数说明data是从申请表单收集的字典字段名要与主数据标准中的字段定义一致。注意校验规则要可配置不要硬编码在代码里——因为业务规则会变硬编码意味着每次调整都要改代码发版。我一般会把规则存到数据库或配置中心代码只负责执行。3.3 发布与同步确保各消费系统拿到一致的数据主数据审批通过后最关键的一步是同步到各消费系统。常见做法有两种推模式和拉模式。推模式是主数据系统主动调用各业务系统的接口推送数据拉模式是各业务系统定时从主数据系统拉取变更。推模式实时性好但耦合度高拉模式解耦但有时延。我一般建议核心系统用推模式边缘系统用拉模式混合使用。同步时必须记录同步日志包括同步批次号、目标系统、数据条数、成功条数、失败条数、失败原因。同步失败的要有重试机制重试三次仍失败的要告警。这里有个容易忽略的点同步顺序。如果客户和组织架构同时变更而客户数据里引用了组织编码那必须先同步组织再同步客户否则会出现外键引用失败。这个顺序要在同步配置里显式定义。4. 避坑指南主数据管理规定落地时最容易翻车的五个地方4.1 制度写了但系统没跟上流程卡在半空现象规定里写了“所有物料新增必须走主数据申请流程”但业务系统里物料新增入口还在业务人员直接在老系统里建了主数据系统根本不知道。原因只发了制度文件没有同步关闭业务系统的直接维护入口。解决主数据管理落地必须和业务系统的权限调整同步进行先关入口再发制度或者至少同时进行。我一般会建议在业务系统里把主数据的新增/修改权限收掉只保留查询权限从源头上堵住。4.2 编码规则设计得太“聪明”业务一变就废现象物料编码里嵌入了部门代码和年份结果部门调整后编码对不上年份跨年后旧编码规则不适用。原因编码承载了太多业务含义而业务含义是会变的。解决编码只保留最稳定的分类信息且分类层级不超过两级其余用流水号。如果业务上确实需要表达更多信息用属性字段而不是编码。4.3 审核环节设了太多人流程走完要一周现象一条客户数据新增要经过业务员、业务主管、数据管理岗、数据Owner、IT支持五道审核平均耗时五天。原因审核环节没有区分“必须人工判断”和“可以自动校验”的部分把所有校验都压到了人工审核。解决把格式校验、重复校验、枚举校验全部自动化人工只审核业务合理性。审核层级控制在两级以内数据管理岗做标准审核数据Owner做业务审核。4.4 历史数据没清洗就直接导入垃圾进垃圾出现象主数据系统上线时把各业务系统的历史数据直接导入结果同一个客户在系统里有五条记录名称略有不同。原因没有做历史数据清洗和去重就直接迁移。解决上线前必须做一轮历史数据清洗至少包括去重按统一社会信用代码或名称地址、补全必填字段缺失的补全或标记、标准化名称去掉多余空格、统一简称。清洗规则要提前定好清洗结果要业务确认。4.5 没有数据质量监控用着用着就烂了现象主数据系统上线三个月后发现客户数据里又出现了重复记录有些记录的必填字段是空的。原因只建了申请流程没有建质量监控机制。解决主数据质量管理规定里要包含定期质量检查的条款至少每月跑一次质量报告检查重复率、完整率、准确率。质量报告要发到数据Owner并且和考核挂钩。没有考核的质量管理就是纸老虎。5. 主数据质量监控的进阶做法从月度报表到实时拦截前面讲的都是流程和规则层面的东西这一章说一个更具体的技巧怎么把质量监控从“事后报表”变成“事中拦截”。我见过太多团队每个月出一份质量报告然后业务部门看一眼就放一边了下个月同样的问题还在。真正有效的做法是在数据进入主数据系统的入口就做实时拦截让脏数据根本进不来。具体做法是在申请提交的API里嵌入质量校验链每条规则有明确的错误码和提示信息。校验链的执行顺序是必填校验→格式校验→枚举校验→重复校验→业务规则校验。前四类可以完全自动化第五类如果规则明确也可以自动化规则不明确的才转人工。校验不通过的直接返回错误码申请人当场就能改不用等审核环节再打回来。# 质量校验链的简化实现 class QualityChecker: def __init__(self): self.rules [] def add_rule(self, name, checker_func, error_code, error_msg): 注册一条校验规则 self.rules.append({ name: name, checker: checker_func, code: error_code, msg: error_msg }) def check(self, data): 执行所有规则返回错误列表 errors [] for rule in self.rules: try: if not rule[checker](data): errors.append({ rule: rule[name], code: rule[code], message: rule[msg] }) except Exception as e: errors.append({ rule: rule[name], code: SYS_ERROR, message: f校验规则执行异常{str(e)} }) return errors # 使用示例 checker QualityChecker() checker.add_rule( 客户名称必填, lambda d: bool(d.get(customer_name, ).strip()), MDM_001, 客户名称不能为空 ) checker.add_rule( 客户名称长度, lambda d: len(d.get(customer_name, )) 100, MDM_002, 客户名称不能超过100字符 ) checker.add_rule( 统一社会信用代码格式, lambda d: not d.get(uscc) or re.match( r^[0-9A-HJ-NPQRTUWXY]{2}\d{6}[0-9A-HJ-NPQRTUWXY]{10}$, d.get(uscc, ) ), MDM_003, 统一社会信用代码格式不正确 ) # 提交时执行校验 result checker.check({customer_name: 测试客户, uscc: 12345}) if result: for err in result: print(f[{err[code]}] {err[message]})这个校验链的设计要点规则可注册、可插拔新增规则不用改核心代码每条规则有独立的错误码方便前端定位和用户理解异常捕获保证一条规则出错不影响其他规则执行。参数说明checker_func接收数据字典返回布尔值error_code建议用“域前缀序号”的格式比如MDM_001表示主数据管理第001号规则。实时拦截的效果比月度报表好得多因为它在数据产生的瞬间就阻止了错误。但要注意拦截规则不能太严否则业务人员会觉得系统难用转而绕过系统。我的经验是必填和格式类规则可以严格拦截业务合理性规则可以给警告但允许提交由审核人判断。这样既保证了基础质量又不至于把业务卡死。还有一个进阶技巧是质量分。给每条主数据算一个质量分基于完整度、准确度、及时性三个维度加权。质量分低于阈值的记录在系统里标红并且在跨系统同步时打上“低质量”标签消费系统可以选择是否使用。这样质量管理的压力就从数据管理岗转移到了数据使用方用数据的人自己会推动源头改。最后说一个我自己的教训主数据管理规定的落地最难的不是技术是让业务部门接受“数据不是我想怎么建就怎么建”。我一般会先找一个痛点最明显的业务场景做试点比如采购部门因为物料编码不统一导致重复采购拿这个场景算一笔账让业务看到统一管理带来的实际收益后面推动就顺了。技术方案再漂亮业务不配合就是空中楼阁。希望帮到你。本文还有配套的精品资源点击获取