—
定制化应该是一个产品可持续发展，一家软件公司可持续发展的最大罪魁祸首，该问题的解决越早期越好。
来源 / SaaS产品说 （ID：meetsaas）
作者 / 李东林
定制化的话题笔者觉得是一个非常重要的话题，二个月之前就想写，只是一直没有抽出时间。定制化问题是中国SaaS公司面临的一个普遍性的重大问题，笔者接下来会分三四篇文章分如下几个部分来说明如何解决定制化的问题。
在创业的早期，很多时候我们为了生存，为了拿单，我们在压力之下做了很多需求，这些需求的设计如果控制的不是很好，比较固化。后面其他的客户很难使用，要改动也很难，慢慢就成为独立的版本，慢慢积累下来，定制化就会越来越多。- 多个版本，加上正常的人员流失，维护工作量以及难度越来越大。
- 定制化的版本基本很难持续迭代，用户体验很难做得非常好。
- 一些定制化的版本都很难跟着主流版本进行升级，成为顽疾。
- 定制化越多，公司的，无论是产研，售后，还是客户成功的负担越来越大，可复制性也变差。当公司营收超过一定金额，比如说5000万之后，公司的发展变得肉眼可见的越来越慢。
- 定制化做久了，团队耦合度越来越高，压力越来越大，团队会越来越疲惫，氛围变差。
另外一个问题，就是定制开发的功能不能复用，边际成本很高，慢慢定制开发的功能算下来可能都是亏钱的。定制化应该是一个产品可持续发展，一家软件公司可持续发展的最大罪魁祸首，该问题的解决越早期越好。否则到了后期，整个公司的发展就积重难返了，君不见大量90年代，00年代成立的企业管理软件公司现在还陷在定制化这个泥潭里面，动弹不得，发展不了，也不能速死。我们现在大量名义上的SaaS公司实际上还是在走历史的老路而已，很难可持续发展。针对SaaS公司，我一个朋友提了一个标准化产品的ARR指标，我觉得非常正确，大家可以参考，作为公司的一个战略指标。当然，团队没有标准化产品的能力，接一些项目作为生意，也是无可厚非。还有一部分，前期团队能力还不够，先通过一些大客户项目活下来，后面升级团队尽快转型到标准化产品，追求长期可持续发展也可以（其实前期如果可以找到一个高手即使只是帮忙把把标准化产品的关，就可以节省大量的时间和金钱，越早越好）。要基于自己团队的情况做具体的选择和判断，但是要知道诗和远方在哪里。第二个问题，为什么可以彻底消灭定制化，因为很多人都不是专业人士，我尽量先来通俗的类比论证一下。我们一直听到一种说法，中国现状因为有很多的定制化，所以PaaS有其空间，业界似乎都认可PaaS可以来解决SaaS定制化的问题。那好，我们可不可以先这样来思考，既然PaaS可以解决定制化的问题，我们再收敛一下，是否可以通过一个垂直的PaaS来解决定制化的问题，比如说HR行业可以做一个垂直的HR PaaS平台，做CRM的可以做一个CRM PaaS平台来解决定制化问题，等等。好像是可以的，那我们再来深入一下，如果HR领域做一个HR PaaS是可以来解决问题的，那我们在做人力资源管理领域是否还是可以抽象出很多共通的功能，不同公司肯定会有一些不同的需求。我们把可以抽象出的共通功能做成SaaS产品的标准功能，另外通过配置化来解决一些客户之间不同的需求。这里可以打一个比方，比如说不同客户的需求总和的形状不一样，但是总是会有一些重合的地方，这些重合的地方都是产品需要标准化下来的功能，其他不一样的地方。产品所做的事情是用一个最小的形状，可以将这些不同的需求形状装进去，还要努力做到无法做减法。这样说来，我们只需要一个配置型更强的行业SaaS来解决问题。在这里，笔者给大家讲一个真实的故事，一个花了数十亿美金的故事。曾经有一家公司，一家全球性的人力资源的龙头企业，这家公司在全球近百个国家都有业务。由于每个国家，国家里面不同公司的人力资源管理都会有一些差别，特别是一些政策性的功能，比如说休假，考勤，薪酬这块，所以不同国家都需要开发不同的人力资源系统来支持该地区的业务。- 不同国家之间开发的人力资源系统很多功能还是类似或者重复，开支很大，浪费了很多人力物力。
- 管理起来难度很大，不同国家产研水平不一样，开发出来的效果差异也很大。
- 不同团队开发出来的产品的界面以及风格差异很大，不利于公司统一的品牌。
所以这家公司做了一个事情，收购了一家专注于给HR领域做PaaS平台的公司，上面有一些固化的模块，比如说人事管理，比如说招聘，培训，绩效的一些功能，一些跟国家区域关系很大的政策性功能，比如说福利，薪酬，休假等管理，可以在这个平台上面配置开发，这样做有几个好处：- 很多共通的功能在平台上面固化了，不用重复开发，大幅度的减少整体开发工作量。
在执行的时候，这个平台公司配合协同全球不同国家的产研团队进行本地化系统的开发和落地。但是在全球化落地的过程中，也带来了几个问题：- 共通固化的功能，因为考虑不周，很多时候对具体国家的支持还是不是太友好，需要在此基础上面做一些开发，这些东西的改动基本上控制在PaaS平台团队手里，他们统一来进行调整，然后开放给不同的国家。
- 那些需要自己配置开发的模块，不同国家因为团队水平不一样，执行出的结果差异很大，还有些国家还迟迟上不了线。
最后的情况是，一部分国家系统上了线，一部分国家也是迟迟上不了线，当然大部分国家的产研团队会将锅让那家PaaS平台公司来背。鉴于这个情况，总部觉得固化很多功能，在这个基础上面满足全球不同国家的需求还是很难，需要更加的灵活化。另外觉得收购的那个团队工程师还是太弱，技术上面响应太慢。因为经费充足，于是又立了一个新项目，招募组建了一个世界顶尖的工程师技术团队，砸了超过10亿美金，去做一个纯粹的PaaS平台，里面没有多少固化的功能，基本上可以基于配置型开发，整个开发出来的页面效果也是非常炫酷。结果是，这个项目做了几年，花了超过十亿美金，然后各个国家基于这个系统去配置开发自己国家的系统，最后似乎没有什么国家的系统成功上线了。如果我们再来复盘一下这个项目，二条路都很难（实际上从来做好的产品从来没有容易走的道路，因为难所以走一条开始看起来容易的路，后面往往是更难）。如果让笔者做选择，笔者觉得第一种方案实际是更好的方案。实际上在平台上面给的空间越小，成功的可能性越大，否则不同团队，能力千差万别，出来的效果肯定很不可控，系统能够越固化的情况下面满足客户的需求，那样成功率会高很多，而且产品的体验会更可控。还有，系统配置型越强，越灵活，交付难度越大，SaaS公司的业务复制型越差。所以如果笔者决策，笔者会选择第一种方案的基础上面可以继续收敛，还需要做更多的标准化，给不同国家团队可以发挥的空间越小，越容易成功。这里面配置型的灵活度把握非常重要，不多不少，恰到好处，说起来容易，实际做起来是非常艰难的。当然，国内只是面向中国地区的不同客户，整体难度要比开发一个全球性的产品来说要简单很多。做SaaS就要努力解决标准化产品的问题，解决定制化的问题。PaaS有PaaS自己的用途，期待PaaS来解决SaaS的标准化问题笔者感觉有点画蛇添足，将问题更加复杂化。
《美国「断供EDA」，究竟怎么一回事？》
《Zendesk：创业，从一个小目标开始》
《ToB世界里没有增长超预期，但一定会有IPO》
《餐饮SaaS头部企业客如云如何走向盈利》
《解码微盟集团2022中报：SaaS收入5.81亿逆势增长，高质量增长路径更清晰》
