SaaS下一步怎么做？

时间：2023-03-14 09:14:01 | 来源：电子商务

时间：2023-03-14 09:14:01 来源：电子商务

SaaS在美国已经火了很多年，中国这几年SaaS公司也层出不穷，在10多年的小心探索后，终于在疫情时代爆发，除了创业公司，许多老牌的软件厂商也纷纷转型，如在房地产行业深耕多年的明源云，在ERP领域沉淀三十载的金蝶，在这一轮浪潮中都攀上了市值的最高峰。

2022年逐渐进入资本寒冬，二级市场疲软，不少企业市值跌去了八九成，火热的市场已经冷下来，投资圈已经形成共识，只投现金流为正的公司，这给众多创业公司带来了极大的挑战，可以预见的是，许多公司可能无法扛过这个寒冬。

新疫情时代下，作为软件服务商如何应对？在占据主导地位的国有经济并不认可SaaS模式的情况下，在中小民营企业步履维艰的时刻，纯粹的SaaS模式还能持续下去么？

中国的SaaS企业分为两类：“纯粹”的SaaS；OP包装的SaaS。

前者更多是追求小而美，切入某些领域，如最为火热的SCRM已涌入上千家企业互相搏杀，产品大同小异互相借鉴，价格可以互相砍到脚脖子，没有核心产品力及技术能力的企业，在这波寒冬中生存几率不大；后者更多是有不少积累的软件企业，自身也在追求“云化”的转型，比如中国的老牌企业用友、金蝶，以及各个行业软件的龙头。

不管是“纯粹”的SaaS还是OP包装的SaaS，都在面临极大的挑战，说几条：

技术研发

中国的软件技术分两个大类，一类是传统的软件研发，一类是互联网研发。前者更追求业务/行业经验的打磨，后者更追求海量数据及并发下的用户体验，而SaaS的要求是两者的结合，现阶段人才缺乏，既对行业有深刻理解又能运用好互联网技术的都是香饽饽，能结合好两者的产品也不多见。

以中国国情来看，小微企业生存率低，付费意识和付费能力都很弱，面向这个群体的产品固然可以做得很标准，但收入及留存是很大的问题，比如某龙头企业接近30%的流失率可见一斑。

大型企业付费能力强，行业里也有很多的声音认为应该主攻大KA，但大KA的定制化如何解决？如何避免A企业的需求变更导致B企业的业务受到影响？

国有企业私有化部署更为普遍，如何低成本高效的私有化，并且能够快捷的进行二开？

产品经理

和上面提到的技术类似，SaaS产品经理需要的是互联网产品思维+传统行业经验的沉淀，这类人才不好寻找现成的，更多需要依靠自己培养、转型。需要具备什么样的素质？ 王戴明《SaaS产品经理从菜鸟到专家》一书中给出了比较好的答案，新的时代提出了新的要求，能否快速培养出优秀的“新产品经理”，将是决定公司未来的重要砝码。

交付实施

SaaS下的实施与OP模式完全不一样，大多数的垂直业务应该追求“无实施自助上线”，尽量的降低交付成本，这对产品可用性也提出了新的要求。行业SaaS如零售ERP，业务极其重，二开是业界满足个性化需求的重要武器；传统OP下实施有足够的权限和能力进行现场开发，贴身定制服务，在SaaS模式下，所有的系统都在云端，实施的权限有限，如果所有的需求都要提交到总部进行排期研发上线，并且由于所有客户都运行在同一个平台，能否将差异化进行隔离、并行交付，是否有一个强大的平台支持二开将拉开竞争对手的差距。

客户成功

大多数的客户成功，并不能让客户成功。除了有很好的服务意识和态度外，是否真正的能让客户用好系统，创造出价值，是非常有挑战的事。如客单不高，投入大量精力可能得不偿失，如果针对大KA，专业度是否足以引领客户，是否具有咨询能力，并且不进行“过度服务”，大家都在探索，并且建立起这样一支队伍需要很长的时间。

销售

