为什么复盘总在项目结束后才开始
很多企业做数字化建设,习惯在项目上线后开一场复盘会,把延期、返工、预算超支逐条列出来。但真正的问题往往在项目启动后的头两个月就已经埋下,只是当时没人把它当成问题。江南在服务客户的过程中发现,复盘的价值不在于追责,而在于识别那些反复出现的节奏信号。把这些信号提前识别出来,比事后总结更有用。
结合三个不同规模项目的观察,我把落地节奏失控的早期表现归纳为四类。它们不一定同时出现,但只要出现两个以上,项目就很难按原计划推进。
信号一:业务部门还没想清楚,系统选型已经启动
第一个项目是制造企业的业务数据管理系统建设。立项会上业务负责人说得很清楚:先把数据管起来。但问到具体管哪些数据、谁来录入、异常怎么处理,回答就比较模糊。与此同时,采购流程已经走到供应商比选阶段。
这种顺序颠倒很常见。系统选型本身并不难,难的是选型之前把业务口径对齐。江南在类似项目中通常建议先做一轮业务流程梳理,把关键数据项、责任岗位、流转规则写成可讨论的清单,再进入选型。否则系统上线后,业务部门会发现功能和自己想的不一样,而供应商认为自己按合同交付,双方都觉得自己有理。
- 选型前是否有书面的数据项清单和责任岗位说明
- 业务部门能否用一句话说清系统上线后自己少做哪件事
- 是否存在“先买了再说”的采购节奏
信号二:责任边界靠口头约定,集成阶段集中爆发
第二个项目涉及多个系统的数据打通。启动时各方都表示配合,但没有明确谁负责接口字段确认、谁负责历史数据清洗、谁负责联调排期。到了集成阶段,问题集中出现:上游说字段口径变了没人通知,下游说数据质量不达标无法入库,项目组夹在中间反复协调。
责任边界不是一句“大家配合”能解决的。江南在实践中会把集成工作拆成若干可交付项,每项明确一个责任人、一个验收标准和一个确认节点。这样做不是为了增加文档负担,而是让问题在发生时能快速找到对应的人。复盘时我们发现,凡是边界写清楚的项目,集成阶段的返工次数明显更少。
信号三:投入节奏跟着预算走,而不是跟着能力走
第三个项目的预算比较充足,于是第一期就同时铺开了报表开发、数据可视化和移动端展示。结果数据基础还没理顺,报表口径反复调整,可视化页面改了又改,团队精力被摊薄,每个方向都只做到一半。
投入节奏应该跟着企业自身的数据能力走。江南通常建议把建设分成几个阶段:先解决数据从哪里来、准不准的问题,再解决怎么看的问题,最后解决怎么用的问题。每个阶段设定明确的完成标志,比如核心指标口径确认、基础报表稳定运行一段时间、业务部门形成固定的看数习惯。阶段之间留出观察期,比一次性铺开更稳。
- 第一期是否只聚焦一个可验证的目标
- 是否有阶段完成标志,而不是只看上线时间
- 预算投入是否与团队承接能力匹配
信号四:上线即终点,日常运营没有接棒人
三个项目有一个共同点:上线当天项目组最忙,上线之后反而没人管。数据没人核对,权限没人维护,新需求没人收集。几个月后系统还在运行,但业务部门已经回到原来的手工表格。
数字化建设真正落到日常运营,需要在上线前就明确接棒人。这个角色不一定是专职岗位,但要有明确的职责:定期检查数据质量、收集使用反馈、协调后续优化。江南在项目收尾阶段会协助客户把这项工作写进岗位说明,并留下一份可执行的运营清单。复盘时我们意识到,系统能不能用起来,往往取决于上线后有没有人持续投入少量精力。
四个信号指向同一个判断:数字化项目的节奏失控,很少是因为技术方案不行,更多是因为业务准备、责任划分和运营衔接没有跟上。江南在复盘这些项目时,越来越倾向于把观察重点放在启动前和上线后这两个容易被忽略的阶段。把这两头管住,中间的实施过程反而会顺很多。
第二个信号太真实了,我们上次做系统集成就是谁都说配合,真出问题了谁都不认,最后项目组背锅。
第一个项目那种情况我们公司也有,采购部门催着比选,业务部门还没想明白要什么,买回来发现用不上。
投入节奏跟着预算走这句说到点子上了,预算多不等于能同时干那么多事,摊子铺大了什么都做不深。
上线即终点这个总结很准,我们系统上线半年了,数据没人核对,现在报表数字对不对都没人敢信。
看完觉得复盘确实应该往前看,不是等项目结束才开会,启动阶段就该把这些信号当检查项过一遍。