做了一半，然后停了

数字化转型项目最常见的状态不是失败，是做了一半，然后停了。

启动时轰轰烈烈，高层站台、供应商入场、全员动员。三个月后，项目进度开始滞后。六个月后，第一批交付的功能上线了，但用的人不多。九个月后，项目团队开始缩减，供应商撤场。一年后，项目被新的优先级取代，没有人再提起。

这不是个别现象。很多企业的数字化转型项目都处于这种“半完成”状态。系统上线了，但使用率低；功能交付了，但业务流程没改；数据接入了，但质量不行。项目不算失败，因为确实交付了一些东西。项目也不算成功，因为预期的价值没有实现。项目处在灰色地带，没有人宣布终止，也没有人继续投入。

这种状态比明确失败更消耗资源。明确的失败至少可以止损，半完成的项目会持续消耗运维资源，却不再产生新的价值。系统在跑，数据在进，但没有人去优化、去推广、去闭环。

做了一半的典型症状

系统上线了，但用户还是用旧流程。ERP里采购订单功能齐全，采购员还是用微信下单，完事后到系统里补单。补单不及时，系统里的数据永远是滞后的、不完整的。问采购员为什么不用系统，回答“系统太慢”“操作太麻烦”“供应商不用系统”。用户绕过系统，系统就成了摆设。

数据接入了，但质量不可信。CRM和ERP之间的客户数据同步了，但对账时还是对不上。BI看板上的图表很漂亮，但管理层不敢用来做决策，因为“数据可能不准”。数据不准不是因为技术实现有问题，是因为数据源头没有治理。源头的问题不解决，下游的数据应用就永远在沙地上盖楼。

流程固化了，但固化的是老流程。系统开发时按当时的业务流程设计，审批节点、权限分配、数据流向都是基于老流程。上线后业务变了，流程需要调整，但改系统要排期、要测试、要上线，周期很长。业务部门等不及，又开始线下操作。系统里的流程是老流程，线下的操作是新流程，两者脱节。

项目交付了，但组织能力没跟上。系统上线后，原来的项目团队解散了，各回各的岗位。系统运维交给了IT部门，业务优化交给了业务部门。IT部门不熟悉业务逻辑，业务部门不熟悉系统配置。碰到问题需要跨部门协调，没人牵头，没人拍板。系统在，能力不在。

为什么项目会做了一半

项目启动时目标定得太高，资源却给得不够。三年建成数据中台、打通所有系统、实现全流程数字化。目标听着很宏大，执行起来发现数据治理、系统集成、流程再造每一项都需要大量投入。一期项目做完了，资源也耗尽了。二期、三期没有预算，项目就停在了半路上。

项目推进时业务部门参与度不够。需求阶段业务部门提要求，开发阶段业务部门不参与，验收阶段业务部门提意见。开发团队按需求文档做，做完发现不是业务部门想要的。改，需求变了；不改，业务不用。业务部门觉得系统不好用，开发团队觉得业务部门需求不清。参与度不够，系统就和业务脱节。

项目考核时重过程轻结果。项目按计划完成、系统按时上线、功能按需求交付。考核指标里没有“用户使用率”“业务效率提升”“数据质量改善”这些结果指标。交付了就算成功了，至于用不用、效果好不好，那是后面的事。考核导向决定了团队的行为重心。

项目收尾时知识转移不到位。供应商撤场时，交付了代码、文档、操作手册。但代码为什么这么写、当初有哪些备选方案、哪些地方打了补丁，这些隐性知识没有转移。项目团队的核心成员可能在下个项目开始前就离职了。系统在，懂系统的人不在。

从“做了一半”到“做完了”需要什么

做完一个项目，不是把功能开发完、把系统上完线，是把业务跑通、把用户教会、把数据管好。做完的标志是用户主动用、业务效率真提升、管理层敢依赖数据做决策。要做到这个状态，有几个事情需要持续投入。

业务部门在系统上线后继续参与优化。不是把系统交给IT就完事了，业务部门需要持续收集使用反馈，提出优化需求，参加迭代评审。系统优化没有终点，业务变了，系统也要跟着变。迭代能力比初始交付能力更重要。

数据治理在上线前就要开始，上线后持续迭代。不能等到数据脏了再来清洗，要在数据产生的源头就管住。编码规则、录入规范、校验逻辑，这些要在系统上线前配置好。上线后定期检查数据质量，发现问题及时处理。

项目团队在系统上线后还要保持一段时间。不能上线第二天就撤场。至少留几个人做几个月的支持，处理用户问题、修复系统Bug、进行小版本迭代。知识转移不是交文档，是教会内部团队自己改。

管理层在项目结束后继续关注使用情况。大屏不看、报表不用、决策不依赖，下面的人就不会重视。管理层定期看使用率、看业务效果、看数据质量，把数字化转型作为常规工作来关注，不做一次性运动。

新易编码如何避免“做了一半”

新易编码不是大平台，不需要长周期实施、不需要大规模定制、不需要依赖供应商长期驻场。部署周期短，实施成本低，业务部门可以自己配置规则、自己管理编码、自己监控质量。

新易编码的价值很容易验证。上线后两周就可以看到编码重复率是否下降、库存准确率是否提升、采购计划是否更准。短期可验证，管理层就能快速判断项目是否值得继续投入。不需要等半年一年才知道结果。

编码是业务部门自己在用、自己管理，对工具的依赖度不高。新易编码做得好不好，用户很快就有体感。编码申请快了、查重准了、报表看得懂了，用户会主动用。主动用的工具，不会出现“做了一半没人用”的情况。

数字化转型项目做了一半就停下来的根本原因，是项目被当成了“一次性工程”。系统上线就是终点，验收通过就是结束。但实际上，系统上线只是起点。用户需要引导，流程需要磨合，数据需要治理，能力需要转移。

做完了的标准不是功能交付，是业务改变。业务没有改变的项目，系统和流程做再多，也只是在旧房子外面刷了一层新漆。漆会掉，房子还是那个旧房子。业务的改变需要持续投入，持续关注，持续迭代。项目有终点，数字化没有终点。

新易编码在这方面有它的特性——小、快、独立、业务部门自服务。不容易出现“做了一半”的状态，因为它的价值验证周期短，用户的体感直接。不需要等一年才知道成不成功。这个特性不适合所有类型的项目，但用在编码管理这个环节，是合理的。编码管理是数字化转型中的一小块，搞定这一小块，其他环节的复杂度就降一些。