规则零件包：让804合规从“报告”变成“可运行的代码”
——804落地笔记 12
老张的共享中心合规项目做完后，专知智库交回来两样东西。
第一样，是那张三十页的映射表。老张已经看过了，逐条对照804，标注覆盖状态，写明缺什么怎么补。
第二样，是一个文件夹，里面装着十几个文件。文件名都是“XX规则包”——数据标准定义规则包、数据质量校验规则包、风险预警阈值规则包、责任追溯标签规则包、研发费用多口径归集规则包。
老张打开其中一个，发现里面不是Word，不是PPT，而是Excel和JSON格式的文件。
他问：“这是什么？”
专知智库的人说：“这是规则零件包。你拿着它，直接给IT部门或系统厂商，他们就知道怎么配。”
传统咨询交付的是“建议”，规则包交付的是“配置”
老张后来把德勤的诊断报告和专知智库的规则包放在一起对比，发现了根本性的差异。
德勤的报告，是一份Word文档，八十页。 结构很规范：现状调研、差距分析、整改建议、实施路线图。翻开“整改建议”那一章，写的是：“建议企业按照804号指引要求，进一步完善数据治理体系和风险预警机制。”
老张看完，知道要“完善”，但不知道“完善什么”。
专知智库的规则包，是一份Excel表格，二十行。 每行对应一条具体的配置动作：
| 规则编号 | 所属模块 | 规则内容 | 配置位置 | 字段/参数 | 优先级 |
|---|---|---|---|---|---|
| DR-001 | 数据治理 | 供应商名称与营业执照名称一致性校验 | 主数据平台-供应商管理-校验规则 | 供应商名称字段、营业执照名称字段 | 高 |
| DR-002 | 数据治理 | 银行账号与户名一致性校验 | 主数据平台-银行信息-校验规则 | 银行账号字段、户名字段 | 高 |
| DR-003 | 数据治理 | 客户主数据重复录入自动拦截 | 主数据平台-客户管理-查重规则 | 客户名称、统一社会信用代码 | 高 |
| DR-004 | 数据治理 | 数据标准版本管理 | 主数据平台-标准管理-版本控制 | 版本号字段、生效日期、废止日期 | 中 |
| DR-005 | 数据治理 | 数据销毁审批流 | 主数据平台-生命周期-销毁流程 | 销毁申请人、审批人、销毁记录 | 中 |
老张看完这张表，直接转发给IT部门，说：“照着配。”
IT部门看完说：“这个清楚，不用猜。”
德勤交付的是“诊断结论”，专知智库交付的是“配置清单”。前者告诉你“哪里有问题”，后者告诉你“在哪个菜单、哪个字段、配什么规则”。
规则零件包的三个核心特征
老张后来把十几个规则包都翻了一遍，发现它们有三个共同特征。
第一，每个规则包都是独立的。
数据标准定义规则包，只管数据标准定义。数据质量校验规则包，只管质量校验。风险预警阈值规则包，只管预警阈值。互不依赖，可以独立配置、独立运行、独立优化。
这意味着企业可以分步实施。先配数据质量校验，跑通了再配风险预警。不用一次性全上，也不用担心“一个没配好，其他都跑不了”。
第二，每个规则包都是可配置的。
不是写死的代码，是参数化的规则。比如“数据质量校验规则包”里，校验规则是“供应商名称与营业执照名称一致性校验”，但校验的字段、比对的方式、不通过时的处置动作，都是可配置的参数。
企业可以根据自己的实际情况调整。比如，有些企业允许供应商名称有简称，那就可以在规则里增加“简称白名单”。有些企业要求必须完全一致，那就把白名单设为空。
第三，每个规则包都是可验证的。
规则包里附带了测试用例。配置完成后，可以用测试用例验证规则是否生效。比如“数据质量校验规则包”里，附了十条测试数据：五条应该通过、五条应该拦截。配完规则后，跑一遍测试用例，就知道配对了没有。
这三个特征合在一起，就是“零件化”的核心——独立、可配置、可验证。
规则零件包和系统配置的关系
老张后来问IT部门：“这些东西，和系统里原有的配置是什么关系？”
IT部门说：“系统里原来有配置功能，但没人告诉我们该配什么。现在有了规则包，我们照着配就行了。”
老张又问：“那如果系统里没有对应的配置功能呢？”
IT部门说：“规则包里写了‘配置位置’。如果系统里没有这个位置，说明需要二次开发。我们就拿着规则包去找厂商，说‘我们要在这个位置加这个功能’。”
老张明白了。规则零件包不仅是配置指南，也是需求说明书。
它告诉IT部门：系统里已有的功能，配什么规则。系统里没有的功能，需要加什么。
规则零件包怎么用
老张后来把规则包分成了三类，分别处理。
第一类：系统已有功能，直接配置。 比如数据标准定义、数据质量校验、审批流配置。这些功能系统里本来就有，只是没配置或配置不全。IT部门照着规则包配就行了，不需要额外花钱。
第二类：系统有类似功能，需要调整。 比如风险预警阈值配置，系统里有预警功能，但只支持报销相关的几条规则。规则包里要求五类风险预警，需要扩展预警规则的类型。这部分需要厂商配合，可能要付一些配置费。
第三类：系统没有功能，需要二次开发。 比如责任追溯标签、研发费用多口径归集。这些功能系统里根本没有，需要二次开发。老张拿着规则包去找用友，让他们按规则包的要求报价。
三类分开处理，钱花在哪里清清楚楚。
规则零件包和804的关系
老张后来把规则包和804原文逐条对照，发现每个规则包都对应804的某一条或某几条要求。
| 804条款 | 对应规则包 | 规则数量 |
|---|---|---|
| 数据治理体系 | 数据标准定义规则包、数据质量校验规则包、数据生命周期管理规则包、数据安全控制规则包 | 23条 |
| 风险预警体系 | 合规执行预警规则包、数据安全预警规则包、流程效率预警规则包、系统性能预警规则包、资金风险预警规则包 | 18条 |
| 责任切分 | 职责边界规则包、审批权限移交规则包、责任追溯标签规则包 | 12条 |
| 研发费用多口径归集 | 会计口径归集规则包、高企口径归集规则包、加计扣除口径归集规则包、差异调节规则包 | 15条 |
804的每一条要求，最终都落到了一个具体的规则编号上。 规则编号又对应到系统里的具体配置位置。一条一条配完，804合规就落地了。
为什么系统厂商不做规则零件包
老张后来问专知智库的人：“这个东西，用友金蝶为什么不做？”
对方说：“两个原因。”
“第一，做不了。规则零件包的核心不是技术，是政策理解。要把804的每一条要求拆解成可配置的规则，需要同时懂政策、懂系统、懂业务。系统厂商的顾问懂系统，但不懂804的每一条原文。他们能配规则，但不知道怎么配才能合规。”
“第二，不愿意做。规则零件包一旦交付，企业就知道自己缺什么、该配什么、该找谁配。系统厂商的售前说‘完全满足’，规则包一配，发现缺了二十多项。这不是自己打自己脸吗？”
“所以系统厂商的选择是：不碰规则设计，只做功能交付。企业说配什么，他们就配什么。企业不知道配什么，他们也不主动说。”
规则零件包，是系统厂商“不愿意做、也做不好”的空白地带。
你的共享中心，有规则零件包吗
如果你也是正在建或已建共享中心的财务负责人，不妨问自己一个问题：
你的804合规，是一份报告，还是一套可以配到系统里的规则？
如果是一份报告，那它解决的是“知道要做什么”的问题。
如果是一套规则零件包，那它解决的是“知道在哪个菜单、哪个字段、配什么参数”的问题。
报告是给人看的，规则包是给系统配的。
804合规的最后一公里，不是从报告到行动，是从报告到配置。规则零件包，就是那座桥。
下一篇，我们聊一个更长远的问题——共享中心上线只是开始，合规是每年都要做的事
