甲方 IT 日益壮大，企业服务软件行业面临的困境与出路

近年来，随着数字化转型的深入发展，软件行业的企业服务端正是“忙”时候，毕竟也算是多个周期的叠加：国产化周期、数字化周期、自发重构周期、基础设施更新周期等，多种因素都在推动软件的大规翻新，这里还没有加上若隐若现的“人工智能”周期。

但是，“忙”归忙，收入好像不太如意，甚至到了有些“危险”的境地，近年来确实不乏乙方公司单子越大越亏的情况，所以也有业界专家为此鸣不平。到底该如何看待这个现象？做企业服务的软件公司未来会是何种走向？这些问题不容易回答，毕竟有些事情行业里的人就算心知肚明也无可奈何，而未来从来都是充满不确定性的。笔者就根据自己的感受聊聊这个话题吧。

笔者自己现在算是个独立的小微乙方，提供企业架构、业务架构咨询服务，由于这两项专业服务现在与数字化转型关系密切，所以也会提供数字化转型方面的服务，算是服务能力的延伸吧。笔者自立门户也就一年半左右，之前曾在国有大行工作了 20 年，业务线 12 年、IT 线 8 年，在内部甲方提过需求、在内部乙方参加过企业级工程实施，做过核心业务架构师，还随着企业组织结构调整，得以在银行系最大的金融科技子公司管了 2 年多的风险合规工作。离开银行后在 IT 头部外资咨询公司、头部互联网企业云服务团队工作过，在互联网中小型企业也做过一段时间高管。就甲乙方的工作来讲，笔者采购过别人，也被别人采购过，两方面都有些体会，只不过采购经验谈不上深。

关于企服端软件行业经营的不如意，笔者自己也跟一些大乙方打过交道，所以也略有耳闻，在这面，笔者有如下感想：

从现象看， 单就价格问题来讲，长期“低价”并非好事情。这个并非针对软件行业而言，放在整个经济领域都是如此，站在经济学视角看，“价格”也相当于经济的“体温计”，人要想活得舒服，就得维持在 36.6 度上下，不能差太远。

企业就相当于经济中“人”，“价格”就是企业的体感温度，当然，穿透了看，“利润”更代表真实温度，但是，“价格”对“利润”的影响很直接，而且“价格”更“可见”，是交易中谈判的“对象”，成交也是达成一致的“价格”，所以，通常用“价格”来解释一切。“价格”太低，“人”就会一直“打哆嗦”来增加“体温”，但是“打哆嗦”消耗能量很快，打着打着，企业可能就“打”没了。

其实这么多年来的互联网发展，虽然让老百姓在消费方面赢得了很多实惠，但是长期的“低价”也会让提供消费服务的企业发展遇到困难，而且这个困难会沿着产业链传递，从 ToC 的企业一点儿一点儿传递给 ToB 的企业，这时候只有垄断资源或具有一定垄断性的行业会好过些。其实，经济学上认为温和的物价上涨对经济发展最有利，就像人在夏天，尤其是夏初，会很活跃一样，温度很舒服，行动很方便。“价格”太高就麻烦了，大热天，40 多度，人除了吹空调可能啥也不想干，这个时候经济就容易出问题了，不活跃了。

经济学上的基本道理，放在企业身上也一样，毕竟理论就是来源于对企业经济活动的思考。“价格”太低，企业可能就“打哆嗦”把自己“打”没了；“价格”太高，钱都烫手了，企业想拿也拿不到了，没人出来活动了。

过度的竞争，拉低价格，最终会砸了行业的饭碗，而甲方也不会真从太低的价格中受益，笔者自己也见过，乙方价格太低，甲方心里也清楚，一开始双方还觉得可以通过甲方做基石客户，打造乙方产品，从其他客户身上盈利，结果这一单亏得远超预期，乙方“躺平”了，甲方也没办法，也知道乙方亏大了，没法提更高要求，最终当然是项目没法达到最初预期效果。这种还算是当初有“饼”在的，也有些没“饼”都硬吃的，最终也就是因为双方的“面子”问题，不至于公开地“不欢而散”吧。单就现象讲，这对行业是没有好处的。

从成因的角度看，这个问题不好解决。单看现象没有什么意义，毕竟解决不了的话，谈都是浪费时间，只能自求多福。造成这个局面的原因很多，绝对不是单一因素造成的，毕竟行业里有些乙方还处在有一定“话语权”的位置上，所以，企服端软件行业的“困难”并非一概而论的，与细分领域的竞争情况有一定关系。笔者只说几个自己观察到的因素：

