数据体检报告 / 2026-11-05 全流程只读

这是一份用印流水,不是合同台账。

对「合同信息库-集团行政、IT」的字段模型与数据质量审计

体检对象合同信息库-集团行政、IT-20261104
工作表2 张 · A1:F77 / A1:F78
有效记录行政 76 / IT 77
操作性质未改动任何单元格

合同管理最该回答的三个问题,两个答不了

核心结论
0/153能回答「对方是谁」的记录
0/153能回答「什么时候到期」的记录
答不准能回答「钱付了多少」
01

没有「对方主体」字段。供应商名字只散落在名称里——梨视频、康莱德、首汽、泛微、野兽派,全表 22 条带人名、约 8 条带供应商,其余无名,无法按供应商聚合支出。

02

没有起止日、没有到期日。而 41 条(26.8%)是续费/续约/维保类合同——SSL 证书、堡垒机、Veeam 备份、O365 邮箱,全部是「到期即断」的硬约束项。

03

付款列 47 条空白(30.7%),另有 12 条付款额大于合同额,最大一条是合同额的 16.7 倍。这一列的口径本身就不成立,任何汇总都不可信。

问题不在脏数据——0 条文本型数字、0 条占位符、0 条重复编号、153 条编号格式 100% 合规。问题在字段模型缺一半。

体检概览:干净,但残缺

规模与质量
合同金额合计
5,330.8万
153 条记录合计
口径:「合同金额」与「累计付款金额」两列各自合计。累计付款含 12 条超额记录,口径修正后需重算。
有效记录153 条
行政 / IT76 / 77
累计付款4,032.2 万
字段总数6 个合同管理核心要素 11 项,缺 7 项
付款列空白47 条占 30.7%;空 ≠ 未付,是没回填
付款超合同额12 条最大 16.7 倍,另 1 条合同额为 0 却已付款
归档滞后 > 7 天60.1%92 条,中位 9 天,最长 144 天
公式 / 条件格式0 / 0无到期预警、无超额告警、无数据验证

两张表、六个字段、零公式

结构体量
项目合同信息库-集团行政合同信息库-集团IT
已用区域A1:F77A1:F78
有效数据行7677
列宽设置6 列统一 140px109 / 167 / 141 / 118 / 87 / 121px
合并单元格 / 图表 / 透视表0 / 0 / 00 / 0 / 0
公式 / 条件格式0 / 00 / 0
结构化表格无无
隐藏行 / 列 / 工作表无 / 无 / 无无 / 无 / 无
合同金额合计3,967.9 万1,362.8 万
表头单行、无合并、无小计混行、无幽灵尾行、编号 153 条格式全合规——结构本身是干净的,真正的问题是它只有 6 个字段。

五个维度分别打分:3.9 分

质量评分
结构规范性6.5
字段完整性1.5
数据准确性6.0
内部一致性4.0
业务可运营性1.5

评分依据:结构看表头/编号/类型;完整性看 11 项核心要素覆盖率;准确性看金额类型/重复/逻辑矛盾;一致性看模板/枚举/流水号;可运营性看能否支撑到期预警与供应商分析。

3.9/10
综 合 评 分
干净但残缺。
适合当流程留痕,
不适合当管理依据。
短板不在数据本身,在字段模型——所以不要花时间清洗这 153 条,同样的人力投到补字段上,回报差一个数量级。

10 项问题:3 项阻断、5 项高风险、2 项观感

问题总览
P0阻断 · 不补字段无法绕过
01

字段模型缺 7 项

对方主体、起止日、到期日、履约状态、负责人、归属部门、合同文本链接——153 条 100% 缺失

02

付款口径自相矛盾

12 条付款额大于合同额,最大 16.7 倍;1 条合同额为 0 却已付 7.28 万

03

41 条周期合同无到期日

SSL 证书、堡垒机、Veeam、O365——不续即断,却没有一条登记到期时间

P2观感 · 影响检索与协同
09

文本卫生 77 处

冗余日期后缀 62、双连字符 5、多余空格 4、下划线 3、半角括号 2、错别字 1

10

版本与模板不一致

文件名含「的副本」;行政表 6 列统一 140px,IT 表六列各不相同

P1高风险 · 会让判断出错
04

日期是文本,且六成事后补录

153 条全为字符串;编号日期与创建日期差 >7 天的有 92 条,最长 144 天

05

两表实为一条流水,只覆盖 37.5%

号段 0029–0413 与 0028–0432 交错;405 个候选号只落了 152 个,0089 撞号

06

「合同名称」其实是流程标题

