成都创新互联网站制作重庆分公司

中国SaaS为什么不赚钱?

引用恒业资本董事总经理江一的一段话,“我们注意到现在50%的SaaS产品推向市场后,证明是完全跑偏的,只有不到10%的SaaS产品能够盈亏平衡。仅有3%,甚至1%、2%的产品能够对应企业客户,产生效果化的重大影响”。

让客户满意是我们工作的目标,不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户,将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴,公司提供的服务项目有:域名申请、虚拟空间、营销软件、网站建设、图木舒克网站维护、网站推广。

很显然,中国SaaS产业表面风光无限,但内里却未必有那么健康,甚至很难盈利。

本人从 95 年就开始做MIS软件,在B端软件行业干了 20 多年,算是这个行业的骨灰级老炮儿。所以,我希望结合自己的从业经验,从多个角度来谈谈中国SaaS不赚钱的根本原因。

【利润=营收-成本】,这是一个非常简单的公式。但当前的多数文章都是去讲怎么增加营收,却很少有文章从成本角度来讲解这个问题。

其实,成本不但会影响利润,而且也会影响营收。如果营收快速增长了,但成本增长的更快,怎么可能盈利呢?

因此,成本的缰绳一定要把控在自己手里,才有爆发的可能。否则创业只是给他人打工而已。

首先C端和B端是完全不同的,C端打法不适合B端。

C端是统一标准化,一个微信或者淘宝可以让 10 多亿人使用,非常容易实现规模效应。可B端是非常非常多样化的,行业不同,企业规模不同,经营者理念不同,都会导致需求不同。多样化的需求会导致规模效应很难实现,这造就了一个碎片化的市场。

C端产品研究的是人,容易理解和接触,而B端软件研究的行业,没有深度行业经验是无法做出能用的产品的。B端软件是交叉学科领域,产品设计者不但要懂各种软件技术,还要非常懂行业的管理运营。

C端是靠广告盈利,只要烧钱烧出规模,用户群体大了,后期容易实现盈利。B端市场和使用人群是碎片化的,而且管理软件是严肃的事情,通过广告盈利的可能性几乎为0。B端软件根本上还是要靠提供工具来挣钱,企业使用工具提升了效率,自然就愿意付钱。

C端互联网的 20 年高速发展,是因为很多企业抓住成本的缰绳。谷歌发明的大数据技术,让他们彻底摆脱了对IBM和Oracle的依赖,通过技术革命使用廉价的成本取得了比之前强大几十万倍的计算能力。如果没有这些技术,当今我们看到的是更加硕大无比的IBM和Oracle,而不是这些互联网巨头。

所以,任何商业模式的发展和变革,都需要先解决某些技术问题。而这些互联网技术不能解决B端多样化的问题,所以B端问题要自己解决。

B端要盈利,就必须做到产品差异化,找到适合的客户群体。

现在SaaS产品的同质化非常严重,同质化的结果就是,竞争只能靠价格,大家都把精力投放到市场营销侧,很少关注真正的产品差异化问题。

01

SaaS厂商的主要客户是谁?

本人对服装、餐饮、便利店这些零售行业非常熟悉,对服装后端的供应链和生产流程也非常熟悉。本人之前做过餐饮软件,接触过不少餐饮客户,深深地感觉到客户期望东西和实际软件功能相差很大。

找到真正有需求的客户非常重要,单店需求非常简单,而且对软件的应用能力也很低,他就需要一辆自行车,你给他再好的汽车也是没有用。

本人第一次创业,就是做小服装店生意的,曾经做了 3000 多家单店和小型连锁店。价格卖不上去,而且后期维护事情很多,很多人因为电脑不熟练,连电脑自身问题也要依靠你来解决,感觉不是在做公司,是在当活雷锋。

之前也有一些餐饮SaaS创业者,跟我谈他们做小门店。小门店虽然看上去很多,但是一个广袤的沙漠之地,没有强大的资金实力,还是不要去碰为好。

而且,小门店的死亡率非常高,上海一些餐饮门店开业不到一个月就关门,小门店因为要求不高,所以可以选择的产品也是非常非常多。巨头做小门店是为了占领支付市场,可能也没有指望挣钱。