“销售给正确的客户”是一个最基本原则，销售团队是否能够正确理解SaaS，走量的产品与大KA销售截然不同，如何敏锐的发现机会和变革点，给产品研发团队很好的向导作用是销售团队的重要职责。另外一点，不要把公司卖成了项目制公司。

安全合规

跟传统软件相比，全面部署在公网的SaaS平台，安全合规要求非常严格，尤其是出海的平台，隐私、安全往往是国内团队缺乏的，不管是意识还是技术规范上。

吴昊的《SaaS创业路线图》中指出， SaaS的本质是续费，由续费模式的变化，驱动产品及运营的变革。但看看现在的SaaS公司，除了收费模型变了，其他是不是老一套呢？

如果不改变配套的产品、技术、服务机制，说到底就是一个伪SaaS，一旦到达较大规模就会遇到很大的瓶颈，能否迈过去将决定生死。

从技术层面来看看这个问题：当服务10个KA时，大量的并发需求靠研发堆人还能应付，但各个KA之间个性化差异的问题已经使得系统复杂度非常高，通过工作流、配置化、规则引擎等能解决一部分问题，但深度的问题只能硬编码；还有一些私有化部署的KA，版本之间差异化已经很大，同一个团队的研发已经记不清到底有哪些不同，再次更新的时候应该如何拉齐版本，从一堆文档中逐个比对，让人精神分裂头晕眼花，更为关键的是，一次小小的疏漏，可能就会导致本来并无需求的用户业务受到重大影响，研发团队谨小慎微，整天提心吊胆，只求上线无恙，又哪里敢大刀阔斧创新求变。

要是100个，1000个呢？

到底是在做产品还是做项目？

从客户方面来看，一个行业有大中小各类客户，产品的定位是什么群体？一套产品是否能包打天下？ 很多小微企业，就是一家人在管理，跟我谈什么流程规范，权责分离，多级审批？适应KA的需求，往往不适应小客户。如果要划分多个版本来服务不同层级的客户，那是另起炉灶重新开发一套产品，还是把现有产品中台化，打造多个前端产品？

是否有一个强大的PaaS平台是分水岭。

这里说的PaaS平台，不是aPaaS低代码平台，也不是iPaaS集成平台，而是基于元数据管理的底层平台。

所有的业务数据不再以固定的物理结构存储，全部是以配置化的形式呈现和存储，存储本质上和市场上诸多aPaaS平台类似。在此之上构建完整的业务，将改变原有的研发习惯和技术方案，正因为天然的元数据管理，每个客户都可以拥有自己的数据结构和流程乃至交互方式，并且完全隔离，使得二开就如同本地部署软件，不会对其他客户产生任何影响。 整个平台均高度灵活可配置，那么在此之上构建能跟业务紧密联系的低代码/无代码平台就是水到渠成很容易的事。 从满足内部研发，到满足实施二开，再到支持ISV二开，最终到支持客户自行开发。

提到生态，往小里说是通过一系列API，开放平台能做到集成，但远远不足以满足各类客户诉求。以元数据管理为基础的一系列能力，包括开放平台、基于源码的二开、低代码平台、无代码平台、页面定制化等综合起来提供服务才能最大化的将能力进行开放，不再受到自研团队资源的限制，真正可以有构建生态的资本。

针对不同客户的不同版本，也完全基于PaaS能力构建，能极大的缩短产品研发周期，构建起产品矩阵，快速领先对手占领先机，快速的响应和调整，往往就是胜负手。

当然，对研发的挑战也是非常大的，同样对产品经理抽象的能力，对行业的理解也会提出新的要求，如果做到高度抽象后再具象，是成败的关键点。

Salesforce提供了很好的样本，花了5年时间构建起PaaS平台，奠定了接下来十几年快速发展的基础，一旦东风来了，就扶摇直上九万里。

国内不少企业也在做自己的PaaS平台，但真正彻底、领先的并不多，大家都还在尝试，在摸索，但这一定是未来，是可持续发展的基石。