系统上线失败的原因里数据准备不足占了大头。这份清单把上线前要备齐的数据项列全漏任何一项都可能让上线变成灾难现场。先给结论数据准备的工作量通常占总上线工作量的三到四成而且必须由业务部门主导、IT部门配合反过来做基本必败。数据是业务的资产编码规则、清理口径、期初数据最终签字确认的责任人应该是业务部门IT只负责工具、通道和校验。这个定位没摆正后面所有问题都会变成IT又上一个不好用的系统。一、四类数据准备顺序不能乱上线前的数据按来源和用途分四类准备顺序有讲究先定基础数据再盘动态数据静态资料穿插进行历史数据最后决策。1. 基础数据编码和主数据物料、供应商、客户、部门、员工、设备台账这些主数据是系统运转的地基。核心工作是定编码规则和清洗存量一物多码的要合并一码多物的要拆分字段缺失的要补齐。主数据的问题在上线后最难改因为所有业务单据都引用它改一个编码牵动一串单据。我们单位的做法是成立临时的主数据清理小组业务骨干加IT支持集中办公两周把用了八年的物料台账从两万六千条清到一万九千条合并掉的七千条全是一物多名。2. 期初动态数据库存、余额、在途切换时点的库存数量、财务余额、在途单据这类数据有时间性盘早了没用必须在切换时点前后短短几天内完成。难点不在录入在盘点账实不符的要在切换前查清原因走审批处理掉带着糊涂账上线系统从第一天起就是错的。3. 静态资料制度、图纸、合同扫描件这类数据不阻塞上线但影响上线后的使用体验。可以先上核心流程静态资料在运行期分批补录别让它拖上线节奏。4. 历史数据迁不迁、迁多少老系统里三五年的业务数据要不要迁我的建议是默认不迁或只迁一年。历史数据迁移的清洗和校验成本极高而查询历史的需求多数可以用老系统只读保留来解决。真正要迁的只有主数据和在途业务范围一收窄工作量断崖式下降。二、数据准备的时间账为什么总在最后一周爆雷数据准备在项目计划里普遍被压到两三周实际需要一两个月这是上线延期最常见的原因。爆雷的机制很简单数据清理的深度问题只有在清理过程中才暴露。表面上物料台账两万条清理第一周发现三成条目字段不全第三周发现一物多名的规模远超预期这些问题在计划阶段根本看不见。1. 倒排工期给数据准备留足提前量我的经验值主数据清理按每业务骨干每天处理三百到五百条估工作量人天不够就加人或砍范围别指望上线前突击。突击出来的数据质量上线后全部变成单据错误和部门扯皮。2. 用试录验证而不是拍脑袋清理到七成时抽一批真实数据走一遍完整业务流程建单、审批、出入库、报表。试录暴露的问题比任何评审会都真实账对不对、编码顺不顺手、报表口径对不对一试就知道。3. 两轮全量模拟切换正式切换前做两轮模拟从老系统导数、按转换规则处理、导入新系统、跑校验、对账。第一轮通常是灾难各种对不上第二轮的目标是对账差异为零。第二轮过关正式切换才有底气。这个环节砍掉的团队正式切换当晚的痛苦会翻倍还回来。三、准备不足强行上线的四类后果上线日期是领导定的数据没准备好怎么办硬着头皮上的团队我见过的后果集中在四类一类比一类贵。1. 账实混乱期最轻的代价期初库存不准系统数和实物数对不上业务部门天天在系统里调整。我见过一套仓储系统因为期初数据粗糙上线后连续两个月每月三千多张调整单仓管员的怨气直接演变成对系统的集体抵制。混乱期本身还不是最伤的伤的是它透支了业务部门对系统的信任。2. 业务停摆风险最急的代价切换当晚数据导不进去或者对不上账周一早上业务开不了单。发票开不出、货发不了、报送赶不上截止日这时候没退路。要么通宵人工救火要么回退老系统回退的方案和数据如果没演练过就是二次灾难。3. 决策失真最隐蔽的代价系统上线后领导层开始看系统的报表做决策。基础数据不干净报表的数字看着精细底子是错的错得比没有系统还隐蔽。国资监管场景里这个问题更尖锐报送数据出了口径问题退回整改是小事数据失真被问责就是另一回事了。4. 信任崩塌后二次实施的代价最贵的代价是系统被判死刑。数据乱三个月业务部门形成系统不准的共识手工台账全部回流系统沦为打字工具。这时候想补救等于二次实施清数据、重建信任、再培训成本比第一次上线还高而且业务部门的配合度已经大不如前。四、切换窗口的组织保障数据准备的最后关口是切换窗口一般是周五晚到周日的七十二小时。这七十二小时不是干活的时间是执行既定脚本的时间所有动作提前一周写进切换手册谁在几点导哪张表、校验脚本谁跑、对账差异谁签认、回退条件是什么、谁有权拍板回退。两个原则值得刻在墙上。第一回退预案不是备胎是保险回退触发条件量化写清比如库存对账差异超过千分之五即回退触发即执行不允许现场讨论。第二切换指挥只有一个总指挥出现意外时最忌讳三个人三个主意总指挥拍板其他人执行。我们一次ERP切换当晚遇到供应商主数据重复导入总指挥半小时内决定启用备用清洗脚本凌晨两点跑完对账周一早八点准时开单。那次之后我再没怀疑过切换手册的价值。五、工具层面别用Excel硬扛数据准备的工具链很多团队从头到尾用Excel两万条数据、几十个字段、多轮清理Excel的版本混乱和误操作能把人逼疯。合理的技术路径分三层清洗用脚本或ETL工具做批量规则处理转换规则版本化管理导入后的校验用SQL批量对账而不是人眼抽查。搭贝这类低代码平台在这环节有天然优势数据模型即建即用导入模板和校验规则都可以在平台上配置主数据管理的编码规则、查重逻辑做成平台级的配置项清理、试录、模拟切换在同一套环境里做完不用在Excel、临时数据库和生产库之间来回倒腾。工具顺不顺手直接决定数据团队每天的有效产出。六、上线不是终点数据治理要接着走切换成功只是数据质量的起点。上线后三个月是数据问题的高发期新单据的录入错误、编码规则执行走样、部门之间口径分歧都会持续制造脏数据。两件事要接着做一是数据质量巡检机制每月跑一遍查重、空值、逻辑冲突的校验问题清单派单整改二是主数据的增量管理流程新增编码走审批而不是谁想建谁建。数据治理做得好的单位系统上线两年后数据还是干净的不做的两年后又要花一两个月清一次。数据的熵增不治理就不可逆这是所有信息系统的共同规律。常见问题Q怎么判断数据准备到可以上线了三个硬指标主数据清理完成率百分之百且业务签字确认第二轮模拟切换对账差异为零或差异全部有解释有审批切换窗口的每一步动作有明确责任人和回退预案。三个都满足就上缺一个就延。延期的成本是一次性的带病上线的成本是复利式的。Q业务部门说没时间清数据怎么办把数据质量的责任和签字确认权一起交给业务部门期初库存谁确认谁负责上线后账实不符的调整单据算谁的问题写进项目启动会的纪要。责任到人之后“没时间会变成怎么排优先级”。IT部门包办数据清理是吃力不讨好清得再好上线后业务一句这不是我们认可的数据就全盘否定。Q老系统数据直接全量迁移行不行不建议。全量迁移听起来省事实际是把老系统的历史脏数据原样搬进新系统新系统从第一天起就背着包袱。推荐做法主数据和在途业务必须迁一年内的单据数据视查询需求迁更早的历史数据留在老系统做只读查询需要分析时用报表工具直接连老库取数比迁移清洗便宜得多。Q切换当晚最容易出现什么问题高频问题三个转换脚本没在真实数据量下测过正式跑时性能撑不住期初数据导出时点和新老系统并行期没对齐出现一笔业务两边都记或都不记对账差异没人敢拍板窗口期白白耗掉。对策都是老办法两轮全量模拟切换覆盖前两个切换手册里预授权覆盖第三个。Q数据准备到底要提前多久启动按主数据规模估一万条以内提前一个月几万条级别提前两到三个月启动清理期初动态数据在切换前一周准备。关键不是日历时间是倒排出来的工作量清理条数除以人均日处理量得出人天人天不够就早启动或加人。多数项目的问题不是启动晚是启动时低估了清理深度。