22 条纯占位名、39 条以「申请盖章」开头、3 对完全同名

07

0 与负数在承担业务语义

10 条 0 值(保密/框架/折扣协议)、1 条 −50,400 冲销,均无标识位

08

零公式、零条件格式、零校验

所以 12 条超额付款至今没有被发现

表里有的 6 个字段,没有一个是合同要素

P0-1 / 字段模型
现有 6 个字段全部填满
创建日期153 / 153
合同编号153 / 153
合同名称实为流程标题
合同金额153 / 153
合同类型仅 2 种取值
累计付款金额106 / 153

这 6 个字段描述的是「谁在什么时候申请盖什么章」——其中真正描述合同的只有 2 个半。

合同管理需要的 7 个字段一个都不存在
对方主体 / 供应商0 / 153
合同起始日0 / 153
合同到期日0 / 153
履约状态0 / 153
负责人0 / 153
归属部门0 / 153
合同文本链接0 / 153

结果是三件事都做不了:到期预警、供应商支出分析、履约跟踪。

其余 9 项靠清洗和规范就能解决,只有这一项不补字段无法绕过——这也是全表投入产出比最高的改造点。

「累计付款金额」是合同额的 16.7 倍

P0-2 / 付款口径
16.7×
IT!F55:香港数据中心专线降速降费合同
合同金额 9.0 万 / 累计付款 150.3 万
如果这一列真是「该合同累计已付」,它不该超过合同金额。但 12 条超了,且多为 2×、3× 的整数倍——它实际是「与该合同相关的付款流水」。
位置合同名称合同金额累计付款倍数
IT!F55香港数据中心多项专线降速降费900,00015,027,90016.7×
IT!F49微软 O365 邮箱服务续约769,9281,539,8562.0×
ADM!F63东方金融中心装修施工补充协议1,161,0001,555,0001.3×
IT!F25上海 GDS 机房租赁/专线/带宽363,600734,2002.0×
IT!F48安全运维堡垒机 JumpServer 续订48,000144,0003.0×
IT!F21Veeam 备份系统(2025 年度)89,000178,0002.0×
IT!F57采购合同流程-张敏敏-2022-12-12072,750—
IT!F46集团信息安全建设服务70,000140,0002.0×

上表为 12 条命中中的前 8 条。其余 4 条差额在 740–394,000 元之间,疑为含税差、尾款调整或多合同串账。

41 条周期性合同,没有一条有到期日

P0-3 / 到期风险
41
26.8%
按名称关键词识别「续费/续约/续订/维保/年度」
IT 34 条 / 行政 7 条
其中 12 条金额 ≥ 10 万
IT!29
集团域名 *.cmcinc.cn SSL 证书续购证书过期 → 全站 HTTPS 告警,邮件/OA/对外站点同时失效
IT!2
安全运维堡垒机 JumpServer 续订阅断订 → 运维审计断档,等保合规失效
IT!21
Veeam 备份系统(2025 年度)断订 → 备份窗口空档,恢复能力归零
IT!49
微软 O365 邮箱服务续约 · 77.0 万断订 → 全员邮箱停用,属最高影响面
IT!66
各办公室专线及机房专线租赁 · 113.8 万断订 → 办公网络与 IDC 互联中断
补两列日期(起始/到期)+ 一个 =到期日-TODAY() 公式,成本不到一天,直接消掉最大一类运营风险。

日期存成了文本,而且六成是事后补录

P1 / 时间质量
61
74
17
1
0–7 天8–30 天31–90 天> 90 天

编号日期 → 创建日期的滞后天数分布,共 153 条有效样本

A 列 153 条全是字符串

含时分秒,不是日期序列号。日期函数、排序、时间轴全部用不了,且无法做任何区间计算。

中位滞后 9 天,最长 144 天

ADM!A41:编号日期 2022-08-18,创建日期 2023-01-09。另有 4 条滞后 84–85 天。

台账是事后补录,不是实时落库

表里的时间不是「合同签订时间」,而是「有人想起来登记的时间」——做时间维分析会系统性偏移。

建议:分两列,不要混用

A 列转真日期并去掉时分秒;另设「合同签订日」独立字段,不要把流程创建日当签约日。

两张表其实是同一条流水,只覆盖 37.5%

P1 / 编号体系

PO 流水号在 0028–0432 之间排布。两个号段大幅交错(行政 0029–0413、IT 0028–0432),但 152 个占用号里几乎零交叉——这不是两套独立编号,是同一条全局流水按部门分流到了两张表。

0028015002700432
已占用(PO)已占用(SC)空号 253 个▼ 0089 撞号