这本是市场竞争的必然结果和好处，尤其是对甲方而言，但是对于擅长搞采购的大甲方而言，这已经不仅仅是好处了，都能到“杀器”的级别了，对于常年开展 IT 采购业务、采购类型众多的大甲方来讲，全市场的价格都是完全清楚地，乙方的实际能力水平、产品性能几乎也是“一清二楚”，对于这种大甲方（甚至再小一些的）而言，乙方几乎没有议价能力，如果想要维持价格，就得冒着落标的风险“硬抗”，但是能“扛”得动的很少。

比如，甲方是特大型采购，而且需要维持多个乙方中标来避免实施风险，这种情况下，有时候行业内排名靠前的乙方不入围可能甲方自己也不好解释，所以，大乙方有点儿“扛”价余地。但如果切换到单一中标的环境下，高价格中标反倒需要很多解释工作，而甲方非常清楚历史价格、当前价格，乙方很少有什么“扛”价余地，甲方也不会愿意给自己找这种“麻烦”。

这种局面的形成时间已经不短了，即便现在取消最低价中标的管理要求，也很难会让乙方得以“溢价”，因为“溢价”的来源并不是投标管理，是“品牌”价格、“产品”价格，不少国内乙方在与外资竞争的十几二十年里，只能靠压低价格与国外品牌、产品竞争，就算现在竞争产品退出市场，也并非一下就能把“溢价”还给国内乙方，因为在甲方记忆里，乙方就是这个价格，改变别人的印象是很困难，甚至是徒劳无功的事情。

如果一件事情只有某个角色能做，这个角色就有“叫价”的资本。十几二十年前的 IT 行业，科技人员仍然是“稀缺”资源，就算是互联网企业，在发展初期，不也传出过很多半路出家的程序员搭上了互联网快车致富的佳话。那个时候，说企业有千人规模的 IT 团队都是难以想象的，毕竟笔者所在的银行业，就算是 IT 钞能力不菲的国有大行，在十几年前，也是刚有千人规模的 IT 团队，但这里边大概有一半左右还不是做开发的，甲方“盛产”的 IT 人员是需求分析和项目经理。

如今，头部的城商行，也就是相当于国有大行省分行一级的机构（这是以经营区域论，就人员和规模来讲比国有大行的省分行还是要大的），都有上千人的 IT 团队了，而国有大行均在上万人了，单论人数，可能比服务他们的乙方企业还多。 一些央企在数字化转型过程中成立了数字科技公司，人员规模也在几百到近千不等。近年来汽车企业随着新能源车的发展，IT 团队也迅速扩张。

其实这是软件行业自己“惹”的祸，我们自己宣传“软件定义一切”、“数字企业就是软件企业”、“一切业务数字化、一切数字业务化”、“数字化转型是生死存亡”等理念，甲方接受了，但是接受之后的反应并非更依赖乙方，而是更试图加强自身能力。 毕竟，如果觉得一件事关系到未来竞争，甚至生死存亡，那一定会抓在自己手里，哪怕是一部分，不然不会安心。

IT 从业人员持续增多，甲方自身力量持续膨胀，对软件重视程度不断提高，这是不争且不可逆的事实，每年可能还有上百万新增就业大军试图进入 IT 领域。就像笔者在企业架构课上常讲的，如果甲方聚集了这么多 IT 力量，不让他自己做点儿什么，还成天买产品、买套件，那是想让他再把 IT 团队解散了吗？是认为甲方的 IT 团队一点儿学习能力都没有，手头儿的系统永远都搞不会吗？

这一点也是顺着上边的因素延展下来的，由于系统增多、IT 人员增多，加上业务的复杂度也上升，现在无论乙方企业有多大能力，甲方企业都不得不思考自己内部的 IT 治理问题。企业架构能力以前对甲方企业来讲若有若无，也是可有可无，系统没那么多，人也没那么多，都交给外边还“清闲”些。

但是现在大不一样了，系统的“家底儿”越攒越厚，还越攒越乱，乙方也没能力帮甲方打理这么大个“大 house”，甲方想不自己打理也不行，总是那种规划交给外边，对错都搞不清楚的干法早就玩不转了。甲方企业现在是被动在提升企业架构能力，或者叫基于整体架构的 IT 治理能力，连国资委都给央企提这个要求，对笔者而言这是好事情，毕竟，这个“冷炕”想“热”起来不容易。

现在不是问企业架构好不好用、有没有价值的时候了，而是 企业无论采取什么办法，都给自己家里画出个“地图”来，不然 IT 治理就会成为企业痛点，不但解决不好业务问题，还会给企业增添技术问题。更“要命”的是，这种整体架构能力本身就是软件研发领域中比较高级的“整体设计能力”，虽然不是说有就能有的，但却是有了就一定要说了“算”的，也就是说，如果甲方的“整体设计能力”上升了，乙方的“话语权”只能进一步下降。

