旧新系统长期混用，多数情况属于替换后的采用问题，而非新系统本身不可用。处置时先界定混用发生在哪些对象、团队和环节，再逐项验证原因，按“冻结新增—迁移存量—关闭入口—验证复发”分批收敛，最后用并行清单和退出标准防止回潮。
要点总览（TL;DR）
- 长期混用先拆成数据混用、流程混用、记录混用三类症状，按对象、团队、环节圈定范围，区分必要并行与习惯性回流。
- 原因排查用“假设—验证方式—证据结论”结构，常见假设包括存量数据未迁移、关键流程或字段缺失、入口与通知未收口、汇报口径未切换。
- 处置按冻结旧系统新增、迁移存量或补建能力、关闭入口与通知、处理流程断点的顺序推进，删除与权限回收须有备份、审批和停止条件。
- 收敛用旧系统活跃账号数、新增工作项数、双份记录数、跨系统评审次数按周验证，连续数周趋零后再结束并行期。
- 防复发靠流程规范写入系统归属、定期抽查回流操作、例外通道设有效期三条机制。
混用表现在哪些环节，范围有多大
“长期混用”是一种笼统感受，直接开会讨论“要不要停用旧系统”往往争不出结果。更有效的做法是先把混用拆成可观察的症状，落到具体对象上，再判断哪些并行是必要的、哪些是习惯性回流。范围清楚之后，原因排查才有明确对象，处置动作也能按批次安排。
混用通常出现在三类环节，症状各不相同：
- 数据混用：同一个需求、缺陷或任务在旧新系统各有一份记录，两边状态不一致，团队需要人工比对哪份是最新的。
- 流程混用：评审、发布、验收等环节跨系统走，例如需求在新系统登记、评审记录留在旧系统，或者发布单在旧系统审批、结果回填到新系统。
- 记录混用：文档、会议结论、决策记录分散在两处，查找历史依据时要同时打开两个系统。
圈定范围时，建议按“对象—团队—环节”三列做一张清单。对象指需求、缺陷、文档、发布单等工作项类型；团队指仍在回流的业务组或职能组；环节指具体动作，如“提测前在旧系统补一条记录”。每一行标注该并行属于哪一类：必要并行（例如旧系统仍有法定留存的历史记录需要查阅）还是习惯性回流（新系统已具备对应能力，团队仍按旧路径操作）。这个区分直接决定后续处置力度，必要并行保留只读访问，习惯性回流则需要关闭入口。
需要说明本文边界：这里处理的是替换完成后的采用与治理问题。新平台从零实施的选型建设、迁移切换窗口内的数据迁移执行细节，属于另外的任务，本文不展开。
长期混用的原因假设与排除证据
混用的原因经常被一句话概括为“大家不习惯”，但这个结论既无法验证，也无法指导处置。更稳妥的方式是先列出原因假设，为每条假设设计验证动作，用证据支持或排除，未取得证据的按待验证处理，不写进处置方案。
| 原因假设 | 验证方式 | 支持证据 | 反证与处理 |
|---|---|---|---|
| 旧系统仍有未迁移的存量数据或历史记录 | 抽样比对两边的活跃工作项与文档，统计旧系统中近30天仍有更新的记录 | 旧系统中存在新系统没有对应条目的活跃记录，且团队确实在引用 | 若旧系统近30天无新增、仅有历史归档，则属于必要并行，转为只读保留 |
| 新系统缺少某条关键流程或字段，团队被迫回旧系统补做 | 收集回流操作的具体动作，记录“在旧系统做了什么、新系统为什么做不了” | 多个团队重复出现同一类补做动作，且指向同一流程节点或字段 | 若补做动作分散、无共同节点，则更可能是习惯问题，按入口与培训处理 |
| 权限、入口或集成未收口，旧系统仍可登录、仍能收到通知 | 检查旧系统账号状态与通知配置，确认是否仍向在职人员推送 | 在职人员账号仍处于活跃状态，或旧系统通知仍在触发 | 若账号已停用但存在共享账号，需先清理共享账号再判断 |
| 责任与考核未切换，旧系统数据仍是汇报口径 | 核对当前周报、月报的数据来源，确认统计取自哪个系统 | 汇报材料仍以旧系统导出数据为准，或两套数据并存且以旧系统为准 | 若汇报已切换但基层仍维护旧数据，属于执行层惯性，按流程规范处理 |
验证时注意两点。第一，证据要来自系统记录和实际操作，而非访谈中的印象描述；访谈可以用来发现线索，但结论需要数据支撑。第二，多条假设可能同时成立，例如既有未迁移数据、又有汇报口径未切换，此时处置要按依赖关系排序，先解决导致回流的硬约束，再处理习惯问题。
把验证结果整理成“假设—验证方式—证据结论”对照表，每条结论标注“已确认”“已排除”“待验证”。待验证项不进入处置清单，避免基于猜测关闭入口造成业务中断。
按原因分批处置：冻结、迁移、关入口
原因确认后，处置按四个动作推进：冻结旧系统新增、迁移或补建存量依赖、关闭登录入口与通知、验证收敛。顺序不能颠倒，冻结在前是为了止住增量，迁移在中是为了消除硬依赖，关入口在后是为了避免在依赖未清除时造成业务断点。
第一步：冻结旧系统新增
设定明确的冻结截止日，冻结后旧系统只允许读取与导出，不再接受新建记录。冻结前完成一次完整数据备份，备份范围包括工作项、附件、评论与操作日志。冻结公告要写清三件事：截止时间、冻结后哪些操作仍可用、遇到特殊情况向谁申请例外。例外申请应有审批记录，并设定有效期，避免例外变成新的长期通道。
第二步：迁移存量与补建能力
针对验证中确认的依赖，分两种方式处理：能够迁移的存量数据做定向迁移，迁移前保留回退副本，迁移后抽样核对条目数量与关键字段；新系统确实缺少的流程节点或字段，在新系统内补建对应能力，明确上线时间与责任人。补建期间允许有限并行，但要在并行清单中登记，标注结束条件。
第三步：关闭入口与通知
停用旧系统登录账号，关闭旧系统发出的通知与提醒，保留只读归档一段时间供查阅。归档保留期限按组织自身的合规与留存要求确定，本文不给出统一期限。关闭入口前确认两件事：迁移数据已完成核对，补建能力已上线并被实际使用。
第四步：处理流程断点
对跨系统的流程断点，在新系统内明确替代路径与责任人，例如评审记录统一在新系统的工作项下留存、发布结果回填到同一工作项。替代路径要写进流程规范，让团队知道绕行没有收益。发现团队自行绕行时，先定位是路径不通还是习惯未改，再决定补能力还是补培训。
涉及删除、批量改写、权限回收的操作，执行前必须具备三个条件：有可恢复的备份、有明确的审批人、有停止条件（例如核对发现条目数量差异超过约定阈值即暂停并回退）。这类操作建议安排在业务低峰期，并保留操作记录以便追溯。
在处置推进过程中，工作项状态与文档归口需要有统一的承载位置，否则冻结与迁移的动作本身又会散落在多个渠道。ONES 可用于在新系统内按工作项状态流转记录迁移进度、把处置清单与评审结论沉淀为文档，并通过权限设置控制旧系统相关入口的访问范围；具体配置方式以组织实际部署为准。
如何验证收敛并防止再次混用
处置完成不等于收敛完成。需要用可观察的指标确认混用确实下降，并用机制防止回流。验证周期建议按周观察，连续数周趋零后再宣布并行期结束。
| 验证指标 | 观察方式 | 收敛标准 |
|---|---|---|
| 旧系统活跃账号数 | 每周统计旧系统登录与操作账号 | 降至仅保留归档查阅所需的少数账号 |
| 旧系统新增工作项数 | 统计冻结截止日之后的新建记录 | 为零；出现即核查是否为例外审批 |
| 双份记录数量 | 抽样比对同一需求或缺陷在两边的存在情况 | 抽样中不再出现同一对象两份活跃记录 |
| 跨系统评审次数 | 统计评审记录与发布记录是否落在同一系统 | 评审与发布记录均在新系统内闭环 |
指标之外，还需要一份双系统并行清单，逐项写明并行对象、并行原因、责任人和退出标准。并行期结束条件建议写成可核验的表述，例如“该对象在新系统内连续两周无回流操作，且旧系统对应入口已关闭”，避免用“大家适应了”这类无法验证的描述结束并行。
防复发靠三条机制。第一，把系统归属写入流程规范与评审检查项，新立项默认只在新系统建记录，评审时检查记录位置。第二，定期抽查回流操作，发现后定位原因并补规则，例如路径不通就补能力、口径未改就调整汇报来源，避免只做通报。第三，例外通道设置有效期与审批记录，到期自动复核，防止临时例外固化为长期双轨。
收敛验证的结果也应留档，与处置清单放在一起，形成从症状、原因、处置到验证的完整记录。下一次出现类似回流时，可以直接对照这份记录判断是旧问题复发还是新原因出现，减少重复排查。
常见问题
冻结旧系统新增后，业务部门提出紧急例外，应该怎么处理？
例外可以保留，但要按通道管理，避免变成新的长期双轨。建议明确三件事：谁有权审批例外、例外有效期多长、到期后如何复核。每次例外都要留下审批记录，并在并行清单中登记对象、原因和退出条件。到期后由责任人确认该对象是否已在新系统闭环，未闭环的重新评估原因，而不是默认续期。
验证发现新系统确实缺少某个流程节点，是等补建完成再关旧入口，还是先关？
建议先补建、再关闭。关闭入口的前提是迁移数据已核对、补建能力已上线并被实际使用。补建期间允许有限并行，但要登记在并行清单中并标注结束条件。如果在能力未就绪时关闭入口，团队会转向线下表格或即时通讯工具，混用从系统之间转移到系统之外，排查难度反而更高。
收敛指标连续几周为零，是否就可以宣布并行期结束？
指标趋零是必要条件，还需要核对并行清单。逐项确认每个并行对象的退出标准是否达成，例如该对象在新系统内连续两周无回流操作、旧系统对应入口已关闭。清单未清空时，即使总体指标好看，也可能存在低频但关键的回流路径，例如季度汇报或年度审计场景。建议把清单清空与指标达标同时作为结束条件。
旧系统只读归档需要保留多久？
保留期限取决于组织自身的合规要求、行业监管规定和内部留存制度，本文不给出统一期限。实际操作中可以按记录类型区分：合同、审计相关的记录按法务与合规部门的要求确定，普通过程记录按内部制度确定。归档期间保持只读访问，并记录访问日志，便于后续追溯。
团队反映新系统路径太长，所以回旧系统操作，这算习惯问题还是能力问题？
需要看回流动作的具体内容。如果多个团队重复出现同一类补做动作，且都指向同一流程节点或字段，更可能是新系统缺少对应能力或路径设计不合理，应按补建能力处理。如果补做动作分散、没有共同节点，更可能是习惯与培训问题，按入口收口和流程规范处理。判断依据来自操作记录和抽样比对，访谈印象只能作为线索。