大型客户群体,没有强大的关系能力,是很难进去的,而且一开始就做大客户群体,很容易进入项目化,很难做到产品化。

做大客户做久了,想往下走是非常非常难的。一个人过惯了花钱随意的生活,突然让他学习勤俭治家几乎是不可能的。

举个后期维护的例子,大客户可能有自己的开发和技术团队,懂数据库,很多事情可以自己解决,但对中型客户群体是不可能的事情。

所以,做中型客户群体,在后期维护上面更加讲究效率,一定需要实现自动化和工具化,这些对软件公司的能力是一个大挑战。

第一次创业中,我们 2 个技术支持维护了 3000 多个客户群体,就是走的这种路线,否则,售后支持就会像洪水一样压死你。

很多人以为大客户难做,那其实是没有真正经历过。大企业贷款从来不是问题,中小企业贷款一直是世界难题。

本人认为,中型企业是一个非常好的标的,数量多,信息化需求比小企业强烈很多,油水虽然不像大企业那么多,但比小微企业还是多的。

而且,如果能够做好中型企业,就说明企业产品化能力非常强,成本把控能力非常强,进入大型企业是相对容易的,因为能够帮助大型企业节约成本。由奢入俭难,由俭入奢易,就是这个道理。

02

中型企业有哪些痛点?

中型企业有强烈的信息化需求,也会有一些个性化的要求,但它们自身却没有能力去像大企业一样自主开发。

一些中等规模的餐饮企业往往存在选型非常困难的问题,比如餐饮SaaS多是集中在销售收银和营销侧。

当然,也有一些SaaS企业开发出了后端的供应链部分,但却太难用,功能编排非常混乱,细节做的不好,流程可能是对的,但很难提升一线员工的工作效率。

其实中型企业已经进入了公司化的运作,管理的需求是多方面的。

比如,一个咨询者跟我谈到酒水管理的问题,还有提出门店固定资产管理问题和移动端管理问题。问题有很多,可当前的软件厂商提供的都是部分解决方案。这就导致企业客户需要去找多家供应商来解决这些问题。

这种思路是因为软件企业希望降低成本,没有能力做好全家桶解决方案,即使声称做好了,也不够细化,陷入”什么都有,但什么都不精”的问题。

但对接软件真不是对接水管,对接软件成本很高,而且很容易失败。对中型企业来讲,这是不可性的,成本和风险都不能承担。

03

SaaS的续费率为什么那么低?

企业信息化成功不是卖了软件就叫成功的,因为B端软件决策者和使用者是分离的,导致购买后往往真正应用效果不如人意。

销售阶段就像是追求美丽的姑娘,用尽花言巧语,勾勒美好未来蓝图,先把姑娘搞到手。

实施应用阶段就是结婚,开始处理双方家庭或者家族的各种琐事,任何细小的家庭矛盾都可能导致分手,真正美满幸福的白头偕老,把孩子抚养成才,才是真正的客户成功。

现在中国SaaS产品的续费率很低,就说明软件企业没有做到真正的客户成功,只是把软件卖出去,割了一次韭菜,后面导致韭菜越割越难割。

软件能够持续发展,持续满足客户的需求也是至关重要的。其实,SaaS续费率低不是一个新问题,只是旧问题的新表现。

以前没有SaaS的时候,很多企业也是隔几年就换软件的,很多情况就是因为发现软件不能满足现在的需求了。

现在软件企业都只关注流程正确,但很少关注用户体验。用户体验好,才能提升一线使用人员的效率,很多人抱怨系统还不如EXCEL表格方便,系统牺牲了一线人员的利益,怎么能得到他们的用户呢。

很多软件企业希望让老板去强压一线员工使用,只能导致表面的服从,不多发钱又降低效率,谁心里能愿意呢?

虽然这些人员没有决定权,但他们会影响最终的使用效果,就和现在姑娘选老公,虽然自身有决策权,但家庭不会影响吗?

所以,客户成功一定要保证一线人员的利益,提升他们的效率,让他们喜欢使用,而且能够积极参与进来。

04

如何做好用户体验?

讲一个我们服装客户的案例,中型服装连锁企业,门店 200 家,拥有自己的工厂和品牌,使用我们软件 12 年。

