尤记得几年前，那桩轰动一时的《国外某巨额投入的数字化转型项目失败所引起的法律纠纷案》。

当时，业界人士几乎都在热议这件事。

我也在了解整件事情的原委后，发表一些感想。

当时我就觉得，作为行业从业人员，不要幸灾乐祸，而应从中吸取经验教训。争执双方是非曲直，自有法律裁判，我们应该基于事实，做出理性判断。

以下再来谈谈我从该事件得到的启示。

根据网上披露的起诉方（乙方）的起诉文件原文（有兴趣朋友可自行搜索）的描述，项目范围应该是“数字化前端体验提升”，不仅仅是“网站开发”那样简单；商务上，项目是基于一个2004年签订的总体咨询框架合同。在过去两年时间，项目实际上经历了三个阶段：第一阶段是2016年3月份开始，大约三个月的数字化转型战略规划、评估的咨询，第二个阶段是基于前期的规划，经过招投标，甲方还是选择了乙方继续从事执行工作，2016年8月到11月期间是架构和方案设计的咨询，第三阶段是从2016年底开始的具体系统开发、实施。问题主要出在第三阶段，技术交付出现了很多让甲方不满意的问题。

起诉书原文第六段，我翻译如下：

6. 甲方信赖乙方所宣称的在实施该类数字化转型方面的专业能力，由乙方承担总体项目经理（Overall project manager）。乙方搜集甲方的需求，并且开发出设计方案来实施这些需求。乙方还作为产品所有人（Product Owner），由乙方，而非甲方,来决定设计是否满足甲方要求。

这段文字明确指出，第一，乙方承担全部项目管理责任，第二，乙方承担产品经理角色。我认为，这样的项目治理模式，已经埋下了很大的失败隐患；项目失败，甲方不是没有责任的。

甲方的初衷也能被理解：一，我们双方有战略合作框架协议，二，前面的规划和架构设计都是你乙方做的，你对我们情况应该很了解了，正是因为信赖你的专业，所以我才完全交给你来操盘。但是，我认为，在任何时候，甲方都不应该把项目管理、产品管理的责任完全推给乙方。企业数字化转型不是简单的IT外包，不是“交钥匙工程”，甲方如果自己不具备专业人才来进行项目管理和承担项目责任，这样的项目，最好不要做，无论对甲方，还是乙方。

项目背后可能还存在着各家公司的风险管理、业绩压力等一系列更深层次的问题。即使大家都看到了项目管理存在的问题，也只有上了。

另外，咨询和实施阶段前后分开，也是数字化转型项目常见的风险：咨询顾问在前面画PPT挖坑，前面顾问撤场后，开发人员没有完全理解PPT的微言大义，接了手顾头不顾尾地到处填坑，这种情况是项目乱象的根源。做数字化转型项目，从一开始就应该由架构师和业务顾问并肩工作，并且保证架构在实施过程中得到持续贯彻。我认为，架构管理也不应该完全交给乙方，应该是甲方自己的核心能力，这才不会到项目后期出现对一些架构基本问题的争论。

项目管理、架构管理，是数字化转型项目实施的两个基本成功要素。

ok，这是比较典型的国外数字化转型失败案例，下面再讲讲国内的。

珠海某企业为了通过某项认证决定开始引进ERP系统，该企业属于传统型企业，虽然进行了一些数字化建设，但都属于简单应用，员工的数字化能力及水平很薄弱，虽然有了数字化意识，但认知深度还是不够；经过企业高层开会讨论后决定，此次引进ERP系统的目的有两个：

第一，先通过某项认证；

第二，实际应用起来；

但在需求调研中业务部门都以为买系统是为了过认证，所以参与度不高；通过选型后选择了某大厂的产品，原因如下：

1.该大厂价格最低；

2.方案做的不错，让领导满意；

3.大厂承诺有相关专家配合做前期认证准备工作，承诺其专家指导后可让企业轻松通过认证；

但合同签订软件公司进场后才发现该大厂实施能力不足，实施人员缺乏对行业的足够了解，所谓的专家也是从全国各地临时抓的“壮丁”，各专家对认证之事所理解所做的方案内容不一，相互矛盾。

让企业反复推翻系统方案，苦不堪言；同时企业的业务部门也缺乏足够的配合，系统数据及时性、准确性难以保障；随着认证时间的临近，不得以企业又额外花钱聘请行业专家前来指导，解决了认证考核的全部问题；通过考核后在系统全面应用后又发现各种问题接踵而来。

