信息化项目交付为何越来越难,是甲方要求高,还是乙方做的不到位？

这个问题可以从各种角度分析，我的分析方式是从参与这件事的人开始。

1、信息化项目的参与方

信息化项目参与的各方势力，可以用下图来概括：

信息化项目各参与方

信息化项目，需求的发起方是业务部门。理论上，是业务部门有需要，才发起需求，和IT部门一起做规划，然后找供应商来设计和实施。

从上面一张图看起来，大家分工明确，职责清晰，是具备完成一个项目的基础的。

2、项目目标的问题

然而实际情况是，很多项目开始时就先天不足：

需求不是业务部门发起的，而是领导交办任务。尤其是过去这些年，数字化是一种趋势，一种国家的战略。很多企业有不参与就会落后的危机感，都希望积极参与。但是，业务部门并没有切实的痛点，或者自我改进的需求。

也就是这个项目的目标是不清晰的。

有时候可能只是领导一句话。

不说项目目标的SMART了，可能只是一个模糊的方向。一个团队，朝着一个模糊的目标前进。项目成功交付的概率，一定是很低的。

3、业务部门存在的问题

信息化项目，理想状态下，是以信息化系统为抓手，建立人机协同的管理流程，实现公司的管理目标。

那么，对于业务部门的代表，应该具备规划业务流程的能力，要能够设计符合管理要求的（领导满意），符合一线可操作性强（员工满意）的流程。

将这个要求拆分一下，就是业务部门代表需要具备如下素质：

业务技能：

• 业务专家：熟悉本部门的业务，有深度，有细节

• 全局观：不能只懂某个细分领域，要全懂。至少是有个宏观的理解。

• 管理能力：跨部门/跨领域拉通资源和能力的能力。

信息化技能：

• 信息化思维：知道软件（作为工具）的功能，在本部门之内的应用；有些场景下还需要涉及硬件，那就要了解智能化设备/IoT设备等。

• OA2">数字化思维/数据思维：这是数字化项目的要求，要有数据思维，了解本领域的数据价值，数据分析目标、方向等，才能设计数字化的流程。

信息化技能方面，如果能和IT部门配合，那业务部门只需要有个基本了解就行。

业务技能方面，一个部门具备这样素质的人是凤毛麟角的。即使有这样的人，那么他通常也是业务最繁忙的一位，是部门创造效益的主力，领导是不愿意让他投入到信息化项目这个坑里的。

为什么领导不愿意把最强的投入到项目里，就得回到上一条，因为某个部门的信息化并不是这个部门自己真的有痛点/有需求，很多时候只是预算驱动，上级任务驱动。

做事的人不对，表现出来的就是事不对，出现诸如：

• 需求不明

• 痛点模糊

• 需求变更频繁

• 项目范围蔓延

等等问题。

南辕北辙的故事听起来很可笑，总觉得不太可能。现实里，这样的事情非常常见。目标不对，范围不清，执行团队越努力，偏差越远，项目的交付，就永远遥遥无期。

信息化项目就是个坑。那业务部门不会觉得核心问题在己，只会怪其他两方乃至多方（后面会分析），也就更加不愿意投入优秀的人和精力，导致恶性循环。

到这里，做个简单结论：信息化项目要成功，首先目标要SMART；其次，业务主导部门一定要出最强的人，一定要那种专业强，管理强的双面选手，能把模糊的目标变成清晰的规划，项目尚有一线生机。

4、信息化部门存在的问题

IT部门在信息化项目中的功能是协助业务部门完成流程规划，并和供应商一起完成项目的设计。

IT部门在这个项目中的作用就是桥梁作用。

桥梁作用可以很简单，不用特别懂业务，能理解业务部门的需求就好；不用特别懂信息化，能看得懂供应商的产品和方案就好。

桥梁作用做得好，要求也可以很高：要知其（业务和IT）然，更要知其所以然。

对业务部门的需求，要理解业务部门为什么设计这样的需求，要解决什么痛点，要达成什么目标，背后的管理效应是什么。然后才能针对性的提出IT的方案，如何和业务部门配合，做好新项目的信息规划，输出高质量的信息化项目需求。

对供应商，前期要评估其实力，评估其功能，技术，服务能力是否满足公司需求；中期，和供应商一起完成本项目的设计，评估供应商的设计符合目标和规划，不要让项目成为“买个六角螺丝来拧十字螺丝”的悲剧；后期，评估合适的成本预算和时间预期，确定项目三角形，为项目成功交付打下基础。

还要在业务部门、供应商和管理者之间沟通协调，拉平需求与预期。

实际场景里，IT部门很容易眼高手低，成了一个不稳定的过滤器：业务部门要A，到供应商那边是A’；供应商说自己提供的是A-，到业务部门那边能提供的就是A+了。

