环球观天下！SaaS公司如何彻底消灭定制化(二)

图片来源：poco 梵丁

(资料图片)

上篇文章讲到 SaaS 公司为什么要消灭定制化，以及为什么可以消灭定制化，很多 SaaS 朋友微信上面加我讨论，定制化问题在 SaaS 界确实是目前是目前比较普遍的问题。

基于上篇再总结一下，关于定制化问题，我们可以看二个维度， 一个是 SaaS 公司面向的客户需求的分化指数 ，如果一个 SaaS 公司面向的客户群越大，客户间的需求差异越大，那这个需求分化指数越高 , 可以将目标客户群需求的分化指数按照如下来进行排序：

某个特定的客户

某个行业的客户

跨行业的通用客户

全球性的某个行业的客户

全球性的跨行业客户

为某一个客户定制化

标准化产品 + 不同程度的配置性

标准化产品＋ PaaS 开发平台

PaaS

开发平台

一般来说需求分化指数越高的客户群，需要用灵活度越强的产品来进行匹配。

另外，如我原来很多文章所说的， SaaS 产品越灵活，交付成本越高，业务扩展的可复制性越差，另外从用户体验的角度来说，越不贴身。

所以 我们永远需要选择能够满足自己客户群体，最贴身最不灵活的产品去满足客户，因为这样公司业务的可复制性最强，客户的用户体验也最好。

在这几类客户中，比如说 SAP 就是典型的跨国跨行业的大客户，所以最后选择采用的是标准化＋ PaaS 的方式，我记得原来 SAP 还有自己的定制化开发语言 ABAP.

作为仅是针对国内市场的垂直产业客户也好，跨行业的客户的 SaaS 也好，笔者觉得标准化产品＋不同程度配置型的产品足矣，如果选择的客户群都需要用到 PaaS 了，个人觉得要重新审视一下公司战略关于客户群的选择。

OK, 回到正题，我们来谈一下如何做一个标准化的 SaaS 产品，笔者觉得主要是考虑好三方面：

1: 客户群的角度

在客户群选择上面，有一些原则性内容：

一般来说， 即使是同一个行业，中大，中小客户的需求差别比较大，一般需要区分不同的产品线，不同的定价体系来进行满足 ，当然实现方式也可能是将满足中大客户的一部分功能拆分出来满足中小客户。

在为一个行业提供服务的时候，即使是垂直产业，可以将客户进行进一步分层， 比如说几类典型用户，一类一类的满足客户，在满足好一类客户之后进入下一步，没有必要急于求成，伤其十指不如断其一指 。

在一个行业客户群进行切入的时候，比较好的选择是先切入腰部客户 ，需求相对比较标准化，也有一定的付费能力，另外从这个角度来切入的时候向更大客户的延展也相对比较容易。

整体来说，客户群的选择不要求大，避免产品的需求早期过于分化，以及不聚焦，产品需求失控以及标准化难度增加，需要一块一块切。

2: 需求的角度

要做好标准化开发，我们首先要做好需求的管理，在售前的角度或者实施过程中，我们会拿到客户过来的大量的需求，在这里首先判断需求是否真实是否合理就非常重要：

如果是真实的需求，实际上客户一定线下用某种手段已经实现，比如说微信，excel，word，电话，面对面沟通等方式满足了需求， 我们要通过客户线下的行为判断是否是真实的需求还是想象的需求，不要去创造需求。

不是所有的线下需求需要被线上化，或者可以被线上化的，适合线上化的需求都是可以定义清晰规则的线下需求 。很多线下需求很随意，或者很难确定规则，这样的需求是不适合线上来满足的，会带来更多的问题，或者更加的不方便。

等拿到的需求都是真实可以线上化之后，这些需求又会分成如下几类：

2.1 需求是对自己产品有帮助，有补充作用的共通需求，需要在产品上面来实现。

这类需求是需要放在标准产品里面进行标准化的，对于这类需求，很多时候产品团队会担心，这种需求可能不能代表所有客户的情况，当然最好可以等到有多个客户提这样的需求的时候再进行开发。

有时候，在客户很难等待的情况下面，这时候可以先基于客户的需求来做，这里不需要过于担心其他客户需求有差异的时候改动太大，B端产品做加法是比较容易的。在拿到的样本还比较少的时候，也不需要做到过于灵活，努力做小做少，做精就可以了，后面再调整也是可以的。

2.2 有些低频极端的需求合理，规则也清楚，但是不适合在产品上面来实现。

实际上，我们发现客户提的很多需求都是这种需求，这种需求的满足反而是更花时间和资源的，一般来说，正常的90%需求只需要花30-50%的精力，极端的10%的需求需要50%－70%的精力。

很多时候售前或者产品团队在这类需求上面栽了跟头，导致了很多不必要的开发，培训和交互，然后也让产品变得非常复杂，这是一个产品公司最大的浪费。

我这里举一个薪酬管理里面的例子，比如说一个月的薪酬计算完成并且发放之后，突然发现某个月的休假天数搞错误，或者一些绩效数据发生错误，上个月的薪酬数据错误，如果单纯的将这部分数据补发到下个月，可能又会影响个人所得税的情况。

很多系统里面会有类似的情况，就是系统是建立规则的，但是有时候我们发现线下很多时候业务有特例，需要去打破规则，线下支持这种特例是很简单的，但是如果线上来支持就难度特大，因为系统是建立规则，如果又要去支持打破规则，代价是非常大的。

实际上上面薪酬的例子，系统上面比较好的支持方式，就是放调整项，这种费用的调整让业务人员在线下算清楚，将这个项目的结果作为调整项输入系统是最优解。

2.3 属于这家的特有的需求，不是那么共通。