例如，系统对业务的匹配问题、易用性问题、业务部门的配合问题、相关制度保障等运营问题；同时系统BUG多且大厂服务响应过慢，导致怨声载道，最后勉强支撑了一年不到，该产品宣布停用，该大厂自然也未能结算到尾款。

你以为该企业的数字化建设这就结束了吗？

不！

接下来发生的与大部分传统企业的情况很类似！

半年后该企业的业务部门又以比第一次多出50万的价格重新采购了另一大厂的ERP产品，因为业务部门认为该大厂更专业，但结果却是：虽然该大厂行业经验足够丰富，产业功能也贴合实际，但经过实施后应用的也很勉强，只应用了几个简单的功能模块，核心的成本管控还是用传统Excel模式，但匪夷所思的是该系统的运维却放在了引进该系统的业务部门，与信息中心无关。

运行大半年后发现经常有数据泄露的情况发生，经信息部门协助核查后发现，原来是业务部门不懂产品运维，后台几乎未设置任何用户权限，可以说是普通用户都可以看到企业经营的所有数据，最后不得以系统运维权限又被划分到信息中心。

我们来分析一下该案例中的数字化项目为什么会失败：

一、初心不对

在该案例中做数字化转型建设的主要目的之一是为了通过某项认证，而非改善管理；但我们不能说这种做法不对，因为通过了某认证确实可以为企业带来可观的经济价值，例如投标加分、获取补贴等，都说数字化建设要以价值为中心，而这种经济价值更有直观性，所以也让很多企业乐此不疲为了获取补贴而大搞“伪数字化”，即为了补贴随便买套系统，按要求例如一些数据，通过考核后该系统也就基本无人使用了。

所以该案例中将通过认证放在首位直接导致了企业领导、业务部门对于该系统的定位：非应用型，而后产生一系列的连锁反应：

1.选型期间首先考察的不是系统的专业性，而是对认证的满足程度；

2.对软件公司实施能力的考核也变成为对认证的熟知程度；

3.业务部门认为该系统就是为了“补贴”而来，所以认为这就是某部门的工作，与己无关，所以在数据录入中随意性强，属典型应付型；

所以不难看出企业做数字化项目的初心不对，将直接影响数字化的“性质”，虽然产生了某些直观经济价值，但确实是已经“变了味”，结果就是对短期的收入有益，但对于企业的长期发展而言无益。

二、选型失误

软件公司可以说是企业数字化转型建设之路的重要战略合作伙伴，一旦选型失误，企业将在数字化建设之路上兜兜转转，难以看到成果。

本案例中虽然企业的选型初衷不对，导致了选型失误，但该大厂的表现也是大跌眼镜，典型的“卖家秀与买家秀”，这也是企业在数字化转型建设中经常遇到的场景：在大厂光环及PPT方案的加持下会让企业领导产生错觉，认为选大厂没错，其实有些时候某些大厂的实际能力就是一张纸，某些大厂为了KPI大搞产品线延伸，每个行业都想做，结果每个行业都做不好，除了大厂的光环外就剩几张PPT了，案例中该企业遭遇的就是此种现象，因此企业在选型环节一定要注意不要被某些大厂的光环蒙蔽了双眼，大厂有实力固然不假，但缺深度却是最致命的。

三、业务部门的参与度

虽然该企业在系统定位时已经说明通过认证后系统还是要真正应用起来，但在整个项目建设过程中业务部门均为消极参与，从系统选型到实施，业务部门均以应付的心态来应对，对系统的成熟度、功能贴合度、业务逻辑都未进行验证、提出任何意见，也未对传统业务进行任何数字化改进，所以当系统全面应用的时候，各种问题层出不群，这个时候要厂家来解决，在时效上已经大打折扣了，因为前期为做认证已经耗费了软件公司大量的实施人天，甚至签订了系统的验收报告，此时软件公司为了控制项目成本，哪里还有什么服务可言，因为服务就意味着投入与支出，大厂响应慢也是情理之中。

所以业务部门的参与度直接影响数字化项目成败，而业务部门参与度低或者不参与也是部分传统企业在数字化建设过程中的常见问题。

从以上不难看出该数字化项目之所以失败，一开始就已注定，不论从建设初心、系统选型还是实施过程都存在着各种隐患问题，因此企业需要：

一个清晰的数字化战略规划；

一个清晰的实现路线；

一个融合的思维；

一个靠谱的供应商；