期间因为各种原因,公司希望找大的品牌公司合作,试用了行业前 3 名的软件,第一次试用持续了 1 年,后来的试用都只持续了不到 1 个月。

事后,本人总结了他们愿意留下的主要 3 个原因:

用户体验好,一线人员使用效率高,容易掌握,全部门店人员支持我们软件,而且很多门店主动联系本人,让本人去公司活动活动;

软件使用维护和使用成本低,而且大数据量情况下,性能非常好;

满足了企业的很多个性化需求,这些都是其它大软件不具备的功能。

所以,当你的软件已经和企业运营相互绑定在一起后,软件是几乎不可能被换掉的。所以,能够做到客户成功,SaaS企业的续费率就不是问题。

下面讲一个小案例来解释为什么用户体验对一线人员至关重要的,本人假设本文读者没有软件使用经验,所以找了一个非常明细的案例来说明,这样的细节太多太多,只适合跟专业的人讲解。

上面两种形式都是用下拉框来做选择,数据不多情况下,二者效率相差不大,但当数据多的时候,左边可以通过拼音缩写快速找到选择项目,而右边就需要找很长很长时间。

这对一线人员而言,右边的软件虽然实现了功能,但却要付出几十倍的使用时间成本。

而做好B端软件,就是处理好多如牛毛的这些小细节,真正的去提升企业效率,而不是拿标准流程框框限制企业的发展。

做好这些细节,我们也是被用户一步步逼的。有些客户是完美主义者,在被逼的同时,我们也感觉到了自身的持续成长。

因为众口难调,小客户应用能力差,就更需要软件企业做好细节,让这些能力差的用户体验到使用软件的好处。

归属自己的蓝海是怎么来的?简单的说,就是自己把标杆再提升一倍,自己努力过去,其他企业过不来,就有自己的蓝海了。

日本汽车怎么占领美国市场的?美国汽车小问题多,经常需要维修,日本汽车做的非常非常可靠,改变了美国人对汽车的观念,发现原来汽车可以做到这样可靠。

韩国现代汽车在 2000 年左右,在美国市场终于打开了局面,当时本人在美国,人家都是 5 年保修,它的广告直接就说 10 年保修,这就是自己把标杆抬高。

比如,哪家SaaS企业可以跟客户讲,我们满足你们的个性化需求,而且不满意不收钱,如果真正做到了,怎么可能不挣钱呢,但做不到就是自寻死路。

05

SaaS生态靠谱吗?

还有一种观点,就是不同的SaaS企业做好自己的标准化部分,众多SaaS企业联合形成生态,来解决客户的多样化需求问题,试图建立起行业标准接口来实现不同SaaS之间的整合,腾讯的SaaS生态计划就是基于这种思路。

但本人看来,这种设计表面上很美好,但真正落地起来太多问题。

容易标准化的部分是可以这样操作的,如短信服务,语音识别服务,但行业软件中太多的是行业商业逻辑,这些怎么标准化呢?

之前看到一篇文章,讲腾讯的烟囱问题,很多东西在多个团队重复建造,大家的东西不能实现共享,一个大公司内部尚且如此,怎么能希望很多不同公司间实现无缝的亲密合作呢?

因为真正落地,里面有太多太多细节问题,这里不再深入讨论了,因为太专业化了。

通过上面的分析,我们可以看到企业是有需求的,用户企业的多样化需求和软件企业的标准化形成了巨大的矛盾,而且现在企业支付能力也越来越弱,软件企业必须能够提供低成本的而且满足多样化需求的产品,最终才能赢得市场,实现规模化。

市场和技术是支撑企业发展的两个轮子,市场是前轮,技术是后轮。当技术门槛解决了,市场方向就变得重要。

比如C端市场,但当后轮没有力量,而市场又是一个漫长爬山的过程,那么技术自然就成了企业发展的瓶颈。

06

照抄美国经验不行

B端软件从 90 年算起,已经发展 30 年了,还是这样不温不火,是不是有种强大的力量在阻止这个行业发展呢?

现在很多SaaS企业去学习美国企业,想抄美国经验,在本人看来是行不通的。管理和文化是相关的,美国人民经历了很长的统一标准化时代,接受了标准流程,而中国民众更喜欢多样化。

