作者|李东林出处|SaaS产品说(ID:metaas)
上一篇《原理系列——2020年最后一章,SaaS能走多远》写的,引起了不小的反响,也有很多朋友进一步提问,所以在这篇文章中,对于一些问题和方向,根据我自己的经验,我会给出一些意见。
本文主要内容:
与 SaaS 轨道可持续性相关的因素
对一般SaaS如OA、HR、CRM等的简要看法
对垂直行业SaaS赛道的一点见解
人工智能在SaaS中应用的一点感悟
关于低代码的一点点
01:
与 SaaS 可持续性相关的因素
上一篇文章提到,从SaaS产品的角度来看,笔者认为最重要的是实现产品的可持续发展,避免陷入泥潭和缓慢死亡。产品的可持续发展指标与业务架构、功能架构、数据库架构、逻辑耦合、服务层抽象程度、产品易用性指标等密切相关。
所以对于B端SaaS初创公司来说,门槛其实比C端软件早期创业公司要高很多,需要的人才组合非常复杂。工业互联网的方向,必然需要一个产业+互联网的联合团队。
另外,在PMF阶段,还需要一定的客户资源。整体来看,SaaS初创企业前期需要一定的资源驱动,但最终都是产品驱动,单纯靠资源驱动是很难走远的。不是资源枯竭的问题,大量客户上线后,无法持续开发的产品就会陷入泥潭,未来很难开发。
虽然B端产品对客户的黏性很大,但如果产品做得不好,5-8年后客户换系统的可能性还是很大的。 5-8年后,一旦产品陷入泥潭,面对新竞争对手的冲击,很多时候已经没有多少反击的能力了。
作为一家SaaS公司免费软件的可持续性,除了上篇提到的自有SaaS产品的可持续发展外,最终能取得的成就,就是自己选择的轨道的可持续发展。在这篇文章中,我们重点关注这一点。
在笔者看来,SaaS所选赛道方向的可持续发展主要由以下几个因素决定:
1:SaaS 软件本身的规模
赛道本身的规模比较容易计算,即赛道的目标客户数量和每个SaaS客户可以产生的年收入。每个客户每年产生的收入与产品能为客户提供的价值密切相关。随着产品的迭代,对客户的价值会增加,因此每年可以产生的SaaS服务收入也可以不断增加。
大部分SaaS是降本增效的工具,所以产品的价值也与受众和痛点息息相关。大的。如果 SaaS 服务本身的工作不那么忙,工作不那么核心,那么帮助这些人提供工具的自然价值和痛点就不那么明显了。
2:数据的价值
SaaS前期是一个简单的软件工具,但后期能否发挥更大的作用,进一步提高效率,降低客户业务的成本,主要看积累数据的价值。
降水数据统计后将为内部业务管理提供一定的指导。基本上,所有的业务系统都或多或少可以扮演这个角色。我想关注降水数据的外部作用。 ,这是更有价值的部分。
一般数据的外部价值如下:
当产品占市场15%以上时,往往可以确定一些行业的大数据,对行业起到一定的作用。例如,在薪酬体系中,如果你得到每个公司、每个职位的数据,就可以制作行业薪酬数据,从而为公司招聘提供参考价值。
如果目标行业有上下游,那么目标客户群体这一层的数据极不对称,对上下游极为重要,那么这些数据就会产生巨大的价值。
如笔者所从事的蔡小蜜项目,主要为生鲜一、二级批发市场的企业提供信息化SaaS系统。由于生鲜食品供需关系波动较大,价格波动较大,同一市场同一企业每天同一蔬菜的价格波动可能在30%以上;
由于生鲜产品保质期短,对供应链要求高,每个市场的每一种蔬菜、水果和水产品的价格和库存数据对上游货主和下游采购商都有很大的价值。例如,如果货主知道每个市场每种蔬菜和水果的实时库存和价格数据,并指导他们运送到哪个市场,将对产品的销售价格和解决问题起到决定性作用。销售缓慢的问题。
为了让数据对上游和下游有价值,必须满足几个条件:
只有当SaaS客户的市场份额达到一定比例时,大数据才能更准确。
目标客户层比较集中(数据比较容易上线),上下游极度分散,数据不对称严重,这些数据对产业供应链影响很大。
工业互联网的核心其实是解决信息流通的效率,解决信息不对称的问题;所以我们必须选择信息不对称严重的,而这些信息对于提高产业供应链的效率会起到很大的作用。
3:连接值
其实所有软件系统的功能主要包括两个方面,一是处理,二是连接;处理就是利用计算机相对于人脑的强大计算能力来提高效率。但软件通常承担另一部分,即连接性。
一般来说,连接的价值大于处理的价值,类似于互联网与单片机的区别。连接一般包括内部连接和外部连接。内部联系主要是组织内各个角色之间的内部协调和信息传递。
外部连接是公司内部角色与外部对象之间的直接联系和协作。作为一种连接,外连接的价值一般大于内连接,因为内外信息不对称更严重,沟通成本也会更高。
基于这个概念,角色协调较多的场景其实需要软件来管理。 Slack、钉钉、企业微信、飞书,本质上都定位于企业内部协作。近期,企业微信形成了突破,也通过与微信外部客户资源建立联系,彻底打开局面,让工具有更高的性能水平。价值。
传统的TO B ERP、HR、Finance相关软件普遍侧重于内部角色和业务协同,但在工业互联网爆发的今天,笔者发现很多行业尤其是批发行业存在明显的上下游场景上下游的协同和聚集效应非常强。
用软件切入中间层,然后用中间层共享数据,连接上下游,从而推动最终的双边交易市场,这是未来一个非常大的趋势。
笔者预测,在两年左右的时间里,随着行业SaaS在其市场中的市场份额增加并形成一定的密度,越来越多的工业互联网公司将从SaaS切入上下游,这是一个巨大的机会,也是工业互联网未来十年最大的机遇。
4:赛道的垄断系数
如果一个赛道很大,但最后是分布式赛道,每个玩家吃一点,最终成为大公司的可能性很小。
归根结底,总的来说,大部分B端SaaS公司都是分布式的市场属性。没看到一般的HR、CRM等行业,你唱我唱,市场相当分散。为什么C端消费互联网市场更容易形成垄断,而B端SaaS市场大部分是分布式市场?赛道的自然市场垄断系数主要取决于以下几个方面:
产品销售周期和实施培训周期
一般来说,C端产品可以通过口碑裂变来获取用户。 B端产品根据客户的大小,订单周期往往是几个月;几个月的实施培训周期。
所以C端产品一旦定位准确,完成PMF,达到一定的传输系数,就能快速占领市场,在短时间内结束战斗。
B端产品由于获取、实施、培训等原因,培训周期较长;即使产品定位正确,因为占据市场的时间太长,肯定会给竞争对手留下很大的空间去占据其他的空白,这也是B端产品比较分散市场的原因之一,但是C -终端产品是更多的垄断市场
产品的网络效应
一般来说,网络效应的简单理解是用户越多,产品就越好。例如,微信、滴滴就是这类典型产品。没有机会,只能切入更细分的领域。
B端产品一般为单边市场,产品网络效应较弱。 B端场景,客户越多,产品使用效果越好,场景越少。
一般来说,B端产品的网络效应需要通过SaaS工具进行上下游连接,形成双边交易市场;双边交易市场本身具有网络效应,从而形成SaaS产品的网络效应。
产品的裂变效应
产品在使用过程中是否会发生快速裂变也是能否形成垄断的重要因素。 C端产品一般通过好玩、好玩、炫耀、激励来促进裂变。
在B端产品中,这样的点自然很难,因为在大多数B端场景中,决策者和产品用户是分离的,产品购买的决策过程相对复杂。难以达到决策层实现交易; Slack和Zoom之所以成功,是因为它们的场景有自己的特殊性,但一般的B端场景很难复制这条路。
但笔者发现,在一些产业互联网场景中,比如蔡小米针对的生鲜批发市场,有以下特点导致产品裂变能力非常强:
横向上,客户非常聚集,基本零距离,客户与客户基本相互认识,产品做工精良容易形成口碑裂变。
开放的商业环境,基本上邻居用什么工具都是很开放的,客户使用的过程就是一个广告传播的过程,甚至刺激潜在客户比较完成销售。
纵向上,上下游之间免费软件的可持续性,上游供应商和下游买家聚集在市场上,容易形成上下游裂变。
基本上可以通过产品销售、训练周期的实施、网络效应、裂变效应来判断工业互联网市场是垄断市场还是分布式市场。
很多时候,我们只关注赛道和市场规模是不够的。数据的价值、连接的价值、赛道的垄断系数都是我们需要衡量的标准,尤其是垄断系数。基于这几点,基本可以确定一个产品在赛道层面的可持续发展指标,判断一个工业互联网公司的发展空间。在选择市场和产品定位时,可以参考上述观点进行分析。
对于很多读者问的几个热门方向,我简单介绍一下作者的观点:
02
OA、HR、CRM 和其他一般 SaaS 轨道
通用软件也分为中大客户市场和中小客户市场。从长远来看,对于同一个产品方向,中大客户和中小客户会被划分为不同的产品线。需求的差异实际上是相当大的。想用一条产品线解决所有需求的人,肯定会失去中小客户市场,因为对于这些客户来说太复杂了,不够个性化。
对于中小企业来说,目前中国的合规需求并不是刚需,所以目前中小企业很难使用通用软件。像美国独角兽Gusto这样的小微企业产品在中国的希望渺茫,目前能够给中小企业留下深刻印象。业务的共同点是营销。
随着市场的完善,合规要求变得僵化,一些针对中小企业的产品将迎来爆发式增长。这个时间点还有待观察。
对于大中型企业来说,由于国内管理要求相对不规范,加上国内SaaS人才严重短缺,产品可持续发展的问题是一个很大的挑战。一旦变成项目型公司,-8年后,发展会遇到很大的瓶颈。
对于大中型企业的软件公司来说,在早期资源支持的情况下,即使产品的可持续发展能力不强,仍然可以有良好的现金流,但要解决产品的可持续发展问题尽快,为长远发展扫清障碍。
根据笔者的经验,需求相对差异化的情况,其实可以通过产品力来解决,但只是在产品可配置性和灵活性方面要更加灵活。为大中型企业成立SaaS公司,在产研团队上投入大量资金。相信我,这笔钱绝对物有所值。
无论是中小企业还是大中型企业,短期是资源驱动,长期是产品驱动,但大中型企业资源驱动更多明显的;从最终的角度来看,产品实力最好的公司将获胜。当然,把产品打磨到理想状态也需要一定的资金支持。
03
垂直行业 SaaS 赛道
在垂直行业赛道,可以从衣食住行的角度看各个垂直行业。根据烹饪秘籍项目中的一些经验和观察,一般来说,好的垂直领域有几个特点:
市场空间大,痛点非常明显,切入点非常强。
垂直行业市场较大,但同时一个市场是最大的。如果没有一般的强痛点作为切入点,其实只能远观,不能玩。
中小企业多,但经营稳定,交易流量大
很多垂直行业没有绝对的巨头,而且大多是中小企业。中小企业的特点之一是死亡率特别高,很难保证高的更新率。但在一些行业,比如生鲜批发,经营失败的概率低于一般大公司,业务流动性较差。大而高的净利润,这样类似的场景可以保证客户的支付能力和高续费率。
集聚效应非常明显的场景,如生鲜食品、饮料、服装批发市场。
聚合效应非常强的B端场景非常适合传播和裂变。与一般写字楼场景相比,获客难度要小得多。这样的场景本质上是垄断系数非常高的场景。
场景比较规范,决策链条短。
场景比较标准,产品比较容易标准化,产品维护成本低,实施和培训周期短,成本低。
短的决策链确保了销售周期非常短。在类似于批发的场景中,决策者和用户通常是集成在一起的。这样的场景可以让客户根据用户快速传播和转化。
上下游或横向有很强的业务协同作用。
如果横向客户之间有协同效应,就有可能通过产品横向裂变,从而实现市场的快速增长。笔者曾经看到一个物流货运公司SaaS的场景,很多时候这些中小货运公司不能独立承担一些业务,需要相互配合才能完成。
利用上下游的协同作用,可以非常自然、轻松地实现上下游客户的上线,为切入上下游SaaS,实现双边交易市场提供了条件。
如果没有上下游协同,基本上这个工业互联网只有软件想象,后续空间会很有限。
行业信息不对称性强,对供应链效率要求高。
行业有很强的数据不对称性,可以让数据的价值非常高。比如笔者目前从事的生鲜食品行业,由于生鲜食品保质期短,需要快速批量销售和高效物流,对供应链的要求非常高,所以价值供应链的数据会很棒。
真正满足以上所有条件的垂直行业也非常少见。我们在判断一个垂直行业时,可以根据以上条件进行分析。
04
人工智能在SaaS领域的应用
人工智能的主要应用仍集中在图像识别,如自动驾驶、安防等场景。
三年前,我对人工智能在SaaS领域的应用寄予厚望;我也研究过很多国外相关的应用,比如Pymetrics,就是用来做游戏来评估人才软技能的,比如根据员工体验反馈给员工行为。 Humu 提供建议和 Glint,HireVue 提供视频面试,Edcast 提供个性化人才培训,Filtered 等等。
经过几年的观察,在SaaS领域,人工智能能够发挥巨大作用的场景非常少。原因是人工智能最适合的方式是识别、处理算法,然后给出建议。
但是,在SaaS领域,更多的是基于流程和业务驱动,与人工智能的合作方式则大相径庭。因此,在SaaS中的几个相对独立的处理场景中,往往会使用人工智能来改进输入。以及判断的效率,起到辅助作用。
目前,在SaaS领域,人工智能的应用需要对公司的组织和管理方式进行比较大的变革,才能让人工智能技术更加智能化。行业具有非常普遍的影响。
目前SaaS管理中可以考虑的一些方向是可以利用行业规范或业务知识形成知识图谱的方向。基于人工智能的识别,结合知识图谱的大数据给用户一些行为建议,目前可能更加现实实用。降落的方向。
关于人工智能在SaaS领域的应用分析,大家可以关注我公众号的一篇文章:《真智能还是伪智能,在HR文章中谈人工智能在企业SaaS中的应用》。
p>
05
关于低代码的一些想法
最后说一下最近比较火的low-code,我真的没有太多时间研究这个赛道这几年的最新进展。作者只是根据自己的经验给出我的看法。如果有不对的地方,我可以在评论中指出。
笔者接触过两个低代码平台,一个是2004-2008年在以色列的一个开发软件,一个叫Magic software的开发平台,是表驱动的,非常适合基于关系型数据库的管理软件开发,基本不用写任何代码。
这家公司在1980年代在纳斯达克上市(这家公司和我有很大关系,因为事实证明我是中国少数精通Magic开发的人之一。Magic 11岁左右.我还被邀请担任中国区产品技术总监)。
先说说它的优点:
特别适合企业管理软件的开发。发展速度极快。它是当时世界上开发企业管理软件速度最快的软件。事实证明,1990 年代有几场世界编程大赛,比编程还要快。由于万智牌参加了第二版,所以这场比赛被取消了,因为实在是没法比了。
特别适合单兵作战或小团队作战。一个非常全面和强大的工程师或一个非常小的团队,往往可以在短时间内设计、开发和实施一个复杂的管理系统。毫不夸张地说,一个精英的几个人的小团队,可以用其他工具与一个几十人、几百人的大团队竞争。
说说它的缺点:
比较适合企业管理软件的开发,尤其是当时的C/S架构。对于B/S结构的前端H5页面,也是使用前端语言开发的,前端开发速度上没有优势。
因为工具比较窄,使用的人也比较少,说明职业的选择范围很窄,也导致愿意从事这个行业的人比较少,导致严重缺乏开发人才,一般公司不敢选择这个平台。
工具的迭代比较慢,组件和开源内容也比较少,从来没有脱离小众工具的范畴。
因为技术更新非常快,所以笔者看一下万智牌这几年的发展。因为参与的人少,使用场景也比较有限,Magic的发展也很缓慢,公司的重心也逐渐转移到自己的另一个集成平台产品上。
在大约 12 年的时间里,我接触到了另一个低代码平台。据说是一个低代码平台。其实开发的工作量不小。这个工具的名字是HR.NET,定位在人力资源领域。低代码平台。
它的想法很有趣。在人力资源领域,人才管理模块(包括人事、招聘、绩效、培训模块)从全球来看其实是比较常见的。它基本上内置了一套配置强的天赋模块。
对于政策驱动的模块,假期考勤,工资福利模块,每个国家都可以根据自己的业务在这个平台上配置和开发,但是这个平台也存在以下问题,最终也不会太大开发:
1:会见的人很少,基本上每个人都要重新培训。真正敢于利用这个平台进行开发的公司很少。
2:这个低代码平台的复杂度还是很高的,平台更新很慢,解决一些问题的速度也很慢。
所以作为一个低代码平台,能否走红,成为大众产品,拥有成熟的开发者社区和大量的开发者是非常重要的。如果低代码平台定位为开发者使用,而用户群非常狭窄,这样的平台很难发展壮大。
如果低代码平台定位给甲方业务人员使用,大部分有产品技术经验的人都知道,配置系统往往需要非常严谨的数学逻辑,无论低代码的使用多么简单-代码平台是。梳理自己的业务逻辑也很难降低复杂度。甲方业务人员很难理清这些业务逻辑。
另外,由于线上和线下的不对称,线下业务和线上产品之间存在非常大的差距。最终这个工具还是要和甲方业务人员的办公工具竞争。
一般来说,作为SaaS公司,不需要自己搭建低代码平台。它需要的是基于自己的客户业务构建一个SaaS产品,足够灵活但又不过分。我记得ADP Global在过去几年花费了数亿美元来构建一个低代码平台。最后的结果不是很好。归根结底,一家SaaS公司做好产品应该就够了,没必要拿刀杀鸡。 .
在我看来,其实无论是低代码平台还是PaaS,真正的本质是技术共享。从这个角度来说,是不是可以先把定位缩小,再精准一点,看能不能做Good;例如垂直领域、CRM领域或HR、OA领域的低代码技术共享平台,帮助相关SaaS企业减少技术层面的重复建设和维护成本,让低代码命题更闭环、更高效易于着陆和舒适贴合。
这里作者提到了两家公司,大家可以参考他们的思路和实践,声网和企业微信,声网是定位音视频处理的技术分享平台。这样的垂直定位依赖于视频行业的发展。数百人的团队为当今价值数十亿美元的公司提供支持。
另一个是企业微信。企业微信已经躺了几年了,冷眼看着钉钉的高调和唱歌。基本上没有任何动作。一招打通微信,基本上秒杀钉钉。人们不得不佩服其产品的实力。
微信其实相当于企业微信的流量池。笔者觉得企业微信的定位更像是一个内部协作和CRM的低代码平台。并且技术与其他 SaaS 提供商共享,从而形成了一个相对低代码的生态系统。
钉钉的新定位太大了,看不到阿里的重点,很难看好。
以一句毛主席的诗作为结尾:
独立寒秋,北上湘江,前往橘子洲。
看万山红遍地,林染;
鹰击天,鱼翱翔于浅底,各种霜天争自由。
惆怅,问广袤大地,谁主宰着风风雨雨?
2020年工业互联网大时代真正开启,百家争鸣。但是创业是极其孤独的,好的机会是极其稀缺的。
创业路上到处都是尸体,但对于那些微光和火花,无数英雄被吸引到了他们的腰间。 Here I wish all entrepreneurs in 2021, while pursuing spiritual freedom and challenging the limits of physical, mental, intellectual, and intellectual achievements. real growth.