做不好软件，就做不好SaaS

2021-07-21 02:02:00

编辑导读：作为以软件起步的SaaS公司，产品才是我们的底盘；底盘不稳固，其他服务乃至商业化都是空中楼阁。本文作者对此发表了自己的看法，与你分享。

01 前言

近一两年来，SaaS行业涌起一股“偏离产品”的思潮。比如，很多朋友开始强调服务，认为服务才是SaaS的核心竞争力；也有朋友认为，SaaS应该像自研系统一样简单，毕竟做那么多功能，只会把系统搞得过于复杂。

其实，我个人也非常认同“SaaS+服务”的方向，国内也有很多“SaaS+”的成功案例。比如领健信息，就是SaaS+供应链平台：除了提供管理软件，他们还给口腔、医美机构供应耗材。

我也很反对功能界面过于复杂，除了培训成本居高不下，也会导致一线员工的抵触。

我甚至提出了“颠覆SaaS”的概念，比如这篇阅读人数破万的《颠覆SaaS》，你可以百度搜索阅读。

但是，我们也不能忽略一点：作为以软件起步的SaaS公司，产品才是我们的底盘；底盘不稳固，其他服务乃至商业化都是空中楼阁。比如，微信的底盘是IM（即时通讯），虽然它的生态很强大，但如果IM不能满足用户需求，那微信生态还有生命力吗？

其实，虽然做服务和交易很有竞争力，但做软件同样是一件有门槛的事。比如，阿里巴巴虽然是中国B2B、B2C的领先厂商，但他曾经为商家开发的CRM软件却是彻底失败的，这才有了后来的给淘宝商家提供软件的第三方服务市场。

因此，作为SaaS创业公司，如果产品还不够领先，就着急着把重心放到服务和交易上，认为产品就应该“小而美”，无疑是搞错了方向。

02 SaaS的软肋

1. SaaS颠覆传统软件了吗？

SaaS是一种商业模式，通过“以租代买”，降低客户的当期成本，同时把SaaS厂商的关注点从“用起来”变成“用得好” ，最终将SaaS公司和客户利益绑定在一起。

但是，如果仅仅通过“以租代买”就能实现颠覆，那么第一波SaaS创业浪潮就不会草草收尾。2014年兴起的这一波SaaS浪潮，更多是借助了移动互联网和社交互联网的红利，利用了传统软件移动体验糟糕、与社交网络集成性差的软肋，对企服市场进行了蚕食。但是，中国领先的SaaS企业，比如有赞等，至今仍然深陷亏损泥潭，客户流失率也居高不下。

超级产品经理

来源：有赞财报

从个人角度，我也听到很多曾经的客户抱怨，说SaaS软件功能太简单，定制化能力很差，还具有不稳定的问题。客户不满意、企业不盈利，在中国，SaaS模式还没有赢得主流市场的胜利。

其实，即便是SaaS鼻祖Salesforce，在2004年上市时，市值也不过十亿美元。在2008年发布PaaS平台之后，Salesforce开始“进攻”大企业市场，并通过收购不断扩充产品线。比如2010年收购企业黄页数据库公司Jigsaw， 2013年斥资25亿美元收购数字营销软件公司ExactTarget。但一直到2016年，Salesforce才实现扭亏为盈。

要知道，美国企业的付费意愿远高于中国企业。根据美国国家软件与服务公司协会(NASSCOM)在2019年的报告，中国IT支出仅占GDP的1.4%，其中只有2.7%用于云服务。与此相比，美国IT支出占GDP的4.7%，其中11.4%用于公共云服务。

产品能力不足，市场又不够成熟，中国SaaS的颠覆之路，还任重道远。

2. SaaS交付最重要的问题

从软件公司角度来说，传统软件模式是一种不错的商业模式。

首先，软件一旦成功上线，软件公司就能收回大部分合同款项，这在很大程度上规避了软件公司的风险。

其次，由于强大的配置能力、低代码能力和定制化能力，传统软件可以最大化满足企业的个性化需求。

但即便如此，企业的需求仍然是很难完美满足的。比如经常出现上线后才发现需求梳理错漏的情况，为了解决这个问题，传统软件制定了非常严格的交付流程。

一个典型的传统软件交付流程如下（基于Oracle实施方法论进行了简化）:

第一步：系统培训与需求调研。

目的：客户了解系统功能，咨询公司了解客户需求，找出系统功能与需求之间的差异。

第二步：制定解决方案并模拟演练。

目的：系统能满足的需求，制定配置和低代码方案；不能满足的需求，制定定制化方案。搭建好测试系统后，需要进行多次模拟演练以确保系统满足需求。