但数字化项目建设失败以后，部分的传统企业又会走进“重复建设”的怪圈，既然A公司产品满足不了需求，那就找B公司重新再来，并未深刻认识到前期数字化建设失败的根源在哪里，认为都是软件公司的错，从未从自身的管理去改进，仍然用工具化的思维去做数字化，所以我们看到该公司第二次进行ERP系统建设比第一次竟然多花了近50万，但最后也只是用了几个功能简单的模块而已。

最后该企业又犯了另一个错误，业务部门做了信息部门的工作，这种现象在部分传统企业里也时有发生，领导甚至认为与“技术”沾边的部门都是搞技术的，都可以做数字化建设与管理，但术业有专攻，业务思维与技术思维是有本质区别的，所以也就闹出了业务部门连最基本的数据安全思维都没有，导致数据完全公开的重大安全事件。

上海某集团旗下产业众多，某分子公司业务部门工作需要准备引进一款管理系统，但其相关需求并未向集团信息中心通报，就直接联系了某软件公司，该软件公司商务能力很强，直接将企业分子公司的总经理拿下。

同时在演示会上以精彩的方案演讲获得了相关领导的认可，该软件公司极力推其SAAS产品，理由是价格便宜，无需企业运维，同时可以享受快速迭代服务，在低价、服务承诺下该分子公司马上就确定采购了其SAAS产品，但实施上线后发现问题如下：

1.该软件公司虽为大厂，产品线丰富，但其对企业分子公司所在的行业认知不深、经验缺乏，之前商务阶段承诺的各种管理及业务指导难以实现；

2. 由于是SAAS产品，业务部门提出的各种个性化需求厂家均拒绝表示不能修改，可以在以后的版本中迭代，导致业务部门使用期间怨声载道，而软件公司所承诺的功能迭代也一直未实现；

3. 厂家相关技术问题响应慢，厂家所解释的原因为：本地无技术售后团队，所有需求均需申报在异地的总部排队解决；

4. 公司以为购买SAAS产品价格低，但却忽略该软件的收费模式是按项目个数，结果一算下来成本并不比本地部署的其他软件产品低；

5. 在下半年的某日财务突然发现一些历史数据不见了，厂家排查后给出的原因是：软件进行了一次大版本升级，导致数据丢失，可进行恢复操作，结果财务苦等3个月后，丢失的数据仍有部分未恢复。

基于该软件的差劲表现，集团财务领导大为光火，分子公司的领导坐不住了，于是求助集团信息部门，在与软件公司召开多次沟通协调会议以后，集团领导决定停止合作，由信息部门配合业务部门一起重新选型，在对该系统的数据进行备份时才发现，软件公司给提供的备份数据全部是一堆的Excel表格，无任何数据逻辑性，售前所承诺的备份数据可导入其他系统是空谈。

最后在信息部门的协助下，分子公司重新选购了一套本地部署的产品（织信Informat），成本节约了60%，而功能却更专业，符合业务部门的应用需求。

从以上这个案例中我们会发现很多问题场景在大部分的传统企业都是相似的，总结如下：

未实现数字化的统一管控

这种在传统型的集团公司非常普遍，由于产品众多、且遍布各地，集团在管理上会存在各种不足，尤其是不被重视的数字化，这就导致企业在数字方管理方面存在：管控不统一、数据不统一、各分子公司数字化能力不一的现象，尤其是产生价值最大的分子公司存在更大的随意性。

管控落实不到位

虽然集团信息部门制定了相关数字化的管理措施，但仅仅是一纸公文而已，并未对分子公司在数字化建设方面的随意性产生约束，即使违反了相关规定，也难以按规定去落实，执行力不足是当前传统企业存在的最大问题。

业务部门数字化能力不足

在大部分的传统企业中，业务部门总是认为系统建设很简单，就是软件买卖过程，于是就被某些软件公司所利用，故意绕开信息部门直接与业务领导接洽，利用其技术能力的缺失，在商务上进行“打动”、在所谓的服务上进行“感动”、让其产生购买的“冲动”；加之企业缺乏数字化统一管控的制度及力度，所以很快就达成采购行为。

而在实施期，软件公司利用业务部门不懂数字化项目管理这一“优势”，很快完成部署、调试、上线，然后让业务部门快速验收，等业务部门发现系统各种问题的时候已为时已晚，之前热情的响应速度一流的商务人员已换成不急不慢甚至半天无响应的售后，这要业务部门痛苦不堪。

还说一个案例吧，某大型代理记账公司的财务部门自行采购了一套财务系统，系统上线后运维工作由其自行负责，结果由于原负责系统运维的人员离职，导致系统新增一个账套就只能找厂家售后，于是这就开启了漫长的等待模式，一个简单的账套新增、权限分配甚至要等上一两天才能完成，这样对日常工作的开展造成了很大的阻碍，感觉用数字化系统不是提升了效率而是制造了新的麻烦。

