合同管理系统上线后没人用，问题通常不在系统

合同管理系统是专项系统里最容易「上线即闲置」的一类。上线时热热闹闹，一年后回看：系统里存着几千份合同扫描件，查询功能基本没人用，合同状态大多停在「已签订」，履约进度靠 Excel 在跟。

遇到这种情况，第一反应通常是「系统不好用」。但真正的原因往往在系统之外，而且在上线之前就已经决定了。

一、根因一：一份合同，三个编号

这是最常见也最要命的问题。同一份合同，在业务部门有一套编号、法务有自己的登记号、财务在 ERP 里又有合同号。三套编号各自维护，互不映射。

系统上线时，如果你问「以哪套编号为准」，通常会得到这样的回答：都重要，都要保留。

于是系统里必须同时存三套编号，任何一次查询都得先问清楚「你按哪个号查」。用户第一次用就发现：想查一份合同，得先知道它在系统里叫什么——这已经违背了查询的初衷。

更麻烦的是数据源头。如果合同系统的数据是从业务系统同步来的，而法务登记是人工录入的，两边一旦对不齐，就会出现「系统里有这份合同，但法务台账没有」或者反过来。两边都不敢信，最后还是回去查 Excel。

二、根因二：签完了，然后呢

很多合同系统的功能边界，止步于「合同签订完成」。签完之后的事情——履约跟踪、付款节点提醒、到期续签、变更管理——要么没做，要么做了一个提醒功能但没人维护。

结果是系统只管前半段，后半段仍在 Excel 里。而合同管理真正的价值恰恰在后半段：什么时候该付款、对方履约到哪一步、还有多久到期、有没有该续没续的。这些信息不在系统里，系统就只是个档案柜。

为什么后半段做不起来？因为权责没定。合同签完之后由谁负责跟踪履约？业务部门说这是法务的事，法务说履约是业务的事，财务只管按发票付款。三方都能说出理由，于是没人负责更新状态。

系统里的状态字段一旦没人维护，三个月后就会失真。失真的数据没人信，没人信就没人用，最后连录入都停了。

判断一套合同系统有没有真正跑起来，不要看合同数量，看状态字段的更新时间和分布。如果九成的合同状态都停留在「已签订」、最后更新时间集中在上线那一个月，这套系统实际上已经停摆了。

三、根因三：磋商过程在系统外

合同签订之前的磋商环节，是合同管理里最复杂、也最难进系统的部分。条款来回改、版本反复迭代、对方用邮件发 Word、我方用微信发修订版。

如果系统只支持「上传最终版合同发起审批」，那磋商过程就完全在系统外。这带来两个后果：

• 版本追溯断链。审批时看到的合同是第几版、改了哪些条款、为什么改，系统里查不到。一旦发生争议，这些信息要靠人去翻邮件；
• 法务介入太晚。合同条款基本谈定了才送法务审，法务能改的空间已经很小，只能提「建议下次注意」。

把磋商搬进系统，技术上不难，难的是改变工作习惯。业务人员习惯用 Word 加批注谈判，让他们改成在系统里提意见，需要培训和一段时间适应，而且系统本身的编辑体验必须过关——如果在线编辑卡顿、格式错乱，推不动是必然的。

务实的做法是分步：先要求「每一版必须归档进系统」，不强制在线编辑；等归档动作稳定了，再推在线协作。一上来就要求全流程在线，通常的结果是大家绕开系统。

四、正确的准备顺序

这些问题的共同点是：都不是系统能解决的，但都会让系统失效。所以合同管理项目的准备顺序，和一般信息系统不一样。

现实中这五步经常是倒着走的：先选型、先上线，前面四步留到实施过程中「边做边定」。这时候实施方会不断提出「这个口径请确认」，而甲方内部还没达成一致，项目就卡在确认环节，工期一天天过去。

第四步特别容易被低估。存量合同的数据质量通常很差：扫描件是歪的、关键字段没提取、合同名称五花八门（同一类合同有七八种叫法）。如果这些数据不整理就导入系统，用户第一次搜索就会得到一堆不相关的结果，然后放弃使用。

五、AI 能帮上什么，帮不上什么

这两年合同系统都在讲 AI：要素抽取、条款比对、风险识别。这些能力确实在进步，但要说清边界。

能帮上的：从扫描件里抽取甲乙方、金额、期限、签订日期这类结构化要素，把人工录入变成人工复核，效率提升是真实的；新合同与标准模板的条款比对，标出偏离项，也基本可用。

暂时帮不上的：判断一条非标条款对我方是利是弊。这需要理解业务背景、交易结构、对方意图，不是读一遍文本能得出的结论。这类工具给的是「这一条与模板不一致」，而不是「这一条有风险，建议改成什么」。

把前者当成后者来宣传，是这一类产品目前最常见的问题。选型时如果对方说「AI 能自动识别合同风险并给出修改建议」，可以要求用本单位的真实合同当场跑一遍，看它给出的建议是否可用。

六、一句话

合同管理系统失败的典型路径是：把它当成一个软件项目来做，而它实际上是一个管理制度 + 数据治理 + 软件的组合项目。软件那部分通常只占三分之一的工作量，但往往是唯一被认真对待的那三分之一。