美国可以有标准化的快餐文化,但谁能让中国人都去吃标准化的早餐呢?中国的饮食文化太丰富了,走美国的标准化路线是走不通的。

信息化也是同样道理,中国有很多的中小型制造企业,行业门类齐全而且复杂度高,而且这些企业是不可能选标准化,而放弃效率的,效率灵活多变是这些企业的命根子,所以,照搬美国模式是行不通的。

提升产品能力,大大降低各项成本,提供多样化产品化解决方案。虽然前面本人提出的思路实现起来确实难度极大,但应该说是一种颠覆技术创新的思路。

而且很多事实都证明了,最难走的路往往是一条活路,容易走的都是死路。

刘邦拿自己当诱饵,给韩信争取到了去击破六国的时间,最终实现了对项羽的合围。面对项羽当诱饵,稍有不慎就会丧命。可中国军队的快速穿插战术就是这种思路,这是可行的。不过,这需要建立在自身能力的基础上的,否则就是自寻死路。

中国软件开发90%以上的精力都是内耗掉的、浪费掉的。前面做的越多,后面包袱越大,阻力越大。最后,在一片漫骂声中,一个产品或者项目被停掉,然后开始了另外一个产品或者项目,然后还是出现了相同的问题。

SaaS公司成本包含多个部分,销售成本,研发成本,测试成本,运维成本和运营成本,所有的这些成本都有着一个控制点,就是软件的结构设计能力和团队成员单兵能力。

下面,本人就使用通俗的语言来讲讲为啥是这样,看看下面一个对比图,代表了 2 种代码风格。

优质代码是容易实现团队间密切合作的,而且很少产生误沟通,因为非常清晰有条理。左边和右边,显然左边团队协作开发成本是低的,右边不但难找到线头,可能会常常找错线头。

再谈谈测试成本,左边线路调整了,很容易推测出哪些部分受影响,而右边调整了,你可能都不知道影响了哪些地方,开发和测试成本都大大提升了,BUG率后期会出现爆发式增长,因为所有的人都可能修改了一个问题,创造出了 10 个问题。

那运维成本是怎么幅度提升呢?

之前面试过一个一线大厂的运维,他说他们运维有 80 多人,我很是奇怪,问他们日常都做啥。

他说大量时间都在传递客服提出的问题到开发那里,因为BUG不可控,而且问题不能追溯,导致客服和运维都无法解决问题,只能把问题传递到开发那边,而且因为客户群多,问题多,所以需要传递信息的客服和运维也多。

如果代码是右边那样,运营那边提出新的需求,开发那边一般都会一拖再拖,因为开发都在忙着在Bug堆里混战,而且不小心可能导致更多的问题,谁愿意当背锅侠呀。

本人做了 20 多年技术,而且管理了 10 多年技术团队,这种事情看到的太多太多,毫不夸张的讲,中国软件开发90%以上的精力都是内耗掉的,浪费掉的,前面做的越多,后面包袱越大,阻力越大。

最后,在一片漫骂声当中,一个产品或者项目被停掉,然后开始了另外一个产品或者项目,然后还是走入了相同的问题。

摆脱不了上面问题的原因就是软件结构设计能力不足,不能让结构清晰化,灵活化和柔性化。

做好结构设计,降低开发,测试,运维和运营成本,这会反过来降低销售成本和提升营收。因为人的本性是无法拒绝低价且优质的东西的。

100 万买到一个 200 万的迈巴赫,开始可能大家不敢买,怕是假货,当证明是货真价实的时候,大家会去抢着买,自然会大大降低营销成本,同时大大提升营收。

当企业自身功力深厚后,只有加上一定的营销外力,自身的内在动力就会爆发出来。

淘宝服装电商的成功就是基于这个道理,因为做了很长时间服装企业的生意,非常懂得其中的原因。

之前服装的加价是非常厉害的,出厂到终端会有 10 倍的差价,电商通过去中间化,即使把价格砍半,商家还是很大利润空间,所有才触发大爆发,这是一次行业成本重新排列的结果,当然现在电商成本也提升了很多,但不能否认之前的爆发原因。

O2O电商为啥喊着去中间化,但基本上都全军覆没,因为成本利润空间太小,哪个餐饮企业敢降价50%,还觉得自己大挣钱呢?

