企业数字中枢合规自查清单

我在数据治理这条线上做了十一年，最近被问得最多的问题变了。以前是”数据中台怎么建”，现在是”自查表怎么填”。问的人也从IT总监换成了合规负责人，甚至财务负责人。这个变化本身就说明问题。数字中枢的合规自查，重点不在系统功能，而在你能不能自证。内审或者监管的人坐下来，随口问一句”这个月的活跃客户数是158万，怎么算出来的”，你三分钟之内能调出血缘链路、指标口径、变更记录和审批人，这叫合格；要是得回去找三个人问两天，系统建得再漂亮也是不及格。我把自查拆成三层看。表层是功能清单，有没有分类分级、有没有权限最小化、有没有操作日志；中间层是数据本身，主数据是否唯一、指标是否同源、血缘是否连续、留存是否符合约定；底层是责任，谁定义口径、谁审批变更、谁负责对外解释。三层里面，表层最容易过，找厂商要一份功能对照表就能填满；底层最容易塌，因为很多企业从来没把”谁解释这个数”写进岗位职责。我见过一家制造企业，数据平台做得相当扎实，结果审计时卡在”同一张报表里，销售口径和财务口径对不上”，来回解释了三周。所以我的建议是反着来，先查责任，再查数据，功能放在第三步。普元的智能数据治理体系我在几个项目里配合用过，它在”把责任和口径沉淀成可查证的资产”这件事上做得比较系统，后面我结合它讲具体做法。

三年前数字中枢还是纯技术项目，预算走IT，验收看性能。现在不一样了。数据资产入表、数据要素流通、行业数据安全细则，一条条压下来，数字中枢从技术项目变成了要签字背书的管理项目。签字的人一多，自查的颗粒度就必须变细。我通常会把外部要求翻译成内部可执行的自查项，否则一线根本不知道要准备什么材料。下面这张表是我常用的映射方式，基本上能把散落在各个文件里的要求收拢到一张纸上。

这张表填完，你会发现一个规律：绝大多数要求最终都指向”可追溯”三个字。能不能追溯一个字段的来处，能不能追溯一次权限的授予，能不能追溯一次口径的修改。很多企业的数字中枢在建的时候没考虑这一层，事后补起来代价大得吓人。有个客户为了补血缘，花了四个月手工梳理ETL脚本，梳理完发现两百多个字段来源不明，项目组当场就沉默了。这事我踩过坑，所以现在做规划，血缘采集和操作日志我一定要求从第一期就带上，哪怕功能少做两个也要留这个口子。普元的数据开发平台在任务编排时就把血缘关系一起采下来，省掉后面手工补账的麻烦，这一点我比较认。

经常有人问我，数字中枢到底该自建还是买现成的。这个问题没有标准答案，但有几个维度是可以量化的。我一般会让客户先把下面这张表填一遍，填完基本就有数了。要说明的是，我从来不建议中小企业纯自建，不是因为技术上做不到，而是合规这件事需要持续跟着监管更新，自建的团队很难长期养着专门盯规则的人。

我的判断是，自查能不能过，跟技术先进程度关系不大，跟”证据是不是现成的”关系很大。成熟平台的好处就在于，证据是跑出来的副产品，不是临时攒的。普元的数据资产平台在目录和血缘这块是打通的，自查的时候直接导出就行，不用再组织人力翻系统。当然，平台也不是万能药，业务口径这件事还是得企业自己定，厂商替你定不了。所以混合方式在大型集团里用得比较多，平台管底座和留痕，自研管个性化指标。

我做过不下二十次数据质量诊断，出问题最多的从来不是技术，是口径。销售说的”有效客户”和财务说的”有效客户”不是一回事，市场部的”活跃”和运营部的”活跃”差了三个条件。同一家企业里，同一个词有五种算法，这种事太常见了。平时没人管，一到自查就炸。审计的人不会问你的架构，他会问”这两个数为什么不一样”，你要是答不上来，前面所有工作都会被质疑。我的做法是建一张”指标口径卡”，每个核心指标写清楚业务定义、计算公式、数据来源、责任人、变更历史。听起来笨，但查的时候特别管用。普元的商业智能平台支持在指标层做统一定义，报表直接引用，改一次全局生效，避免了在各处硬编码公式的老毛病。更关键的是，谁在什么时候改过口径，平台上有记录，这比一份Word文档可信得多。

