用友说“满足”，金蝶说“满足”，到底谁真满足？

——804落地笔记 05

老张的共享中心要升级，增加804号指引要求的数据治理和风险预警功能。项目不大，预算两百多万，走的是邀请招标。

用友来了，金蝶来了，浪潮也来了。

三家讲标，每家四十分钟。老张坐在下面听，越听越困惑。

用友说：“我们BIP平台的数据治理模块，完全满足804要求。”

金蝶说：“我们星瀚的数据标准管理和质量校验，完全覆盖804条款。”

浪潮说：“我们GS Cloud的风险预警和运营监控，完全符合804规范。”

三家都说“完全满足”。三家的报价差了不到二十万。三家的PPT里都有一张“804功能对照表”，逐条列着“满足”“完全满足”“高度匹配”。

老张让团队把三张对照表收上来，仔细看了一遍。

对照表的左侧，三家写的都是804条款的原文。右侧，三家写的都是自家产品的功能名称。

用友的对照表上，“数据治理体系”对应的是“数据标准管理+主数据管理+数据质量管理”。金蝶的对照表上，同样这一条，对应的是“基础数据平台+数据校验引擎+数据资产目录”。浪潮的对照表上，对应的是“主数据管理+数据质量监控+数据生命周期管理”。

三张表，三种写法，三种功能组合。但结论一模一样：完全满足。

老张问团队：“到底谁真满足？”

团队答不上来。

对照表的左侧是804，右侧是厂商自己的产品

老张后来把三张对照表铺在桌上，一行一行地比对。他发现了一个规律：

每一张对照表的左侧，写的都是804条款的原文。但右侧，写的是厂商自己的产品功能名称。

这意味着什么？

意味着厂商在填这张表的时候，逻辑是“我有什么，就往上靠什么”。804说“数据治理体系”，我有“数据标准管理+主数据管理+数据质量管理”三个模块，那我就写“满足”。至于804要求的“全生命周期”里还包括数据采集、加工、应用、存储四个阶段——我的模块覆盖了哪几个阶段？没写。

对照表的结论是“满足”，但“满足”的颗粒度是模块级的，不是字段级的。

老张又翻到风险预警那一条。804要求对“合规执行、数据安全、流程效率、系统性能、资金风险”五类风险进行动态监测。用友的对照表上，右侧写的是“智能稽核+风险监控”。金蝶写的是“合规校验+风险预警”。浪潮写的是“运营监控+风险预警”。

三家都说“满足”。但老张让IT部门查了一下自家现有的智能稽核模块——预警规则只有报销相关的十几条，覆盖的风险类型只有合规执行这一类。数据安全、流程效率、系统性能、资金风险四类，一条规则都没有。

如果对照表是“满足”，那自家系统里的真实状态是什么？

厂商的对照表，基准是企业招标文件，不是804

老张后来想明白了这件事。

三家厂商的对照表，看起来是以804为基准。但实际上，他们填表的时候，参照的是老张自己写的招标文件。

老张在招标文件里写：“投标人应提供数据治理功能，包括数据标准管理、主数据管理、数据质量管理。”——这是他从804里摘出来的，但他只摘了三个子项，漏了数据生命周期管理和数据安全控制。

厂商看到招标文件，就按这三个子项来答。用友说“我们有数据标准管理、主数据管理、数据质量管理”，金蝶说“我们有基础数据平台、数据校验引擎、数据资产目录”，浪潮说“我们有主数据管理、数据质量监控、数据生命周期管理”。

三家答的都是老张问的那三个子项。老张没问的那两个子项，三家都没答。

老张问：“你们怎么不做全生命周期？”

厂商说：“您招标文件里没写这一条。”

这就是问题的核心。 厂商的对照表，基准是企业的招标文件，不是804号指引。企业招标文件里写漏的条款，厂商不会主动补。因为补了，等于告诉企业“你招标文件写错了”。而且补了，自己的系统可能也答不上来。

企业需要的是“买方映射”，不是“卖方映射”

老张后来找了一家独立咨询机构，做了一件事：以804号指引为唯一基准，逐条对照三家厂商的系统功能，做一张字段级的合规映射表。

这张映射表长这样：

这张表的价值在于：它的左侧是804原文，右侧是三家系统的真实配置状态，结论不是“满足”，而是“部分覆盖”“未覆盖”“需定制”。

老张拿着这张表，再去看三家厂商的对照表，发现了一个有趣的现象：

用友说“数据治理完全满足”，但映射表显示，数据生命周期管理和数据安全控制两个子项，用友的系统里没有对应功能。

金蝶说“数据治理完全覆盖”，但映射表显示，数据质量校验的规则库需要额外购买，而且版本管理不支持。

浪潮说“数据治理完全符合”，映射表显示，浪潮的生命周期管理确实有，但需要配置，配置费用不含在报价里。

三家都没有说谎。他们说的“满足”，是模块级的满足。映射表说的“部分覆盖”，是字段级的真实状态。

厂商不会告诉你的事

老张后来跟一位在系统厂商做过售前的老朋友聊天。

老朋友说：“我们做对照表，逻辑很简单——企业问什么，我们答什么。企业招标文件里写了‘数据治理’，我们就答‘有数据治理模块’。至于804要求的全生命周期里，我们到底覆盖了几个阶段，那是实施阶段的事。售前不会主动拆那么细，拆细了标就不好投了。”

老张问：“那如果企业招标文件里漏了804的某一条呢？”

老朋友说：“那就不答。企业没问，我们主动提，等于给自己找麻烦。而且提了，企业可能反过来说‘你既然知道，为什么不早说’。”

这就是卖方映射的天然局限。厂商的KPI是签单，不是确保企业合规。企业招标文件写漏的条款，厂商不会补。厂商系统里缺的功能，售前不会主动说。

合规映射，必须由买方顾问来做

老张最后想明白了一件事：

804合规映射这件事，不能由卖方做，必须由买方顾问做。

卖方做映射，基准是企业的招标文件，立场是“证明我满足”，颗粒度是模块级，寿命是售前一次性。

买方顾问做映射，基准是804号指引，立场是“确认你缺什么”，颗粒度是字段级，寿命是持续监控。

前者是销售工具，后者是审计工具。

企业两个都需要。但后者只能找第三方做——因为卖系统的人，不会说自己的系统不合规。

你的系统，经得起“买方映射”吗？

如果你也是正在建或已建共享中心的财务负责人，不妨让团队做一件事：

把三家厂商的对照表收上来，逐条问三个问题——

第一，这一条804要求，在你的系统里，具体对应哪个功能节点？

第二，这个功能节点，覆盖了804要求的全部子项，还是只覆盖了其中几个？

第三，如果只覆盖了部分，缺的那几个子项，是二次开发、额外购买，还是根本没有？

这三个问题的答案，才是804合规的真实分数。

厂商说的“满足”，是他们的语言。你需要一张用804的语言写的映射表。

下一篇，我们聊一个更敏感的话题——共享了，责任也共享吗？804附则里那条容易被忽略的“保险丝”