文／明道创始人任向晖
回忆起来，我用过最早的SaaS产品应该是Basecamp。那时候创造它的公司还叫37Signals，打动我的不仅仅是在Web2.0时代开创性的项目管理Web应用，更因为这家公司把敏捷开发的协作模式用软件方法直接传授给了用户，当然也包括我们的团队。37Signals的总部在远离硅谷的芝加哥，在2004年Basecamp面世的时候，整个硅谷还没有从2000年的泡沫破裂中涅槃重生。可以说，后来诞生的绝大多数互联网创业企业的产品研发管理都受到了37Signals的方法论和工具的影响。他们团队所写的Getting Real和Rework也成为商业领域的畅销书。
过了将近十年，这套基于工作列表和内容共享看板的思想才又一次被硅谷的新创公司复制，诞生了Trello，Asana这样的新兴产品。这一代新产品的社交模块和交互体验做得更好，但核心的思想依然来自kanban这一套。可以这么说，如果你使用了Basecamp或者Trello，那么你的团队协作模式也就一定据此确定。
在协作SaaS门类中，市场领导者几乎确立了标准方法，但这个方法也绝非37Signals原创而来。在Basecamp产品诞生之前，已经有先锋性的软件开发群体开始倡导敏捷开发模式，甚至他们也借鉴了制造业的看板管理工具，但Basecamp创造的价值在于它将特定行业的先进运营模式抽象成一个普遍适合的方法，去掉了行业局限，并且将这个流程用软件定义成范式（paradigm）。协作SaaS把项目管理的理念和方法从70年代的时间资源管理控制模式迁移到了协同沟通为核心的新模式上。这也是为什么现代SaaS的项目协作软件几乎都不提供甘特图的原因。
和Basecamp创造和传达的新模式不同，Salesforce在2000年左右推出的销售自动化SaaS基本直接利用了西方企业销售管理当中普遍认可的漏斗模式（Sales Pipeline），它把复杂和多样化的销售过程抽象成“潜在客户到真实客户的转化阶段变化”。依附成交机会的阶段迁移，销售人员通过软件进行记录和分析，从而帮助优化整体转化率和销售资源配置。Salesforce没有原创任何管理模式，但成功地在软件中策展了这项管理知识，而且它的呈现和传统软件，纸面记录非常接近。
当然，后来Salesforce已经延伸到销售漏斗管理以外的领域，甚至通过https://Force.com的开发平台来覆盖各种弹性需求。理论上来说，开发平台可以搭建出任何信息系统，但IT上能够做到的事情，未必就能够直接产生价值，因为任何一种信息系统的设计，要么是某家具体企业的需求指示，要么就来自一种运营模式和方法。所以，你可以看到在Salesforce的AppExchange中，不仅列出基于Salesforce扩展的软件，还包括全世界的顶尖咨询机构。
这样的例子几乎在SaaS软件的每个门类都很普遍。一款SaaS软件在被主流客户接受前，必然需要通过软件来传达出一种管理和运营方法，而这个方法对于用户的价值显然要超过使用一款软件来解决的IT问题。在垂直行业领域内，这样的规律更加明显。如果作为一家饭店，你接入了一款餐饮业SaaS，那么从店铺营销，菜单管理，进货管理到收银财务，你不得不全面接受这套方法的要求。反过来，如果某个饭店希望根据自己过去的运营流程，要求一家软件公司帮它来定制一套软件，那么客户得到的只能是IT价值，但它几乎必然是劣于公共方案的。一家餐饮业SaaS公司如果不能在运营流程上给客户带来明显的效率提升，它绝无可能赢得客户。
软件需要传达运营知识和方法，并不代表软件厂商需要自己去原创这些内容。我也几乎没有看到过软件公司独立创造出企业运营和管理方法的例子。真正有价值的方法一般都来自企业实践，甚至是全行业实践的融合。SAP诞生在德国并不偶然，在1972年创办时，整个德国的先进制造工业已经为软件的定义提供了大量的方法依据。创始人迪特马荷普等人以前是IBM的咨询人员，但他们发现自己的客户正在试图开发非常近似的软件来满足业务流程中的一个共性需求（让工厂财务人员获得实时数据），因此他们意识到应该提供一种标准化的软件工具，并通过它来集成业务流程和实时的数据维护。第一年SAP就凭借这款软件获得了成功。理论上说，SAP软件背后的理念和方法几乎全然来自客户，但是它的软件产品融合了来自客户运营方法和需求的核心，并通过软件的范式传达给了更多企业。利用德国制造管理的先进优势，SAP很快将业务拓展到泛欧和美国市场。北美客户接受的实质并非SAP的软件，而是背后的精益制造管理理念和方法。
既然软件的价值都来自理念和方法，那么新进入SaaS市场的企业还有没有机会呢？企业的运营知识是否已经被各大软件巨头掏空了呢？如果是这样，一个新创的SaaS产品只能拷贝某个标杆产品的理念，做出一个蹩脚或者至多一样好的复制品，这毫无疑问是无法创造价值的。对于中国的SaaS产品来说，我们能否还能够传达不一样，但却有价值的管理理念和方法？
下面几篇文章的内容与这篇文章的内容相似,也许你也会有兴趣:
13 年了，SaaS 公司的 IPO 市场到底是怎样一番景象？
成熟SaaS产品的四个标志
CommandIQ 前 CEO：SaaS正在死亡，”后SaaS世界”会是什么样？
显然，这样的机会并不少。
最为明显的机会存在于各个垂直行业中。正如我前文提到的餐饮业例子，因为营销环境，人力成本的快速变动，今天的餐饮业已经不再是信息技术的被动接受者，而是在主动寻求机遇。除此以外，金融、房地产、医药、教育等主要行业也都充斥着这样的机会。也难怪，在过去的两年中，大多数的SaaS创业都聚集在这个大领域。好在市场足够大，好像大家并不在意激烈的竞争。但谁会胜出呢？当然是看谁能够最快获得行业的标杆客户，那么标杆客户又凭什么选择这家或者那家呢？当然是看软件背后的理念、方法和流程能否帮助客户解决问题。我最近看到酒店和公寓管理领域的产业SaaS已经不满足于帮助客户梳理和运营流程了，甚至他们已经开始通过物联网的整合帮助客户开发新的业务机会，比如通过集成的计费系统帮助增销宽带服务、洗衣服务；通过大数据帮助识别潜在的群租违约行为。这些场景的确没有出现在这个行业过去的运营实践中，是软件开发者和新技术环境催生出来的好东西。
在通用软件领域，这样的机会同样很多，尤其是中小企业市场。这个市场是传统IT服务的真空地带，大多数应用在大企业的运营技术即使被局部引入，但也绝没有一套有效的IT系统来完整支持。CRM是一个典型的需求领域，围绕这个领域创业的SaaS公司非常之多，但迄今还没有一个产品能够结合本土需求，传达出有效的运营方法。有的虽然舶来了销售漏斗理念，但产品本身并没有清晰地呈现这个模型，相反被无厘头的销售外勤打卡（这背后也有一个理念，只是不正确而已）特性所掩盖。
理念的传达也不能是过于概括的原则，即使正确的原则也不能帮助客户有效利用到这个模式。比如我们所在的协作SaaS，一早就鲜明地建立了“围绕任务的扁平协作”理念。大多数客户也都认可这个理念，但和上文提到的正面例子相比，早期的协作SaaS还没有能够传达到具体的运营知识和方法层次，这会让客户无从下手。好在我们正在迎头赶上，在近一年中，国内外的协作SaaS几乎都同时意识到了这个问题，正在做出针对性的产品加强。Teambition，Worktile和我们明道都推出了任务的自定义功能，而且提供了让客户可以开箱即用的行业或职能模版。
这些模版中，除了“产品研发”这个类别来自我们自己的实践，其他的模版大多来自行业实践的融合，而不是我们自己的创造。我们所要做的是设计出高明和可靠的架构，让各种需求都能够被弹性满足，让客户用很低的成本就能够实现自己最想要的运营和协作工具。
所以，一家SaaS软件公司最终会成为一家知识策展机构。它不仅要有设计师和工程师，更要有观察和研究企业运营的专业人员。所谓客户成功部门，不仅仅是自家软件功能的培训师，更是企业运营知识的传播者。这难怪SaaS公司的营销组合中都不会离开内容营销。但内容营销的逻辑并非是做出了软件产品以后，再去找一些关联内容传播，而是在产品设计过程中，就已经亲自策展了这些知识。为了做好这个行当，我个人搜集了硅谷大概100家顶尖SaaS企业出品的电子书，这些电子书不仅仅让我了解到了一个好产品，也让我学到了很多运营的方法和技巧。我把其中几十本允许转载的加入到一个共享文件夹，你可以从中选择自己感兴趣的，看看我说的理念和知识到底长什么样。
