3. 切换前现状评估与基线建立
智能工厂上线切换不是“把新系统打开、把旧系统关掉”这么简单。真正决定切换成败的，是切换之前是否把现状摸清、把基线定准。现状评估与基线建立的核心目的，是回答三个问题：现在有什么、现在跑得怎么样、切换后拿什么标准判断变好还是变坏。如果这三件事没有量化答案，切换就失去了判断依据，一旦出现异常，团队只能凭感觉争论，无法快速定位是系统问题、数据问题还是业务操作问题。
一、现状调研：从“听说”到“看见”
现状调研不是发一张问卷让各部门填，而是要到现场看真实操作。调研应覆盖四条线：业务线、系统线、数据线、人员线。业务线关注订单到交付的主流程、异常处理路径、手工台账和线下审批；系统线关注现有MES、ERP、WMS、SCADA、PLC等系统的版本、接口方式、数据库类型和运行年限；数据线关注主数据（物料、BOM、工艺路线、设备台账）的完整率与准确率；人员线关注关键用户的操作习惯、班次安排和培训接受度。
调研方法建议采用“跟单法”：选一张真实工单，从订单录入开始，跟着它走完计划排产、领料、加工、质检、入库全过程，记录每一步在哪个系统操作、耗时多少、是否依赖纸质单据、异常时如何回退。跟单法能暴露大量问卷问不出来的问题，例如某工序实际靠Excel排产、某质检结果只记录在班组白板上。调研输出应形成现状流程图+问题清单，问题清单按“影响切换”和“不影响切换”分类，避免把所有历史遗留问题都塞进切换范围。
二、系统清单与接口清单
系统清单不是简单列软件名称，而要形成可核对的资产表。每套系统至少记录：系统名称、版本、供应商、部署方式（本地/云）、数据库、关键接口、责任人、当前用户数、日均事务量、是否在切换范围内。接口清单要单独维护，因为切换中最容易出问题的就是接口。每个接口记录：源系统、目标系统、协议（如REST、OPC UA、数据库直连、文件交换）、频率（实时/分钟/小时/班次）、数据方向、字段映射、异常处理方式。
例如，某工厂MES与ERP之间通过中间表交换工单，频率为每5分钟一次。切换前必须确认新MES是否支持同样的中间表结构，或者改为API调用后，ERP侧是否需要改造。如果只记录“MES与ERP有接口”，而不记录频率和字段，切换后可能出现工单延迟或重复下发。
三、数据基线与业务基线
数据基线是切换后判断数据是否“接得上”的参照。建议在切换前对关键数据做一次快照，记录：物料主数据数量、BOM层级数、工艺路线条数、设备台账数、未结工单数、库存批次数量、供应商与客户主数据数量。同时记录质量指标：主数据完整率、重复率、编码规则一致率。例如，切换前物料主数据共12,480条，其中缺少默认仓库的占3.2%，缺少采购单位的占1.8%。这些数字就是切换后数据校验的基准。
业务基线是切换后判断“跑得好不好”的参照。应选取切换前连续2～4周的稳定生产数据，统计：日均工单数、平均工单交付周期、计划达成率、一次合格率、设备综合效率OEE、库存周转天数、异常工单占比。业务基线必须注明统计口径，例如“计划达成率=按期完工工单数/计划工单数，按工单完工日期统计，不含返工”。口径不一致，切换后的对比就没有意义。
四、风险基线与切换就绪度评估
风险基线是把已识别风险按“发生概率×影响程度”排序，并记录当前控制措施。常见风险包括：接口不通、主数据缺失、关键用户不会操作、新旧系统并行导致数据双写冲突、网络或服务器资源不足。每条风险应有责任人、缓解措施和触发条件。例如，“接口不通”的触发条件是切换后2小时内工单未同步，缓解措施是启用备用文件导入通道。
切换就绪度评估是把上述工作转化为可打分的检查表。建议按六个维度评分：业务准备、系统准备、数据准备、接口准备、人员准备、应急准备。每个维度设若干检查项，每项按0/1/2分（未开始/部分完成/完成）打分，总分换算为百分比。通常要求总分≥85%且无单项为0才允许进入切换窗口。若数据准备得分低，即使系统功能再完整，也应推迟切换，因为脏数据会直接污染新系统。
五、就绪度评估的实际操作
就绪度评估不是一次性打分，而应在切换前T-14天、T-7天、T-1天各做一次。T-14天用于暴露缺口，T-7天用于确认整改完成，T-1天用于最终放行。每次评估后更新得分和未完成项，未完成项必须明确“谁、在什么时间前、完成什么”。如果T-1天仍有单项为0，应启动延期决策，而不是带着已知缺口强行切换。
一个常见的误区是把“系统功能测试通过”等同于“切换就绪”。功能测试只覆盖系统准备一个维度，数据是否清洗完、接口是否联调完、用户是否会操作、回退方案是否验证过，都不在功能测试范围内。因此，就绪度评估必须由业务、IT、数据、接口、培训、运维六方共同确认，任何一方不签字，都不应进入切换窗口。
最后需要强调：现状评估与基线建立的价值，不仅在于“切换前用一次”，更在于它形成了一套可复用的度量体系。切换完成后，同一套指标可以继续用于稳定运行期的日常监控，帮助团队从“救火式切换”转向“数据驱动的持续改进”。