看行业,真不能忽略成本问题,成本,成本,还是成本,只有大大降低成本才能触发爆发,否则都是伪概念。现在的SaaS软件企业,没有解决这个成本问题,自然也不会实现想象中的大爆发。

07

太多软件只关注当前需求

不考虑未来变化

下面讲一个单兵素质问题的案例,下面是我的一个面试题,考察的是开发者的思维能力而不是简单的打印出答案,所有的人都能做到打印出需要的答案,但只有不到十分之一的面试者的思路是正确的。

面试题只是一个简单的分组问题,在软件领域普遍应用,就和四则运算一样基础,但就这样一个特别基础的问题,卡掉了非常多的面试者。

多数人给出的答案类似左边的,很少数人给出了类似右边的答案。你可能不懂编程,但看长度,你就发现左边要长很多,而且这只是部分,不是全部。

左边的代码可以说没有任何扩展性,需求稍微一变化,这些代码就是废品,而右边不但简单易懂,而且扩展性非常好,需求变化了,只有稍微调整一下即可。

为啥要讲解这个案例呢?这就是不同软件应对多样化客户需求的不同结果,结构化好的软件,非常灵活和柔性,需求变化了,软件可以非常低成本的随之变化,持续满足客户的需求。

现在太多的软件只关注当前需求,而不考虑未来变化,导致今天的努力堵了明天的路,怎么可能会持续的低成本的快速发展。

当大量的开发人员还处于只满足当前需求的水平,怎么能做到柔性化和灵活化,为未来考虑呢?

阿里提出中台战略,其实也基于相同的”软件模块重用”思想,重用的越多,则前面讲的多个成本就越低。

只不过真正实现重用,光有概念是不行的,做好可重用的软件是需要工匠精神和持续的努力的,思路需要能力来支撑。

前些时间很多国内武术大师被KO,格斗的基础能力就是力量、速度和反应能力,招式是建立在这些基础上面的。

软件的基础能力就是灵活,稳定,成本,这些能力都不是短时间能够掌握的,或者学习一些概念就能够掌握的。

国内软件行业在可重用方面的实践还是很少的,而且B端领域的重用其实是比计算机标准领域复杂很多,操作系统就是一种重用概念,还有很多软件框架,但在B端软件的重用还是很少的。PaaS是一种国外的尝试,但本人看来并不适合中国国情。

一个校友就职于国内一流的零售连锁企业,使用了Oracle的Netsuite,花费 500 多万,聘请了国内顶级实施团队,花费大半年时间,结果失败了,钱都打水漂了。

行业框架其实是一种跨学科的实践,光有软件知识是不够的,Netsuite缺乏对中国行业逻辑支撑,很难适应中国的企业。

做可持续软件,就是需要把变化和不变分开,让变化的业务逻辑体现到参数化当中,通过参数化的框架来应对多变的需求。

例如,中学大家开始学习代数,发现小学的很多难题都可以通过代数轻松解决,代数就是参数化,当然B端软件框架的参数化要复杂太多太多。

////

总结

只有做到客户成功,SaaS软件企业才能走出困境,要把客户的个性化需求当作是福气,因为解决越多客户实在问题,提升客户的效率,你和客户的绑定才会越紧密。

续费率低只是表象,深层次是因为需求多样化和供给标准化的矛盾没有解决,用户没有深刻体会到软件带来的价值。

B端软件不像很多人想象那样简单,客户要的不只是一个能飞的飞机,客户要的是一个快速、舒适、运营成本低而且非常安全的飞机,这就是为什么造大飞机非常非常难,而造能飞的飞机并不难。

把标准去提升一倍,甚至几倍,提升自身的软件产品能力,跨域这个标杆。如此,你才能到达一个属于自己的蓝海。

本文作者:黄允聪, 20 多年的信息化老兵,对中国 2025 信息化具有很深的思考,一直在研究如何通过提升软件开发效率,降低成本,提升中国的信息化水平。


本文标题:中国SaaS为什么不赚钱?
分享URL:http://cxhlcq.com/article/cgepsh.html

其他资讯

在线咨询

微信咨询

电话咨询

028-86922220(工作日)

18980820575(7×24)

提交需求

返回顶部