SaaS标准化的意义

1、降低边际成本

SaaS公司最大的成本投入是研发成本， 如果每一个项目都是通过配置完成交付，这意味着随着用户数的增加，研发成本会被逐步摊薄，最终形成规模效应。因此标准化是SaaS公司盈利的关键之一。

2、沉淀最佳实践

B端客户真正希望购买的是“行业最佳实践”。

即便SaaS公司具备丰富的行业经验，也了解行业标杆的业务策略和执行方案，如果SaaS产品不能体现和支撑这些“最佳实践”，那么推广和执行的成本都会很高。

所谓标准化，其实就是把领先企业的解决方案进行提炼，再固化到系统中。这些固化的解决方案，是SaaS系统的灵魂。

3、积累产品能力

如果SaaS公司依赖运营而不是依赖产品来保障“客户成功”，那产品和产品经理的价值都会大打折扣。

标准化会不断增强产品的配置能力，使得产品越来越厚重，价值越来越高。也只有厚重的B端产品，才能磨炼和体现产品经理的产品能力。

02 标准化策略

标准化策略是SaaS产品策略的重要组成部分。可以分为三个部分，分别是：

1、产品版本标准化策略

标准化最重要的策略，是确定“不满足哪些客户的需求”。

“一套产品吃遍天下”的传统软件时代，已经过去了。即便我们要占领多个细分市场，也要谨慎判断，是否通过“一个行业版本”满足全部客户的需求。

比如，在快消品行业，经销商和生产商的管理模式差异是比较大的。对于经销商来说，组织和权限的管理是相对简单的，也不涉及严格的外部账号管理；而品牌商则有复杂的多组织管理的需求，包括外部组织和账号的管理。

再比如，经销商的价格体系是相对简单的，不同等级的客户可能会有对应的价目表，部分客户会签订特定的价格协议；但是品牌商的价格体系则复杂很多，不同分公司、不同区域、不同商圈等级都会影响具体的价格。这是因为“价盘”是品牌商的生命线，所以精细的控制是有必要的。

快消品经销商和品牌商需求差异

当然，并不是说，我们一定不能在一个版本满足多个行业的需求。过去SAP、Oracle的成功已经证明这一点是可以实现的。

但是，SaaS引以为傲的正是足够“高可用”的系统。过于臃肿的产品，会大大增加客户的使用成本。

反过来说，“一个版本满足所有需求”当然是不正确的。但是如果盲目的横向扩充版本，也会给SaaS公司带来沉重的研发负担。

比如，当我们面对“非处方药”行业的客户，是否需要划分出一个版本呢？虽然并不是快消品行业，但是“非处方药”却在学习快消品行业的分销模式。在这种情况下，如果我们提供的是分销SaaS产品，就暂时没有必要单独为“非处方药”划分一个行业版本出来。

2、功能层标准化策略

标准化第二重要的策略，是决定“哪些功能不标准化”。

对于大部分SaaS，90%以上的功能是能够在产品层面进行标准化的，但是可能有10%的功能是很难标准化的。分清楚哪些功能可以“在产品层面进行标准化”，也非常重要。

比如，中小企业对报表的需求相对简单，因此报表功能是相对容易标准化的；但是对于百亿级企业来说，报表是一个高度复杂且不能妥协的需求，因此对于还没有BI或者PaaS产品的SaaS企业来说，暂时进行定制也是一个可行的选择。

3、开发层标准化策略

对于无法“在功能层进行标准化”的功能，我们要想办法在开发层进行标准化，即通常我们所说的PaaS，现在流行的叫法是“低代码”。

也就是说，即便是能够灵活二次开发的传统软件，也非常依赖低代码。更不用说二次开发相对困难的SaaS公司了。

因此，如果一家SaaS公司决意要做大，PaaS能力就不是可选题，而是必选题。

但是，自研PaaS平台确实是一个费钱的工作，并不是所有SaaS创业公司，都能够轻易负担得起的。好消息是，中国SaaS正在进入平台时代，钉钉、企业微信逐步增强的低代码能力，有望帮助SaaS公司低成本的拥有“PaaS自由”。

03 标准化设计难点

和自研系统相比，SaaS产品的设计更依赖长远规划。这是SaaS设计的核心，也是SaaS设计的难点。

重视长远规划，主要是由于两个原因。

1、控制开发成本

由于标准化强调配置能力，因此同样一个功能，所需要的开发量可能是自研系统的数倍。一旦开发了拙劣的功能，就可能对开发资源造成惊人的浪费。

2、便于持续迭代

更重要的是，作为“公用产品”，SaaS必须保持简洁性：如果系统充斥着一堆鸡肋的功能，且有少数企业坚持在使用，那么会对系统迭代造成阻碍。读者可以思考一下，当规划的新功能与这些鸡肋功能产生冲突，产品经理应该如何处理？

因此，好的SaaS设计就是尽量做“加法”，避免做“减法”和“改法”。

当然，标准化设计对产品经理本身也是有要求的。我常常比喻，所谓的标准化设计，就像在棋盘上放棋子：棋盘就是产品经理所拥有的架构能力，棋子就是具体的需求。没有棋盘，就不可能正确落子。