软件行业大面积亏损的逆转还有多远-AI肯定不能替代包括SaaS的行业(日抛的无招已撤)但能成为了包括SaaS的行业的白衣骑士吗
先说一下结论,AI已经部分成为了包括SaaS在内的软件行业的白衣骑士,比如目前AI在2B最成熟的写代码方面,但在其他方面还需要观察而不是盲目乐观和误导客户。

近期,喊AI来了要颠覆这颠覆那甚至软件行业要消失了的已经不多了,因为理想很丰满现实很骨感。
AI中长期可能因为当下的认知局限,依然是被低估的,但AI短期(3-5年)肯定是被高估了的。
前头有篇文章《软件行业大面积亏损能逆转吗-“企业大部分业务和管理交给AI还需要多久?”以及“在没有达到以前咱们这些从业人员应该做什么?”》里有朋友留言“都被ai淘汰了”“不会很长,毕竟企业认为有了ai,就不要人了”“不可能有过程,软件行业已经落幕,以后就是AI时代了”……
我还是认为,AI从理论(1)到技术(2)到实践(3)到真正解决具体问题(4)到普及,有个相对长期的过程,也正是这个过程中的不确定性,让AI中长期可能被低估短期被高估。
这个过程除了需要《软件行业大面积亏损能逆转吗-“企业大部分业务和管理交给AI还需要多久?”以及“在没有达到以前咱们这些从业人员应该做什么?”》里描述的那些,更重要的就是把AI进一步细分。
AI是软件行业不那么苦逼甚至摆脱亏损的白衣骑士吗,需要进一步在当前阶段最起码可以细分为“技术侧”和“业务侧”。
截至目前AI已经基本证实了AI对软件行业的技术侧类似于白衣骑士般效率提高甚至颠覆(已经走到了第4步),但AI对于软件行业的业务侧还有待观察(可能还处在第1步)。

认识的人里,吴昊老师是相对最熟悉的一个在AI上真正有意愿(服务技术最前沿的企业客户)也有能力(懂业务也懂研发)也躬身入局一直在实践的人,他最近公众号很多思考非常值得行业内的厂商和客户作为参考。

尤其是在吴昊老师最近的《定制项目版本AI合并的进展研究:现状、案例及12个月后的未来》里,提出了一个让所有厂商值得思考的问题“有了真正能用的AI Coding之后,AI会不会让标准软件产品公司重新拥有个性化开发能力”
想起了5年前,和医药行业CRM做的最好的厂商做咨询的那段经历,当时他们在资本介入后,被动(资本需要)或者主动(定制化项目太累)面临的,就是从项目定制向SaaS转型的阵痛。
当时和他们沟通最多的,也作为整个转型期底层逻辑的一句话是“技术一定要平台化(厂商角度/当时叫低代码现在可以叫AI代码化),业务一定是定制化(客户角度/销售和交付必须结合客户当前需求),模式可以SaaS化(项目-产品-SaaS)。”
在吴昊老师最近的《定制项目版本AI合并的进展研究:现状、案例及12个月后的未来》里,有一个观点“AI辅助定制成果回收”可能混淆了“技术侧”和“业务侧”,具体内容是“AI能否帮助软件公司从客户定制项目中,找到有产品价值的局部能力,将其抽取、重构、验证,再由人判断是否进入标准代码库?”。
AI的自动写代码,属于技术范畴,也是技术手段之一或者是目前最高效的技术手段,但一定不是保留分叉版本,而是在产品设计之初,就是平台化的一个版本。
所谓的“版本分叉”,不应该是代码层面,而是在代码层面技术版本之上的业务范畴。
如果AI写代码想介入业务范畴,针对不同的客户做定制化产品代码,必然会陷入版本分叉,也大概率陷入泥潭。

就好比客户去面馆吃面。
技术平台化:这碗面在后厨一定是标准化(或者说平台化的),是个会做面的老师傅根据自己的能力和经验做出来的,而不是每个客人都要服务员去告诉这个老师傅怎么做面,服务员可以传递的是客户要“油泼面”还是“打卤面”还是“炸酱面”等等
业务定制化:但这碗面端上来给客人以后,餐桌上的酱油、醋、胡椒粉、辣椒、麻将、盐等调味品,客人根据自己的口味酌情。
但在2B软件行业,目前的现状是“技术侧”和“业务侧”混在一起,更多是后厨不仅仅要做面,还要为客户的咸淡吃不吃辣等各种细节“业务侧”需求去定制,客户不满意、实施交付累、研发乱。
这个模式下,无论是传统的写代码还是AI写代码,只是效率的提高,无法从底层逻辑真正发挥AI的价值和作用。
当然,如果有人不想吃面(假如面是CRM)想吃炒菜(假如炒菜馆是ERP有MESPLM财务等各个菜单),那就换一家餐馆,而不是让面馆的厨房现场给客人定制。
如果一桌客人有要吃面(CRM)有要吃炒菜(ERP)还有要吃火锅(OA)的,那如果这家饭店都提供,那就应该提前有专门的面点师傅、炒菜师傅、火锅师傅,而不是只有一个面点师傅非要给客户提供炒菜和火锅。
遗憾的是目前2B厂商里,好像有综合性的厂商(比如微软),但因为2B远比2C的吃饭复杂,始终因为专业度不够,远没有各个专业厂商可以给客户提供更好的产品和服务。
目前最常见的还是类似外卖模式,自己不提供产品,只是提供简单的配送,就是当前成千上万家的各个软件厂商的代理商。
记得很早的时候也是看了吴昊老师的《SaaS创业路线图(148)个性化需求:能否先定制再合并到标准版本中?》写过一篇《把版本的迭代权和维护交给客户而不是公司CTO-昊哥的“个性化需求能否先定制再合并到标准版本中”读后感想》,这么长时间过去了,AI并没有跳出这个框架。
所以,AI这个白衣骑士,还没有发现在“业务侧”有类似写代码的颠覆性解决问题的创新。
金蝶的“灵基”、用友的“YonCode”都还是技术侧,纷享销客的“ShareAI”从罗总视频号以及几场发布会的内容来看很吸引人,但从CRM这30年的发展以及基层反馈来看,基本还停留在“从理论(1)到技术(2)到实践(3)到真正解决具体问题(4)到普及”的2和3之间的阶段,类似于20年前一直到当前没有几个客户能真正发挥价值而只是对厂商的销售和售前有价值的“机会漏斗”理论,客户一听就兴奋,实际一用就抓瞎。
夜雨聆风