经过正确的筛选之后，你会发现实际公司特有的需求会非常少，剩下的这类需求需要努力说服客户用线下，或者已有线上功能＋线下的方式来进行解决。

当然，在不同行业可能有不同的情况，这个时候一般需要在输入，计算，输出等地方保证一定程度的灵活，确保可以帮他们把这类需求配置出来，这就涉及到下面讲到的设计层面的一些原则问题。

3: 设计的角度

在需求问题解决之后，就是具体怎样将每一个需求做到标准产品里面去的问题，怎样做一个灵活度刚刚好的产品，既能满足不同客户的不同需求，也能够让客户实施成本，客户体验在一个很高的水准。 下面具体讲讲怎样将不同公司不同需求怎样在产品里面进行标准化的一些方式。

首先说明标准化设计的时候需要把握的一些原则性的内容：

1: 架构上考虑长远，需求上先做小

2: 功能架构，信息架构做好分类

3: 刚刚好，不要过度灵活

4: 每个公司，每个人看到自己需要的内容

5: 做好默认配置。

实际上所有的软件系统的功能都是由输入，计算，输出组成， 我们软件的功能组成来说明标准化设计的方法：

3.1 输入这块

输入表单或者导入

不同公司同样的表单功能可能有不同的需求，比如说人事系统里面人员信息的详情和编辑页面，可能会有如下不同的需求。

a：数据维度，不同公司要求的输入字段不一样。

不同公司要求的字段集不一样，比如说A公司的员工要管理50个字段，B公司要管理60个字段，C公司要管理55个字段，这个时候标准化的方式如下

将共通需要固化的字段尽量固化出来，确定默认大家都需要的字段。

将固化字段里面，有些公司需要，有些公司不需要的可选的配置字段，在实施的时候在公司的维度进行配置。

还有一些无法固化定义的字段，这些字段可以在配置平台，支持字段名，类型，显示顺序等内容的配置，这些配置项都可以存在数据表里面。

导入文件方面也是类似的逻辑，可以通过配置表单的方式来解决，表单中尽量将可以固化的字段以及逻辑固化下来。

3.2 关于计算这块

很多时候就是不同公司有不同的计算项目，不同的计算逻辑，对于这些需求的标准化基于不同的场景有不同的方式：

3.2.1 可以抽象的不同的逻辑分支。

大部分SaaS产品在逻辑方面的分支都属于这块，这里面一般的做法就是内置多套逻辑，然后将参数暴露出来，不同公司可以配置不同的计算参数或者选择走不通的逻辑分支。

3.2.2 很难抽象的不同计算逻辑。

对于很难抽象的不同计算逻辑，这个时候要支持公式的配置。除非少数需要非常灵活的计算引擎，要尽量避免这样的情况发生。

3.3 流程这块

流程这块，在我们做标准SaaS的时候，经常会碰到不同公司同一业务，或者同一公司，同一业务流程不一致的情况。

比较典型就是人事管理里面休假管理的流程处理，不同假种，不同请假的天数都有可能有不同的审批流。

在SaaS里面，关于流程这块的标准化设计，一般有二种设计，第一种就是很多公司都在应用的状态流程配置工具，可以灵活的定义流程，定义节点，流程流转条件等等。

另外一种就是将流程尽量抽象标准化下来，将需要进行条件化配置的地方，设计好参数管理或者条件表达式，从而来支持不同情况下面流程的运转。

笔者建议在做标准SaaS设计的时候，尽量采用后面一种方式，前面一种实际是将问题复杂化，这个复杂化的问题本身就很难解，而且会演变得越来越复杂，后续的实施，培训，用户体验都会出现一些问题。

3.4 输出这块

3.4.1报表

关于报表这块，其实是容易产生分化的功能模块，一般不同公司关心的报表数据总是会有一些差异。关于报表这块在进行标准化的时候也是遵循下面的逻辑：

第一块就是每家公司都会用到的比较标准化的报表，这块报表需要抽象出来，固化下来。

有一种情况就是每个客户字段会有些差异，这个情况下面，需要将所有用户基本都需要的基本字段抽象出来，固化下来。其他的还有二类字段，一类就是有些客户需要，有些客户不需要，这部分通过是否显示进行配置。

如果有些客户还有一些需要个性化的字段，可以考虑支持一些字段的增加，这些字段的显示名以及结果逻辑支持配置。

如果产品针对一些通用行业，总是有一些输出报表很难抽象出来，可以支持一些报表模版的配置，支持搜索字段名，字段逻辑以及排序，筛选条件等配置。不过这块配置的灵活度需要把控，尽量不要过于灵活。

3.4.2 外部接口

一般来说，作为标准SaaS供应商来说，给外部提供的接口数据格式，可以比较标准，不需要太多的配置化。

3.5 权限与角色

所有的SaaS系统的权限主要分二个维度，一个是功能维度，一个是数据维度，通过功能和数据定义出来每个用户可以访问哪些功能，在访问功能的数据可以查看和操作哪些数据。

因为用户很多，每个减少定义的工作量，一般系统还会引入一个角色的概念，通过角色定义每个角色对应的功能权限，然后用户再和角色进行挂钩，一个用户可以对应多个角色，通过这种方式配置出每个用户可以访问的功能。

数据级别的权限一般跟用户直接挂钩，因为同一角色很多时候对应的数据权限不一样，定义在角色身上不是很合适。

在很多系统里面，角色都是依据岗位来进行定义的，因为同一岗位对应的功能集都是比较类似的。

而数据权限有组织完善的公司里面，很多时候都是和组织对应的，所以很多时候做好数据权限的管理要做好组织的管理，然后定义每个用户和组织数据权限的关系。

今天就说到这里，后续的文章笔者会继续讲解已经存在大量定制化的公司，怎样庖丁解牛来做标准化产品。

关键词： 很多时候 一般来说