以当前的情况来看，这种现象不仅已经在一部分行业出现，而且会随着大规模转型工作的推进，在更多行业中扩散开，这只是时间问题，对甲方而言，这并非不可企及的“能力”问题，只要敢坚定地做就一定会提升，肯定比 “造火箭”容易多了。

软件设计领域一直有“积木化”的梦想，其实隐含在“积木化”梦想之后的是软件的快速工业化生产。关于软件行业的生产，笔者一直有个开玩笑的形容方式，“大规模小团队手工作坊”，自己认为还挺形象的，再大的企业、再大的 IT 团队，开发起来也是切小块，由小团队以手工撸代码的方式为主来做，一直没能“工业化”，“敏捷”以加班为主，也并非以方法为主，甲乙双方都如此，截止目前，应该没有真“敏捷”企业出现。

尽管上个世纪还处在缺人年代的老师傅就说过 软件行业不是单纯靠“堆人”就能提升效能的行业（《人月神话》），但是目前我们在总体生产力提升上，除了加人之外并没有更好的方法可用。不过理论研究倒是有在一直发展，并且还趋同了，就像在企业架构领域，主流方法论都将自己的研究指向了 “业务能力”定义，面向“业务能力”的软件设计，分散、独立地定义“业务能力”，那也就意味着软件应该继续走向“零件化”、“积木化”，方向是没错的，方法也开始支持（其实流程和能力分离的设计思想也有二三十年了，笔者写《聚合架构》这本书时略微做过考古），就剩下更充分的实践了。

笔者作为业务架构领域的从业者，自己也在接触到越来越多想要重新做面向能力、面向抽象的架构设计，这种诉求也包括来自一些互联网领域的企业。毕竟，只有设计是“零件化”、“积木化”的，才有组装式生产的可能，才有向工业化效率靠近的可能。 不少的企业都在尝试将业务设计“能力”化，曾经红了半边天的半套企业架构方法论——“中台”方法论也是这个范畴，完整的企业架构方法论基本上也都指向这个方向。

随着企业“被动”提升企业架构能力（不是只认识到，而是能执行），企业自己的“业务能力”识别、定义、设计水平也会逐渐增强，这会在软件要求方面进一步与乙方“理想”的输出模式产生冲突，目前一些软件项目要求的服务化设计并不仅仅是为了集成方便，也是在寻找更为灵活的面向能力的架构。这一模式目前变化还是较为缓慢的（毕竟甲方能力的提升总体而言还是在少数企业），但是总体是方向还是明确的，基于能力组装企业应用是大家都想做的，那组装一般应是基于“零件”而非“套件”。

因为缓慢，所以乙方可能更“痛苦”，这个阶段，新的模式没完全出来，旧的模式还不如意，定制越来越强（目前 IT 能力不那么强的甲方也有定制倾向），项目成本越来越难控制，也许还不如来个“痛快”的。

这几个成因也许算不上什么根因，但在笔者看来，基本上都属于不可逆转的因素。

笔者要说的这些改变也许不能成为上述问题的“解决之道”，但可能会成为“适应之道”，毕竟，可能 5-8 年之后，软件行业可能还有更大的“变数”会到来，不先“适应”一把，后边的“变数”也许会更不好接受。

笔者认为乙方企业要做的最大适应应该还是 软件产品形态的变化，变“套件”输出为以“零件”输出为主的多样化输出，如果有机会做，那就对既有的套件做彻底的“零件化”，完成流程与能力分离的设计。笔者“产品化”的经验尚浅，从自己的角度看，“套件”中最不容易适配的就是 界面、流程、角色、权限这些与“套件”实际包含的“真知识”（规则）关系不大的部分，可能读者会觉得“流程”不是“真知识”吗？“流程”是，但准确地讲，是“不稳定真知识”、“不通用真知识”，不同企业的“流程”会因组织规模、结构的差异而有很大不同，“流程”非常重要，却不能轻易搬来搬去，与之相对的是，“规则”适用性会更广，并且也有机会做更综合性的抽象，变成“产品化”能力。

有些乙方企业也询问过做产品抽象的方式，笔者自己结合业务架构的经验思考，“对象 - 规则 - 流程 - 界面”，这四层抽象顺序应该是做“产品化”抽象的可借鉴顺序。

“对象”是逻辑级数据实体，也就是业务处理对象，先抽象业务处理对象，这层设计很多企业其实考虑的是库表抽象，不是实体抽象，这里需要改变；之后是处理“对象”的“规则”，规则通常是可以“参数化”、“整合”的；之后是“流程”，但一般是结合流程引擎做些变通，实际上很多时候在集成时都要考虑改流程，所以，“流程”很不稳定，抽象了也基本上只能给连“流程”都“懒”（也可能是没有业务人员支持）得想的甲方用；最后是“界面”，最不成功的抽象往往就是界面，谁能做出人见人爱的呢？甲方企业自己还有统一门户呢。