两个号段交错,号码零交叉

行政占 0029–0413、IT 占 0028–0432,区间几乎完全重叠,但 152 个占用号里只有 0089 出现过两次。说明两表共用同一个流水计数器,不是各自编号。

唯一的撞号:0089

ADM!6 的 INC-ADM-SC-20250801-0089 与 ADM!50 的 INC-ADM-PO-20220804-0089 共用同一流水号——2025 年的 SC 单占用了 2022 年 PO 单用过的号。

候选流水号
405
0028–0432 连续区间
实际占用
152
153 条记录,0089 重复使用
覆盖率
37.5%
是设计还是漏录,需业务确认
覆盖率低有两种解释,含义完全不同:若只收录「需盖章的采购合同」,则法务、HR、非用印合同全在账外;若是历史漏录,则台账本身不完整。这一条只能由业务方回答。

名称是流程标题,0 和负数在承担语义

P1 / 内容质量

合同名称其实是审批单标题

不是合同标的,无法检索归档
22条纯占位名:形如「行政部-『集团总部』采购合同流程-闫蕊-2022-08-18」,只有部门、人名、日期
39条以「申请加盖公章/合同申请盖章/用印申请」这类动作词开头,标的藏在后半句
3对完全同名但金额差异巨大:ADM!51/52 同为「…2022-08-01」,金额 5,307 与 684,000

处理建议:拆成「流程标题 + 合同标的」两列,前者留痕审批链、后者可检索归档——这是唯一不丢信息又恢复可用性的做法。

0 和负数在承担业务语义,却没有标识位

10 条 0 值 + 1 条负数,都不是录入错误
10条 0 元合同:保密协议、折扣协议、框架协议、内部结算——「0」同时表示四种含义
1条负数:IT!D36 = −50,400,是补充合同变更的冲销,与正常合同混排在同一列
77处文本卫生问题:冗余日期后缀 62、双连字符 5、多余空格 4、下划线 3、半角括号 2、错别字 1

处理建议:加「是否无金额合同」布尔位隔离 0 值;负数加「冲销」标识并与原合同配对登记。

SUM 会把 10 条 0 值合同静默吞掉,AVERAGE 会被拉低,按金额筛选会漏掉它们——不是数字错了,是数字承载了不该由它承载的信息。

近八成金额压在 2022 年,一半记录是场地与 IT

业务透视

按年度:金额高度集中在存量导入年

2022 年含 11 条「BPM 合同信息转移」历史合同导入
2022
58条
4,106.7 万
占金额 77.0%
2023
26条
324.9 万
占金额 6.1%
2024
22条
202.6 万
占金额 3.8%
2025
37条
633.0 万
占金额 11.9%
2026
10条
63.5 万
占金额 1.2%

按主题:场地与 IT 两条线占 64.7%

按名称关键词归入 10 类,同一条只归一类
场地租赁 / 物业28 条2,584.7 万
IT 订阅 / 维保 / 云50 条867.1 万
IT 硬件 / 建设27 条855.0 万
装修 / 施工 / 改造20 条822.5 万
会议 / 团建 / 年会15 条148.9 万
77% 的金额集中在 2022 年,是 11 条 BPM 历史合同一次性入库,不是业务萎缩;但 2026 年只有 10 条、63.5 万,行政表已 129 天无新增——需确认行政侧是否停更。

总金额的两种划分:按年份可以,按有效期不行

业务透视 / 划分口径

按录入年份 × 部门

A 列是全表唯一的时间字段,只能按「录入年」分,不是签订年
年份行政IT合计金额占比
20223,390.6 万(36)716.1 万(22)4,106.7 万77.0%
202392.7 万(13)232.2 万(13)324.9 万6.1%
202453.4 万(10)149.2 万(12)202.6 万3.8%
2025423.2 万(15)209.8 万(22)633.0 万11.9%
20268.0 万(2)55.5 万(8)63.5 万1.2%
合计3,967.9 万(76)1,362.8 万(77)5,330.8 万100%

括号内为条数。60.1% 的记录录入滞后超过一周(最长 144 天),所以「录入年」只是近似——2023 年初录入的合同可能实际签在 2022 年。

94%

5,014.3 万(119 条)的金额,从名称里完全推不出服务期。没有起止日期字段,「在不在有效期」无从判断。

22 条 / 4%

只有 22 条能从名称严格推断服务期(跨度类 6 条、单一年度类 16 条),合计 213.0 万。其中推断「2026 年仍在有效期」的仅 6 条、67.3 万。

注意:剩下 94% 是「未知」,不等于「不在有效期」——没有字段,连错都算不出来。