系统选型缺乏综合分析能力

由于业务部门各种数字化能力的不足，技术上的认知不足，所以在选型阶段极易被急于达成交易的软件公司售前人员所忽悠，在选型阶段，业务部门经常犯的错误是只考虑满足自身的业务需求，而忽略其他协同部门的应用需求，业务人员想当然的认为系统仅自己部门使用，结果应用起来才发现，很多工作其实是需要其他部门来协助完成的。

例如某集团财务部门为了项目结算方便自行引进了一套项目管理系统，上线应用以后业务部门怨声载道、叫苦不迭，因为系统不符合业务部门的需求，很多功能难以满足；而财务部门却应用感觉良好，因为系统满足了财务管理的需求。

最后该公司业务部门又自行采购了一套业务管理系统满足自身的管理需要，但与财务系统未打通，为了结算方面还是需要再财务系统内录入相关数据，这无形中造成了数据孤岛、造成了大量的重复工作产生，给业务部门带来了额外的工作负担。

需要企业注意的是，SAAS产品虽然具有开箱即用、免运维、迭代快、成本低（暂时的）的优势备受一些企业的青睐，特别是没有信息人员的中小企业，但并不是所有的企业都适合用SAAS，而SAAS本身也是存在一些缺点的。

在本案例中最突出的问题是：

1. 业务部门并未对产品的功能与需求进行匹配；

2.未对软件公司的行业能力进行考察，综合考评；

3. 对SAAS缺乏深度的认知，只看到了所谓的一时的表像化的便宜、快速的迭代、免运维；而这些其实存在很大的“坑”；所以盲目的做数字化转型，不是踩坑就是被坑。

综上所述，在本案例中由于企业本身管理的缺失造成了数字化转型工作中的损失，而这些损失本就可以避免的，在大部分情况下，业务部门自行采购的系统都存在应用难、运维难、数据安全隐患大的风险，最后兜兜转转又回到了信息部门。

所以想破解重复建设的魔咒，降低数字化建设成本，集团型企业必须统一数字化建设、实施、售后、运营等各个环节的出入口，制定相关制度、明确相关责任，特别是要严格处理违反制度的行为，保障数字化管理体系健康、顺利的执行与发展。

某企业内部招待中心接待量大，从包厢预定到招待消耗都是人工登记、人工签字核单，且经常发生接待超标的事情，一把手为此经常批评接待中心管理工作不到位，因此为了规范管理也为了方便接待数据统计，接待中心的负责人找到企业信息中心的开发团队要开发一款订餐的小程序，开发管理程序上严格按公司要求走内部审批流，通过了分管领导、董事长审批，没问题。

软件开发部门按部就班进行系统开发，从需求调研到功能测试一切看似很顺利，但在进行系统上线正式推广应用时接待中心的负责人就有点打退堂鼓了，原因是找他订餐的均是副总级大佬，他一个不敢得罪，大佬们一听说要用系统订餐就纷纷反对，因为大佬们习惯了用电话安排，为此接待中心负责人也不敢推系统，仍按原始的方式处理：电话订餐、纸质签单，信息部门找分管领导沟通当前难点，分管领导态度坚决表示一定要用系统，结果找一把手争取支持准备下文强推的时候，一把手的态度竟然翻转了，理由是副总们在一把手那里抱怨用系统太麻烦了，而一把手又不愿增加副总们的工作负担，又默认了最开始的那套模式。

其实系统功能设计的很人性化，在易用性上下了功夫，开发部门从一开始就考虑到那些大佬们不愿填资料，大部分都是选择按钮，点几下即可完成操作；但由于一把手此时态度翻转，系统虽然开发了出来，但也没办法推广只能选择弃用！

从这个失败案例，我们分析如下：

该案例从需求提出到系统上线没有任何问题，过程合规，业务痛点明确，相关领导支持；但唯一的变数是最大的系统使用方领导层反对，这种现象在大部分的传统企业数字化推广过程中比较常见。

第一，高层领导年龄偏大，思想趋于保守，喜欢用传统的模式工作，骤然的改变一时间是难以接受的。

第二，大部分的高层领导不喜欢被约束，不喜欢自己的相关工作数据被系统记录，在接待中超标也是常事，但应用数字化系统约束了其相关招待行为，因此领导们反对、不用也是正常。