所以，有些时候，IT部门就做个传声筒吧：简单的把业务部门的需求给到供应商，再把供应商的需求给到业务部门，或者就拉个群，自己做个群主，让他们双方直接沟通。

那这个时候，对业务部门的代表的信息化技能要求就高了。

信息化项目是个团队合作工程，互相能协作比单独一方的技能更重要一些。

那说到合作，我自己是做信息化服务的，可能对IT部门的批评会更严厉一些，大家参考吧。

公司的信息化部门的成立，背景就是计算机技术发展很快，东西很多。计算机曾经作为一门新兴学科，一些非计算机专业的人士，对计算机/软件有畏惧感，对计算机的专业有疏离感，崇拜感。而信息化部门的成立是希望拉平这种信息差而存在的。过去10年，随着互联网的发展，数据+算法已经算是人人皆知的通识了，而信息化部门没有做到知其然而知其所以然，只能做传声筒，有被边缘化的趋势。

于是，实际工作中，我观察到一些信息化部门员工，能力只能做传声筒，却竭力去做过滤器，同时，从自身利益出发，会利用业务部门对IT部门的滤镜，创造新的信息差，以求保住自己的部门和岗位。不得不说，是一件挺遗憾的事。

从信息化项目交付成功的角度，让业务部门的项目代表懂IT，是减少团队合作障碍的是信息化项目成败的关键之一。

而从信息化部门角度，争取自己知其然而知其所以然，懂业务，也懂IT才是正确的方向。

实际上，坐在甲方IT的位置上，各路供应商会竭尽全力的把甲方IT教成自己产品的深度用户，甲方IT是有地位优势的。对这个岗位的机会和挑战是：全局观，学习能力强，合作态度强。不需要什么都懂，需要什么，供应商教，能学会就行。

5、业务部门和信息化部门的跨部门沟通障碍

不同部门，不同团体之间的沟通障碍是一个通用问题。专业背景不同，工作方式不同，沟通方式不同，目标不同，团队之间利益有冲突等等都会导致彼此无法信任。一些项目里，双方不仅仅不能互相合作，还会互相拆台，互相挖坑。

所以，本质上，信息化项目首先是个管理问题。

6、供应商存在的问题

供应商作为信息化项目交付中唯一的乙方，是项目最后的执行者，必然需要承接甲方最大的期望。

甲方提供了一份名义上清晰的需求，有时候也会提供依靠供应商拼凑出来的规划，需要供应商做出一道让领导满意的菜出来。

所以，供应商往往最委屈，觉得项目做不好都是甲方的锅。

但是我们抛开甲方的问题，甲方对供应商的一个要求是：专业。

那么，供应商够专业吗？

由于环境要求，整个行业对供应商的要求是：

• 抓准甲方需求

• 提供合理的设计方案

• 合格的执行团队

• 做好软件上线后的服务

前面分析了，因为甲方先天不足，抓准甲方需求就成了一门玄学。坊间有各种方法研究和讨论如何分析需求，抓需求，管理需求。但是都治标不治本。

因为帮助一个不知道自己需求是什么的人找准需求，就是个伪命题。何况这个人，他也没什么时间、精力，乃至于兴趣，陪着你帮他找需求 ---- 甲方从来不认可，或者有些人内心明白，也绝对不能承认，自己的需求是不明确的。

因为从某种意义上来说，甲方自己也没能力抓准需求。不是他故意刁难你，不给需求，而是他也不知道他自己的需求。

从这个意义上来说，还真的是只有需要从信息化项目中获利的乙方才有动力，有能力去厘清需求。

也就是说，信息化项目走到这一步，对供应商的要求是非常的专业的。

那么，我们国内有多少专业的，企业服务类的信息化项目供应商呢？有多少企业，又有多少专业人士呢？

就目前而言，可能有很多专业的人，但是，国内没有公认的专业的软件服务提供商。

当然，可以反驳说，国外公认的企业，SAP，IBM，Salefore，国内的口碑也一般。但是，就我这个从业人员来说，国内真的是没有。

国内整体的企业管理水平是不足以支撑起信息化的发展的，同样，软件服务企业的管理也是如此。后一节，我努力分析一下。

内部自研项目，研发团队就是供应商，乙方了，有不一样，但是问题类似，就不展开了。

7、信息化项目的成本问题

所有问题，本质上都是钱的问题。如果太有钱了，就是人的问题。

前面分析了，信息化项目，三大执行方，每一个环节都面临着输入质量低，过程能力弱，输出质量必然低的问题。

美国的数据，85%的信息化项目都是烂尾的。最新的，和我们国内的数据，我没有看到过权威的。咱们姑且就用85%作为输入吧。

也就是大部分企业，信息化项目的投入产出比是很差的。

所以，如果我是企业管理者，如果不是大环境天天在叫唤信息化/数字化是未来，我一定一分钱也不投给信息化项目。