从这个角度讲，乙方如果能够顺应目前甲方出现的“缓慢”变化趋势进行产品调整，将专业能力聚焦在更小的“零件”上，也许更有机会提升“专业”性， 毕竟所谓的乙方专业性是要比甲方专业性付出更大努力的，毕竟甲方再懒得总结知识，也是天天要做业务，业务也还是时常有变化的，严格说来，乙方的能力如果能聚焦在“规则”上，做好“规则”级“零件”已经很不容易了，毕竟不是业务源头，业务创新又不会发生在乙方。

如果“零件”能做好，那么对大甲方的输出应该以零件为主，这里笔者特别想说的就是 大甲方应该自己做“流程”，对于大甲方而言，迟早架构能力会掌握在自己手里，自己的开发资源至少要覆盖对“流程”的开发，毕竟开发资源也不少，甲方做“流程”不仅是因为它具有强烈的企业本地化特征，而且从企业架构视角看，“流程”是横向的应用视角，也就是对“能力”的调用、串接视角，是很强的业务视角，也是业务创新的表现，本身流程的变化、对调用的重新编排就是业务创新的方式，所以这部分该由甲方企业自己做，乙方提供的是更强的“规则”式“零件”，也许采购金额下降了，但是乙方成本也降了，并且在该专业的地方可能也更专业了。 不过，很多“规则”甲方也许自己也会做，这个也没办法。对于连“流程”的开发资源都不足的甲方，这就是卖“套件”的对象了。

这会不会导致乙方企业规模缩减，未必，因为“零件”不见得就必须很便宜，毕竟是“专业级产品”（如果乙方打造得够专业的话），但这也会“暴露”出软件原本哪里就不那么“昂贵”。不过，如果发展的趋势最终是乙方规模缩减了，那该做的如果都做了，也没有什么可以遗憾的，毕竟，软件行业发展的目标已经灌输给我们的客户了，“数字企业都是软件企业”。

企业服务端软件生产能力的大幅度提升是否一定伴随着特定软件企业的大规模发展， 这个不好说，也许这正是软件行业与制造行业不同的地方，大规模软件生产不特殊依赖于特定的“生产设备”供应商，因为就行业来看，软件生产所需的基础实施在各行业里本就已经是“分布式”的了，只差能力的“分布式”了，而这个“分布式”也已经是“进行时”的。

今年三月首个 AI 工程师 Devin 诞生了，之后就是若干个开源版、加强版，还没等 Devin 自己公开源码，别的版本都已经开源了。记得去年还是不少人觉得 AI 编程不太靠谱，结果在一片“怀疑”中，今年 AI 工程师又进步了。这轮大语言模型带来的发展对个体能力的增强是非常令人关注的，也是笔者相信的发展方向。

别的不讲，再给它五年，有几个人敢赌定 AI 在编程方面还是“垃圾”一个？五年的话，是不是再说不过去也能让个体编程效率提升个 50% 吧（笔者还没敢按照数倍提升去看），那么以大甲方当前的 IT 人员数量看，甲方自己搞定全部业务系统的主要实施、重构到底是能还是不能呢？至少没有生产力方面的问题，而设计能力、知识萃取能力、工程管理能力，只要企业真重视，肯下功夫，也是可以大幅度提升的，那时的乙方又要怎么办呢？

AI 的未来我们就不去“焦虑”那么多了，仅这一个趋势就足够乙方企业思考了。回到当前，现在的困难如果需要帮助，尤其是政府帮助，那也许可以考虑一些补贴、商业政策的调整之类的。但是，在产品、软件模式、开发理论、核心技术等方面的核心竞争力，还是得靠企业自己去解决，外人只能帮帮环境，“适应”还得靠自己，“保护”无法提升能力。《侏罗纪公园》中有个名句：“生命会自己寻找出路”，笔者还会狗尾续貂一句，“只要生命力够强”。

付晓岩，《企业级业务架构设计：方法论与实践》、《银行数字化转型》和《聚合架构：面向数字生态的构件化企业架构》三书作者。北京天润聚粮咨询服务有限公司执行董事总经理，数孪模型科技公司高级副总裁；工业和信息化重点领域数字化转型与人工智能产业人才基地专家委员会副主任；中国计算机学会软件工程专委会委员、数字金融分会首批执行委员；信通院企业架构推进中心、组装式推进中心技术专家；中华全国数字化人才培育联盟专家委员会特聘专家；工信部中小企业发展促进中心产教融合产业实践教授；国家工程实验室金融大数据应用与安全研究中心研究员；CIC 金融科技与数字经济发展专家委员会成员；国家互联网数据中心产业技术创新战略联盟专家委员会副主任专家委员。