Charles是我原来的同事，七年前他创办了一家软件公司，在某个细分行业做得风生水起。大约一年半前，他找到我说：做项目的收入增长越来越难，公司开始由盈转亏了。我劝他转型SaaS，他迟迟下不了决心。他担心的是，客户的需求多变，SaaS的标准化，客户可能不会接受，所以转型有风险。所以想再多做些项目，提炼出更多标准功能，先产品化，然后再试着转型SaaS。不久前，他又找到我说要转型SaaS了，后悔当初没有听从我的建议。因为经营困难，公司不得不裁掉大部分员工，现在主要靠维护费维持公司运转。我们在梳理客户业务需求时发现，虽然这段时间做了很多项目，但能提炼出来的共性业务需求没有几个。也就是说，原来设想的从项目到产品的路，根本走不通。（1）项目都是围绕客户各种需求，拼凑成的一个系统。特别是大客户，做的功能可能永远也用不到，但功能全面，是项目验收标准。（2）项目唯一目标，是在合同约定时间内合同交付，至于有用没用那不是乙方要考虑的事。（3）一个项目做完，就再到另一个项目；公司只关注回款，项目成果没人管理。所以，虽然做了很多项目，但是没有获得什么有价值的行业洞见，对于现在转型SaaS没什么帮助。不过，Charles当初的担心也不无道理；实际上，很多人都有同样的担心。即SaaS的“通用性”和客户的“个性化”之间，存在似乎无法解决的矛盾。众所周知，SaaS的最大优势，就是一个版本全球通用。但这也成为SaaS的最大槽点，即不能个性化开发，满足不了客户定制化需求。不过，这只是大部分软件厂商的认知；而对于SaaS行业内来说，并不是这样的。也就是说，这个问题在很大程度上是有解的。先说什么是“标准化”。在这个问题上，一直存在一个误区。业务用户提出的标准化，是指服务标准化，而不是功能的标准化。客户只要求把一个业务问题，解决到什么程度的标准；至于你是用了几个功能、怎么解决的，客户并不关注。换句话说，你的软件工具与客户的业务目标之间，还有个距离。它们不是一回事。再回头看，SaaS是怎么解决“标准化”与“个性化”的矛盾的。首先，依靠后台用户使用行为数据分析，以确定迭代增加哪些业务，弱化甚至去掉哪些。这样可以从对客户最重要的业务入手，然后扩展业务范围和优化客户体验。也就是说，SaaS的迭代升级，并不依赖人工调研和判断，而是由数据驱动的。其次，为了提高迭代响应速度（SaaS迭代频率可以以周或天衡量），SaaS的架构需要有一定的扩展能力，类似零代码扩展。这样可以在交付过程中，定义和配置出客户的个性化业务要求。最后，做时间的朋友。靠着数据驱动的循环迭代，终有一天在一个业务领域，不再有新的属于80%需求提出。实际上，软件做得越久，功能会越来越多，但最终发现被客户采用的却不多。SaaS开始于满足客户关键业务需求，在一个细分领域有较多客户采用；随着数据驱动的迭代，覆盖的业务和服务的领域也开始扩展，客户体验也不断提升。做软件和做SaaS，这两者不但没有什么关联，反而是相向的发展。因此不要期望转型会有个渐变的过程，实际上转变是断层的。随着经济更多的不确定性，很多企业都在减少IT投资预算，XaaS服务的红利也将随之显现。所以，在搞清业务SaaS化和商业化原理的基础上，转型越早越好。
本文来源于网络，如有侵权，请联系删除。
×