但是，因为大趋势要投，企业就不得不投。那么，为了避免我投入的钱打水漂，为了减少决策失误（背锅），为了更好的保住投资收益，甲方的通常做法就是：各种需求往一个项目里面塞；无限压低成本；尽量短的时间看见成品。

国内的信息化项目，主流是招标是最低价中标（当然咯，其他行业也差不多，这个就是另一个话题了）；交付，3个月；再大的项目，能给供应商六个月上线一个最小产品，就是恩赐了（国际供应商相对谈判能力高一些）。

而对于供应商来说，互联网的发展带来了行业机遇，但是，也抬高了用工成本。

本来就需求不明确的，杂糅了更多无关的需求，需求管理的难度更高了；本来钱就不够，用工成本更高了，项目人力资源管理的难度更高了。

PMP总结的项目九大管理领域：范围管理、时间管理、成本管理、质量管理、风险管理、人力资源管理、沟通管理、采购管理及系统管理，其中核心的项目三角形：范围、时间和成本，每一个省心的。

项目能顺利交付才怪。

但是，对于供应商来说，企业活下去更重要。所以，能不能交付，有时候不是最重要的问题，拿到合同才是。

恶性竞争，比比皆是。一部分共识是，先低价，无条件答应各种需求，进入牌局再说。然后通过信息化项目的一次又一次迭代把前期的钱赚回来。

就我个人的观点来说，其实，这也未尝不是一种存在即合理的行业生态。

关键是，最终，能够达成客户的需求，给到信息化项目的收益。

钱花了，时间也拖了，最终交付的产品和原始需求已经十万八千里了，都没关系，有用就行。

信息化项目的收益问题我们跨一章节讲，先讲跟成本有关系的产品化问题。

8、信息化项目的产品化问题

信息化项目的成本居高，有个解决方式是有共识的，就是软件产品化。用标准化的软件来降低开发成本，提升企业的价格竞争力。

但是，前面也分析了，甲方企业：

需求蔓延，希望一次采购解决所有问题。

在OA里面实现HRIS的功能，CRM里面合同的跟踪管理自然是需要的。

而供应商的盈利点，也在这收不住的需求里。

双方都愿意在一个项目（多个迭代项目里）不停的扩展需求。

资产要WMS管理，生产资料也要WMS，实验室的耗材最好也WMS，那么这个WMS是放在资产管理系统EAM，企业总管ERP，实验室管理LMS，还是供应链管理SCM里？或者还是建一个独立的WMS系统管理这些全部？

从理论上讲，业界对此很容易达成专业上的共识，只是，实际项目中，各方为了自己的短期利益，成本所限等等原因，不会遵照共识。

以及，我们国家的确足够大，企业业态，经营的竞争优势啊等等又的确多样。

标准化很难，产品化也就遥遥无期。

• 产品化对团队人员专业性要求更高

• 对行业共性需求的总结能力/产品定义能力/要求更高

• 项目交付时对客户需求的管理能力要求更高

而从软件产品化的经济效应角度看：

• 从业人员工资高，产品化前期投资高，投资回报周期长，也是导致产品化难的原因之一

可以说，行业里面一些公司，死就死在产品化上。不产品化，每个项目都做得辛辛苦苦。产品化，直接把公司给干趴了。

我自己做公司时，想过国内市场这么大，做一个小众的标准化产品，应该是可以活下来，慢慢拓展自己的市场的。没想到高估了一个大市场下，提供标准化产品的供应商和需要一个标准化产品的客户互相找到对方的难度。

这是一个信息爆炸的年代却难以准确获取信息的问题了，这个话题下就不展开了。

同时，这也是商业环境下，在信息不充分的前提下，如何获取彼此信任的问题，后面会提到一些。

9、各方合作的互信问题

理想情况下，信息化项目是找一个合适的供应商，大家按照目标、规划，在规定的预算和规定的时间内完成项目范围，就能完美交付。

但是，实际情况是，目前国内没有一套评估合适的供应商的方式，很多公司选择供应商采用的事最低价中标的方式。

也就是价格是一切。

供应商为了赢，就靠关系，拿到最低价。不论成本。

这样拿到的项目，公司还想盈利，就只能控制人力成本，用最便宜的人。

而在拿项目时，为了证明自己行，一定会承诺自己用最好的，最专业的人。

而这种承诺，采购（业务部门+信息化部门）是很难分辨真伪的。那么，为了减少项目风险，控制不住人，抓住唯一可控的成本（付款）有成了大家的共识。

选择供应商时，选择价格最低的；项目交付验收时，严格管控，设置各种门槛不让项目验收；项目验收了，再设置各种门槛不付款或者延期付款。

甲方乙方都对对方的专业性存疑，又都没有合适的方式认证对方的专业性，只能是带着互相怀疑的猜忌来合作。为了规避风险，故意设置信息差，也是项目内部的常态。