第三步：做上线前大规模演练和测试。

目的：用尽可能真实、全面的数据进行大规模演练，检查方案和系统是否存在错漏。

第四步：上线并试运行。

从这个过程可以看出来，即便是功能强大的传统软件，其成功交付的关键仍然在于“弥补软件满足客户需求所存在的能力不足”。而说到产品能力，以我的经验来看，中国SaaS还远比不上传统软件。比如，一套Oracle ERP的安装空间需要200多个G，而大部分中国SaaS的安装空间恐怕连一个G都达不到。毕竟中国SaaS的历史并不长，同时，作为具有互联网基因的SaaS，从一开始就非常重视用户体验，这在很大程度上降低了产品功能的开发速度。

因此，SaaS交付最重要的问题，目前仍然是“产品能力无法满足客户需求”的问题。

03 需求分层模型

要想满足客户需求，首先需要分析客户需求。

在一个To B软件项目中，客户的需求主要是解决以下两类问题：

1）管理/运营问题

这一类问题往往比较复杂，主要包括僵化的管理机制、落后的运营模式等。

2）流程/效率问题

这一类问题，主要是流程低效或存在漏洞，比如手工订单降低流程效率（内勤人员需要将手工订单录入系统，才能安排发货）。

举一个例子。某公司购买了采购管理系统，希望解决以下问题:

1、管理/运营问题：

集团采购管控模式落后，采购权分散，同一类商品多个分公司都在采购，议价能力差。

2、管理/运营问题：

基础数据混乱，缺乏统一的数据管理部门；一物多码现象严重，导致部门协同出现问题。

3、流程/效率问题：

采购流程混乱，不同物资缺乏清晰的采购和库存管理流程。

4、流程/效率问题：

通过手工账本进行应收款账期管理，管理透明度较差，存在错漏现象。

5、流程/效率问题：

有一套简单的订单管理系统，但录入订单时不能自动计算商品总数，不便于与客户订单核对。

6、流程/效率问题：

统计报表手工编制，时效性差、效率低下。

不同的问题，解决方案是不一样的。

问题1：对于集团采购管控模式问题，必须由采购管理专家，给客户提供一对一的咨询服务。将分散采购模式变为集中采购模式。

问题2：对于基础数据问题，需要由具备一定编码经验的项目人员，和客户一起制定编码规则，并对现有物料进行统一编码。

问题3：对于采购流程混乱问题，需要由熟悉采购流程的客户成功经理，和客户一起对流程进行梳理，按不同的物资类型制定不同的采购和库存管理流程。

问题4：对于手工账本问题，标准账期管理功能可以满足需求，配置即可使用

问题5：对于订单录入问题，可以使用标准功能。但“自动计算商品总数”的需求，需要通过低代码能力满足（标准表单嵌入SQL）。

问题6：统计报表手工编制问题，通过定制化开发统计报表解决。

总结一下，满足客户需求主要是依赖以下四种方案:

1、变革类管理咨询：

帮助客户梳理管理思路和运营模式，甚至推动管理改革。对于改革类咨询，实施难度颇大，除了需要咨询顾问具有实操经验，也非常依赖企业自身的条件。比如对于国内很多二三线制造企业，通过咨询实现精益生产难度极大，因为他们整个供应链的质量管控能力都非常糟糕。

2、优化类管理咨询：

对于优化类管理咨询，比如流程和数据梳理，则难度相对小。需要咨询公司具备相应经验，同时客户的配合也很重要，比如有专人承接数据管理或流程管理的工作。

3、系统配置：

在梳理清楚需求后，通过系统的标准配置能力满足客户需求。对于有低代码能力的系统，也可以通过低代码满足一部分需求，可以有效减少二次开发。

4、系统定制开发：

根据客户需求进行二次开发。值得一提的时候，由于二次开发的容错率低，即一旦需求梳理错漏，开发的沉没成功相当高。因此，需要成熟的客户成功经理或者产品经理，确保需求梳理质量。

这四种方案，按照方法难度（高难度/中难度/低难度）和方法类型（咨询解决/系统解决）可以分为六个象限。比如，问题1的解决方案属于高难度/咨询解决方案，问题2的解决方案则属于低难度/咨询解决方案，问题4则属于低难度/系统解决方案，问题5属于中难度/系统解决方案，具体对应关系如下：

超级产品经理

为什么要划分为这6类问题呢？这是因为不同类型的问题，需要匹配不同类型的资源。

04 交付资源分层模型