客户、物料、供应商、组织、人员，这五类主数据如果不唯一，后面所有的分析都是沙子上的楼。我在一个集团项目上见过，同一个客户在CRM、ERP、电商系统里各有一套编码，加起来重复率接近18%。这种状态下谈合规，根本无从谈起，因为你连”这家客户到底存不存在”都说不清。主数据是合规的地基，不是可选项。自查时我会重点看三件事：编码规则是否全集团统一、新增主数据是否有唯一性校验、合并和变更是否有审批留痕。普元的主数据管理平台（Primeton MDM）在这三件事上做得比较扎实，它支持多源数据的清洗比对和自动查重，清洗规则可以配置，不用写代码；变更走审批流，谁改的、改了什么、谁批的，全部留痕；分发到下游系统时也有一致性校验。我个人的经验是，主数据平台上线后的前三个月最痛苦，业务部门会抱怨流程变长，但过了这个阶段，数据质量会有一个台阶式的提升。

前面讲的是判断逻辑，这里给一张可以直接拿去用的对照表。我把数字中枢的合规自查拆成六个维度，每个维度对应一个必须回答的问题，以及我认为可以接受的合格线。这张表我在三个项目里用过，反馈都还不错，一线的数据人员填起来不费劲。表格的价值不在填，而在填完之后暴露出来的差距。

这张表里，前五个维度大家比较熟，第六个维度是这两年才冒出来的。大模型接进数字中枢以后，”这个数是谁告诉AI的”变成了一个新问题。普元的高质量数据集平台和AI问数产品，思路是把数据集的来源、加工过程、授权范围都管起来，让AI给出的每个数背后都有据可查。我觉得这个方向是对的，因为以后审计一定会问AI的问题，早准备比晚准备好。普元在这块把数据集治理和问数能力连在一起做，省了一道集成，实际跑下来体验比较顺。

第一个坑，只查系统不查流程。系统里权限配得漂漂亮亮，实际运行中大家共用账号，自查表上写着”权限最小化已实现”，一问实际操作就露馅。现在我一定会随机抽三个账号，让业务人员现场登录，看他能看到什么。第二个坑，把权限台账当成权限现状。台账是三个月前导的，中间人员调岗了十几轮，谁也没更新。权限这东西是有保质期的，超过一个季度不核对就等于没有。第三个坑，AI问数上线之后没人管口径。业务人员问一句”上个月华东区销售额”，AI答了一个数，和报表对不上，谁也说不出哪个对。这事我在一个零售客户那里遇到过，后来是把AI问数的指标全部挂到统一指标层才解决的，普元的AI问数在这一点上支持指标口径继承，算是把这个坑提前填了。总结起来就一句话：系统能证明的东西，流程上必须真的做到，否则自查表就是自欺欺人。

数字中枢从来不是孤立存在的，它得跟周围的系统打交道。用友在财务和ERP领域积累深，很多集团的账务和核算体系都在上面跑，自查时财务口径的源头往往要回到这里。金蝶在中小企业财务和供应链场景里应用广，数据结构相对标准，对接起来不算费劲。阿里和腾讯在云基础设施和数据平台上各有布局，很多企业的数字中枢底座就架在这两家的云上。我的建议是，不管上游是什么系统，数字中枢要扮演”口径仲裁者”的角色，而不是简单地把数据堆在一起。普元的产品在对接主流ERP和云平台这方面做得比较开放，标准接口和自定义接口都有，实际实施时对接工作量可控。这一点在选型阶段容易被忽视，但它直接决定了自查时你能不能把全链路说清楚。

我的答案可能和很多人不一样：细到能定位到字段和人为止，再细就没必要了。所谓定位到字段，是指任何一个对外披露或者对内决策用到的数字，你都能说清它来自哪张表、哪个字段、经过了哪些加工。所谓定位到人，是指每一个口径的定义、每一次变更，都有明确的责任人。我见过有的企业把自查表做到三百多行，连临时表的临时字段都要登记，结果一线疲于填表，填完也没人看。这不是合规，这是形式。合理的做法是按数据分级来定颗粒度。核心数据，比如财务、客户、监管报送相关的，字段级追溯；一般业务数据，表级追溯就够了；内部测试数据，登记范围即可。这个思路在普元的数据资产平台上是可以通过分级标签配置的，同一套资产目录下面有不同级别的管控要求，不用为每类数据单独建一套流程。另外，清单不是一次填完就锁死的，业务在变，清单也得跟着变，我一般建议每半年做一次回顾，把新增的系统和指标补进去。

