从邮件和 Word 迁移到合同系统，应该先动哪一步

历史合同的价值集中在少数几种场景：到期续签提醒、争议时调阅、审计抽查。这几种场景对数据完整度的要求其实不高，通常知道合同存在、对方是谁、什么时候到期、原件在哪就够了。全文录入、条款结构化这些重活，绝大部分历史合同一辈子都用不上。

更关键的是，先迁历史不会改变任何人的日常工作。业务和法务明天早上依然在邮箱里改 Word，摩擦一点没少。项目投入了两个月，可感知的改善是零，这对后续推动是致命的。

反过来，先接一条在途流程，第一周就能看到变化：一份来稿上传后有了带原文锚点的风险清单，版本不再靠文件名区分，法务的意见和业务的确认留在同一处。这种即时可见的改善是后续所有推动的燃料。

闭环的意思是有明确起点和终点的一段流程，走完之后产生一个可交付的结果，而不是半截。选择标准有三条：发生频率高、当前最痛、参与方尽量少。

选定之后要写清不包含什么。第一条闭环不处理的事情要明确列出来并告知相关方，否则试点期会不断被追加需求，最终变成一次全量上线。

在途流程稳定运行之后再启动历史迁移，通常是第二或第三个月。迁移分三档，按用途决定每一份属于哪一档，而不是一视同仁全量处理。

三档的数量关系通常是金字塔：索引级占大头，结构化级是少数。有扫描件的情况下，OCR 识别按页计费作为增值服务单列，先分档再决定扫哪些，可以避免把预算花在永远不会被调阅的纸堆上。

试点期间必然有一段时间新旧两套并行：部分合同在系统里，部分还在邮箱。这段时间最大的风险不是效率，是版本错乱，因为同一份合同可能两边都有。

控制手段有两条。第一条是按范围切而不是按人切：某一类合同全部进系统，其余全部留在旧方式，不允许同一类合同两边都能走。按人切会让同一份合同在不同经办人手上走不同路径，这是版本错乱的直接来源。

第二条是定一个明确的截止日，过了这个日期该类合同不再接受邮件流转。没有截止日的双轨会无限延长，因为旧方式永远更熟悉。截止日不必很快，但必须在项目启动时就定下来并同步给所有相关方。

把提醒推回员工已经在看的地方

双轨期里系统被绕过，多半是因为它的提醒没人看。审批待办、签署提醒、到期提醒都应该推回协同平台的消息与待办中心，而不是只存在于合同系统自己的站内信里。这一点对迁移成败的影响，往往超过功能本身。

不要用录入量或覆盖率判断，这两个数字可以靠补录刷出来。用行为指标：该类合同里有多少比例是在系统内发起的而不是事后补录的，以及法务处理一份来稿时打开了几个地方。

配合流程结果一起看：从收稿到可决策结果的时间、版本往返次数、仍需人工重复录入的字段数、误用版本的次数。这几项在项目启动前先测一次基线，第一条闭环稳定运行一个月后再测一次，差值才是迁移是否成功的依据。基线没测，后面所有数字都没有参照。