系统上线失败的原因里，数据准备不足占了大头。这份清单把上线前要备齐的数据项列全，漏任何一项都可能让上线变成灾难现场。
先给结论：数据准备的工作量通常占总上线工作量的三到四成，而且必须由业务部门主导、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：数据准备到底要提前多久启动？
按主数据规模估：一万条以内提前一个月，几万条级别提前两到三个月启动清理，期初动态数据在切换前一周准备。关键不是日历时间，是倒排出来的工作量：清理条数除以人均日处理量，得出人天，人天不够就早启动或加人。多数项目的问题不是启动晚，是启动时低估了清理深度。