交付SaaS的过程，其实就是解决客户问题的过程。对于SaaS公司来说，问题具体怎么解决还不是最重要的。最重要的是，我们是否有解决问题的资源，以及资源的成本是否足够低，解决问题的效率是否足够高，这才是决定SaaS交付质量的关键。

根据资源的类型，我们可以把SaaS交付资源分为“工具”和“人才”两个类型。工具的核心就是SaaS产品，当然也包括案例库、SOP文档等等。而交付人才的核心则是客户成功经理，或者实施顾问。工具和人才往往需要搭配起来解决客户的问题。以上述采购系统项目为例，按照“人才+工具”的维度，6个问题对应的交付资源可以分为：

问题1：对于集团采购管控模式问题，依赖资深的采购管理专家，使用基本的office工具就可以了。采购管理专家依靠丰富的实战经验，很难批量复制。该方案属于高级人才+低级工具。

问题2：对于基础数据问题，需要由具备一定编码经验的项目人员，制定编码规则并对现有物料进行统一编码。这样的项目人员经过简单培训即可上手，需要了解的业务知识和系统功能均有限，因此属于低级人才+低级工具。

问题3：对于采购流程混乱问题，需要熟悉采购流程的客户成功经理，流程梳理以后还需要配置到系统中。不过，采购流程熟悉和系统配置，都可以依赖详尽的文档和完善的培训进行批量培养，再加上一定的项目经验即可。因此该方案属于中级人才+高级工具。

问题4：对于手工账本问题，需要熟悉系统的客户成功经理进行系统配置，客户成功经理同样可以通过精心的培训和文档进行批量复制，因此属于低级人才+高级工具。

问题5：对于订单录入问题，需要熟悉系统和低代码的客户成功经理进行系统配置和低代码配置，考虑到低代码需要一定的技术基础，对人才的要求更高，因此属于中级人才+高级工具。

问题6：对统计报表手工编制问题，需要由开发人员进行二次开发。开发人员属于相对稀缺资源，成熟开发人员往往较长时间的培养，但他们所使用的开发工具，往往都是很容易获取的，因此属于中级人才+低级工具。

示意图如下：

超级产品经理

如果“资源分层模型”匹配到“需求分层模型”，则关系图如下：

超级产品经理

“高级工具+中低级人才”最能体现SaaS公司的核心竞争力，这一类问题主要是系统能够解决的问题，是最应该优先投入的领域；而“低级工具+高级人才”则很难体现SaaS公司的优势，这一类问题主要是管理/运营咨询才能解决的问题，不建议产品还未成熟的SaaS公司重点投入。

05 工具升级，人才降级

除了选择合适的领域投入，我们还必须明白：随着“工具”能力的提升，“人才”能力要求可以同步下降，从而带来整体成本和风险的下降，即“工具升级，人才降级”。

比如，大型ERP的实施需要大量专业人员。在早期，人才的匮乏和高成本一直是困扰行业规模化的难题。直到有一家厂商，采用大量招聘毕业生的思路(低级人才)，通过高水平的学习文档和集中培训机制(高级工具)解决毕业生经验不足的问题，成功实现了低成本规模化。反之另一家曾经的国内领先企业，因为没有解决成本和规模化的问题，最后被收购，现在已经消失匿迹了。

在传统软件时代，国内大部分咨询公司没有自己的产品，因此工具能力只能从培训文档、SOP流程入手。但是到了SaaS时代，SaaS公司都有自己的产品，虽然从培训文档、SOP流程入手仍然是可行的，但更好的方式，就是增强SaaS产品功能，不断推进交付的“工具升级、人才降级”。比如，通过高可用的报表配置平台，我们可以实现简单报表的自定义配置（拖拉拽），这就减少了部分定制化开发，将问题6的交付资源从“低级工具+中级人才”变成了“高级工具+低级人才”，不但提高了产品竞争力，还降低了交付成本。

说到这里，就不能不提PaaS平台。曾经有创业者问过我，是不是必须要做PaaS平台？其实，我更愿意把PaaS作为一种能力。比如，我们支持通过配置，在订单表单新增字段，并且赋予字段文本或者数字的属性，这就是PaaS能力。至于是不是一定要做PaaS平台，我觉得对于缺乏资源的创业公司来说，并不是必须的。

另外，工具提升空间是相对无限的，只要投入足够资源，工具的提升是快速且稳定的；而人才提升空间是相对有限的，哪怕投入再多资源，人才的提升也很容易遇到瓶颈。有远大理想的SaaS创业者，一定会首先把精力放到“工具”上。