而团队合作最重要的基础是互信。

10、管理问题

在第一部分的参与方图中，有个管理团队。理想情况下，项目各方各有所求，是管理团队来协调各方利益，合作共赢。

只是实际过程中，管理团队或者项目经理，在一家公司里跨部门去协调资源、任务，对项目经理的挑战是很大的。PMP/项目管理师认证，只能认证硬技能，跨部门协调沟通，更多的是软性技能。还得看项目的天时地利与人和。

行业发展了这么多年，对各种问题都有感知。比如，业界有一句话，信息化项目是一把手工程。也就是大家都知道各种困难，需要企业一把手出面才能协调和沟通这种种问题。

但是，实际的工作中，一把手，最重要的永远是企业的赚钱问题。他不可能一直关注这件事。项目以来周会月会上“一把手”的决策肯定是不够的。

何况，最重要的项目目标和需求问题，一把手自己都未必知道。

普通员工，总是把管理者想象为无所不能，先有企业战略，然后分解目标，各部门执行。而实际上大部分企业（尤其中小型企业）并没有确切的战略，可能只有老板模糊的想法。

中国过去几十年的发展，不是老板们战略规划出来的，是老板们，带着“草台班子”做出来的。

所以，我们不妨乐观的看待信息化项目交付的困难：有问题，才有机会。

有些企业为了信息化/数字化项目落地专门设立了数字化部门。但是面临的问题其实并没有改变。

11、信息化项目的收益问题

虽然有这么多问题，企业信息化依然得到和发展。国内的企业服务类软件公司还是有些做出来品牌的（以下都是我个人工作总结，基于2024年的分析，无广告，也不保权威）：

• OA的泛微、致远、蓝凌；

• ERP的用友、金蝶、织信Informat；

• CRM的悟空、纷享销客、销售易；

• SRM的织信、甄云、商越等。

最近几年，围绕企业内部沟通糅合办公应用的企微、钉钉、飞书也取得了很好的成绩。

所以，问题不是关键，给客户带来收益才是关键。

信息化交付项目，各方的专业度不够，配合也不顺畅完美，但是，只要团队最后能有收益，就可以顺利交付。

信息化项目的收益问题，主要就是前面说的，项目初始的目标不明，痛点太散，或者不明确。

但是，以客户看得见的收益为目标，缩小范围，找几个垂直的突破点，还是相对容易的。

后面会稍微提一下数字化项目，数字化项目的收益更难。

12、数字化项目的几句拓展

企业在信息化阶段，信息化软件的功能主要是工具性的。财务没有软件记账税务都不同意，采购竞标没有系统操作很不方便，查库存WMS比execl更方便，合同归档和可查系统比前台更可靠....

但是在数字化阶段，要让IT系统采集数据已经难了，如何让这些数据在企业经营管理中发挥出作用？

从流程管理到数据管理，说了很多年，可以是需求推动数据，还是数据驱动需求？

管理者知道应该用数据，可是不知道数据有什么用，也不知道自己需要什么数据，数字化还做不做？

中层管理者，虽然不知道数据有没有用，但是有些数据不想让领导、平级部门和下属看到，还不能直接发对数字化，他会怎么做？

对于底层员工，工具化软件工作更方便，提高效率固然很好，可是效率提高了，自己要被AI干掉了。我该做些什么？

和信息化项目类似的问题依然存在，最核心的收益问题，数字化项目更难衡量。

13、信息化项目的信息系统规划

信息化项目交付，信息化项目成功的关键，在于收益清晰明确。收益清晰明确，解决的源头依然在项目目标SMART，项目范围清晰。

实现信息化项目的范围界定清晰的一个方式是企业先有信息系统规划，然后用项目分布执行。不要在一个项目里杂糅各种需求。

业界是有信息系统规划共识的。

大家都需要基础的财务管理系统，生产型企业需要ERP，销售型企业进销存就足够了。在这个基础上，重视客户的拓展CRM，需要严格采购的上SRM，库存是痛点拓展WMS....什么时候扩展ERP，什么时候让OA越来越重，什么时候分子系统。子系统太多了主数据怎么办....都是企业根据自己家的企业基因来规划的。

因为有个性，让信息系统规划成了无解的话题。

但是，这依然是个解决方向。后续我会把笔记慢慢整理出来。

14、数字化项目的财务核算方式

到数字化项目，有个根本性的问题在财务核算方式。

目前数字化项目的成本依然是传统的信息化项目的核算方式，以办公软件/生产工具成本的方式计入业务部门。

但是，数字化的核心在数据管理，核心使用者是高层管理者。这样的核算方式，也是导致业务部门名义上支持，实质上消极抵抗（验收难）的一个原因。

篇幅有限，以后再展开吧。