要按有效期划分,必须先补「合同起始日/到期日」两列——补完一个 =到期日-TODAY() 就能自动分成有效/临期 90 天/已到期三档,这页右侧的 94% 也就有了答案。

六个会真的出事的场景,五个没有防线

风险推演
场景触发条件后果现有防线
SSL 证书过期IT!29到期日未登记,无人跟踪续费*.cmcinc.cn 全站证书失效,邮件、OA、对外站点同时告警无——只有一条 2025-02 的续购记录,无到期日
堡垒机 / 备份断订IT!2 · IT!21年度订阅到期未续运维审计断档、数据保护出现空窗,恢复能力归零无——三年三条记录散落,彼此无关联
重复付款 / 超额付款IT!F55同一合同多期付款被并到一行,无人核对付款额达合同额 16.7 倍仍无预警,多付难以追回无——零公式零条件格式,12 条超额至今在表里
审计问询内审/外审要求「这份合同对方是谁、签了多久」答不出,或需人工翻 BPM 逐条回溯,153 条工作量以人日计无——对方主体、期限均非字段
供应商集中度采购谈判需要「某供应商历史支出」只能靠名称模糊匹配,漏算率高,谈判缺少数据支撑部分——名称里偶见供应商名,但非结构化
版本冲突两份「的副本」各自更新同一合同两个版本,最终以哪份为准无法追溯无——无版本号、无修订记录

注:「现有防线」为「无」的五行,均不是责任心问题,而是机制缺失——表里没有任何自动报警能力,靠人盯必然漏。

先定口径,再补字段,最后上机制

整改路线
第 1 周

定口径
先把「是什么」说清楚

  • 明确 F 列语义:合同累计已付,还是流程相关付款
  • 锁定 12 条超额逐条核实,先查 IT!F55/F57、ADM!F63
  • A 列转真日期,去掉时分秒
  • 指定唯一权威文件,去掉「的副本」,加版本号
  • 确认 37.5% 覆盖率是设计还是漏录
  • 确认行政表 2026 下半年是否停更(已 129 天无新增)
第 2–4 周

补字段
把台账补成台账

  • 新增 7 个核心字段,153 条按编号回填
  • 名称拆成「流程标题 + 合同标的」两列
  • 两张表合并为单表,加「归属部门」
  • 0 值加「无金额合同」标识,负数加「冲销」标识
  • 建「母合同—子订单」关联,解决 8 组多期登记
  • 清理 77 处文本卫生:错别字、双连字符、冗余日期后缀
第 5–8 周

上机制
让它自己报警

  • 转结构化表格,支持自动扩展
  • 到期预警:=到期日-TODAY() + 条件格式(<0 红 / ≤90 黄)
  • 超额高亮:=F>D 条件格式
  • 关键列加数据验证下拉,锁住枚举
  • 每月跑一次同样的体检,看指标是否改善
  • 指定唯一权威源 + 版本号,废弃「的副本」
不要从「清洗这 153 条」开始——脏数据极少,清洗边际收益极低。同样的时间投进去,收益全在补字段和建机制上。

目标表结构:12 个必须先落地的字段

目标模型
字段类型校验规则 / 取值
对方主体新增枚举关联供应商主数据,下拉选择,非空
合同起始日新增日期≤ 合同到期日;格式 yyyy-mm-dd
合同到期日新增日期≥ 起始日;长期合同填 2099-12-31
履约状态新增枚举未生效 / 履行中 / 已到期 / 已终止 / 已续签
续签状态新增枚举不适用 / 待续签 / 已续签 / 终止续签
负责人新增文本非空;建议从员工主数据下拉
归属部门新增枚举行政 / IT / 人力 / 财务 / 法务
合同文本链接新增超链接以 http / https 开头,指向合同系统或共享盘
累计已付金额改造数值0 ≤ 已付 ≤ 合同金额;超额须填说明
是否无金额合同新增布尔是 / 否;用于隔离 10 条 0 值合同
主合同编号新增文本有值时必须存在于本合同编号列,建立母—子关联
付款进度公式公式=IF(金额=0,"",已付/金额)

前三行(对方主体、起始日、到期日)是投入产出比最高的三项——补齐它们,这份表才第一次能回答「跟谁签的、什么时候到期」。

合同信息库 · 数据体检 2026-11-05

判断清楚它是什么,比修它更重要。

下一步:定口径 → 补字段 → 上机制 153 条记录 · 6 个字段 · 10 项问题 · 3.9 / 10
合同信息库 · 数据体检
← → 翻页 · F 全屏01 / 17
‹
›