为什么要写这个系列，是因为目前的SaaS市场以及产品上面存在很多常见误区，觉得有必要将一些貌似正确的观点拿出来探讨一下，供大家参考，帮助大家减少一些跳坑的可能性，另外也会基于一些市场热点进行简要分析,以短文为主.
今天要说的一个观点就是B端产品配置能力越强越好吗？很多公司吃了定制化的亏，陷入了项目的泥潭里面，于是开始考虑另外一个极端，就是将产品做到尽量灵活，笔者看到的最极致的情况是是，物理的数据库表格以及字段都可以配置，流程搞一个流程配置工具，计算逻辑可以配置或者实施的时候直接用触发器写逻辑。实际上最后看来，这样处理产品的结局都比较一般，主要是会导致如下几个问题：
｜物理的数据库表格以及字段如果固定不下来的话，造成不同用户的数据库版本不一致，后面版本的维护会很困难，产品升级的时候涉及到复杂的数据迁移问题。
｜产品过于灵活，会导致实施的成本变高，特别是一些复杂逻辑的编写，对于实施人员要求很高，会导致实施周期变长，以及实施团队的复制性变差。
｜产品做的非常灵活的一个反面就是，对于每种类型的客户来说产品都不是那么贴身，用户的体验很难做到极致。
想象一下，如果在一个领域里面，比如说CRM，HR，ERP等，有一个特别牛掰的公司做了一个配置能力很强的产品来跨行业的支持大，中，甚至小客户，这个时候出来一个产品只是针对中型客户，或者小型客户，是不是可以做得非常贴身，也不需要那么强的灵活性，这样既可以让用户体验更好，也可以减少实施成本以及提升市场扩展的可复制性，这样的情况一定是可以在市场里面占据一块市场的。这里面引出了二个观点：
·针对通用市场来说，最终的产品形态，针对不同Size的客户，是需要有不同的产品线来对应的。
·通用市场很难一家独大，基于客户Size选择一块区域，或者选择特定垂直行业来进行切入，只要帐算的过来，都是有立足之地的。
好吧，那说一下笔者的结论吧，一个产品的可配置性，灵活度需要控制在什么程度呢？想清楚目标的客户肖像，抽象出来的这个产品模型用最小的灵活度来满足主要的客户是最好的，当然这里肯定涉及到客户的取舍，需求的取舍，啥都想要，产品最后也就不能看了，帐其实也算不过来的。
曾经有人在做薪酬系统的时候问我，我们是要将所有的薪资项目都可以配置计算公式吗？基于这个观点，标准项目尽量固化，另外的尽量通过参数配置，实在不行的再留一点小口支持公式就好了。同样的道理，我们需要一个极致灵活的导入模版吗？我们需要一个极致灵活的权限配置吗？我们需要一个极致灵活的组织架构配置吗？我们需要一个极致的流程配置吗？我们需要一个极致灵活的报表配置工具吗？…….
所以，不要跟我谈PaaS，不看好……..
END
SaaS产品说近期精选文章:
更多文章请长按二维码关注我们，实时了解最新SaaS产品技术深度分析：
网友评论