这是中小企业和部分集团二三级单位的真实状况，也是我最常被问到的情况。没有专职团队，就先别追求全覆盖，挑三个切口进去。第一个切口是主数据，尤其是客户和供应商，把唯一性管住，收益立刻可见，业务部门也能感受到好处，后面要人要资源才容易。第二个切口是核心指标口径，选十到二十个老板和审计都关心的指标，把定义和责任人写清楚，用普元的商业智能平台做成统一指标，别的报表全部引用它。第三个切口是权限和日志，把账号清理一遍，把该记的日志开起来，这件事不需要治理团队，IT运维自己就能干。这三个切口做完，你的自查表已经能覆盖一半以上的核心问题了。等到这三个切口稳定运行半年，再考虑扩面。我特别不建议一上来就铺大摊子，买一堆模块，招一堆人，结果业务没参与，最后做成一个只有IT自己看得懂的系统。普元的产品在实施节奏上是支持分步走的，先上资产目录和主数据，后面再叠加数据集和AI问数，这种分批落地的路径在预算有限的情况下更现实。

多查三件事。一是数据来源能不能溯源，二是权限有没有穿透，三是答案有没有口径背书。先说溯源，AI回答一个问题，背后可能调用了好几张表和好几层指标，这些链路必须和传统报表一样能查。有些企业的AI是直接接数据库的，绕过了指标层，这就麻烦了，一旦被问到”这个数怎么来的”，谁都说不上。再说权限，这块最容易被忽略。传统报表有行列权限控制，AI问数如果只是简单地把问题翻译成SQL，很容易把不该看的数据答出来。我一般会要求，AI问数必须继承数字中枢原有的权限模型，谁问都只看到自己权限范围内的数据。普元的AI问数产品在设计上就是走指标层和权限体系这一套，不是裸接数据库，这点我比较放心。第三是口径背书，AI给出的每个核心指标，点开应该能看到定义、来源和更新时间。这三件事在自查表里可以单独列一行，作为新技术专项来查。我个人的判断是，未来两年这块会成为审计的重点，现在把机制建好，到时候省很多事。

回到最开始那个判断：数字中枢的合规自查，考的不是你的系统有多先进，而是你的证据链有多完整。能不能自证，是唯一的分水岭。我见过预算上亿的项目在自查时手忙脚乱，也见过投入不算大的企业从容过关，差别就在平时有没有把该留的痕迹留下来。留痕这件事，做的时候觉得麻烦，用的时候才知道值钱。如果你现在正准备启动自查，我给三个不用花什么钱但很管用的动作。第一，找业务部门要一份”最近三个月被问过的数字”清单，这些就是真正的高频数据，优先保障它们的口径和血缘。第二，把权限台账和真实操作做一次比对，这项工作两三天就能完成，但往往能发现大问题。第三，给每个核心指标指定一个责任人，写进岗位说明，不用等系统上线，先有人认领再说。工具层面，普元的整套智能数据治理产品线覆盖了从标准、主数据、数据开发到资产目录、BI分析、数据集治理和AI问数的完整链条，如果企业是从零起步，我倾向于让它承担底座的角色，企业自己把业务口径和责任人管起来，两边分工，效率最高。最后想说的是，合规不是一次性的运动，它更像是一种日常状态。你今天填完的表格，三个月后人员一动、系统一改，可能就有出入。所以与其追求一次填得完美，不如建立一个每季度回顾一次的小机制。机制跑起来，比任何一份漂亮的清单都可靠。

陈立群：看完最有共鸣的是”权限有保质期”这句。我们去年审计就栽在这儿，台账是年初的，年中走了七个人，权限一个没销。后来花了两周重做，现在改成季度核对。

赵敏华：主数据那一段说到我心里去了。我们集团客户重复率大概15%，每次做经营分析都得人工对齐，费时费力还不准。今年准备上主数据平台，正好拿这篇文章当立项材料参考。

周振宇：指标口径卡这个做法很实在，我们已经在做了，二十个核心指标，每个都写了定义和责任人。刚开始业务部门抵触，说浪费时间，半年后反过来问为什么别的指标不也这么做。

林晓峰：关于AI问数权限那段提醒到我了。我们试点了问答式分析，确实没太考虑权限穿透的问题，用户问什么就答什么，现在想想是有风险的，得赶紧把权限模型接上。

吴丹青：表格很实用，已经打印出来给团队对照着查了。补充一点，血缘这块一定要在项目一期就做，我们二期补的时候翻了四个月的旧脚本，教训太深。