新旧系统并行一段时间后，旧系统仍有人登录、提单、查报表，是替换项目里常见的收尾难题。原因通常集中在流程依赖、数据依赖、习惯与信任、治理缺位四类。本文给出一套从症状取证到停用验证的排查路径，帮助判断旧系统使用属于哪类原因，并据此安排处置。
要点总览（TL;DR）
- 旧系统在切换后仍被使用，常见原因分为四类：流程依赖、数据依赖、习惯与信任、治理缺位，每类对应不同的验证证据。
- 排查顺序建议先看新系统是否覆盖旧流程的关键环节，再看数据出口是否仍指向旧系统，然后评估用户习惯与信任，最后检查治理规则是否缺位。
- 判断的关键是找到“新系统能走通但用户不用”与“新系统确实走不通”的分界，让用户现场演示完整操作，比询问感受更可靠。
- 处置按原因对应：流程补位、数据出口切换与只读归档、统一入口与试点案例、停用时间表与权限回收；停用前须确认在途单据清零、归档完成、口径核对。
- 验证用旧系统活跃账号、关键操作迁移率、新系统流程完成率三项指标，配合入口收敛、定期审计与变更同步防止回流。
旧系统仍被使用的典型症状与范围界定
判断旧系统是否仍被实质性使用，先看行为数据，而不是听口头反馈。并行期可以观察三类信号：旧系统的登录量与活跃账号是否维持在一定水平；提单、审批、查报表等关键操作是否仍集中在旧入口完成；是否存在整条业务流程从发起到结束都跑在旧系统上的情况。登录量高但只发生在月初查历史报表，与每天在旧系统走审批，性质完全不同。
需要区分个人零星回访与团队级流程依赖。个人回访通常表现为少数账号低频登录、操作集中在查询类功能、没有新增业务单据；团队级依赖则表现为某个部门或多个岗位持续在旧系统完成同一类操作，且新系统对应位置没有产生等量记录。前者多与习惯或数据出口有关，后者往往指向流程覆盖不足。
本文讨论的范围限定为系统替换完成后的采用问题，即新系统已经上线、旧系统尚未停用的并行阶段。新平台从零实施、选型评估以及迁移切换窗口内的具体操作，属于另外的任务，不在本文展开。明确这条边界，可以避免把实施期遗留问题误判为推广问题。
症状清单
- 旧系统日活或周活账号数在切换后一个月内没有明显下降。
- 关键业务单据仍从旧入口发起，新系统同类单据数量偏低。
- 审批链条在旧系统完整走完，新系统仅做结果登记。
- 报表需求方仍指定从旧系统导出数据，或要求两边数字对齐后再使用。
- 外部接口、对账文件仍以旧系统字段为准。
- 部分岗位的权限在旧系统中未回收，账号仍可正常操作。
按流程、数据、习惯、治理四类归因的排查框架
四类原因对应不同的证据来源，排查时应先提出假设，再用证据验证或排除，避免看到旧系统有登录就直接归因为“用户不习惯”。建议的排查顺序是：先确认新系统是否覆盖了旧流程的关键环节，再看数据出口是否仍指向旧系统，然后评估用户习惯与信任，最后检查治理规则是否缺位。这个顺序的依据是，流程与数据属于硬约束，用户即使愿意用新系统也无法完成工作；习惯与治理属于软约束，通常可以在硬约束解决后通过引导和规则收敛。
| 原因类别 | 假设表述 | 验证证据 | 结论判定 |
|---|---|---|---|
| 流程依赖 | 新系统缺少旧流程的某个环节或审批路径，用户只能回旧系统完成 | 对比新旧审批路径；查看旧系统中仍在流转的单据类型；访谈经办人卡在哪一步 | 若存在新系统无法完成的必要环节，判定为流程依赖 |
| 数据依赖 | 历史数据、报表口径或外部接口仍以旧系统为准 | 报表取数来源；接口对接文档；财务或业务对账口径说明 | 若关键数据出口未切换，判定为数据依赖 |
| 习惯与信任 | 用户不熟悉新入口，或担心数据丢失、结果不一致 | 培训签到与答疑记录；用户访谈；新系统操作失败或退回的记录 | 若流程与数据均已覆盖，用户仍回旧系统，判定为习惯问题 |
| 治理缺位 | 旧系统没有停用节点，权限未回收，双轨期没有截止条件 | 旧系统账号清单与权限状态；变更管理文档；停用计划是否存在 | 若旧系统仍开放且无停用安排，判定为治理缺位 |
用证据排除假设的关键，是找到“新系统具备替代能力但用户仍不用”与“新系统确实无法完成”的分界。做法是让提出旧系统需求的用户现场演示一遍完整操作：如果在新系统中能走通，问题落在习惯或治理；如果走到某一步无法继续，记录缺失环节，归入流程依赖。对于数据类问题，直接追溯报表和接口的取数来源，比询问用户感受更可靠。
排查中常见的误判是把流程缺失当成习惯问题。例如用户说“新系统不好用”，实际可能是某个审批节点在新系统中没有对应配置，导致单据无法提交。此时安排培训不会解决问题，反而消耗用户信任。反过来，把习惯问题当成功能缺失也会导致不必要的开发投入。因此每一类原因都应有对应的证据记录，形成归因排查表后再进入处置。
分原因处置：流程补位、数据切换与习惯引导
处置动作应与已确认的原因一一对应，避免对所有用户统一加培训或统一发通知。流程依赖的处置核心是补齐新系统缺失环节或明确替代路径。可以由流程负责人列出旧系统中仍在流转的单据类型，逐项确认新系统中的对应配置；确实无法立即补齐的，明确临时替代路径和责任人，并设定补齐期限。涉及旧系统停用前，必须先确认没有在途单据，否则停用会造成流程中断。
数据依赖的处置从梳理数据出口开始。把报表、接口、对账文件的取数来源列成清单，逐项确认切换计划；历史数据安排只读归档，保留查询能力但关闭写入；切换前做一次口径核对，由报表使用方确认新旧数字一致。归档和口径核对完成之前，不宜关闭旧系统的查询权限，这是数据类处置的停止点。
习惯与信任问题适合用统一入口和可见的成功案例来解决。统一入口指把新系统的访问路径、待办提醒和常用功能集中到用户日常工作的起点，减少“回旧系统看看”的触发机会；培训应围绕具体岗位的操作任务设计，配合答疑渠道处理个别卡点。试点团队的结果可以作为信心来源，例如展示试点部门在新系统中完成同类流程的周期和准确率，让其他团队看到可比较的结果。
治理缺位的处置是设定规则并执行。包括明确旧系统停用时间表、回收不再需要的账号与权限、规定双轨期的截止条件。这些动作具有不可逆性，执行前需确认在途单据清零、数据归档完成、相关方已知悉停用安排。在并行治理中，ONES 可用于承载新流程的工作项状态流转与成员权限管理，让流程负责人按状态跟踪单据是否已在新系统走完，并为停用前的检查提供可核对的记录；具体配置方式需结合组织自身的流程设计确定。
验证恢复与防止回流的检查项
处置是否有效，用指标验证而不是凭感觉判断。建议跟踪三项指标：旧系统活跃账号数的变化趋势、关键操作的迁移率（新系统同类操作量占新旧合计的比例）、新系统流程完成率（发起后走完审批的单据占比）。三项指标同时改善，才说明使用正在收敛；只有登录量下降而迁移率未上升，可能只是用户暂时搁置了业务。
| 检查项 | 通过标准 | 未通过时的处理 |
|---|---|---|
| 旧系统活跃账号 | 连续观察期内活跃账号降至约定范围 | 按账号逐一确认用途，区分查询需求与流程需求 |
| 关键操作迁移率 | 提单、审批等核心操作主要在新系统完成 | 回到归因表复查是否存在未补齐的流程环节 |
| 新系统流程完成率 | 发起单据能够正常走完审批 | 检查审批配置与权限，排除流程中断 |
| 在途单据 | 旧系统中无未完成单据 | 安排单据在新系统补录或走完后再停用 |
| 数据归档 | 历史数据只读可查，口径已核对 | 完成归档与核对后再关闭写入权限 |
| 权限回收 | 旧系统账号与权限已按清单处理 | 核对账号清单，处理遗漏账号 |
防止回流依靠机制而非一次性通知。入口收敛是第一步，把旧系统入口从常用位置移除，保留必要的只读查询通道；定期审计是第二步，按月检查旧系统登录与操作记录，发现异常使用及时归因；变更同步是第三步，当业务流程、报表口径或组织分工发生调整时，同步更新新系统的配置和操作说明，避免用户因新系统未跟上变化而回到旧系统。三项机制配合停用检查清单使用，可以把并行期的收尾变成可验证、可复查的过程。
常见问题
并行期旧系统登录量下降，但业务单据仍从旧入口发起，说明什么？
这通常说明登录量下降只是查询类回访减少，流程层面的使用并未收敛。判断时应看关键操作的迁移率，即提单、审批等核心操作在新旧系统中的占比，而不是只看活跃账号数。若单据仍从旧入口发起，回到归因表复查是否存在未补齐的流程环节或审批配置缺失，再决定是补流程还是做引导。
用户反馈“新系统不好用”，如何区分是功能缺失还是习惯问题？
让提出问题的用户在新系统现场演示一遍完整操作。能走通则问题落在习惯或治理，可安排针对性答疑或检查入口与权限；走到某一步无法继续，记录缺失环节，归入流程依赖。仅凭口头反馈容易把流程缺失误判为习惯问题，导致培训无效、消耗用户信任。
旧系统停用前必须确认哪些条件？
停用属于不可逆操作，执行前至少确认三项：旧系统中没有未完成的在途单据，历史数据已完成只读归档且报表使用方确认新旧口径一致，账号与权限已按清单处理。任一条件未满足时，先安排单据补录、归档核对或权限清理，再推进停用。
历史数据归档后，是否还需要保留旧系统的查询入口？
归档的目标是关闭写入、保留查询能力。在报表口径核对完成、使用方确认新旧数字一致之前，不宜关闭旧系统的查询权限。之后可将旧系统入口从常用位置移除，仅保留必要的只读通道，并按月审计登录与操作记录，发现异常使用及时归因。
流程、数据问题解决后，仍有少数用户回旧系统，怎么处理？
这类情况多属习惯与信任问题。可把新系统的访问路径、待办提醒和常用功能集中到用户日常工作的起点，减少回旧系统的触发机会；培训围绕具体岗位任务设计，配合答疑渠道处理个别卡点；用试点团队在新系统完成同类流程的周期和准确率作为可比较的结果，帮助其他团队建立信心。