第三，虽然企业有了相关接待管理制度，必须用系统报备、结算，但违反事件也时有发生，尤其是核心高层领导带头违反，所以在这种情况下不管是信息部门还是招待部门也是敢怒不敢言，只能寻求一把手来支持。

但本案例中一把手态度出现了翻转，这在大部分传统企业也是常见现象，因此在传统企业推行数字化不仅需要一把手的口头支持，更需要一把手亲力亲为带头应用。

从以上这个案例我们看到有多少企业数字化建设是毁于缺乏共识，缺乏政策支持，缺乏执行能力。有时候企业想利用数字化工具提高工作效率，奈何阻力重重，这种无形的阻力就是传统的意识、传统的权威，但这层权利墙只有一把手可以破解，执行力不够，一把手魄力不足，什么“转意识”都是扯淡。

企业做数字化转型，仅仅有意识是不够的，有时候给数字化寄予太高的期望，不以企业管理现状为基础盲目做数字化，其结果也只有失败与烂尾。

某企业拓展了异地新产业项目，由于是异地管理，加之是新项目，各方管理制度还不够完善，存在着很多管理漏洞，因此企业的相关业务负责人给予了数字化系统很高的期望，要求采购一套ERP系统用于经营过程管理，信息部门经过调研后认为当前企业管理还不完善，标准产品难以满足当前灵活的业务需求，建议分步走，先用工具化系统解决最基础的数据采集问题，然后逐步开发相关模块规范经营过程，但业务负责人认为企业的管理是没问题的，迫切要求开发一套ERP系统规范经营全过程，最后报请一把手后同意后自研ERP系统，但只给30天时间，不得以又花费了大量资金请第三方开发团队支持，按期完成开发任务后，在系统上线推广环节又卡壳了。

原因如下：

1. 项目现场组织架构混乱，人员职责不明，权限不明；

2. 现场基层人员人手紧缺，一人兼多职，难有时间配合系统应用；甚至公然排斥，认为是给项目填麻烦；

3. 由于项目初建，管理层人员不稳定，换人即换管理模式，系统功能难以匹配；

4. 项目深处异地，企业总部从业务部门到信息部门难以派出人手赴项目现场做系统推广；

虽然在一开始的推广过程中业务负责人提出不用系统就不做项目相关费用的结算与报销，但奈何项目建设为重，在一把手的关照下，还是做了相关费用结算，在这种情况下系统面临着推广难、应用难，最后该系统又不了了之，名存实亡。

从以上案例中我们不难看出：

第一，任何数字化建设必须以企业实际管理现状为基础，但部分管理者总是想当然的认为管理没问题，流程很正确不需要梳理，人员能力很强不需要培训，员工执行力很强不需要做前期的沟通与调研；结果系统一上线，让企业的管理原形毕露；

第二，系统建设不宜贪大求全，要以企业实际现状为原则分步实施；

第三，数字化系统并不是万能的，特别是在公司或者项目初创期，不论是业务模式、还是人员管理，一切变数很大，需要慎重选择做数字化，需要找一个合适的单点去突破，不要总想着一步到位，那几乎是不可能的；

第四，企业管理者需要深度了解数字化，任何数字化系统从研发到应用都是一个复杂的工程，并不是某些企业管理者想的那般简单，功能照抄解决不了企业的业务难点与痛点。

以上案例是大部分传统企业在数字化转型建设过程中的常见现象，但即使已经发生了，但这种现象依然会重复，因为数字化转型不仅涉及的是技术，更多的是转变，而这一切做起来着实不易，没有一把手的改革魄力，任何信息部门或者业务部门的一厢情愿都是徒劳的，大部分的传统企业总是企图让数字化系统来适应传统的业务模式与工作流程，总想让灵活多变的业务去改造固化的信息系统，缺乏的是认知、共识、融合、转变。

最后建议大家一定要合理并且有效地运用和选择数字化转型工具，因为选择一个合适的工具，不仅可以让我们工作高效地运行，还能最大程度保证团队目标的达成。这里推·荐·织信Informat，平台基于数据模型优先的设计理念，提供大量标准化的组件，还内置了自动化（自研的一套图形化编程）、脚本、工作流引擎（BPMN2.0）、自定义API等功能，能帮助企业构建高度复杂核心的业务系统。如ERP、PLM、MES、SCM、WMS、OMS、EMS、项目、企业服务等多个应用场景，全面助力企业落地数字化转型战略目标。

当然，数字化项目不可能存在100%的成功率，所以不管说得再天花乱坠，都不能代替产品本身，好产品，值得大家切身体验！